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

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

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

我特别强调。

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

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

Eric pretty much nailed it. We (Bitnami) are a popular provider of free AMIs for popular applications and development frameworks (PHP, Joomla, Drupal, you get the idea). I can tell you that EBS-backed AMIs are significantly more popular than S3-backed. In general I think s3-backed instances are used for distributed, time-limited jobs (for example, large scale processing of data) where if one machine fails, another one is simply spinned up. EBS-backed AMIS tend to be used for 'traditional' server tasks, such as web or database servers that keep state locally and thus require the data to be available in the case of crashing.

我没有提到的一个方面是，您可以在运行时对ebs支持的实例进行快照，这有效地允许您对基础设施进行非常经济的备份(快照是基于块的和增量的)

如果您运行多个实例，并将AWS实例的预定服务分配为避免意外收费的优先级之一，我建议不要使用实例存储。

正如EBS文档中解释的那样 卷 j2d3和Siddharth Sharma的答案 实例存储可以运行多长时间就可以运行多长时间，但它不能 停止了。表示服务不能由自动调度程序调度 启动/停止或实例 复苏。

Moreover, for this kind of scheme there is also no benefit to use EBS Backed on Elastic Beanstalk as it is designed to ensure that all the resources you need are keep running. It will always do an automatically relaunches any services that you stop. Reviewing all the rest, out of the total charges on using the VPC, EBS and ELB that added to EC2-Classic, the EC2-VPC with ELB is mostly the best choice where unlike on EC2-Classic, a stopped instance retains its associated Elastic IP addresses and the EBS volume is stored automatically.

作为结论，以你问题的主要部分为例:

似乎EBS更有用(停止，启动，坚持+更好 速度)成本差异相对较小…?

答案是肯定的，但如果您的实例是基于ebs的，则可以停止它。这笔钱会留在您的账户上，不收取任何费用。您将只收取容量，但EBS是按小时收费的。您还可以考虑，在所有可用类型中，您可以灵活地调整EBS卷的大小。

除了Eric已经列出的好处之外，还应该意识到，就成本而言，S3可能比EBS便宜，也可能不便宜。我同意，如果你一直在同一个平台和应用程序的架构中运行这两种类型的实例，成本上的差异相对较小。

然而，如果在一个低成本的服务上运行应用程序，在短时间内(比如每天1小时以内)通过管道或lambda将所有未处理的任务和角色拉到VPC/EBS中，这在使用实例存储时是不可能做到的，那么情况就不同了。

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

底线是您应该几乎总是使用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.