所以，我一直在玩我的自动缩放configuration和我的Cloudwatch警报，试图保持所有的实例呜呜，但不咆哮。

我似乎无法摆脱一个恒定的溜溜球。 CPU使用率上升，引入一个实例，CPU使用率下降，杀死一个实例。 冲洗并重复。

目前，我正在以平均CPU> = 40％的3 x 1分钟间隔进行报警。 也许我可以基于其他东西？ CPU是一个棘手的一个，因为当这个图表尖峰（高），我可以看到一些实例与空闲的CPU，所以平均正在提出一个单一的实例。

• 是否可以configurationEC2 VPC安全组的inheritance？
• 如何在S3中存储Cloudfront自定义错误页面？
• IOPS越less，线程越多？
• AWS ec2 public IP上的UDP / TCP端口被阻止
• 从一个人转移到另一个人

我发现有些人在得到200的时候会得到502。 显然，我希望这是一致的，并停止这一次的尖峰。

提前致谢。

编辑1：我已经调整了Cloudwatch指标为20％的CPU超过2分钟，还发现一个nginx错误，也可能归因于一些额外的负载。 当前graphics如下所示。

编辑2：负载监控是好多了。 请参阅下面的负载警报。 我收到警报的频率很低，一切都运行得更好。

这就是我每分钟都在运行的东西。

/usr/local/bin/aws cloudwatch put-metric-data --namespace="NS" --metric-name="GroupLoad" --value `cat /proc/loadavg | awk '{print $1}'` --dimensions AutoScalingWebGroup=NS-WebGroup 

 $ mon-put-data -namespace App1 -metric-name Latency -value 104 $ mon-put-data -namespace App2 -metric-name Latency -value 120