我不清楚我在Amazon EC2上为我的实例从EBS和实例存储中获得了什么好处。 如果有的话，似乎EBS在成本相对较小的差异方面更有用(停止，开始，持续+更好的速度)......？ 此外，是否有更多人正在使用EBS，因为它仍然相对较新？

#1楼

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

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

强调我的。

我做的数据分析比网络托管更多，所以持久性对我来说并不像对网站那么重要。 鉴于亚马逊本身的区别，我不认为EBS适合所有人。

我会尝试记住在使用两者之后再次称重。

#2楼

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

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

#3楼

最重要的是，你应该几乎总是使用EBS支持的实例。

这就是原因

可以设置EBS支持的实例，以便它们不会(意外地)通过API终止。

当您不使用它们时可以停止EBS支持的实例，并在您再次需要它们时重新启动(例如暂停虚拟PC)，至少使用我的使用模式可以节省比我在几十GB的EBS存储上花费更多的钱。

EBS支持的实例在崩溃时不会丢失实例存储(不是对所有用户的要求，而是使恢复更快)

您可以动态调整EBS实例存储的大小。

您可以将EBS实例存储转移到一个全新的实例(如果运行的亚马逊硬件变得不稳定或死亡，这种情况很有用)

启动EBS支持的实例更快，因为不必从S3获取图像。

如果计划维护 EBS支持的实例的硬件，则停止和启动实例会自动迁移到新硬件。 我还能够通过强制停止实例并再次启动它来在故障硬件上移动EBS支持的实例(您的里程可能因故障硬件而异)。

我是亚马逊的重度用户，一旦技术出现测试版，就将我的所有实例转换为EBS支持的存储。 我对结果非常满意。

EBS仍然可能失败 - 而不是银弹

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

什么时候不

在某些时间点，在实例存储实例上实现更快的IO可能更便宜。 曾经有一段时间它确实是真的。 现在有许多EBS存储选项，可满足许多需求。 随着技术的变化，选项及其定价也在不断变化。 如果您有大量实际可以丢弃的实例(如果它们刚刚消失，它们对您的业务影响不大)，请对成本与性能进行比较。 EBS支持的实例也可能在任何时间点死亡，但我的实际经验是EBS更耐用。

#4楼

EBS就像VM的虚拟磁盘：

EBS支持的持久实例可以自由启动和停止(节省资金)

可以在任何时间点进行快照，以获得时间点备份

可以从EBS快照创建AMI，因此EBS卷成为新系统的模板

实例存储是：

本地，所以一般更快

非网络，在正常情况下，EBS I / O以网络带宽为代价(EBS优化实例除外，它具有单独的EBS带宽)

每秒IOPS的I / O有限。 即使配置的I / O最高也只有几千IOPS

脆弱。 实例停止后，您将丢失实例存储中的所有内容。

这里是每个地方使用的地方：

使用EBS作为后备操作系统分区和永久存储(数据库数据，关键日志，应用程序配置)

将实例存储用于进程内数据，非关键日志和瞬态应用程序状态。 示例：外部排序存储，临时文件等

当实例之间有复制时(NoSQL DB，分布式队列/消息系统和带复制的DB)，实例存储也可用于性能关键数据

将S3用于系统之间共享的数据：输入数据集和处理结果，或者用于每个系统在运行时使用的静态数据。

将AMI用于预烘焙，可启动的服务器

#5楼

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

截至目前，所有AMI的快速启动部分都是EBS支持的

对于EBS和Instance商店之间的区别， 官方文档也有一个很好的解释

＆这个图像几乎总结了它