在管理自己的集群（即不使用/不支付Amazon Autoscale，Rightscale，Scalr等的费用）的人们中，您如何在EC2上管理实例并处理（例如）故障转移？我想知道大多数人是否最终会像EC2 API一样最终编写自己的脚本脚本。
当然，这就是我们的方法：启动我们自己的基于Python Boto的监视/重新启动守护程序，该守护程序在异地运行，侦听实例中的UDP保持活动。发生故障时，我们将对卷进行快照，注册映像，启动新实例，删除旧卷等等。
每隔一段时间，当我入侵我们的脚本时，我认为必须已经有一些开源工具可以处理这些问题，并且没有（例如）Scalr的限制，但是我总是从Google回来空手。（诸如Scalr之类的东西在受支持的软件集/版本/配置中非常有限，并且具有操纵这些设置的专门且IMO繁琐的方式。）
另外，Linux-HA / Pacemaker生态系统（Heartbeat，ldirectord等）听起来似乎并不适合EC2。（但是后来我发现了这一点 -尽管我不确定这是否是高质量的解决方案）。
Answers:
好吧，我并不是要说显而易见的事情，而是总的想法是将这种复杂性推到由亚马逊管理的服务中。
因此，在前端，您将使用Amazon Elastic Load Balancing（ELB）提供高可用性的负载平衡。在后端，您使用Amazon Relational Database Service（托管MySQL），SimpleDB和S3进行存储。所有这些均由Amazon管理，并包含某种高可用性/故障转移处理。
通常，这会留下您的Web应用程序服务器以及您可能正在使用的任何次要的常见服务器类型（渲染服务器，自安装的NoSQL数据存储等）。
通常使用ELB内置的运行状况检查可以很好地处理Webapp服务器。当一台webapp服务器宕机时，您可以接受性能的小幅下降，或者持续提供比您所需更多的+1服务器。或者，如果您的配置很简单，则当webapp服务器出现故障时，ELB和Cloudwatch可以自动为您生成一个新的webapp服务器。
您自己的自定义服务器是另一回事。对于这些，这是真的，您是一个人，需要使用应用程序的内置方法，或者将磁带与自定义脚本/开源HA工具捆绑在一起。
购买Rightscale的解决方案可能太昂贵了。但是，如果您需要高可用性，那么价格较低的Amazon工具，例如ELB，基本的CloudWatch警报（现在可以免费使用5分钟）或AutoScale都是值得的。
关于如何在EC2上自动执行故障转移，RightScale上有很多很棒的文章。尽管其中大多数内容都向您展示了如何使用RightScale本身来执行此操作，但这些原则是通用的，可能对任何考虑如何在EC2上建立故障转移体系结构的人都有帮助。
您描述的问题（HA，监视自定义服务器，“引导”服务）通常由PaaS提供商处理。在上一个答案中已经提到了Rightscale和Scalr，还有其他一些不错的选择（有关某些PaaS选项，请参见此处：
/programming/9542784/ looking-for-paas-providers-recommendations）
您应该考虑哪个提供商最适合您的需求。
适当的通知：我为开源PaaS提供商cloudify工作。
您在两台服务器上都安装了心跳，将弹性IP附加到“活动”服务器上，通过启动API请求以获取弹性IP，将脚本配置为执行故障转移，一旦“备用”服务器获得了弹性IP（大约需要30-60秒）。
我没有在这里提供的细节。