我正在编写一个移动应用程序的后端，该应用程序执行一些cpu密集型工作。我们预计该应用程序在大多数情况下不会有大量使用，但偶尔会有高需求的高峰。我在想我们应该做的是保留几个24/7服务器来处理低需求流量的稳定状态，然后根据需要添加和删除EC2实例来处理峰值。移动应用程序将首先点击一个简单的负载平衡服务器，在所有可用的处理服务器之间进行简单的循环用户分发。负载均衡器将处理新的EC2实例并根据需要将其关闭。
有些问题：
我之前从未写过类似的内容，听起来这是一个好策略吗？
处理新EC2实例的最佳处理方式是什么？我以为我可以提前创建X实例，根据需要设置它们（安装软件等），然后停止每个实例。然后，负载均衡器将根据需要启动和停止实例（例如，通过boto）。我认为这应该比尝试创建新实例并通过脚本或其他东西安装所有内容更快更容易。好主意？
我在这里关注的一件事是关闭和重新启用EC2实例的成本。我查看了AWS使用情况报告，但难以解释。我可以看到启动已停止的实例是一项潜在的高成本操作。但似乎因为我刚刚开始停止实例而不是从头开始配置新实例，所以不应该太糟糕。听起来不错吗？
答案 0 :(得分：5)
这是一个非常合理的策略。我之前成功使用过它。
您可能希望结合Elastic Load Balancing查看Auto Scaling（ELB）。从概念上讲，两者应该解决这个确切的问题。
当我在2010年左右这样做时，ELB在某些类型的HTTP请求中遇到了一些问题，导致我们无法使用它。我理解这些问题已经解决了。
由于ELB不是一个选项，我们根据需要手动从EBS快照启动实例，并手动将它们添加到NGinX负载均衡器。这当然可以使用AWS API实现自动化，但我们的峰值是如此可预测（月底），我们只是要求某人启动新实例并且没有自动完成任务。
当一个实例停止时，我相信您支付的唯一成本是支持实例及其数据的EBS存储。除非您的实例有大量数据关联，否则EBS存储费用应该是最小的。自从我上次使用AWS以来，事情可能已经发生了变化，但如果发生变化，我会感到惊讶。
答案 1 :(得分：1)
首先，关于成本，实例是从头开始还是从停止状态开始，对成本没有影响。您需要支付一段时间内使用的计算单位数量。
其次，您要做的事情称为自动缩放。您所做的是设置一个启动配置，指定您要使用的AMI（以及您正在使用的任何用户数据配置，您将要使用的ELB和可用区域，最小和最大实例数等。您使用该启动配置设置了一个扩展组。然后设置扩展策略以确定将附加到该组的扩展操作。然后，将云监视警报附加到每个策略以触发扩展操作。
您没有附加到ELB的保留服务器或类似的东西。一切都基于创建单个AMI，该AMI用作所需服务器的模板。
您应该阅读以下链接中的自动缩放：