CloudWatch dashboards pricing: what to include (dashboard-month + API)

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

CloudWatch dashboards are usually modeled as dashboard-month, but the “real” costs often live next door: metrics API requests, custom metrics, and alarms created to support dashboards and alerting.

The useful review question is whether you are paying for dashboard-month footprint itself or for the metrics requests, custom metrics, and companion alarms that teams created so the dashboards would stay rich enough for day-to-day operations.

Dashboard pricing inputs

• Dashboard count: billable dashboard-months.
• Widget refresh: API requests per refresh.
• Viewer traffic: shared dashboards multiply calls.

What to model

• Dashboards: dashboard-month count (how many dashboards exist and are billed)
• Metrics API requests: GetMetricData / GetMetricStatistics called by dashboards and tools
• Custom metrics volume: metrics you publish to support visualizations and SLOs
• Alarm-months: alarms created as “dashboard companions”

A fast estimation workflow

1. Count dashboards (prod vs non-prod).
2. Estimate dashboard refresh traffic: users × views × refreshes.
3. Estimate API requests: refreshes × widgets × metrics per widget.
4. Apply dashboard-month and API request rates from your region pricing.

Worked example (order-of-magnitude)

Suppose 25 engineers open a dashboard 10 times/day, each view refreshes 5 times, and the dashboard has 20 widgets:

• Dashboard refreshes/day ~= 25 * 10 * 5 = 1,250
• If each widget queries ~3 metrics, metric queries/day ~= 1,250 * 20 * 3 = 75,000

This is why “dashboard sprawl” can create surprisingly large API request volume, even with normal usage patterns.

Common pitfalls

• Dashboard duplication: each team clones a dashboard pack instead of sharing a standard set.
• High-cardinality metrics: dashboards require per-dimension metrics that explode metric count.
• Always-on refresh: wallboard TVs and NOC screens refresh continuously and drive constant queries.
• Tool overlap: multiple observability tools poll the same CloudWatch metrics in parallel.
• Cross-account views: shared dashboards across accounts can increase polling if multiple teams keep them open.

Cost control levers (without losing visibility)

• Reduce duplication: maintain a shared “golden dashboard” per service.
• Reduce refresh: avoid 10-second refresh for slow-moving metrics.
• Reduce metrics per widget: aggregate where possible and avoid per-instance views by default.
• Move heavy exploration to logs/traces for investigations and keep dashboards for operational monitoring.

If you need fast detection, prefer alarms for paging and keep dashboards optimized for triage rather than continuous high-frequency polling.

Validation checklist

Before you compare teams or months, separate the billable dashboard inventory from the recurring refresh traffic, then verify which extra spend belongs to dashboards versus the surrounding metrics and alerting choices they trigger.

• Count dashboards by environment and by ownership/team.
• Identify “always-on” dashboards (TVs, wallboards) and measure their refresh rate.
• Measure metrics API request volume from a real week and validate the estimate.

Sources

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

Related guides

Related calculators

FAQ