What CloudWatch alarms actually cost — and the three levers that actually reduce the bill

Most CloudWatch alarm cost advice repeats the same claim: switch to composite alarms and cut your alarm count 60–70%. It's wrong in a specific way that matters. Composite alarms don't remove the underlying metric alarms — they sit on top of them, and they add $0.50/month each on top of what you're already paying. If you're optimizing for the AWS bill, composite alarms make it slightly worse, not better. They're still worth using — just not for the reason most guides give.

How much does a CloudWatch alarm actually cost?

A standard-resolution CloudWatch alarm costs $0.10 per alarm-metric per month, prorated hourly. Anomaly-detection alarms cost $0.30/month — three times the standard rate, because they track the actual metric value plus the upper and lower bounds of the expected range as three separate series. A composite alarm costs a flat $0.50/month regardless of how many underlying alarms it references. The first 10 alarm-metrics per month are free.

The billing unit is the alarm-metric, not the alarm

This is the detail that breaks most cost-optimization advice: AWS bills per metric referenced inside an alarm, not per alarm you create. A single alarm using a metric math expression that references three metrics is billed as three alarm-metrics — even though it's one alarm, fires one state change, and sends one notification.

This means the metric-math patterns that make alarms smarter (see the guide to CloudWatch metric math for the full set) don't reliably reduce the bill either. A fleet-wide MAX() across 10 ECS services' CPU metrics is billed as 10 alarm-metrics — the same as 10 separate per-service alarms — because all 10 raw metrics are still referenced. What changes is that you get one alarm state and one notification instead of 10, which is an operational win, not a billing one.

Myth: composite alarms cut your CloudWatch bill

A composite alarm evaluates the state of other alarms — it doesn't replace them. The child metric alarms still exist, still evaluate independently, and still bill at $0.10 each. The composite alarm is a fourth thing on top, billed at $0.50/month flat.

# 10 per-service CPU alarms — still bill individually at $0.10 each = $1.00/mo
HighCpuService1:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: service-1-cpu-high
    Namespace: AWS/ECS
    MetricName: CPUUtilization
    Dimensions:
      - Name: ServiceName
        Value: service-1
    Statistic: Average
    Period: 60
    EvaluationPeriods: 3
    Threshold: 85
    ComparisonOperator: GreaterThanThreshold
    TreatMissingData: notBreaching
# ... 9 more identical alarms for service-2 through service-10 ...

# Composite alarm on top — adds $0.50/mo, does not remove the 10 above
FleetCpuDegraded:
  Type: AWS::CloudWatch::CompositeAlarm
  DependsOn:
    - HighCpuService1
    # ... all 10 child alarms ...
  Properties:
    AlarmName: fleet-cpu-degraded
    AlarmDescription: Page only when 3+ services are CPU-saturated simultaneously
    AlarmRule: >-
      (ALARM("service-1-cpu-high") + ALARM("service-2-cpu-high") +
       ALARM("service-3-cpu-high")) >= 3
    AlarmActions:
      - YOUR_SNS_TOPIC_ARN

Total bill for this setup: 10 × $0.10 + $0.50 = $1.50/month — 50% more than the $1.00/month baseline of just the 10 alarms with no composite layer. What you get for that extra $0.50 isn't a cheaper bill. It's going from up to 10 possible pages during a fleet-wide CPU event down to exactly 1. That's the actual value of composite alarms: fewer notifications, not a lower invoice. If your goal is genuinely a lower AWS bill, a composite alarm is a small net cost, not a saving.

The three things that actually reduce your CloudWatch alarm bill

• Prune alarms nobody acts on. Pull the ALARM-state history for the last 90 days per alarm. If an alarm has never fired, or has fired repeatedly with no runbook action taken, it's pure cost with no signal. Deleting it removes $0.10/month and — more importantly — one less thing to triage during an incident.
• Stop mirroring prod alarm coverage 1:1 into every non-prod environment. A dev and staging environment rarely need the same alarm density as production. If your CloudFormation/Terraform stack deploys identical alarm sets per environment, you're paying 2-3x for coverage nobody is paged on.
• Avoid anomaly detection unless the pattern genuinely varies by time of day or week. At 3x the standard rate, anomaly detection alarms are the most expensive alarm type per metric. They're worth it for traffic-shaped metrics (request count, queue depth) but are usually overkill for hard capacity limits like FreeStorageSpace or FreeableMemory, where a static threshold is both cheaper and clearer.

When alarm cost actually becomes real money

For a small team, the raw alarm bill is genuinely trivial. A 10-person startup running 50 alarm-metrics across one environment pays $5/month — $60/year. The bill becomes material only when alarm count multiplies across environments and services without pruning.

Frequently asked questions