AWS CloudWatch Metrics Pricing & Cost Guide

CloudWatch metrics pricing often looks like "a few small line items" until metric sprawl and polling add up. A useful cost model separates metric volume (time series) from metric access (API requests and dashboards), and then adds alarms as a related bucket.

What to include in a metrics estimate

• Custom metrics time series: metric names * dimension combinations * environments
• Resolution: standard vs high-resolution where applicable
• Metrics API requests: dashboard refresh + tooling polling
• Dashboards: dashboard-month charges (and their polling effects)
• Alarms: alarm-months created from metrics (separate pricing bucket)

Fast modeling workflow

1. Estimate custom metric time series (baseline + growth scenario).
2. Estimate metrics API requests from dashboards and tooling polling.
3. Count dashboards and alarms (prod vs non-prod).
4. Apply your region pricing and validate against a real week of usage.

How to estimate the two core drivers

• Custom metrics: count time series and identify high-cardinality dimensions. Guide: estimate custom metrics.
• API requests: model dashboard refresh and tool polling. Guide: estimate API requests.

Worked example (why this grows fast)

Suppose you publish 30 metrics per service, each with 2 dimensions (service and status), and you have 12 services and 2 environments. If status has 5 values, a rough series estimate is:

• Series ~= 30 * (12 * 5) * 2 ~= 3,600 series

If you add a high-cardinality dimension (podId, tenantId), series can jump by orders of magnitude without any traffic increase.

Common pitfalls

• Adding unbounded dimensions (tenantId, userId, podId) and creating runaway series counts.
• Copying full dashboard packs into every environment and keeping them forever.
• Multiple tools polling CloudWatch in parallel (duplicated API request volume).
• Publishing per-instance metrics when service-level aggregates would work for alerting.
• Not separating prod vs non-prod (non-prod is often the safest cost reduction).

Optimization direction

• Control cardinality with a dimension budget and explicit review.
• Aggregate by default; use per-instance only for deep debugging.
• Reduce polling overlap and slow down refresh for slow-moving metrics.

Guide: CloudWatch metrics cost optimization.

Validation checklist

• Measure active series by namespace and identify top dimensions.
• Measure API request volume for at least 7 days (include a busy/incident day if possible).
• Confirm dashboard time ranges and refresh intervals match the decision speed you need.
• Validate alarms: do you have many per-resource alarms that scale with fleet size?

Sources

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

Related guides

Related calculators

FAQ