Estimate CloudWatch alarm count (standard, high-res, composite)

To estimate CloudWatch alarm cost, you need one input per alarm type: alarm-month count. The tricky part is that alarm counts are rarely stable: autoscaling, ephemeral environments, and copy-paste monitoring packs can change the number by 2–10× over time.

Step 1: count current alarms by type (baseline)

• Standard alarms: default evaluation.
• High-resolution alarms: faster detection; priced separately.
• Composite alarms: rollups of multiple alarms.

Step 2: include environments and time fraction

Alarm-month is proportional to time. If a PR environment exists 3 days and creates 60 alarms, the alarm-month contribution is roughly:

• 60 alarms * (3 / 30.4) ~= 5.9 alarm-months

This is why short-lived environments with “full production alarm packs” can quietly become expensive.

Three practical inventory methods (pick one)

• CloudWatch inventory: list existing alarms and group by alarm type and environment tag or name prefix.
• IaC source-of-truth: count alarms defined in Terraform/CloudFormation and multiply by the number of stacks/environments.
• Monitoring templates: if you generate alarms from templates, count template expansion rules (per service, per instance, per queue, etc.).

Spot the scaling multipliers (what makes it explode)

• Per-instance alarms: alarm count scales with fleet size (N instances -> N alarms).
• Per-dimension alarms: per tenant/customer/region dimensions multiply the base set.
• Per-team duplication: teams copy the same alarms for shared components.
• Ephemeral stacks: PR environments, sandboxes, and test deployments add time-weighted alarm-months.

Model growth scenarios (so you don't re-estimate every month)

• Fleet growth: if you use per-instance alarms, model alarm count as proportional to instance count.
• Team growth: if each new service includes a full alarm pack, model alarms as “alarms per service”.
• Ephemeral usage: if PR environments are common, model “environments active per day” as a driver.

Even a simple scenario (baseline month vs busy month) is better than a single point estimate for planning.

Cross-check: does the number make operational sense?

• How many alarms fired in the last 30 days vs total alarm count?
• How many alarms have never fired (or always OK) in the last 90 days?
• Can on-call engineers name what the top 20 alarms are for?

If most alarms never fire and nobody can explain their purpose, you likely have a high “alarm-month waste” rate.

Validation checklist

• Count by type (standard/high-res/composite) and by environment (prod/staging/dev).
• Pro-rate ephemeral environments by days active per month.
• Identify scaling multipliers (fleet size, tenants, regions) and model growth scenarios.

Sources

• CloudWatch pricing: aws.amazon.com/cloudwatch/pricing

Related guides

Related calculators

FAQ