无 active alarm 时为何产生 CloudWatch Alarm Billing？

2026-10-24支付小周

明确结论

会计费。CloudWatch Alarm 的费用与当前状态无关，无论是 ALARM、OK 还是 INSUFFICIENT_DATA。

只要 alarm 没有被删除，CloudWatch 就会继续评估，并根据对应的 alarm metric 用量计费。也就是说：

4 个处于 INSUFFICIENT_DATA 状态的 alarms 仍可能产生费用。
1 个处于 OK 状态的 Monthly Billing alarm 仍可能产生费用。
History 中没有触发记录，只能说明没有发生状态转换或相关操作，不能说明 alarm 未被评估。
TreatMissingData=ignore 只决定缺失数据如何影响 alarm 状态，不会暂停评估或停止计费。
禁用 alarm actions 也不会停止计费。通常只有删除 alarm，才能停止这部分费用。

AlarmMonitorUsage 不是可以单独关闭的功能，也不是某个 alarm 的名称，而是账单中的 CloudWatch alarm 用量类型。要找到费用来源，需要结合区域、账号和现有 alarms 进行排查。

为什么没有处于 `ALARM` 状态仍然收费

CloudWatch 控制台中的状态分别表示：

OK：当前条件未达到阈值。
ALARM：当前条件达到阈值。
INSUFFICIENT_DATA：数据不足，无法判断条件是否成立。

这些状态是 alarm 的评估结果，不表示 alarm 已启用或停用。只要配置没有被删除，alarm 就仍是一个受监控资源。

Monthly Billing alarm 也是普通的 CloudWatch metric alarm。即使账单从未超过阈值，History 中也没有触发通知，它仍会定期评估 AWS/Billing 指标，因此可能计入 AlarmMonitorUsage。

CloudWatch Alarm 通常按照 alarm 引用的指标数量计费，不一定只看控制台中显示的 alarm 数量。使用 metric math、Metrics Insights 或引用多个底层指标的 alarm，可能产生多份 alarm metric 用量。具体单价和免费额度应以当前区域及账号适用的 CloudWatch Pricing 页面为准。

如何定位 `AlarmMonitorUsage`

1. 在账单工具中确认账号、区域和时间段

在 Cost Explorer 或 Cost and Usage Report 中设置以下筛选条件：

Service：AmazonCloudWatch
Usage type：包含 AlarmMonitorUsage
Charge type：排除税费、退款等非使用费用
时间粒度：建议先按天查看

然后分别按照以下维度分组：

Linked account
Region
Usage type
Operation

重点检查费用是否来自其他 AWS Region，或者 AWS Organizations 下的其他 linked account。CloudWatch 控制台默认只显示当前区域，手动逐个切换时容易漏查。

账单中的 Region 有时使用内部区域代码，显示方式可能与控制台中的区域名称不同。如果无法从账单直接定位具体 alarm，可以将用量开始日期与各区域 alarm 的创建时间进行比对。

2. 使用 AWS CLI 枚举所有区域中的 alarms

下面的脚本只查询 alarms，不会修改资源：

for region in $(aws ec2 describe-regions \
  --query 'Regions[].RegionName' \
  --output text); do
  echo "===== ${region} ====="
  aws cloudwatch describe-alarms \
    --region "${region}" \
    --query '{
      MetricAlarms:MetricAlarms[].{
        Name:AlarmName,
        State:StateValue,
        Namespace:Namespace,
        Metric:MetricName,
        ActionsEnabled:ActionsEnabled
      },
      CompositeAlarms:CompositeAlarms[].{
        Name:AlarmName,
        State:StateValue,
        ActionsEnabled:ActionsEnabled
      }
    }' \
    --output json
done

如果使用多个 AWS 账号或 CLI profile，需要针对每个 profile 分别执行。例如：

AWS_PROFILE=production aws cloudwatch describe-alarms \
  --region us-east-1

检查 AWS/Billing 指标和传统 Billing alarms 时，通常需要特别留意 us-east-1：

aws cloudwatch describe-alarms \
  --region us-east-1 \
  --query 'MetricAlarms[?Namespace==`AWS/Billing`].{
    Name:AlarmName,
    State:StateValue,
    Metric:MetricName,
    Dimensions:Dimensions
  }' \
  --output table

3. 检查 alarm 实际引用了多少指标

对于 metric math alarm，应查看 Metrics 数组，不能只检查 MetricName：

aws cloudwatch describe-alarms \
  --region us-east-1 \
  --query 'MetricAlarms[].{
    Name:AlarmName,
    State:StateValue,
    MetricName:MetricName,
    Metrics:Metrics
  }' \
  --output json

如果某个 alarm 的 Metrics 中包含多个 MetricStat 或表达式，它产生的账单用量可能高于简单的单指标 alarm。实际计算方式需要结合当前 CloudWatch Pricing 中对应 alarm 类型的规则来确认。

4. 检查自动创建的 alarms

DynamoDB Auto Scaling、Application Auto Scaling、CloudFormation、CDK、Terraform 或其他 AWS 服务可能会自动创建 CloudWatch alarms。

可以查看 alarm 的 tags：

aws cloudwatch list-tags-for-resource \
  --region ap-southeast-1 \
  --resource-arn 'arn:aws:cloudwatch:ap-southeast-1:123456789012:alarm:example-alarm'

还要检查基础设施代码和自动扩缩容策略。否则，即使手动删除了 alarm，部署流程或扩缩容配置也可能将其重新创建。

如何停止计费

确认不再需要某个 alarm 后，可以将其删除：

aws cloudwatch delete-alarms \
  --region ap-southeast-1 \
  --alarm-names \
  'dynamodb-read-capacity-alarm' \
  'dynamodb-write-capacity-alarm'

删除 Monthly Billing alarm 的示例：

aws cloudwatch delete-alarms \
  --region us-east-1 \
  --alarm-names 'monthly-billing-alarm'

删除前需要确认：

alarm 是否由 CloudFormation、Terraform、CDK 或其他部署工具管理；
alarm 是否由 DynamoDB Auto Scaling 等服务自动维护；
删除后是否会失去容量、费用或故障告警能力；
当前需求是彻底取消告警，还是调整监控设计。

如果 alarm 由基础设施代码管理，应先从源配置中删除或禁用相应资源，再执行部署。只在控制台中手动删除，后续部署可能会重新创建它。

注意事项

以下 TreatMissingData 设置都不会停止计费：

breaching
notBreaching
ignore
missing

这些设置只决定缺失数据如何参与状态判断。以下操作同样不会消除 alarm 用量：

将 alarm actions 设为 disabled；
删除 SNS notification action；
让指标停止上报；
让 alarm 长期处于 OK 状态；
让 alarm 长期处于 INSUFFICIENT_DATA 状态。

删除 alarm 后，账单数据通常不会立即归零。Cost Explorer 和账单明细存在处理延迟，删除前已经产生的按比例用量也会保留。应等待账单数据更新完成，再检查删除后的新时间段。

如果所有区域和所有 linked accounts 中确实只有这 5 个简单 alarms，但实际费用仍明显高于预期，还需要核对：

账单显示的是“用量”还是实际的非零费用；
是否存在 metric math、高分辨率或其他类型的 alarms；
是否遗漏了其他区域或账号；
免费额度是否已被组织内的其他用量消耗；
费用是否来自 alarm 删除前的账期。

如果仍然无法对应到具体资源，可以向 AWS Support 提供账期、linked account、Region、Usage type 和 Operation。账单中的 AlarmMonitorUsage 通常不像 EC2 实例费用那样始终提供可直接映射的 resource ID，因此，枚举所有区域并按账号拆分，往往是更可靠的定位方法。