# Orphaned CloudWatch Alarms for Deleted Resources Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/orphaned-cloudwatch-alarms-for-deleted-resources CloudWatch alarms are not deleted when the resource they watch goes away. By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version CloudWatch alarms are not deleted when the resource they watch goes away. PointFive Research Cloud cost research at PointFive AWS service [AWS CloudWatch](https://www.pointfive.co/efficiency-hub/cloud-services/aws-cloudwatch) Category [Other](https://www.pointfive.co/efficiency-hub/service-category/other) Reference CER-0381 Type Idle or Unused Resource ## 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. - [Amazon CloudWatch Pricing aws.amazon.com](https://aws.amazon.com/cloudwatch/pricing/) - [Analyzing, optimizing, and reducing CloudWatch costs docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_billing.html) - [Automating Amazon CloudWatch Alarm Cleanup at Scale aws.amazon.com](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarm-cleanup-at-scale/) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - AWS CloudWatch CER-0060 ### [Inactive CloudWatch Log Group](https://www.pointfive.co/efficiency-hub/inefficiencies/inactive-cloudwatch-log-group) CloudWatch log groups often persist long after their usefulness has expired. In some cases, they are associated with applications or resources that are no longer active. In other cases, the systems may still be running, but the log data is... Other - AWS CloudWatch CER-0233 ### [Overly Permissive VPC Flow Log Filters Sent to CloudWatch Logs](https://www.pointfive.co/efficiency-hub/inefficiencies/overly-permissive-vpc-flow-log-filters-sent-to-cloudwatch-logs) VPC Flow Logs configured with the ALL filter and delivered to CloudWatch Logs often result in unnecessarily high log ingestion volumes - especially in high-traffic environments. This setup is rarely required for day-to-day monitoring or... Other - AWS CloudWatch CER-0224 ### [Suboptimal Log Class Configuration in CloudWatch](https://www.pointfive.co/efficiency-hub/inefficiencies/suboptimal-log-class-configuration-in-cloudwatch) By default, CloudWatch Log Groups use the Standard log class, which has a higher per-GB ingestion price. AWS also offers an Infrequent Access (IA) log class designed for logs that are rarely queried - such as audit trails, debugging... Other --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.