弹性三剑客
如下图所示，ELB，AutoScaling和CloudWatch组成了AWS的弹性三剑客，三个服务保证了应用的弹性。
当ELB中的目标组中的实例的指标（比如CPU利用率）出现告警时，会触发cloudwatch监控，cloudwatch进行扩展或者缩减策略，auto scaling通过该策略进行EC2实例的扩展或者缩减，并注册在ELB目标组中。
Auto scaling 冷却时间、预热时间作用
- 冷却时间作用：Auto Scaling 组在使用简单扩展策略扩展后，会等到冷却时间完成，然后再执行简单扩展策略可以启动的任何扩展活动。（比如若一个实例的启动需要安装配置脚本和文件，可能需要几分钟，在此期间，若没有冷却时间，对于任何标准精度警报，可能会持续每分钟触发 CloudWatch 警报，从而导致 Auto Scaling 组在警报每次触发时都另外启动一个实例）。
- 预热时间作用：当触发警告后，实例开启，同时开启预热时间计时，实例开启完成后加入ELB目标组，等待预热时间过后，ELB对EC2进行健康检查，检查通过后ELB正式转发流量，目的主要是为了机器能完成开启并完成服务加载。
Auto Scaling 重要参数
关联目标组
负载均衡器将作为 Auto Scaling 组的所有传入 Web 流量的单一接触点。将实例添加到您的组时，它需要注册到负载均衡器中，否则不会有流量路由到该实例。从您的组中移除某个实例时，必须在负载均衡器中注销它，否则流量会继续路由到该实例。
当您将 Elastic Load Balancing 负载均衡器与 Auto Scaling 组配合使用时，无需将 EC2 实例注册到负载均衡器或目标组。通过 Elastic Load Balancing，由 Auto Scaling 组启动的实例将自动注册到负载均衡器或目标组，由 Auto Scaling 组终止的实例将自动从负载均衡器或目标组中注销。
运行状况检查类型
由于EC2类型的健康检查只是单纯的检查机器硬件层面以及OS系统是否正常开启，并没有检查应用服务层面，会出现机器能开启但是应用没有正常加载的情况。所以最佳实践是选择ELB作为健康检查类型。
