---
title: Amazon CloudWatch Pricing: The 10 Billing Dimensions Behind Your Observability Bill
description: CloudWatch bills across ten distinct dimensions: Logs ingestion at $0.50/GB, Logs storage, custom metrics with cardinality multipliers, alarms tiered by resolution and type, dashboards at $3 each, Synthetics canary runs, RUM events, X-Ray traces, Container Insights, and cross-region replication. Logs ingestion is the largest line on most accounts.
url: https://www.joinhorizon.co/blog/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: kevin-w
category: Cost Optimization & FinOps
tags: aws-cloudwatch, cloudwatch-pricing, aws-pricing, cost-optimization, finops, observability
---
# Amazon CloudWatch Pricing: The 10 Billing Dimensions Behind Your Observability Bill
> CloudWatch bills across ten distinct dimensions: Logs ingestion at $0.50/GB, Logs storage, custom metrics with cardinality multipliers, alarms tiered by resolution and type, dashboards at $3 each, Synthetics canary runs, RUM events, X-Ray traces, Container Insights, and cross-region replication. Logs ingestion is the largest line on most accounts.
import PricingHeroStats from '~/components/blog/PricingHeroStats.astro';
import PricingDimensionTable from '~/components/blog/PricingDimensionTable.astro';
import BillSurpriseCallout from '~/components/blog/BillSurpriseCallout.astro';
import PricingDecisionCard from '~/components/blog/PricingDecisionCard.astro';
import PricingCalculatorCta from '~/components/blog/PricingCalculatorCta.astro';
CloudWatch is the AWS observability primitive with the most pricing dimensions of any single service. Core lines (Logs ingestion, Logs storage, Logs Insights queries, custom metrics, alarms, dashboards, Synthetics canaries, RUM events, X-Ray traces, and Container Insights) each have their own per-unit rate, free tier, and cardinality multiplier. Since **July 31, 2026**, Prometheus scrape into CloudWatch adds **managed collector-hours** and **OpenTelemetry metric ingestion ($/GB)** as additional meters when you use [CloudWatch managed Prometheus collectors](https://www.joinhorizon.co/blog/cloudwatch-managed-prometheus-collectors-july-2026/). The bill on a mature account is rarely under five figures, and Logs ingestion is almost always the largest line.
> **Amazon CloudWatch pricing** bills custom metrics, log ingestion and storage, alarms, dashboards, and Container Insights separately. In us-east-1 (June 2026), log ingestion is $0.50/GB. Most surprises come from verbose application logs, high-cardinality custom metrics, and Container Insights on large EKS fleets.
| Dimension | us-east-1 | Trap |
| ------------------ | ------------------ | ---------------------- |
| Log ingestion | $0.50/GB | Unsampled app logs |
| Custom metrics | $0.30/metric-month | Cardinality explosion |
| Alarms | $0.10/alarm-month | One alarm per resource |
| Container Insights | Per pod/node | EKS fleet multiplier |
This post is the bill story. For the operational angle (alarm hygiene, log structure, dashboard design), see our [CloudWatch observability best practices guide](https://www.joinhorizon.co/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/). For the specific case of logs cost control, the [CloudWatch logging costs post](https://www.joinhorizon.co/blog/aws-cloudwatch-logging-costs-observability/) covers sampling and structured-logging patterns in depth.
## CloudWatch billing dimensions
_If you only audit one dimension first, sample or filter **log ingestion**, the largest line on most observability-heavy accounts._
## 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.** CloudWatch Logs defaults to "Never expire". Set 14 to 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.
Container workloads on EKS/ECS often ship every container's stdout/stderr to CloudWatch Logs via FluentBit at default
settings. A busy cluster with 200 pods producing 100 MB of logs per pod per day generates 20 GB/day per cluster, or
$300/month per cluster in ingestion alone. Configure FluentBit with `Path_Key`, `Tag`, and `Refresh_Interval` to drop
non-essential containers, use the AWS for Fluent Bit `ExcludePath` to filter healthcheck endpoint logs, and apply
CloudWatch retention aggressively on container log groups.
## Custom metric cardinality: the hidden explosion
_Figure: custom metric cardinality in the article. A dimension with many values becomes many custom metrics. Log class and metric streams are an earlier diagram. Rates stay in the article. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/card.drawio)._
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.
Every unique user ID becomes a unique billable metric. A B2C app with 50K daily active users publishing per-user
metrics creates 50K unique metrics within a day, which bills about $7,000/month ($3,000 for the first 10K plus $4,000 for the next 40K). Pre-aggregate at the application layer
(publish "requests_per_account_tier" instead of "requests_per_user_id"); use EMF (Embedded Metric Format) which
automatically rolls up; use Contributor Insights for high-cardinality dimensions where you need top-N analysis.
## Alarm sprawl: the untracked multiplier
_Figure: alarm sprawl in the article. One metric can feed several alarms, and each alarm is billed. Thresholds stay in the article. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/alarms.drawio)._
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, so delete them.
- 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.
## Managed Prometheus collectors and OTLP ingestion (July 31, 2026)
On **July 31, 2026**, AWS shipped [CloudWatch managed Prometheus collectors](https://www.joinhorizon.co/blog/cloudwatch-managed-prometheus-collectors-july-2026/): agentless scrapers that pull `/metrics` from EKS, EC2, ECS, MSK, and OpenSearch into a CloudWatch OpenTelemetry dataset. Pricing is **not** the classic custom-metric per-series model when you pick the CloudWatch destination:
| Meter | Published rate (confirm on AWS) | What drives it |
| ------------------------- | ------------------------------------------ | --------------------------------------------------------- |
| **OTLP metric ingestion** | **$0.50 / GB** uncompressed OTLP payload | Targets × metrics × scrape interval × bytes per datapoint |
| **Collector-hours** | **$0.04 / collector-hour** | One always-on scraper ≈ 744 hr/mo per scraper |
| **Samples collected** | **$0.03 / 10M samples** (AMP pricing page) | Scrape volume; separate from OTLP GB |
| **PromQL API queries** | **$0.01 / M samples scanned** | Programmatic queries only; console free |
AWS [CloudWatch pricing Example 22](https://aws.amazon.com/cloudwatch/pricing/) (100 EC2 hosts, 50 metrics each, 60s interval) illustrates **108 GB/mo OTLP → $54/mo** vs **5,000 series × $0.30 → $1,500/mo** classic custom metrics for the same shape, before collector-hour fees and VPC transfer. Halving scrape interval roughly doubles OTLP GB; classic per-series fees do not change with interval.
> **Reproduce this:** Plug your fleet into the [OTLP vs classic cost model CSV](https://www.joinhorizon.co/examples/architecture-blog-2026/cloudwatch-managed-collectors/otlp-vs-classic-cost-model.csv). Walk the [destination decision matrix](https://www.joinhorizon.co/examples/architecture-blog-2026/cloudwatch-managed-collectors/collector-destination-decision-matrix.md) before dual-writing to AMP and CloudWatch.
## 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 to $2,000/month per cluster in CloudWatch.
For cost-sensitive deployments, the alternatives:
- **Managed collectors → CloudWatch OTLP (July 2026).** Agentless scrape with GB-based ingestion instead of per-series custom metrics when label hygiene is in place; see [managed collectors post](https://www.joinhorizon.co/blog/cloudwatch-managed-prometheus-collectors-july-2026/).
- **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, which is 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, which is modest. The bill driver is event volume; configure RUM sampling at the application level for very high-traffic sites.
## When to use each 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 to 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 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](https://www.joinhorizon.co/blog/aws-observability-beyond-cloudwatch-otel-prometheus-grafana-2026/) and the [July 2026 managed collectors guide](https://www.joinhorizon.co/blog/cloudwatch-managed-prometheus-collectors-july-2026/) if migrating scrape workloads to agentless collectors or OpenTelemetry + Managed Prometheus + Grafana.
## More in this series
Part of the **AWS Service Pricing** series (June 2026).
- Previous: [Part 8](https://www.joinhorizon.co/blog/amazon-eventbridge-pricing-events-pipes-schema-archive/)
- Next: [Part 10](https://www.joinhorizon.co/blog/aws-cloudtrail-pricing-data-events-lake-insights/)
- Browse all: [Cost Optimization & FinOps category](https://www.joinhorizon.co/category/cost-optimization-and-finops/)
- FinOps pillar: [FinOps shift-left: cost feedback in the pull request](https://www.joinhorizon.co/blog/aws-finops-shift-left-engineering-cost-ownership/)
## 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:** per-sample ingest + per-query; collector → AMP destination uses the same CreateScraper surface. Covered in the [Prometheus cardinality post](https://www.joinhorizon.co/blog/prometheus-cardinality-explosion-amp-cloudwatch-cost-control/) and [managed collectors post](https://www.joinhorizon.co/blog/cloudwatch-managed-prometheus-collectors-july-2026/).
- **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](https://www.joinhorizon.co/blog/aws-cloudwatch-logging-costs-observability/) covers the application-side techniques.
## FAQ
### Why is CloudWatch Logs ingestion so expensive at $0.50/GB?
Logs ingestion is the largest CloudWatch line on most accounts because it bills per GB of compressed log data ingested into the service. A noisy application logging at INFO level can easily generate 50 GB/day per service, which is $25/day or $750/month per service. Across a microservices fleet of 50 services, that is $37,500/month in ingestion alone before storage and Logs Insights queries. The mitigations: sample non-essential logs (DEBUG, verbose access logs), use structured logging with field-level filtering, route low-value logs to S3 directly via Firehose rather than to CloudWatch Logs, and apply retention policies aggressively.
### How does custom metric cardinality drive the bill up?
CloudWatch custom metrics bill per unique metric per month. A metric with 5 dimensions, each with 100 possible values, can create 10 billion unique metric combinations (the cardinality). Each unique combination is a billable metric at $0.30/month for the first 10K, then $0.10 for the next 240K, $0.05 for the next 750K, and $0.02 above 1M. A poorly-designed metric with a high-cardinality dimension (request URL, user ID, container ID) can generate hundreds of thousands of unique metrics within hours. Pre-aggregate dimensions before publishing; use EMF (Embedded Metric Format) which auto-aggregates; avoid high-cardinality dimensions like user IDs entirely.
### Are CloudWatch alarms really billed per alarm?
Yes. Standard-resolution alarms (1-minute evaluation) are $0.10/alarm/month; high-resolution alarms (10-second evaluation) are $0.30/alarm/month; composite alarms are $0.50/alarm/month; anomaly detection alarms add $0.30/metric/month on top of the underlying alarm. An organization with 1000 standard alarms pays $100/month for alarming alone; if those alarms are high-resolution by default it is $300/month. Audit alarms quarterly. Many production accounts have hundreds of alarms inherited from past incidents that no one acts on anymore.
### How does Container Insights add up across an EKS fleet?
Container Insights for EKS bills per metric per cluster per month plus the underlying CloudWatch Logs ingestion for container logs. A 50-node EKS cluster with Container Insights enabled and FluentBit shipping container logs to CloudWatch Logs typically adds $500 to $2,000/month per cluster: Container Insights publishes hundreds of metrics per cluster, and the container log ingestion at $0.50/GB compounds with deployment frequency. The alternatives for cost-sensitive observability: ship container logs to S3 via Firehose at a fraction of the cost, use OpenTelemetry with Amazon Managed Service for Prometheus instead of Container Insights, or selectively enable Container Insights only on production clusters.
### What is the cheapest way to retain logs long-term?
Set the CloudWatch Logs retention period to the shortest duration that meets operational needs (typically 14 to 30 days), then export logs to S3 via subscription filters + Firehose for long-term storage. CloudWatch Logs storage at $0.03/GB-month is much more expensive than S3 Standard at $0.023/GB-month, and S3 lifecycle policies can transition older logs to S3 Standard-IA ($0.0125/GB-month) or Glacier ($0.004/GB-month). For compliance retention, this pattern cuts long-term storage cost per GB-month by 23% (S3 Standard), 58% (Standard-IA), or 87% (Glacier) compared to leaving logs in CloudWatch Logs indefinitely.
### Are CloudWatch dashboards really $3 each?
After the 3-free-per-account allowance. The first 3 dashboards per account are free; each additional dashboard is $3/month, regardless of widget count or update frequency. A large organization with shared dashboards across teams can quietly accumulate 50 to 100 dashboards at $150 to $300/month. Most of these dashboards go unviewed for months. Audit dashboard usage with CloudWatch dashboard view metrics; consolidate or delete unused ones; use Cross-Account Observability to share dashboards across accounts rather than recreating per account.
### When does X-Ray become more expensive than expected?
X-Ray includes 100K trace recorded and 1M traces scanned free per month, then bills $5/M traces recorded and $0.50/M traces scanned. A high-traffic microservices fleet at 1B requests/month with X-Ray sampling at 5% (50M traces) costs $250/month for tracing recording plus query costs on Insights and Service Maps. The bill driver is rarely the per-request rate; it is sampling rate combined with traffic volume. Reduce the sampling rate or use head-based sampling at the application boundary to control trace volume. AWS Distro for OpenTelemetry with selective sampling is a richer pattern for high-volume services where uniform 5% sampling misses interesting tails.
### How are CloudWatch managed Prometheus collectors and OTLP metrics billed?
Since July 31, 2026, agentless managed Prometheus collectors (CreateScraper API) add two meters when the destination is a CloudWatch dataset: collector-hours on the AMP scraper surface (AWS documents $0.04 per collector-hour plus $0.03 per 10M samples collected on the AMP pricing page) and CloudWatch OpenTelemetry metric ingestion at $0.50 per GB of uncompressed OTLP payload ingested, with 15 months storage included and no separate per-series custom-metric fee. PromQL API queries bill $0.01 per million samples scanned; console and dashboard queries are free. VPC data transfer between collector ENIs and targets can add cost. Model your shape with the OTLP vs classic cost CSV in the managed collectors post rather than assuming classic $0.30/metric-month applies.
---
*Source: https://www.joinhorizon.co/blog/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/*