所以我一直在使用Python中的Boto尝试基于CPUUtilization配置自动缩放，或多或少与此示例中指定的完全一致：http://boto.readthedocs.org/en/latest/autoscale_tut.html
但是，CloudWatch中的两个警报都只报告：
州详细信息：状态在2012/11/12 16:30 UTC更改为“INSUFFICIENT_DATA”。原因：未选中：初始警报创建
自动缩放工作正常，但警报根本没有获取任何CPUUtilization数据。对于我可以尝试的任何想法？
编辑：实例本身报告CPU利用率数据，而不是当我尝试在CloudWatch中以编程方式在python或界面中创建警报时。为了以防万一，还启用了详细的监控......
谢谢！
来自AWS的official answer如下：
嗨，转换到INSUFFICIENT_DATA状态（仅）的固有延迟，因为警报等待一段时间来补偿指标生成延迟。对于具有60秒周期的警报，转换到I_D状态之前的延迟将在5到10分钟之间。
约翰。
显然这是一个临时状态，可能会自行解决。
还遇到了这个问题但出于不同的原因：我在我的Cloudformation模板中传递了ES集群ARN而不是域名。这非常令人沮丧
我不确定后端发生了什么，但如果您比较警报历史记录，您将看到AWS删除“单位”列，如果您只是修改警报而没有任何变化，因为at7000ft说。因此，请删除脚本的单位列。
确保警报的命名空间为“AWS / EC2”。
我知道这是在原始问题之后的很长一段时间，但是如果其他人通过谷歌发现这个问题，我遇到了同样的问题，结果发现我设置了不正确的警报名称空间。
需要使用用于创建警报的相同单位发布数据。如果你没有指定一个，它将是一个<None>单位。
可以使用aws put-metric-data在aws-put-metric-alarm和--unit <value>中指定单位
单位<value>可以是：
单位也区分大小写，在脚本中要小心。
对于CPUUtilization，您可以使用百分比。
将第一个数据集发送到您的警报后（对于非详细的受监视实例，最多可能需要5分钟），警报将切换到OK或ALARM状态而不是INSUFFICIENT_DATA状态。
我在CloudWatch中显示相同的INSUFFICIENT_DATA警报状态，以便使用CloudFormation创建RDS CPUUtilization> 60警报。 （“原因：未选中：初始警报创建”显示在详细信息下）。这是一个非常粗略的修复但我发现通过选择警报，单击修改按钮，然后单击保存按钮（不更改任何内容），警报进入OK状态，一切都是文件。
我有这个问题。确保用于创建警报的度量标准名称与实际度量标准名称匹配。
您可以使用以下内容列出指标：
aws cloudwatch list-metrics --namespace=<NAMESPACE, e.g. System/Linux, etc>
查找指标和MetricName。确保为该指标配置了警报。
据我所知，默认度量标准分辨率是5分钟（如果您付费可以降低到1分钟，或类似的东西），所以如果您的警报的测量周期低于此值，那么它将永久保留在INSUFFICIENT_DATA州。在我的情况下，我有一个1分钟的CPU利用率测量周期，并将其更改为5分钟已修复状态问题。
我有类似的问题，我的警报一直处于INSUFFICIENT_DATA状态，尽管我可以在GUI中看到指标。
出现这种情况，因为我在创建警报时为度量指定了错误的单位。没有报告任何错误，但它从未成为绿色。
如果您不确定，最好避免指定它，AWS将在后台执行正确的匹配。
有一个目录/ var / tmp / aws-mon /包含几个文件。一个是instance-id。我所使用的实例是从AMI创建的，该文件保留了旧的实例ID。我刚编辑它并确保/ var / tmp / aws-mon / placement / availability-zone也是正确的。警报几乎立即变为OK。