我目前正在运行单个 EC2 实例，并计划最终迁移到容错架构。EC2 MTBF 可以帮助我确定迁移的紧迫性。
有没有关于 EC2 机器故障频率的数据？
答案1
没有公布 MTBF 统计数据。“比你希望的更频繁”是你所能得到的最好结果。除此之外，其他发帖者还提供了关于如何处理应用程序架构的出色答案。
答案2
我通常预计 EC2 实例的 MTBF 会比我购买并放置在数据中心的高端硬件更高。
最大的不同是，我可以设计我的 EC2 设置，这样当一个实例发生故障时，我可以在收到警报并连接到互联网的几分钟内启动一个新的实例。这与我以前所做的工作形成了鲜明对比，以前当一个服务器在 40 分钟路程外的托管服务器发生故障时，我必须开车去那里，调试硬件问题，安装替换部件（如果我手头正好有的话）。
例如，如果实例的底层硬件出现故障，您可以将其丢弃，并使用以下几个命令切换到新硬件：
更换 EC2 实例硬件的更简单方法
http://alestic.com/2011/02/ec2-move-hardware
因此，尽管我有时会设计复制和自动恢复或故障转移，但其他时候我往往会发现自己面临着一点停机风险，因为手动恢复太容易了。
记录/编写实例设置（软件安装/配置），以便您可以随时重现它。定期拍摄快照。定期备份您的数据（除了快照之外）。将备份副本保存在异地（EC2 之外）。
如果您需要额外的正常运行时间，请选择更复杂的复制、冗余、故障转移、自动扩展架构，AWS 也比使用物理硬件更容易实现这些架构。
答案3
这是我为公司项目研究过的东西，不幸的是，它实际上无法量化。由于 EC2 中有如此多的节点，并且由于运行的机器数量众多，集群计算本质上是不稳定的，因此它实际上是以下因素：您的应用程序能否处理故障？
需要注意的是，最大的问题似乎是单点故障（显然）。不要在云中托管单个数据库、单个文件存储等。EC2 上的磁盘故障并不常见，但我见过 0.0001% 到 2% 的磁盘故障率。谷歌搜索（并检查 EC2 主板）会为您提供更多证据。对于长期存储（或“更可靠”的存储），请查看 Amazon S3。
总体而言，您不应将 EC2 实例视为您自己的数据中心或 co-lo 中服务器的替代品。相反，您应该将它们视为兼职人员——许多都会出现，大多数都会做得很好，但偶尔，其中一个会请病假或辞职。当这种情况发生时，您的应用程序需要能够处理丢失，无论是数据损坏还是服务器脱机。如果它可以（就像您说的那样），那么云计算是一个好主意。