Explanation
Why the waste happens and who it affects.
When an EC2 instance, Lambda function, load balancer, queue or database is removed, its alarms keep existing and typically move to the INSUFFICIENT_DATA state because the metric stops receiving data. Every alarm is billed for each hour it exists, per metric it references, whether it can ever fire or not.
The waste scales with automation. Teams that create alarms per instance, per function or per container through templates, Auto Scaling lifecycle hooks or monitoring tools, but do not delete them on teardown, accumulate hundreds or thousands of orphaned alarms over time. AWS's CloudWatch cost guidance says the best way to reduce alarm costs is to remove unnecessary or unused alarms, including alarms that evaluate metrics from AWS resources that no longer exist, and to avoid alarms in Regions you are not using.
Billing model
The pricing dimensions that drive this cost.
Metric and composite alarm charges are prorated by the hour and incurred only while the alarm exists.
- Standard resolution alarm
- Billed per alarm metric per month ($0.10 per alarm metric in the US East (N. Virginia) pricing examples)
- High resolution alarm
- Alarms with a 10 or 30 second period are billed at a higher rate per alarm metric
- Metric math and anomaly detection
- Each metric referenced in a metric math expression is billed, and anomaly detection alarms add two band metrics
- Composite alarm
- Billed per composite alarm per month in addition to the alarms it references
How to detect
4 checks to find it in your estate.
- Run describe-alarms --state-value INSUFFICIENT_DATA in each Region and list alarms that have stayed in that state for days or weeks (StateUpdatedTimestamp)
- For each alarm, check whether the resource named in its dimensions (for example InstanceId, FunctionName or LoadBalancer) still exists
- List alarms in Regions where no workloads run, which AWS calls out as a cost to avoid
- In Cost Explorer, group CloudWatch cost by usage type and review AlarmMonitorUsage, HighResAlarmMonitorUsage and CompositeAlarmMonitorUsage for growth that does not track the size of the environment
How to fix
4 ways to remove the waste.
- Delete alarms whose target resources no longer exist, after confirming they are not placeholders for resources that are recreated with the same identifiers
- Automate cleanup, for example with an EventBridge rule on resource deletion events that removes associated alarms, or a scheduled job that deletes long-lived INSUFFICIENT_DATA alarms tagged as auto-created
- Create per-resource alarms in the same IaC stack or lifecycle hook as the resource so they are removed together
- Replace high-resolution alarms with standard resolution where 1-minute evaluation is sufficient, and for metric math alarms that aggregate four or more metrics, aggregate the data before publishing so a single-metric alarm can be used
Documentation
Vendor references for pricing and configuration.