AWS CloudWatch Metrics Pricing: Custom Metrics, API Requests, Dashboards, and Resolution
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
If you searched for AWS CloudWatch metrics pricing, the first thing to separate is what actually starts the bill. For most teams, the main paid surface is custom metrics, not the standard AWS service metrics they view every day. After that, metrics API requests, dashboard refresh behavior, and high-resolution usage decide whether the bill stays small or grows with observability sprawl.
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.
If two teams publish similar dashboards but only one team owns the custom metrics explosion, this page should help you keep the CloudWatch-native bill attached to the publisher instead of hiding it inside a shared observability bucket.
Quick pricing read
CloudWatch metrics pricing is not one generic "observability" number. The bill usually starts when you publish custom metrics, then expands through metrics API requests and dashboard usage. High-resolution metrics can change the unit economics again. Alarms and external tooling are related, but they are still separate cost surfaces.
- Custom metrics are the main paid surface: standard AWS service metrics are not the same thing as custom-metric inventory.
- Metrics API requests matter: dashboard refreshes, GetMetricData, and polling tools can create a meaningful request line item.
- Dashboards are not free decoration: dashboard-month charges and refresh patterns belong inside the CloudWatch-native bill.
- High-resolution usage is separate: high-resolution metrics and any high-resolution monitoring pattern should not be buried inside standard metric assumptions.
- Alarms still sit beside the metrics bill: even when metrics trigger them, alarm charges should remain a separate budget line.
This page was updated on 2026-06-18 against the current AWS CloudWatch pricing page and CloudWatch documentation.
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. This is usually where the native bill really starts.
- Resolution: standard vs high-resolution metrics where applicable. Do not price them as one blended bucket if resolution choices differ by team.
- Metrics API requests: dashboard refresh plus CloudWatch-native request usage such as GetMetricData and publisher-side write patterns.
- 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.
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.
Before you compare environments or teams, verify which request volume is truly CloudWatch-native, which refresh behavior comes from dashboards, and which access pattern starts only after another observability tool begins polling the same metrics.
Related operational guides
- AWS CloudTrail pricing: useful when metrics, dashboards, and audit pipelines are being reviewed as one observability spend cluster.
- AWS Route 53 pricing: useful when DNS health checks, failover posture, and CloudWatch-backed monitoring need to be budgeted together.
Sources
- CloudWatch pricing: aws.amazon.com/cloudwatch/pricing