我在ELB后面和Auto Scaling组中有两个EC2实例。放大政策如下：
CPUUtilization> = 70 300秒（添加一台服务器）
在进行Atoscaling活动时，现有实例的负载已经达到99％，连接正在被删除。
有没有办法更有效地处理这个问题？
Auto Scaling的技巧是定义一个可以准确识别系统负载的警报。
CPU利用率并不总是正确的使用方法 - 您的应用程序可能只能处理有限数量的连接，可能会挤压RAM并且请求类型也可能不同。
一个好主意是在峰值负载期间密切监控您的系统，以确定识别繁忙时段的准确信号（或者更好的是，帮助您预测即将到来的繁忙时段）。在各个实例上使用标准监视工具，例如监视可用内存，应用程序用户数，事务数等。
您可以使用常规监控工具，也可以编写将指标推送到Amazon CloudWatch的内容，以便超越CloudWatch通常提供的基本CPU和网络指标。您甚至可以使用Load Balancer的Latency指标在应用程序变慢时触发扩展（需要自定义代码）。
一旦您有可靠的信号来检测系统何时接近容量并需要向外扩展，您就可以集中精力缩短添加新容量的时间。测量新实例启动并开始接受流量所需的时间。尝试使用完全配置的AMI减少启动时间，而不是通过用户数据安装软件。也许您可以删除或关闭实例上的服务，以使其更快地启动。尝试使用不同的EBS卷类型（例如，通用SSD可以突发多达3000个IOP）和不同的实例类型。
也许甚至可以提前横向扩展（例如50％） - 与改善用户服务相比，额外费用可能会很小。
您的目标应该是确保用户永远不会有慢速服务或断开连接。
检查实例的状态是否健康。如果突然出现压倒性流量，通常实例/容器实例会进入不健康/耗尽静态。 在这种情况下，请设置自动调节策略以检测要删除的最小健康实例数，并相应地将实例扩展至最低阈值的50％。例如，运行30个健康实例的系统突然降至25，然后自动调整到其他45个实例，以便它可以处理突然的峰值。随着流量冷却，您对CPU，内存等指标的缩减策略可以将这45个实例降低到所需的数量。