Amazon CloudWatch Alarm
Does ZopNight manage Amazon CloudWatch Alarm?
CloudWatch alarms bill per alarm per month, with higher rates for high-resolution and composite alarms. An alarm watching a deleted resource keeps billing while it can never fire usefully. ZopNight discovers alarms on the 6-hour cycle, recommends cleanup of orphaned and broken ones, and attributes per-alarm cost from Cost Explorer or CUR 2.0.
Rules that fire on Amazon CloudWatch Alarm
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
A CloudWatch alarm watches a metric and triggers actions, billed per alarm per month with higher rates for high-resolution and composite alarms. Alarms referencing deleted resources keep billing while alerting on nothing.
Metered per alarm, forever
Every alarm bills a monthly fee for existing: standard-resolution alarms at the base rate, high-resolution alarms (sub-minute periods) at a premium, and composite alarms (those combining other alarms with boolean logic) at their own rate. The fee is independent of whether the alarm ever changes state. That combination of small per-unit cost, unbounded population, and no expiry is exactly the profile that produces thousands-strong alarm estates in mature accounts, created by autoscaling policies, dashboards-as-code, and every team’s monitoring stack since the account opened.
Broken-watch detection
A dedicated provider discovers every alarm on the 6-hour cycle, with per-alarm cost from Cost Explorer or CUR 2.0. The cleanup recommendations target two failure classes. Orphaned alarms watch metrics from resources that no longer exist: an instance ID that was terminated, a load balancer that was deleted. Such alarms sit permanently in INSUFFICIENT_DATA while billing monthly. Broken alarms have actions pointing at deleted SNS topics or disabled autoscaling policies, so even a genuine breach notifies nobody. Both categories are worse than useless: they cost money and erode trust in the alarms that matter.
Why alarm estates rot
Alarms are created alongside resources but deleted separately from them. Terminating an instance does not delete its CPU alarm; destroying a Terraform stack leaves manually added alarms behind; and autoscaling deletes policies without deleting the alarms that referenced them. Monitoring migrations, whether to Datadog, Grafana, or a new alarm taxonomy, reliably leave the previous generation intact “for reference”.
Sweeping the alarm list
CloudWatch’s All alarms view can be filtered by state; a long-standing INSUFFICIENT_DATA population is the orphan shortlist. Checking a sample’s metric dimensions against live resources confirms the diagnosis, and deleting an orphaned alarm carries no risk beyond losing a record that something once existed.