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。

EBS就像虚拟机的虚拟磁盘:

持久，由EBS支持的实例可以自由启动和停止(节省资金) 可以在任何时间点进行快照，以获得时间点备份吗 可以从EBS快照创建ami，因此EBS卷成为新系统的模板

实例存储为:

本地的，所以通常比较快 非联网，在正常情况下，EBS I/O是以网络带宽为代价的(EBS优化实例除外，它们具有独立的EBS带宽) 每秒I/O IOPS有限。即使配置的I/O最大IOPS也只有几千 脆弱的。一旦实例停止，就会丢失实例存储中的所有内容。

以下是使用它们的地方:

Use EBS for the backing OS partition and permanent storage (DB data, critical logs, application config) Use instance storage for in-process data, noncritical logs, and transient application state. Example: external sort storage, tempfiles, etc. Instance storage can also be used for performance-critical data, when there's replication between instances (NoSQL DBs, distributed queue/message systems, and DBs with replication) Use S3 for data shared between systems: input dataset and processed results, or for static data used by each system when lauched. Use AMIs for prebaked, launchable servers

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

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

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

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

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

我特别强调。

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

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

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。

底线是您应该几乎总是使用EBS支持的实例。

这是为什么

EBS backed instances can be set so that they cannot be (accidentally) terminated through the API. EBS backed instances can be stopped when you're not using them and resumed when you need them again (like pausing a Virtual PC), at least with my usage patterns saving much more money than I spend on a few dozen GB of EBS storage. EBS backed instances don't lose their instance storage when they crash (not a requirement for all users, but makes recovery much faster) You can dynamically resize EBS instance storage. You can transfer the EBS instance storage to a brand new instance (useful if the hardware at Amazon you were running on gets flaky or dies, which does happen from time to time) It is faster to launch an EBS backed instance because the image does not have to be fetched from S3. If the hardware your EBS-backed instance is scheduled for maintenance, stopping and starting the instance automatically migrates to new hardware. I was also able to move an EBS-backed instance on failed hardware by force-stopping the instance and launching it again (your mileage may vary on failed hardware).

我是Amazon的忠实用户，在技术beta版一出来，我就把所有实例都切换到EBS支持的存储。我对结果非常满意。

EBS仍然可能失败——这不是一颗银弹

Keep in mind that any piece of cloud-based infrastructure can fail at any time. Plan your infrastructure accordingly. While EBS-backed instances provide certain level of durability compared to ephemeral storage instances, they can and do fail. Have an AMI from which you can launch new instances as needed in any availability zone, back up your important data (e.g. databases), and if your budget allows it, run multiple instances of servers for load balancing and redundancy (ideally in multiple availability zones).

什么时候不做

At some points in time, it may be cheaper to achieve faster IO on Instance Store instances. There was a time when it was certainly true. Now there are many options for EBS storage, catering to many needs. The options and their pricing evolve constantly as technology changes. If you have a significant amount of instances that are truly disposable (they don't affect your business much if they just go away), do the math on cost vs. performance. EBS-backed instances can also die at any point in time, but my practical experience is that EBS is more durable.