我目前正在运行一个EC2实例，并计划最终转移到容错体系结构。 有些东西可以帮助我决定迁移的紧急程度是EC2 MTBF。
有没有关于EC2机器失败的信息？
没有公布的MTBF统计数据。 “比你想象的更多”是关于你将要得到的最好的。 除此之外，其他海报已经提供了有关如何处理架构应用程序的优秀答案。
我通常期望EC2实例的MTBF高于我将购买并放入数据中心的高端硬件。
最大的区别是我可以devise我的EC2设置，这样当一个实例出现故障时，我可以在几分钟之内提醒一个新的连接到互联网。 这是一个巨大的反差，当我需要在40分钟内将服务器故障时，我必须在那里下车，debugging硬件问题，安装replace部件，如果我碰巧拿到它们，我曾经必须做的。
例如，如果实例的底层硬件出现故障，您可以将其丢弃并使用几条命令切换到新硬件：
在EC2上更换实例硬件的一种更简单的方法
http://alestic.com/2011/02/ec2-move-hardware
所以，虽然我有时会devise复制和自动恢复或故障转移，但是有时我会发现自己生活在一点点停机的风险之中，因为手动恢复是非常容易的。
文档/脚本实例设置（软件安装/configuration），以便您可以立即复制。 定期拍摄快照。 定期备份您的数据（除了快照）。 保留备份副本（EC2以外）。
如果您需要额外的正常运行时间，请select更复杂的冗余，故障转移，自动扩展架构，AWS也比物理硬件更容易。
这是我为公司项目研究的东西，不幸的是，它不可能量化。 由于EC2中有大量的节点，并且由于大量的机器在运行，集群计算本质上是不稳定的，所以它真的是一个因素：你的应用程序能否处理失败？
要注意的是，最大的问题似乎是单点故障（显然）。 不要将您的单个数据库托pipe在云端，单个文件存储等中。EC2上的磁盘故障并不是很正常的地方，但是我看到磁盘故障率从0.0001％到2％。 谷歌search（并检查EC2板）将会给你更多的证据。 对于长期存储 – 或“更可靠”的存储 – 请查看Amazon S3。
总体而言，您不应该将EC2实例视为替代您自己的数据中心或协同服务器中的服务器。 相反，你应该把他们视为兼职人员 – 很多人会出现，大多数人会做得很好，但每过一段时间，他们中的一个人就会叫人生病或退出。 当发生这种情况时，您的应用程序需要能够处理丢失，无论是数据损坏还是服务器正在运行。 如果可以（就像你说的那样），那么云计算是一个好主意。