AWS CloudWatch Metrics Pricing & Cost Guide

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-02-23. Editorial policy and methodology.

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

Log Cost Calculator Log Ingestion Cost Calculator Log Retention Storage Cost Calculator Log Search Scan Cost Calculator

Use this page when you need to decide what belongs inside the CloudWatch metrics bill before you debate cardinality cleanup, polling reduction, or dashboard pruning.

This guide is about bill boundaries: custom metrics, high-resolution metrics, metrics API requests, dashboards, and the adjacent alarm and external observability costs that should be tracked beside the metrics bill rather than blended into it.

Inside the metrics bill vs beside the metrics bill

Inside the metrics bill: custom metrics, high-resolution metrics, metrics API requests, and dashboard-month charges.
Beside the metrics bill: alarms created from the metrics, external polling tools, and other observability systems that use CloudWatch as an input.
Why this distinction matters: teams often blame CloudWatch metrics for downstream alarming or third-party observability costs that should be budgeted separately.

What to model on the bill itself

Custom metrics time series: the active-series inventory created by names, dimensions, and environments.
Resolution: standard vs high-resolution metrics where applicable.
Metrics API requests: dashboard refresh plus CloudWatch-native request usage.
Dashboards: dashboard-month charges and their CloudWatch-native polling footprint.
Bill ownership: whether the spend belongs to CloudWatch metrics itself or to the systems consuming those metrics.

CloudWatch metrics cost Alarms cost

Scope choices that change the bill boundary

Metric type mix: custom and high-resolution metrics should be budgeted as separate buckets when they price differently.
Access pattern: CloudWatch-native dashboards and API requests belong inside the metrics bill, while external tools should be tracked beside it.
Alarm coupling: alarm-month charges belong to the alarms bill even when they are triggered by metrics.

How to get inputs without mixing jobs

Active series: bring in a defendable time-series model from the estimate page instead of doing the full counting workflow here.
API request posture: keep CloudWatch-native polling separate from third-party access patterns before assigning cost ownership.
Adjacent services: list alarms and external observability systems beside the metrics bill instead of hiding them in one blended estimate.

When this is not the right page

You still need time-series evidence: go to Estimate CloudWatch custom metrics if the real problem is turning inventory, instrumentation, exporters, and dimensions into a defendable active-series model.
You already know the dominant driver: go to CloudWatch metrics cost optimization if the real question is what to change in production.

A fast pricing structure (metrics + adjacent services)

Use CloudWatch metrics cost for CloudWatch-native metrics, API requests, and dashboards, then keep alarms and external systems in separate buckets.

CloudWatch-native: custom metrics, high-resolution metrics, API requests, and dashboards by your effective regional pricing.
Adjacent services: CloudWatch alarms, external polling tools, and downstream observability systems.
Scenario split: keep baseline months separate from growth months where cardinality or polling rises.

Worked pricing example (why boundary matters)

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 bill-boundary mistakes

Using the pricing page to do the full active-series counting workflow instead of separating scope from measurement.
Blending alarms and external polling tools into the core CloudWatch metrics bill.
Treating third-party observability polling as if it were a native CloudWatch dashboard cost.
Assigning one blended bill to “metrics” without separating CloudWatch-native inventory from adjacent consumers.

How to validate the bill model

Reconcile your active-series and API-request assumptions against measured CloudWatch-native usage.
Confirm which charges are CloudWatch-native and which begin once alarms or external tools consume the metrics.
Validate dashboard, request, and alarm ownership before comparing teams or environments.
Keep growth windows separate from normal budgeting assumptions.