我自己刚开始使用EC2，所以不是专家，但亚马逊自己的文档说:

我们建议您将本地实例存储用于临时数据，对于需要较高持久性的数据，我们建议使用Amazon EBS卷或将数据备份到Amazon S3。

我特别强调。

我做的数据分析比虚拟主机多，所以持久性对我来说不像对网站那么重要。考虑到亚马逊自身的区别，我不会认为EBS适合所有人。

在我用完这两种方法后，我会试着再次称重。

我在上一份工作中有和埃里克完全一样的经历。现在在我的新工作中，我正在经历我在上一份工作中经历过的同样的过程……为EBS支持的实例重新构建所有AMI——可能是32位机器(更便宜——但不能在32和64机器上使用相同的AMI)。

EBS支持的实例启动足够快，您可以开始使用Amazon AutoScaling API，该API允许您使用CloudWatch指标来触发其他实例的启动，并将它们注册到ELB(弹性负载均衡器)，还可以在不再需要时关闭它们。

这种动态自动伸缩就是AWS的意义所在——IT基础设施的真正节省可以发挥作用。用旧的s3“instanceore”支持的实例来实现自动伸缩几乎是不可能的。

99%的AWS设置是可回收的。所以对我来说，如果我终止一个实例并不重要——什么都不会丢失。例如，我的应用程序自动部署在SVN的实例上，我们的日志被写入中央syslog服务器。

我认为实例存储的唯一好处是节省成本。否则，ebs支持的实例胜出。埃里克提到了所有的好处。

今天，我会用不同的措辞来回答这个问题。

在过去一年左右的时间里，我在使用ebs支持的实例方面没有什么好的经验。AWS的最后一次停机也几乎破坏了EBS。

我猜像RDS这样的服务也使用某种EBS，这似乎在大多数情况下都是可行的。在我们自己管理的情况下，我们已经尽可能地摆脱了EBS。

摆脱一个扩展，我们移动了一个数据库集群回铁(=真实硬件)。我们的基础设施中仅剩下一个DB服务器，我们将多个EBS卷分条到一个软件RAID中，并每天进行两次备份。不管在备份之间会损失多少，我们都可以接受。

EBS是一种有点不可靠的技术，因为它本质上是一个网络卷:从远程连接到服务器的卷。我并不是在否定使用它所做的工作——这是一个了不起的产品，因为从本质上讲，无限持久存储只是一个API调用。但是它几乎不适合I/O性能是关键的场景。

除了网络存储的行为方式外，所有网络都在EC2实例上共享。实例越小(例如t1。micro, m1.small)会变得更糟糕，因为您在实际主机系统上的网络接口是由运行在其上的多个虚拟机(=您的EC2实例)共享的。

当然，实例越大，效果就越好。这里更好的意思是在合理范围内。

当需要持久性时，我总是建议人们使用S3之类的东西来集中实例。S3是一个非常稳定的服务。然后将实例设置自动化到可以引导新服务器并自行准备就绪的程度。这样就没有必要使用比实例存活时间更长的网络存储。

因此，总而言之，我认为ebs支持的实例没有任何好处。我宁愿增加一分钟的引导，然后运行一个潜在的SPOF。

我自己刚开始使用EC2，所以不是专家，但亚马逊自己的文档说:

我们建议您将本地实例存储用于临时数据，对于需要较高持久性的数据，我们建议使用Amazon EBS卷或将数据备份到Amazon S3。

我特别强调。

我做的数据分析比虚拟主机多，所以持久性对我来说不像对网站那么重要。考虑到亚马逊自身的区别，我不会认为EBS适合所有人。

在我用完这两种方法后，我会试着再次称重。

我们喜欢实例存储。它迫使我们使实例完全可回收，并且我们可以轻松地在给定AMI上从头构建服务器的过程自动化。这也意味着我们可以很容易地交换ami。此外，EBS仍然时不时地存在性能问题。

对于一个刚接触这一切的人，如果不小心降落在这里

到目前为止，快速入门部分的所有AMI都是EBS支持的

另外，在官方文档中有一个很好的解释，说明了EBS和实例存储之间的区别

&这张图片几乎总结了它