我有一个基于EBS的Amazon EC2实例（ m4.xlarge ）启动并运行。 这个example已经被使用了一段时间，并且处于我们希望在未来所有情况下都能够拥有的状态。 以下两种方法中的哪一种更具成本效益？
快照：创buildexample的快照。 然后每次需要新实例时，从快照中创build一个新卷并将其附加到实例。
AMI：从example创build一个图像。 这个图像有一切需要，所以不要从这个图像中旋转新的实例。
从长远来看，哪一个会是更好的成本效益战略？ 这两种方法之间的任何影响？ 还有其他方法可以达到同样的目标吗？
这个问题的前提是信息不完整。
AMI由一个或多个快照组成 – 与其他快照完全相同 – 加上几个字节的元数据。 没有关于存储我知道的元数据的费用的文档。 如果是计费的话，这将是一个小小的费用，不被忽视。
如果你要创build新的实例，你必须从AMI开始。 没有一个你不能创build一个实例。 启动实例时，即使AMI正好是基本操作系统安装的AMI，也总是selectAMI。
因此，对于成本来说，没有什么意义的区别，而对于AMI来说，至less对于基于快照的configuration来说，没有什么有意义的select。 我的意思是，当然可以将压缩的tarball或原始磁盘映像存储在您自己的文件中，然后将它们提取到磁盘上，但这些都不太实际。
许多人会认为，在云环境中，一个优秀的快照/基于映像的configuration方法是使用Ansible这样的工具从基本操作系统安装开始自动configuration您的机器，并最终生成一个具有所有依赖关系的工作系统代码就绪 – 允许您的configuration作为一组可重复的步骤存在，您可以在版本控制中进行pipe理。
当然，“自动”听起来像是魔法。 我们不是在谈论魔法，我们正在谈论自动化执行一组预定的步骤，这些步骤已经过testing并且已知可以正常工作并产生所需的结果。
在前面，做所有的设置和testing可能是更多的工作，但在长尾巴，这个想法是，它是一个更平稳的骑，因为你确切知道你的系统应该如何得到他们应该的方式是。
我的意图不是在这个答案中认可这是优越的，而是作为一个来自旧学校的老狗，这个新的诀窍正在增长。