Amazon CloudWatch Pricing: The 10 Billing Dimensions Behind Your Observability Bill

CloudWatch is the AWS observability primitive with the most pricing dimensions of any single service. Ten distinct lines — Logs ingestion, Logs storage, Logs Insights queries, custom metrics, alarms (in three tiers), dashboards, Synthetics canaries, RUM events, X-Ray traces, and Container Insights — each with its own per-unit rate, free tier, and cardinality multiplier. The bill on a mature account is rarely under five figures, and Logs ingestion is almost always the largest line.

This post is the bill story. For the operational angle — alarm hygiene, log structure, dashboard design — see our CloudWatch observability best practices guide. For the specific case of logs cost control, the CloudWatch logging costs post covers sampling and structured-logging patterns in depth.

The 10 CloudWatch Billing Dimensions

The Logs Line: Always the Biggest

Logs ingestion at $0.50/GB is almost always the largest CloudWatch line on a mature account. The math is direct: a single noisy application logging at INFO level can produce 50 GB/day. Across a 50-service microservices fleet, that is 2.5 TB/day, $1,250/day, $37,500/month — for logs that mostly sit in CloudWatch and never get queried.

The four mitigations, ranked by impact:

1. Sample DEBUG and verbose access logs. Drop 90%+ of low-value logs at the application before they reach CloudWatch. A 50% reduction in ingestion is a 50% reduction in this line.
2. Route low-value logs to S3 via Firehose. Operational logs that exist for retention but not for active querying can go to S3 Standard-IA at $0.0125/GB-month instead of CloudWatch Logs at $0.50/GB ingest + $0.03/GB-month storage.
3. Aggressive retention. Default CloudWatch Logs to “Never expire” — set to 14–30 days for application logs, 90 days for security/compliance logs, then export the older data to S3.
4. Structured logging. Logs Insights queries on structured logs scan less data per query — $0.005 / GB scanned on JSON logs with field filtering is 10× cheaper than full-text scanning across unstructured logs.

Custom Metric Cardinality: The Hidden Explosion

Custom metrics bill per unique metric per month. The cardinality math is multiplicative: a metric with 5 dimensions × 10 possible values per dimension = 100,000 potential unique metrics, all of which bill if all combinations occur.

The most common waste pattern: publishing a metric with a high-cardinality dimension. User ID, request URL, container instance ID, customer ID — any dimension with hundreds or thousands of possible values will explode the metric count.

Alarm Sprawl: The Untracked Multiplier

Alarms accumulate. An organization that hits an incident, creates 20 alarms during the post-mortem, and never deletes them, will have thousands of alarms within a year. At $0.10/alarm/month for standard resolution, this is $100s/month for alarming alone. If alarms are high-resolution (10-second evaluation) by default — many incident-response runbooks specify high-resolution — the multiplier is 3×.

Audit quarterly:

• Find alarms that have never triggered. Many are dead — delete.
• Find alarms whose SNS topic targets an inbox no one reads. Either consolidate or delete.
• Find composite alarms that depend on alarms that themselves are dead. Composite alarms are $0.50/each; clean them first.

Dashboards: Easy to Create, Easy to Forget

After the first 3 free per account, dashboards are $3/each per month. A large organization with shared dashboards across teams accumulates dashboards over time. The cost is small per dashboard but compounds: 100 dashboards across an organization is $300/month.

The cleanup: use Cross-Account Observability (CloudWatch’s centralized observability primitive) to share dashboards across accounts rather than recreating them per account. Audit individual dashboard usage with CloudWatch’s dashboard view metrics; consolidate or delete those with no views in 60+ days.

Container Insights: Per-Cluster Multiplier

Container Insights for EKS publishes hundreds of metrics per cluster (CPU, memory, network, disk per node and per pod) plus enables Container Insights logs. On a 50-node cluster, this can land at $500–$2,000/month per cluster in CloudWatch.

For cost-sensitive deployments, the alternatives:

• OpenTelemetry → Amazon Managed Service for Prometheus. Prometheus’s per-sample pricing is generally lower than Container Insights’ per-metric model at the cardinality typical for Kubernetes.
• Selective enablement. Enable Container Insights only on production clusters; use kubectl/k9s for dev/staging visibility.
• FluentBit to S3 for container logs. Skip CloudWatch Logs for container logs entirely; route to S3 via Firehose for long-term storage at a fraction of the cost.

Synthetics and RUM: Frequency-Driven

Synthetics canaries bill $0.0012 per run. A canary running every minute costs $0.0012 × 60 × 24 × 30 = $51.84/month — small. A canary running every 10 seconds costs 6× that, $311/month. Across 10 canaries at 1-minute frequency, the bill is ~$520/month.

The pattern: budget canary frequency. Critical-path APIs warrant 1-minute checks; secondary endpoints can run every 5 or 15 minutes; nightly batch jobs need only daily canaries.

RUM bills $1/100K events. A high-traffic web app pulling 10M page views per month with RUM enabled generates $100/month — modest. The bill driver is event volume; configure RUM sampling at the application level for very high-traffic sites.

When to Use What CloudWatch Feature

A 30-Day CloudWatch Bill Cleanup Plan

Week 1 — Logs retention and sampling. Audit every log group’s retention setting. Default to 14–30 days for application logs, 90 for security. Identify the top 10 log groups by ingestion volume; apply sampling at the source for the high-volume ones.

Week 2 — Custom metric cardinality. Find metrics with the highest unique-count using the CloudWatch Metrics API. Identify dimensions that drive the cardinality. Pre-aggregate or remove the high-cardinality dimensions.

Week 3 — Alarm and dashboard cleanup. List every alarm via aws cloudwatch describe-alarms; identify alarms that have never triggered (use CloudWatch’s history metric). Delete dead alarms. List every dashboard; identify those with no views in 60+ days; delete or consolidate.

Week 4 — Container Insights and Synthetics scope. For EKS/ECS clusters with Container Insights enabled, decide which clusters genuinely need it (production yes; dev usually no). Disable on non-production. Audit Synthetics canary frequencies; reduce to the lowest cadence that meets SLO needs.

Cross-check the broader observability cost picture in our observability beyond CloudWatch post if migrating workloads to OpenTelemetry + Managed Prometheus + Grafana.

What This Post Doesn’t Cover

• Cross-Account Observability — CloudWatch’s central-observability pattern is feature-rich but adds its own cross-account read charges; covered separately.
• Application Signals — the modern application performance management feature on CloudWatch has per-monitored-service pricing; covered separately.
• AWS Managed Service for Prometheus (AMP) comparison — different pricing model (per sample ingested + per query); covered in the Prometheus cardinality post.
• Lambda Insights pricing — separate add-on at $0.20/M function invocations enhanced; covered in the Lambda cost optimization series.

If You Only Do One Thing This Week

Set CloudWatch Logs retention to 30 days (or less) on every log group via a one-time script: aws logs describe-log-groups --query 'logGroups[?!retentionInDays].logGroupName' --output text | xargs -I{} aws logs put-retention-policy --log-group-name {} --retention-in-days 30. Log groups with no retention policy currently keep logs forever, billing at $0.03/GB-month storage in perpetuity. Setting a default retention is non-destructive (you can always change it back) and starts the cleanup of accumulated old logs within a day. Pair with a Service Control Policy that enforces a maximum retention period on new log groups and the storage line stops growing.

For logs sampling and structured-logging patterns to reduce the ingestion line, the CloudWatch logging costs post covers the application-side techniques.