AWSCostAWS cost · CloudWatch metrics
CloudWatch metrics and alarms cost more than you think
Everyone knows CloudWatch logs can get expensive. Fewer people notice the other half of the bill: metrics and alarms. Each custom metric is $0.30 a month and each alarm past the first ten is $0.10, and both are the kind of thing you create once and never revisit. A dashboard here, a per-instance alarm there, a custom metric emitted for a feature that shipped two years ago. None of it is expensive on its own. Multiplied by hundreds, and never cleaned up because nobody can see the pile, it turns into a line item that surprises people.
CloudWatch custom metrics cost $0.30/month each (first 10,000) and alarms $0.10 each past the free 10. They accumulate silently - per-resource alarms, forgotten dashboards, high-cardinality metrics - and nobody deletes what nobody sees. Audit what exists, cut what is unused, and watch for dimensions that multiply the metric count.
What does CloudWatch charge beyond logs?
The metric and alarm side of the bill, each small per unit and easy to multiply:
| What | Rate | Note |
|---|---|---|
| Custom metric | $0.30/month | first 10,000 - then $0.10, $0.05, $0.02 in tiers |
| Standard alarm | $0.10/month | per alarm metric, first 10 free |
| High-resolution alarm | $0.30/month | 10-30 second periods |
| Metric filter | free to define | you pay only if it emits a custom metric |
Why do metrics and alarms pile up?
Because they are created by the dozen and deleted by no one. Tooling auto-creates an alarm per resource. A custom metric gets emitted for a feature that later ships or dies, but the metric keeps arriving. A high-cardinality dimension - one metric per container, per route, per user - quietly turns a single idea into thousands of billable metrics. Each was a reasonable decision in the moment, and none of them announces its monthly cost. It is the same shape as the CloudWatch logs bill, on the metrics side of the meter.
How do I find and cut them?
Count what you have first - the number of custom metrics and alarms is usually a surprise on its own - then delete what nobody queries or acts on. This lists your custom (non-AWS) metric namespaces and counts your alarms so you can see the scale before you prune:
# your custom metric namespaces (anything not starting with AWS/)
aws cloudwatch list-metrics \
--query 'Metrics[?!starts_with(Namespace, `AWS/`)].Namespace' \
--output text | tr '\t' '\n' | sort | uniq -c | sort -rn
# how many alarms exist (past the free 10, each is $0.10/month)
aws cloudwatch describe-alarms \
--query 'length(MetricAlarms)'Want to know how much of your CloudWatch bill is metrics and alarms nobody looks at? Connect your account read-only and see what it is wasting, in real dollars.
The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.
Frequently asked questions
How much do CloudWatch custom metrics cost?+
$0.30 per custom metric per month for the first 10,000, dropping to $0.10, $0.05, and $0.02 per metric in higher tiers. The free tier covers 10 custom metrics. The cost is per unique metric, so high-cardinality dimensions - a metric per instance, per path, per customer - multiply the count fast.
How much do CloudWatch alarms cost?+
$0.10 per standard-resolution alarm metric per month, or $0.30 for high-resolution alarms, with the first 10 alarms free. A few dozen alarms is a few dollars; hundreds of them - often auto-created per resource and never cleaned up - become a real line item.
Why is my CloudWatch bill high even without heavy logging?+
Metrics and alarms, not just logs. Every custom metric is $0.30/month and every alarm past the free 10 is $0.10, and both accumulate silently - dashboards, per-resource alarms, and high-cardinality custom metrics that were emitted once and forgotten. Hundreds of each is common, and nobody deletes them because nobody sees them.
Are metric filters cheaper than custom metrics?+
The metric filter itself is free to define - it extracts a value from logs you are already ingesting, with no PutMetricData API calls or extra instrumentation. If the filter emits a custom metric, that metric still costs $0.30/month like any other. The saving is avoiding duplicate instrumentation and API charges, not the metric itself.
How do I reduce CloudWatch metrics and alarms costs?+
Audit what exists. Delete custom metrics nobody queries and alarms nobody acts on, watch for high-cardinality dimensions that explode the metric count, and prefer metric filters over separately instrumented custom metrics where you already log the data. Most accounts carry far more metrics and alarms than anyone actually uses.
Do CloudWatch alarms cost money even if they never fire?+
Yes. An alarm is billed for existing and evaluating, not for triggering. An alarm past the free 10 costs $0.10/month whether it fires once or never - so a pile of forgotten alarms on resources you deleted still bills every month until you remove them.
Related cost breakdowns
Why your CloudWatch logs bill is so high - and how to cut it
CloudWatch charges $0.50/GB just to ingest logs - I have seen it hit ~$700/month on a single cluster. The Infrequent Access class, retention limits, and metric filters cut most of it.
Why EKS is expensive: the $73/month control plane
Every EKS cluster bills $0.10/hour - about $73/month - for the control plane before a single node runs, and $0.60/hour once it falls out of standard support. Idle and forgotten clusters are pure waste.
ECR storage costs $0.10/GB - and CI builds pile it up
ECR stores container images at $0.10/GB-month, and every CI build pushes layers that never expire on their own. Without a lifecycle policy the bill climbs forever - here is how to cap it.