我有一个在多个EC2机器上运行的Web服务。基于Cloudwatch延迟指标，我想扩大其他功能。但是，考虑到从AMI启动EC2花费几分钟（带有启动代码以下载最新的应用程序JAR和应用OS补丁），有没有办法提供可以立即打开/启动的“冷”服务器/关闭？
答案 0 :(得分：1)
不通过使用AutoScaling。至少没有，您所描述的瞬间。但是，可以通过制作自己的修改后的AMI映像（放置JAR和最新的OS修补程序）来使其更快。这些AMI可以作为构建管道的一部分生成。在这种情况下，您唯一真正的等待时间就是操作系统和服务的启动，类似于“冷”服务器。
Packer是此类用例中常用的工具。
或者，您可以通过关闭服务器来自己进行管理，并通过编写一些由Cloudwatch警报触发的自定义Lambda脚本来启动它们。但是由于停止的服务器也不是完全免费的，出于成本原因，我建议不要这样做。
答案 1 :(得分：0)
在冒险进行自动扩展基础架构并花费时间/精力的旅程之前。也许您应该对每天，每天，每周和每月的流量模式进行一点分析，看看是否有必要？尝试回答其中一些问题。
您的应用程序处理过的最高流量是多少？服务器如何分配流量？用户的响应时间如何？
您的流量何时会增加或达到峰值？有些应用在工作时间内获得流量，而其他则在晚上获得流量。
您当前的吞吐量是多少？例如，您可以处理每分钟1k个请求，并且两台EC2主机平均占用20％的CPU。如果请求数量增加到3k / min，则您能够看到平均60％-70％的平均CPU吗？这很好地表明您的应用使用情况是可以预测的，可以通过添加更多主机来线性扩展。但是，如果您从未见过那样的流量爆裂，那就没有什么比供应更重要了。
除非您拥有类似Zynga的应用程序，否则您一次可以看到大量流量，也许更好地了解您的流量模式并投入额外的主机是有帮助的。我做出这些假设是因为我不了解您的业务性质。
如果您还是想自动扩展，一种解决方案是使用Docker容器化您的应用程序或像其他人建议的那样创建自己的AMI。仍然需要几分钟来启动它们。下一个选项是使主机保持待机状态，然后使用脚本（或lambda函数）将其添加到负载均衡器中，这些脚本监视您定义的指标（假设您的应用程序在负载均衡器后面运行）。
祝你好运。