EBS与实例存储的优点(反之亦然)

小开

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

这是为什么

可以设置EBS支持的实例，这样它们就不会(意外地)通过API终止。
EBS支持的实例可以在您不使用它们时停止，并在您再次需要它们时恢复(例如暂停虚拟PC)，至少我的使用模式节省了比我在几十GB的EBS存储上花费更多的钱。
EBS支持的实例在崩溃时不会丢失实例存储(不是所有用户都需要，但可以使恢复更快)
您可以动态地调整EBS实例存储的大小。
您可以将EBS实例存储转移到一个全新的实例(如果您正在运行的Amazon上的硬件出现故障或死亡(这种情况时常发生)，则非常有用)
启动EBS支持的实例更快，因为不需要从S3获取映像。
如果ebs支持的实例的硬件是计划维护，停止和启动实例会自动迁移到新的硬件。我还能够通过强制停止实例并重新启动它来将ebs支持的实例移动到故障硬件上(您的性能可能因故障硬件而异)。

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

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

请记住，任何基于云的基础设施都可能在任何时候发生故障。相应地规划您的基础设施。虽然与临时存储实例相比，ebs支持的实例提供了一定程度的持久性，但它们可能并且确实会失败。拥有一个AMI，可以根据需要在任何可用分区中启动新实例，备份重要数据(例如数据库)，如果预算允许，还可以运行多个服务器实例以实现负载平衡和冗余(理想情况下是在多个可用分区中)。

什么时候不做

在某些时候，在实例存储实例上实现更快的IO可能更便宜。曾经有一段时间，这当然是真的。现在有许多EBS存储选项，可以满足多种需求。期权及其定价随着技术的变化而不断变化。如果您有大量真正可丢弃的实例(即使它们消失了，也不会对您的业务产生太大影响)，请计算一下成本与性能。EBS支持的实例也可能在任何时间点消失，但我的实际经验是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实例)共享的。

你得到的实例越大，它得到的更好的当然就越大。这里Better指的是内部原因。

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

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

小开

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

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

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

小开

埃里克几乎做到了。我们(Bitnami这样)是一家为流行应用程序和开发框架(PHP, Joomla, Drupal，你懂的)提供免费ami的流行提供商。我可以告诉您，ebs支持的ami明显比s3支持的ami更受欢迎。一般来说，我认为s3支持的实例用于分布式的、有时间限制的作业(例如，大规模的数据处理)，如果一台机器出现故障，另一台机器就会启动。ebs支持的AMIS倾向于用于“传统的”服务器任务，例如web或数据库服务器，它们将状态保存在本地，因此在崩溃的情况下需要数据可用。

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

小开

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

小开

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

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

我特别强调。

我做更多的数据分析比虚拟主机，所以持久性对我来说并不重要，因为它可能是一个网站。考虑到亚马逊自身的区别，我不会认为EBS适合所有人。

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

小开

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

实例存储是无状态的，在任何实例失败的情况下，您将丢失其中的所有数据。但是，由于实例卷绑定到虚拟机运行的物理服务器上，因此它是免费的，而且速度更快。

小开

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

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

实例存储为:

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

以下是使用它们的地方:

使用EBS作为备份操作系统分区和永久存储(DB数据、关键日志、应用程序配置)
将实例存储用于进程内数据、非关键日志和瞬时应用程序状态。例如:外部排序存储，tempfile等。
实例存储还可以用于性能关键型数据，如果实例之间存在复制(NoSQL数据库、分布式队列/消息系统和具有复制功能的数据库)
将S3用于系统间共享的数据:输入数据集和处理结果，或用于启动时每个系统使用的静态数据。
将ami用于预烘焙的、可启动的服务器

小开

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

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

此外，在官方文档中有一个很好的解释EBS和实例存储之间的差异

,这张图很好地概括了这一点

小开

如果你运行多个实例，并在避免意外费用上分配一个AWS实例的预定服务作为你的优先级之一，我会推荐不使用实例存储。

如文档解释EBS 卷 < / > 和j2d3和哈斯。沙玛的答案实例存储可以运行多长时间就可以运行多长时间，但是不能 < / >强停了下来。表示服务不能被自动 Start/Stop或实例复苏< / > . 

此外，对于这种方案，在弹性豆茎 .上使用EBS已支持 .也没有好处，因为它的设计是为了确保你需要的所有资源都是保持运行。它总是会自动重新启动你停止的任何服务。回顾所有其他的，在使用添加到EC2-Classic的VPC、EBS和ELB的总费用中，EC2-VPC with ELB基本上是最好的选择，与EC2-Classic不同，一个停止的实例保留与其关联的弹性IP地址和EBS卷自动为存储
作为结论，取你问题的主要部分:

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

答案是对，但如果你的实例是基于ebs的，它可以被停止。它将保留在您的帐户你不会为此收费的中。你将只收取体积，但EBS按小时收费。你也可以考虑在所有可用的类型中，你可以灵活地使用调整EBS卷的大小。

除了埃里克 已经列出的好处，它还应该意识到，在成本方面S3可能比EBS便宜，也可能不便宜。我同意，如果你一直在相同的平台和应用程序架构中运行两种类型的实例，成本差异相对较小。

然而，如果有一个场景是在一个更低成本的服务上运行应用程序，拉出所有未处理的任务和他们的角色通过管道< a href = " https://stackoverflow.com/a/38250144/4058484 " > < / >或< a href = " https://stackoverflow.com/a/38371889/4058484 " >λ< / >在短时间内运行到VPC/EBS，比如每天1小时，当你使用实例存储时，这是不可能的，那么情况就不同了。