今天，我创建了一个包含多项策略的 AutoScaling 组，每项策略都有一个与 CloudWatch 指标关联的警报。AutoScaling 组启动了两个实例，因为这是我对该组所要求的最低限度。我打开基准测试来测试新组，它们的平均 CPUUtilization 超过了我为警报设置的阈值。我观察了每项警报的历史记录，状态从 INSUFFICIENT_DATA 变为 OK，最后变为 ALARM。正如预期的那样。然后我等待策略执行。执行前指定的 300 秒已经过去了。然后我决定看看策略执行需要多长时间。现在已经过去了一个半小时，这些策略仍未执行。
我很沮丧，删除了 ASG 以及所有策略和警报。我决定，也许我在创建策略和警报时犯了一个错误。所以我重新创建了它们。同样的问题。警报处于 ALARM 状态，从不执行策略。我可以手动执行策略而不会出现问题，但这违背了重点。
如果有什么不同的话，我都是在 AWS 控制台中创建这些东西的。过去，我曾使用 API 创建 ASG 和策略，这些组可以很好地执行策略。
我做错什么了吗？（或者也许 AWS 服务只是出了问题。）
更新：
今天又试了一次。决定使用 API 而不是控制台来查看是否有任何区别。我正在使用的警报 20 分钟前刚刚从 OK 更新为 ALARM。
CPUUtilization >= 35 for 5 minutes
Actions: In ALARM: For group TEST use policy Scale Out API (Add 1 instance)
Namespace: AWS/EC2
Metric Name: CPUUtilization
Dimensions: AutoScalingGroupName = TEST
Statistic: Average
Period: 5 minutes
2013-12-19 15:13 UTC-7 - 状态更新 - 警报从正常更新为警报
当前时间：15:43 UTC-7（闹钟响起 30 分钟后）
操作未触发。知道原因吗？
答案1
我在亚马逊论坛显然，最近在创建警报时出现了一个错误，它会自动将“ActionsEnabled”属性设置为 False。
从 AWS：
We have identified an issue in the AutoScaling console regarding the binding of
AutoScaling policies to CloudWatch alarms and are working on a fix. We will post
an update to this thread once the fix is rolled out. Thanks for bringing this to
our attention.
目前的解决方法：
In the meantime, please try calling the DescribeAlarms CloudWatch API. If the
alarms associated with your policies have ActionsEnabled=false, then this could
cause your policies to not be invoked when the alarm is triggered. Please try
calling the PutMetricAlarm CloudWatch API to update ActionsEnabled=true for the
affected alarms, and that should fix the issues you are experiencing.
我已经通过 API 用我自己的警报确认了该错误和解决方法。