今天，我创build了一个包含多个策略的AutoScaling组，每个策略都有一个与CloudWatch指标关联的警报。 AutoScaling组启动了两个实例，因为我要求该组的最小数量。 我打开了我的基准testing，打到了新组，平均CPU使用率超过了我为报警设置的阈值。 当状态从INSUFFICIENT_DATA变为OK时，我观察了每个报警的历史logging，最后到ALARM。 正如所料。 然后我等待政策的执行。 执行前指定的300秒来去。 然后我决定看看政策执行之前需要多长时间。 现在已经过了一个半小时了，那些政策还没有执行。
我感到沮丧，并删除了ASG和所有的政策和报警。 我决定也许我在创build策略和警报时犯了一个错误。 所以我重新创build了它们。 同样的问题。 警报处于ALARM状态，从不执行策略。 我可以手动执行这些策略而不会有任何问题，但是这样做是无能为力的。
如果它有什么不同，我在AWS控制台中创build了所有这些东西。 在过去，我使用API来创buildASG和策略，这些组执行策略就好了。
有什么我做错了吗？ （或者也许AWS服务只是有问题。）
更新：
今天再试一次。 决定使用API而不是控制台来查看是否有任何区别。 我正在使用的闹钟刚刚从OK更新为20分钟前的闹铃。
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 状态更新 – 警报从OK更新为ALARM
当前时间：UTC-7 15:43（报警后30分钟）
行动没有触发。 任何想法为什么？
我在亚马逊论坛上问过这个问题，显然最近在创build闹铃时会出现一个错误，会自动将“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确认了自己的警报和解决方法。