The $0.30 metric: what CloudWatch custom metrics actually cost

$0.30 per metric per month sounds like a rounding error. It stays a rounding error right up until someone adds a customer_id or request_id dimension to a metric that's already being published every minute from every instance — and the bill jumps from single digits to hundreds of dollars with no code change anyone remembers making. Here's exactly how CloudWatch custom metric pricing works, and which pattern actually causes the surprise.

• What does a CloudWatch custom metric actually cost?
• What counts as one metric, exactly?
• Where the bill actually grows: cardinality, not metric count
• Standard vs high-resolution metrics
• The PutMetricData charge nobody budgets for
• When a custom metric is worth $0.30/month — and when it isn't

What does a CloudWatch custom metric actually cost?

CloudWatch bills custom metrics in three tiers per account per month: $0.30 per metric for the first 10,000, $0.10 per metric from 10,001 to 250,000, and $0.05 per metric above that. Metrics are prorated by the hour — you're only charged for hours in which a data point was actually published, not a flat monthly rate.

Note the tiers apply cumulatively across your whole account, not per metric type — publishing 12,000 custom metrics means the first 10,000 are billed at $0.30 and only the remaining 2,000 drop to the $0.10 tier.

What counts as one metric, exactly?

A CloudWatch metric identity is the combination of namespace, metric name, and the full set of dimension name/value pairs attached to it. Change any dimension value and CloudWatch treats it as a distinct metric for billing purposes — even if the metric name and namespace are identical.

That's the part that catches teams off guard. Publishing `OrderLatency` with a dimension of `Service=checkout` is one metric. Publishing the same `OrderLatency` metric with a dimension of `CustomerId=<uuid>` creates one metric per unique customer ID that has ever sent a data point — potentially thousands, all counted separately against the tiered pricing above.

Where the bill actually grows: cardinality, not metric count

Teams rarely get surprised by adding metrics deliberately — three or four custom metrics per service, even across fifty instances, stays in the low hundreds of dollars. The bill grows from high-cardinality dimensions: a dimension whose value set is effectively unbounded, like a user ID, session ID, request ID, or IP address.

As an illustrative example: a single custom metric with a low-cardinality dimension like `Environment` (production, staging) stays at 2 billed metrics forever, regardless of traffic. The same metric with a `CustomerId` dimension across 5,000 active customers becomes 5,000 billed metrics — at the $0.30 tier, that's $1,500/month for what started as "just one metric." This is the single most common cause of an unexplained CloudWatch cost jump.

Standard vs high-resolution metrics

CloudWatch also supports high-resolution (sub-minute, down to 1-second) custom metrics, priced separately from the standard 60-second resolution tier above — check the current CloudWatch pricing page for the exact rate, since AWS has adjusted this tier before. The operational point that doesn't change: a metric published every 10 seconds generates 6x the data points of one published every 60 seconds, and storage/processing cost scales with publish frequency, not just metric count. Default to standard resolution unless you have a specific sub-minute alerting need — most alarm use cases don't.

The PutMetricData charge nobody budgets for

Publishing custom metrics happens through the PutMetricData API, which carries its own per-request charge separate from the per-metric storage cost above. Each PutMetricData call is limited to 1,000 distinct metrics and 1MB of request size — so the fix for both API cost and CloudWatch's 400 throttling error is the same: batch data points into fewer, larger calls instead of calling PutMetricData once per metric per instance.

# One call, three metrics batched — not three separate PutMetricData calls
aws cloudwatch put-metric-data \
  --namespace "MyApp/Checkout" \
  --metric-data \
    MetricName=OrderLatency,Value=142,Unit=Milliseconds,Dimensions=[{Name=Environment,Value=production}] \
    MetricName=OrderErrors,Value=0,Unit=Count,Dimensions=[{Name=Environment,Value=production}] \
    MetricName=OrderCount,Value=1,Unit=Count,Dimensions=[{Name=Environment,Value=production}]

If your metric volume is high enough that per-metric-series pricing itself becomes the bottleneck — not just the API call count — AWS's newer OpenTelemetry metrics option for CloudWatch bills at $0.50/GB ingested (including 15 months of storage) instead of per metric series, with no separate PutMetricData-style API charge. It's a different pricing model, not a strictly cheaper one — it's worth comparing against your actual metric volume rather than assuming either model wins by default.

When a custom metric is worth $0.30/month — and when it isn't

The test that filters out most unnecessary custom metrics: if you can't name the alarm you'd attach to it, it's probably not worth $0.30/month times however many dimension combinations it generates.