EBS与实例存储的相对优势（反之亦然）[关闭]

对于在Amazon EC2上的实例，我从EBS相对于实例存储可以获得什么好处，目前尚不清楚。如果有的话，EBS似乎在成本差异相对较小的情况下更有用（停止，启动，持续+更好的速度）...？此外，考虑到EBS还是相对较新，是否有任何指标可以衡量现在是否有更多人正在使用EBS？

最重要的是，您几乎应该始终使用EBS支持的实例。

这就是为什么

• 可以设置EBS支持的实例，以使它们不能（偶然）通过API终止。
• 当您不使用EBS支持的实例时，可以停止它们，而在再次需要它们时可以将其恢复（例如暂停Virtual PC），至少由于我的使用模式比在几十GB的EBS存储上花费的钱要多得多。
• EBS支持的实例在崩溃时不会丢失其实例存储（不是所有用户的要求，但可使恢复速度更快）
• 您可以动态调整EBS实例存储的大小。
• 您可以将EBS实例存储转移到一个全新的实例（如果您所运行的Amazon上的硬件不稳定或死掉，这种情况有时会发生，则很有用）
• 启动EBS支持的实例的速度更快，因为不必从S3提取映像。
• 如果计划维护您的EBS支持的实例的硬件，则停止和启动该实例会自动迁移到新硬件。通过强制停止实例并再次启动它，我还能够在故障硬件上移动由EBS支持的实例（您的里程可能因故障硬件而异）。

我是Amazon的重度用户，一旦该技术退出Beta版，我便将所有实例切换到EBS支持的存储。我对结果感到非常满意。

EBS仍然可能失败-不是灵丹妙药

请记住，任何基于云的基础架构都可能随时发生故障。相应地计划您的基础架构。尽管与临时存储实例相比，由EBS支持的实例提供了一定程度的持久性，但它们可能并且确实会失败。拥有一个AMI，您可以从该AMI在任何可用区域中根据需要启动新实例，备份重要数据（例如数据库），如果预算允许，请运行多个服务器实例以实现负载平衡和冗余（最好在多个可用区域中） ）。

什么时候不去

在某些时候，在实例存储实例上实现更快的IO可能会更便宜。曾经有一段时间确实如此。现在，有许多EBS存储选项，可以满足许多需求。期权及其定价随着技术的变化而不断发展。如果您有大量的实例是真正可丢弃的（如果它们只是消失了，它们对您的业务影响不大），请对成本与性能进行数学计算。由EBS支持的实例也可以在任何时间点消失，但是我的实际经验是EBS更持久。

我们99％的AWS设置都是可回收的。因此对我来说，终止实例并不重要-永远不会丢失任何东西。例如，我的应用程序自动从SVN部署在实例上，我们的日志被写入中央syslog服务器。

我看到实例存储的唯一好处是节省了成本。否则，由EBS支持的实例将获胜。埃里克（Eric）提到了所有优点。

[2012-07-16]今天我会说这个答案有很大的不同。

在过去的一年左右的时间里，我对EBS支持的实例没有任何良好的经验。AWS的上一次停机时间也严重破坏了EBS。

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

摆脱扩展，将数据库集群移回铁（即实际硬件）。基础架构中唯一剩下的部分是数据库服务器，我们在其中将多个EBS卷分拆到软件RAID中，每天备份两次。无论在两次备份之间会丢失什么，我们都可以忍受。

EBS是一种易用的技术，因为它本质上是网络卷：从远程连接到服务器的卷。我并不是要否定使用它所做的工作–这是一个了不起的产品，因为本质上无限的持久性存储仅需调用API。但是，它几乎不适用于I / O性能至关重要的情况。

除了网络存储的行为方式之外，所有网络都在EC2实例上共享。实例越小（例如t1.micro，m1.small），情况就越糟，因为实际主机系统上的网络接口在运行在其上的多个VM（= EC2实例）之间共享。

您获得的实例越大，当然它就越好。在这里更好意味着在合理范围内。

当需要持久性时，我总是会建议人们使用S3之类的东西来在实例之间集中化。S3是一项非常稳定的服务。然后将实例设置自动化到可以启动新服务器并自行准备就绪的地步。这样就不需要拥有比实例更长寿命的网络存储。

因此，总的来说，我仍然认为EBS支持的实例没有任何好处。我宁愿花一点时间进行引导，然后使用潜在的SPOF运行。

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

埃里克几乎钉牢了它。我们（Bitnami）是流行的免费AMI提供商，可为流行的应用程序和开发框架（PHP，Joomla，Drupal，您明白了）。我可以告诉您，EBS支持的AMI比S3支持的AMI更为流行。通常，我认为s3支持的实例用于分布式的，有时间限制的作业（例如，大规模处理数据），如果其中一台机器发生故障，那么另一台机器就会被启动。由EBS支持的AMIS往往用于“传统”服务器任务，例如在本地保持状态的Web或数据库服务器，因此在崩溃时要求数据可用。

我没有提到的一个方面是，您可以在运行时为EBS支持的实例拍摄快照，从而有效地为您的基础结构提供了非常经济高效的备份（快照是基于块的和增量的）。

我在上一个职位上与Eric的经历完全相同。现在，在我的新工作中，我将按照与上一份工作相同的过程进行操作...为EBS支持的实例重建它们的所有AMI-可能会重建为32位计算机（更便宜-但不能在32位和32位上使用相同的AMI） 64台机器）。

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

这种动态自动扩展就是AWS的全部功能-IT基础设施的真正节省可以发挥作用。用旧的s3“ InstanceStore”支持的实例进行自动缩放几乎是不可能的。

我只是自己开始使用EC2，因此不是专家，但是Amazon自己的文档说：

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

强调我的。

我进行的数据分析比网站托管更多，因此持久性对我来说并不重要，对于网站而言。考虑到亚马逊本身的区别，我不会认为EBS适合每个人。

我会在使用完两次后再次尝试称重。

EBS就像VM的虚拟磁盘：

• 耐用，由EBS支持的实例可以自由启动和停止（省钱）
• 可以在任何时间点进行快照，以获取时间点备份
• 可以从EBS快照创建AMI，因此EBS卷成为新系统的模板

实例存储为：

• 本地的，所以通常更快
• 非网络，在正常情况下，EBS I / O是以网络带宽为代价的（除了EBS优化的实例，它们具有单独的EBS带宽）
• 每秒的I / O IOPS受到限制。甚至配置的I / O最高可达到数千IOPS
• 脆弱。一旦实例停止，您将丢失实例存储中的所有内容。

这是每个使用位置：

• 将EBS用于后备OS分区和永久存储（数据库数据，关键日志，应用程序配置）
• 将实例存储用于进程中数据，非关键日志和临时应用程序状态。示例：外部排序存储，临时文件等
• 当实例之间进行复制（NoSQL数据库，分布式队列/消息系统以及具有复制功能的数据库）时，实例存储还可以用于对性能至关重要的数据
• 将S3用于系统之间共享的数据：输入数据集和处理的结果，或用于启动时每个系统使用的静态数据。
• 将AMI用于预烘焙的可启动服务器

大多数人选择使用EBS支持的实例，因为它是有状态的。这样做比较安全，因为您在其中运行和安装的所有内容都将在停止/停止或任何实例故障后幸免。

实例存储是无状态的，如果发生任何实例故障情况，您会将其内部的所有数据都丢失。但是，它是免费且更快的，因为实例卷与运行VM的物理服务器相关联。

对于所有这一切的新手，如果不小心落在这里

截至目前，快速入门部分中的所有AMI均支持EBS

另外，官方文档中对EBS和实例存储之间的区别也有很好的解释

和这个图像几乎总结了一下

如果您运行多个实例并将AWS Instance的计划服务分配为避免意外费用的优先事项之一，则建议不要使用instance-store。

如EBS Volumes文档中的解释 以及j2d3和Siddharth Sharma的回答中所述，实例存储可以运行任意长时间，但不能停止。表示无法通过“ 自动启动/停止”或“ 实例恢复”来调度服务。

此外，对于这种方案，在Elastic Beanstalk上使用EBS Backed也没有任何好处，因为它旨在确保所需的所有资源保持运行。它将始终自动重新启动您停止的所有服务。 回顾所有其余部分，在使用添加到EC2-Classic的VPC，EBS和ELB的总费用中，带有ELB的EC2-VPC通常是最佳选择，与EC2-Classic不同，已停止的实例保留其关联的Elastic IP地址EBS量将自动存储。

作为结论，请考虑问题的主要部分：

似乎EBS在成本差异相对较小的情况下更有用（停止，启动，持续和更好的速度）...？

答案是肯定的，但是如果您的实例基于EBS，则可以将其停止。它会保留在您的帐户中，不会向您收费。您将只收取音量，但EBS每小时收费。您可能还认为，在所有可用类型中，您都可以灵活地调整EBS卷的大小。

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

但是，如果存在在较低成本的服务上运行该应用程序的方案，请在短时间内将所有未处理的任务拉出，并通过管道或lambda将它们分配给VPC / EBS，例如每天少于1个小时，这在您执行此操作时是不可能的。使用实例存储，那将是另一回事。