我不清楚我在Amazon EC2上为我的实例从EBS和实例存储中获得了什么好处 . 如果有的话，似乎EBS在成本相对较小的差异方面更有用（停止，开始，持续更好的速度）......？此外，是否有更多人正在使用EBS，因为它仍然相对较新？
最重要的是你应该几乎总是使用EBS支持的实例 .
Here's why
可以设置EBS支持的实例，以便它们不会（意外地）通过API终止 .
EBS支持的实例可以在您不使用它们时停止，并在您再次需要时恢复（如暂停虚拟PC），至少我的使用模式比在几十GB的EBS存储上花费更多的钱 .
EBS支持的实例在崩溃时不会丢失实例存储（不是对所有用户的要求，而是使恢复更快）
您可以动态调整EBS实例存储的大小 .
您可以将EBS实例存储转移到一个全新的实例（如果您运行的亚马逊上的硬件变得不稳定或死亡，这种情况很有用）
启动EBS支持的实例更快，因为不必从S3获取图像 .
如果您的EBS支持的实例的硬件是scheduled for maintenance，则停止并启动实例会自动迁移到新硬件 . 我还能够通过强制停止实例并再次启动它来在故障硬件上移动EBS支持的实例（您的里程可能因故障硬件而异） .
我是亚马逊的重度用户，一旦技术出现测试版，就将我的所有实例转换为EBS支持的存储 . 我对结果非常满意 .
EBS can still fail - not a silver bullet
请记住，任何基于 Cloud 的基础架构都可能随时出现故障 . 相应地规划基础架构 . 虽然与临时存储实例相比，EBS支持的实例提供了一定程度的持久性，但它们可以并且确实失败了 . 有一个AMI，您可以根据需要在任何可用区域中启动新实例，备份您的重要数据（例如数据库），如果您的预算允许，运行多个服务器实例以实现负载 balancer 和冗余（理想情况下在多个可用区域中） ） .
When Not To
在某些时间点，在Instance Store实例上实现更快的IO可能更便宜 . 曾经有一段时间它确实是真的 . 现在有许多EBS存储选项，可满足许多需求 . 随着技术的变化，选项及其定价也在不断变化 . 如果您有大量真实可丢弃的实例（如果它们刚刚消失，它们对您的业务影响不大），请对成本与性能进行比较 . EBS支持的实例也可能在任何时间点死亡，但我的实际经验是EBS更耐用 .
99％的AWS设置都是可回收的 . 所以对我来说，如果我终止一个实例并不重要 - 永远不会丢失任何东西 . 例如 . 我的应用程序自动部署在SVN的实例上，我们的日志被写入中央系统日志服务器 .
我看到的实例存储的唯一好处是节省成本 . 否则EBS支持的实例获胜 . 埃里克提到了所有的优点 .
[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支持的实例没有任何好处 . 我宁愿添加一分钟到bootstrap，然后运行潜在的SPOF .
我们喜欢实例店 . 它迫使我们使我们的实例完全可循环使用，并且我们可以轻松地自动化在给定AMI上从头开始构建服务器的过程 . 这也意味着我们可以轻松换掉AMI . 此外，EBS仍然不时出现性能问题 .
埃里克几乎把它钉了起来 . 我们（Bitnami）是流行的应用程序和开发框架的免费AMI的流行提供商（PHP，Joomla，Drupal，你明白了） . 我可以告诉你，EBS支持的AMI比S3支持的更受欢迎 . 一般来说，我认为s3支持的实例用于分布式，限时工作（例如，大规模数据处理），如果一台机器发生故障，另一台机器就会被简化 . EBS支持的AMIS倾向于用于'traditional'服务器任务，例如在本地保持状态的Web或数据库服务器，因此在崩溃的情况下需要数据可用 .
我没有看到提到的一个方面是，您可以在运行时拍摄EBS支持的实例的快照，从而有效地允许您对基础架构进行非常经济高效的备份（快照是基于块的和增量的）
我在上一个职位上和Eric有着完全相同的经历 . 现在，在我的新工作中，我将完成我在上一份工作中执行的相同流程...为EBS支持的实例重建所有AMI - 可能还有32位机器（更便宜 - 但不能在32和32上使用相同的AMI） 64台机器） .
EBS支持的实例启动速度足够快，您可以开始使用Amazon AutoScaling API，它允许您使用CloudWatch指标触发其他实例的启动并将它们注册到ELB（Elastic Load Balancer），并在不再使用时关闭它们需要 .
这种动态自动扩展就是AWS所关注的 - IT基础架构的真正节省可以发挥作用 . 使用旧的s3“InstanceStore”支持的实例进行自动缩放几乎是不可能的 .
EC2“硬件”
启动EC2实例时，将保留一个虚拟机以供该实例运行 . 该虚拟机具有特定的规格，具体取决于实例类型：32位或64位CPU，虚拟核心数，硬盘大小等 . 有关实例规范的详细信息，请参见http://aws.amazon.com/ec2/#instance .
当您的EC2实例处于“运行”状态时，这意味着它正在虚拟机上运行，这就是您需要付费的 .
虚拟机的硬盘被认为是“短暂的” . 术语“短暂的”来自希腊语“ephemeros”，意思是“仅持续一天” . 这种硬盘上的任何东西都应该被视为暂时的 . 除非数据从硬盘驱动器复制，否则如果虚拟机停止，则数据将丢失 . 这包括数据，软件，甚至是驻留在这些硬盘驱动器上的操作系统 .
Amazon Web Services为EC2实例提供两种类型的根设备：“EBS支持”和“实例存储” .
“实例存储”实例
“实例存储”实例是其根设备驻留在虚拟机的硬盘驱动器上的EC2实例 . 创建实例时，基本AMI将复制到虚拟机的硬盘驱动器并启动 . 该实例可以根据需要运行，但不能停止 . 由于实例的根设备是实际的硬盘驱动器，因此它“卡在”硬件上，您唯一能做的就是终止实例 . 如果执行此操作，将删除该实例，永远不会恢复 . 您还冒着这样的风险：如果虚拟机的硬件出现故障，那么您也将丢失硬盘驱动器上的任何内容 .
如果您启动“实例存储”实例，请准备好让它保持运行，直到您完成它为止 . 请注意，从实例启动到关闭实例，您将收取费用 .
“EBS支持的”实例
“EBS支持的”实例是EC2实例，它使用EBS卷作为其根设备 . EBS卷是冗余的“虚拟”驱动器，它们与任何特定硬件无关，但它们仅限于特定的EC2可用区 . 这意味着EBS卷可以在同一可用区内从一个硬件移动到另一个硬件 . 您可以将EBS卷视为一种网络附加存储 .
如果虚拟机的硬件出现故障，则可以将EBS卷简单地移动到另一个虚拟机并重新启动 . 从理论上讲，您不会丢失任何数据 .
另一个好处是，可以轻松备份和复制EBS卷 . 因此，您可以轻松备份卷的快照，创建新卷并根据这些重复卷启动新的EC2实例 .
可能“EBS支持的”实例的最大优势在于“实例存储”实例是他们可以被阻止 . 执行此操作时，将关闭虚拟机并存储EBS卷以供以后检索 . 然后，硬件可供其他人使用 . 此外，在此期间，您不会向EC2实例收取运费 . 但是您需要为EBS存储付费 . 当您希望实例再次运行时，您只需再次启动它 . 保留一个新虚拟机，连接您的EBS卷，然后启动您的实例 .
但虚拟机的硬盘怎么样？
是的，即使您的EC2实例是“EBS支持的”，也可以使用这些硬盘驱动器 . 默认情况下，它们不可用 . 如果使用命令行程序启动实例，则可以使用ec2-run-instances命令中的“-b”选项将“实例存储”驱动器附加到EC2实例 .
如果要存储临时数据，将这些驱动器提供可能是有益的 . 读取和写入访问应该比读取和写入EBS卷更快，因为您不是通过网络发送数据 . 此外，您不需要为数据传输或数据存储付费 . 但这仅在数据可能随时丢失时才有效 .
资料来源：https://skeddly.desk.com/customer/portal/articles/1346918-ebs-backed-versus-instance-store
我刚开始使用EC2，所以不是专家，但Amazon's own documentation说：
我们建议您将本地实例存储用于临时数据，对于需要更高级别持久性的数据，我们建议使用Amazon EBS卷或将数据备份到Amazon S3 .
强调我的 .
我做的比网络托管更多data analysis，所以持久性并不认为EBS适合所有人 .
在我使用两者之后，我会记得再次称重 .
EBS就像VM的虚拟磁盘：
耐用，EBS支持的实例可以自由启动和停止（省钱）
可以在任何时间点进行快照，以获得时间点备份
可以从EBS快照创建AMI，因此EBS卷成为新系统的模板
实例存储是：
本地，所以通常更快
非联网，在正常情况下，EBS I / O以网络带宽为代价（EBS优化实例除外，它具有单独的EBS带宽）
每秒IOPS的I / O有限 . 即使配置的I / O最高也只有几千IOPS
脆弱 . 实例停止后，您将丢失实例存储中的所有内容 .
使用EBS作为后备操作系统分区和永久存储（数据库数据，关键日志，应用程序配置）
将实例存储用于进程内数据，非关键日志和瞬态应用程序状态 . 示例：外部排序存储，临时文件等
当实例之间存在复制时，实例存储也可用于性能关键数据（NoSQL DB，分布式队列/消息系统和带复制的DB）
对系统之间共享的数据使用S3：输入数据集和处理结果，或者每个系统在运行时使用的静态数据 .
将AMI用于预烘焙的可启动服务器
大多数人选择使用EBS支持的实例，因为它是有状态的 . 它更安全，因为您在其中运行和安装的所有内容都将在停止/停止或任何实例故障后继续存在 .
实例存储是无状态的，如果出现任何实例故障情况，您将使用内部的所有数据将其丢失 . 但是，它是免费且更快的，因为实例卷与运行VM的物理服务器相关联 .
对于所有这一切的新手，如果不小心落在这里
截至目前，所有AMI的快速入门部分均为EBS支持
对于EBS和Instance商店之间的区别，official doc也有一个很好的解释
＆这个图像几乎总结了
如果您运行多个实例并将AWS实例的计划服务指定为Avoiding Unexpected Charges的优先级之一，我建议不要使用实例存储 .
正如EBS卷的文档以及j2d3和Siddharth Sharma的答案所解释的那样，实例存储可以运行多长时间，但无法停止 . 表示无法通过自动启动/停止或实例恢复来调度服务 .
此外，对于这种方案，在Elastic Beanstalk上使用EBS Backed也没有任何好处，因为它旨在确保您需要的所有资源都是keep running . 它将始终自动重新启动您停止的任何服务 . 回顾all the rest，在使用添加到EC2-Classic的VPC，EBS和ELB的总费用中，带有ELB的EC2-VPC大多数是最佳选择，与EC2-Classic不同，停止的实例retains与其关联的Elastic IP addresses和EBS卷自动stored .
As conclusion ，主要回答你的问题：
似乎EBS在成本相对较小的差异方面更有用（停止，开始，持续更好的速度）......？
答案是 yes ，但如果您的实例是基于EBS的，可以停止 . 它将保留在您的帐户中，you will not be charged for it . 您只需收取音量但EBS is charged hourly . 你也可以考虑在所有available types中你有Resize the EBS Volume的灵活性 .
除了Eric已经列出的好处之外，还应该注意到成本S3 may or may not be cheaper than EBS . 我同意，如果您始终在应用程序的相同平台和体系结构中继续运行both types of instance，则成本差异相对较小 .
但是，如果有一种方案可以在较低成本的服务上运行应用程序，pull all unhandled task和VPC/EBS通过pipeline或lambda在短时间内说<1小时一天 which impossible to do when you use an instance-store ，那么这将是一个不同的故事 .
11 回答
最重要的是你应该几乎总是使用EBS支持的实例 .
Here's why
可以设置EBS支持的实例，以便它们不会（意外地）通过API终止 .
EBS支持的实例可以在您不使用它们时停止，并在您再次需要时恢复（如暂停虚拟PC），至少我的使用模式比在几十GB的EBS存储上花费更多的钱 .
EBS支持的实例在崩溃时不会丢失实例存储（不是对所有用户的要求，而是使恢复更快）
您可以动态调整EBS实例存储的大小 .
您可以将EBS实例存储转移到一个全新的实例（如果您运行的亚马逊上的硬件变得不稳定或死亡，这种情况很有用）
启动EBS支持的实例更快，因为不必从S3获取图像 .
如果您的EBS支持的实例的硬件是scheduled for maintenance，则停止并启动实例会自动迁移到新硬件 . 我还能够通过强制停止实例并再次启动它来在故障硬件上移动EBS支持的实例（您的里程可能因故障硬件而异） .
我是亚马逊的重度用户，一旦技术出现测试版，就将我的所有实例转换为EBS支持的存储 . 我对结果非常满意 .
EBS can still fail - not a silver bullet
请记住，任何基于 Cloud 的基础架构都可能随时出现故障 . 相应地规划基础架构 . 虽然与临时存储实例相比，EBS支持的实例提供了一定程度的持久性，但它们可以并且确实失败了 . 有一个AMI，您可以根据需要在任何可用区域中启动新实例，备份您的重要数据（例如数据库），如果您的预算允许，运行多个服务器实例以实现负载 balancer 和冗余（理想情况下在多个可用区域中） ） .
When Not To
在某些时间点，在Instance Store实例上实现更快的IO可能更便宜 . 曾经有一段时间它确实是真的 . 现在有许多EBS存储选项，可满足许多需求 . 随着技术的变化，选项及其定价也在不断变化 . 如果您有大量真实可丢弃的实例（如果它们刚刚消失，它们对您的业务影响不大），请对成本与性能进行比较 . EBS支持的实例也可能在任何时间点死亡，但我的实际经验是EBS更耐用 .
99％的AWS设置都是可回收的 . 所以对我来说，如果我终止一个实例并不重要 - 永远不会丢失任何东西 . 例如 . 我的应用程序自动部署在SVN的实例上，我们的日志被写入中央系统日志服务器 .
我看到的实例存储的唯一好处是节省成本 . 否则EBS支持的实例获胜 . 埃里克提到了所有的优点 .
[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支持的实例没有任何好处 . 我宁愿添加一分钟到bootstrap，然后运行潜在的SPOF .
我们喜欢实例店 . 它迫使我们使我们的实例完全可循环使用，并且我们可以轻松地自动化在给定AMI上从头开始构建服务器的过程 . 这也意味着我们可以轻松换掉AMI . 此外，EBS仍然不时出现性能问题 .
埃里克几乎把它钉了起来 . 我们（Bitnami）是流行的应用程序和开发框架的免费AMI的流行提供商（PHP，Joomla，Drupal，你明白了） . 我可以告诉你，EBS支持的AMI比S3支持的更受欢迎 . 一般来说，我认为s3支持的实例用于分布式，限时工作（例如，大规模数据处理），如果一台机器发生故障，另一台机器就会被简化 . EBS支持的AMIS倾向于用于'traditional'服务器任务，例如在本地保持状态的Web或数据库服务器，因此在崩溃的情况下需要数据可用 .
我没有看到提到的一个方面是，您可以在运行时拍摄EBS支持的实例的快照，从而有效地允许您对基础架构进行非常经济高效的备份（快照是基于块的和增量的）
我在上一个职位上和Eric有着完全相同的经历 . 现在，在我的新工作中，我将完成我在上一份工作中执行的相同流程...为EBS支持的实例重建所有AMI - 可能还有32位机器（更便宜 - 但不能在32和32上使用相同的AMI） 64台机器） .
EBS支持的实例启动速度足够快，您可以开始使用Amazon AutoScaling API，它允许您使用CloudWatch指标触发其他实例的启动并将它们注册到ELB（Elastic Load Balancer），并在不再使用时关闭它们需要 .
这种动态自动扩展就是AWS所关注的 - IT基础架构的真正节省可以发挥作用 . 使用旧的s3“InstanceStore”支持的实例进行自动缩放几乎是不可能的 .
EC2“硬件”
启动EC2实例时，将保留一个虚拟机以供该实例运行 . 该虚拟机具有特定的规格，具体取决于实例类型：32位或64位CPU，虚拟核心数，硬盘大小等 . 有关实例规范的详细信息，请参见http://aws.amazon.com/ec2/#instance .
当您的EC2实例处于“运行”状态时，这意味着它正在虚拟机上运行，这就是您需要付费的 .
虚拟机的硬盘被认为是“短暂的” . 术语“短暂的”来自希腊语“ephemeros”，意思是“仅持续一天” . 这种硬盘上的任何东西都应该被视为暂时的 . 除非数据从硬盘驱动器复制，否则如果虚拟机停止，则数据将丢失 . 这包括数据，软件，甚至是驻留在这些硬盘驱动器上的操作系统 .
Amazon Web Services为EC2实例提供两种类型的根设备：“EBS支持”和“实例存储” .
“实例存储”实例
“实例存储”实例是其根设备驻留在虚拟机的硬盘驱动器上的EC2实例 . 创建实例时，基本AMI将复制到虚拟机的硬盘驱动器并启动 . 该实例可以根据需要运行，但不能停止 . 由于实例的根设备是实际的硬盘驱动器，因此它“卡在”硬件上，您唯一能做的就是终止实例 . 如果执行此操作，将删除该实例，永远不会恢复 . 您还冒着这样的风险：如果虚拟机的硬件出现故障，那么您也将丢失硬盘驱动器上的任何内容 .
如果您启动“实例存储”实例，请准备好让它保持运行，直到您完成它为止 . 请注意，从实例启动到关闭实例，您将收取费用 .
“EBS支持的”实例
“EBS支持的”实例是EC2实例，它使用EBS卷作为其根设备 . EBS卷是冗余的“虚拟”驱动器，它们与任何特定硬件无关，但它们仅限于特定的EC2可用区 . 这意味着EBS卷可以在同一可用区内从一个硬件移动到另一个硬件 . 您可以将EBS卷视为一种网络附加存储 .
如果虚拟机的硬件出现故障，则可以将EBS卷简单地移动到另一个虚拟机并重新启动 . 从理论上讲，您不会丢失任何数据 .
另一个好处是，可以轻松备份和复制EBS卷 . 因此，您可以轻松备份卷的快照，创建新卷并根据这些重复卷启动新的EC2实例 .
可能“EBS支持的”实例的最大优势在于“实例存储”实例是他们可以被阻止 . 执行此操作时，将关闭虚拟机并存储EBS卷以供以后检索 . 然后，硬件可供其他人使用 . 此外，在此期间，您不会向EC2实例收取运费 . 但是您需要为EBS存储付费 . 当您希望实例再次运行时，您只需再次启动它 . 保留一个新虚拟机，连接您的EBS卷，然后启动您的实例 .
但虚拟机的硬盘怎么样？
是的，即使您的EC2实例是“EBS支持的”，也可以使用这些硬盘驱动器 . 默认情况下，它们不可用 . 如果使用命令行程序启动实例，则可以使用ec2-run-instances命令中的“-b”选项将“实例存储”驱动器附加到EC2实例 .
如果要存储临时数据，将这些驱动器提供可能是有益的 . 读取和写入访问应该比读取和写入EBS卷更快，因为您不是通过网络发送数据 . 此外，您不需要为数据传输或数据存储付费 . 但这仅在数据可能随时丢失时才有效 .
资料来源：https://skeddly.desk.com/customer/portal/articles/1346918-ebs-backed-versus-instance-store
我刚开始使用EC2，所以不是专家，但Amazon's own documentation说：
强调我的 .
我做的比网络托管更多data analysis，所以持久性并不认为EBS适合所有人 .
在我使用两者之后，我会记得再次称重 .
EBS就像VM的虚拟磁盘：
耐用，EBS支持的实例可以自由启动和停止（省钱）
可以在任何时间点进行快照，以获得时间点备份
可以从EBS快照创建AMI，因此EBS卷成为新系统的模板
实例存储是：
本地，所以通常更快
非联网，在正常情况下，EBS I / O以网络带宽为代价（EBS优化实例除外，它具有单独的EBS带宽）
每秒IOPS的I / O有限 . 即使配置的I / O最高也只有几千IOPS
脆弱 . 实例停止后，您将丢失实例存储中的所有内容 .
这里是每个地方的用法：
使用EBS作为后备操作系统分区和永久存储（数据库数据，关键日志，应用程序配置）
将实例存储用于进程内数据，非关键日志和瞬态应用程序状态 . 示例：外部排序存储，临时文件等
当实例之间存在复制时，实例存储也可用于性能关键数据（NoSQL DB，分布式队列/消息系统和带复制的DB）
对系统之间共享的数据使用S3：输入数据集和处理结果，或者每个系统在运行时使用的静态数据 .
将AMI用于预烘焙的可启动服务器
大多数人选择使用EBS支持的实例，因为它是有状态的 . 它更安全，因为您在其中运行和安装的所有内容都将在停止/停止或任何实例故障后继续存在 .
实例存储是无状态的，如果出现任何实例故障情况，您将使用内部的所有数据将其丢失 . 但是，它是免费且更快的，因为实例卷与运行VM的物理服务器相关联 .
对于所有这一切的新手，如果不小心落在这里
截至目前，所有AMI的快速入门部分均为EBS支持
对于EBS和Instance商店之间的区别，official doc也有一个很好的解释
＆这个图像几乎总结了
如果您运行多个实例并将AWS实例的计划服务指定为Avoiding Unexpected Charges的优先级之一，我建议不要使用实例存储 .
此外，对于这种方案，在Elastic Beanstalk上使用EBS Backed也没有任何好处，因为它旨在确保您需要的所有资源都是keep running . 它将始终自动重新启动您停止的任何服务 .
回顾all the rest，在使用添加到EC2-Classic的VPC，EBS和ELB的总费用中，带有ELB的EC2-VPC大多数是最佳选择，与EC2-Classic不同，停止的实例retains与其关联的Elastic IP addresses和EBS卷自动stored .
As conclusion ，主要回答你的问题：
答案是 yes ，但如果您的实例是基于EBS的，可以停止 . 它将保留在您的帐户中，you will not be charged for it . 您只需收取音量但EBS is charged hourly . 你也可以考虑在所有available types中你有Resize the EBS Volume的灵活性 .
除了Eric已经列出的好处之外，还应该注意到成本S3 may or may not be cheaper than EBS . 我同意，如果您始终在应用程序的相同平台和体系结构中继续运行both types of instance，则成本差异相对较小 .
但是，如果有一种方案可以在较低成本的服务上运行应用程序，pull all unhandled task和VPC/EBS通过pipeline或lambda在短时间内说<1小时一天 which impossible to do when you use an instance-store ，那么这将是一个不同的故事 .