我设置了如下AWS自动缩放：
1） 创建了一个负载均衡器并向其注册了一个实例；
2） 向ELB添加健康检查；
3） 增加了2个报警：
-CPU使用率->60%，60秒，旋转1个实例；
-CPU使用<120秒40%，降速1个实例；
4） 编写了一个jMeter脚本来向有问题的网站发送流量：250个线程，200秒的上升时间，循环计数5。
我看到的很奇怪。
我预计CPU使用率会随着用户数量的增加而激增。但CPU使用率保持在20-30%之间（这就是为什么新实例永远不会启动的原因），并且运行中的实例一旦达到100个以上的用户就开始抛出超时错误。
我不明白为什么CPU使用率如此之低，而网站实际上已经超时了。
想法？
这可能是ELB的问题。ELB的扩展速度不是很快，它需要持续的流量才能让亚马逊知道你需要一个更大的ELB。如果你一下子就把它打得很重，那对它的规模没有帮助。因此，ELB在处理所有连接时可能会出现问题。
这是SSL吗？您在ELB上执行SSL吗？这也会给规模不足的ELB增加开销。
我真诚地建议大家不要使用ELB。haproxy是一种更好的产品，在大多数情况下速度更快。如果需要的话，我可以详细说明，但看看亚马逊是如何处理cname的，以及你可以用haproxy做什么。。。
听起来您正在测试AutoScaling，以确保它能满足您的需求。作为简单查看As是否会启动新实例的第一步，请尝试将CPU启动检查减少到25%。我意识到这比您希望使用的要低得多，但这将有助于验证您的初始配置是否有效。
作为第二步，您应该查看您的应用程序，看看CPU是否是让As监控扩展的最佳指标。你的应用程序中可能有其他地方的瓶颈，可能不一定与CPU有关（网络服务器调整、内存、数据库、存储等）。你没有提到你正在提供什么类型的内容；它是静态的还是由解释器生成的（比如PHP或其他什么）？您还可以将自己的自定义度量数据发送到CloudWatch，并使用此度量触发缩放。
您可能还需要计算一个实例从冷启动开始准备提供流量所需的时间。如果时间超过60秒，您可能需要适当调整监控阈值时间（或设置冷却期）。正如chantheman所指出的，ELB注册实例也可能需要一些时间（如果新实例在不同的AZ中，则需要更长的时间）。
我希望所有这些都能有所帮助。
我们发现，当您在t2实例上使用自动缩放时，在高负载下，这些实例将耗尽CPU信用，然后它们被限制为CPU的20%（从监控的角度来看，内部htop仍然是100%）。在内部，它们处于最大负载。
这将向自动缩放发送错误的度量，并且新闻实例将不会激发。
您需要更改度量或开发您自己的或移动到m个实例。