---
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.factualminds.com/blog/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-06-13T00:00:00.000Z
author: palaniappan-p
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';

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.

<PricingHeroStats
  stats={[
    { value: '$0.50', label: 'Logs ingestion / GB', note: 'The single biggest CW line on most accounts' },
    { value: '$0.30', label: 'Custom metric / month', note: 'Tiered down at scale; cardinality is the trap' },
    { value: '$3', label: 'Dashboard / month', note: 'First 3 free; audit the rest' },
    {
      value: '10',
      label: 'Distinct billing dimensions',
      note: 'Logs, metrics, alarms, dashboards, Synthetics, RUM, X-Ray, Container Insights, Lambda Insights, cross-region',
    },
  ]}
  caption="us-east-1 list prices, June 2026. Verify against the AWS CloudWatch pricing page for your region."
/>

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

## The 10 CloudWatch Billing Dimensions

<PricingDimensionTable
  title="CloudWatch pricing breakdown — us-east-1, June 2026"
  intro="The Logs ingestion line dominates most bills. Cardinality on custom metrics and alarm count are the next two leaders."
  region="us-east-1"
  dimensions={[
    {
      name: 'Logs ingestion',
      unitPrice: '$0.50 / GB',
      example: '500 GB / month',
      monthly: '$250.00',
      note: 'Largest line on most accounts',
      highlight: true,
    },
    {
      name: 'Logs storage',
      unitPrice: '$0.03 / GB-month',
      example: '5 TB retained 90 days',
      monthly: '~$450',
      note: 'Cheaper to export to S3 for long-term',
    },
    {
      name: 'Logs Insights queries',
      unitPrice: '$0.005 / GB scanned',
      example: '10 TB scanned / month',
      monthly: '$50.00',
      note: 'Each query scans the entire matching window',
    },
    {
      name: 'Custom metrics — first 10K',
      unitPrice: '$0.30 / metric / month',
      example: '10K unique metrics',
      monthly: '$3,000',
      note: 'Cardinality is the trap; tiered down above 10K',
      highlight: true,
    },
    {
      name: 'Custom metrics — over 10K',
      unitPrice: 'Tiered: $0.10 → $0.05 → $0.02',
      example: '100K unique metrics',
      monthly: '~$12K',
      note: 'High-cardinality dimensions explode the count',
    },
    {
      name: 'Standard alarms',
      unitPrice: '$0.10 / alarm / month',
      example: '1000 alarms',
      monthly: '$100',
      note: '1-minute evaluation period',
    },
    {
      name: 'High-resolution alarms',
      unitPrice: '$0.30 / alarm / month',
      example: '100 alarms',
      monthly: '$30',
      note: '10-second evaluation; use sparingly',
    },
    {
      name: 'Composite alarms',
      unitPrice: '$0.50 / alarm / month',
      example: '50 composite alarms',
      monthly: '$25',
      note: 'For multi-metric incident logic',
    },
    {
      name: 'Anomaly detection',
      unitPrice: '$0.30 / metric / month',
      example: '100 metrics with anomaly bands',
      monthly: '$30 + alarm cost',
      note: 'Worth it on key SLI metrics',
    },
    {
      name: 'Dashboards (after 3 free)',
      unitPrice: '$3 / dashboard / month',
      example: '50 dashboards',
      monthly: '$141 (50 - 3 × $3)',
      note: 'Audit dashboard view counts',
      highlight: true,
    },
    {
      name: 'Synthetics canaries',
      unitPrice: '$0.0012 / canary run',
      example: 'Canary every 1 min × 10 canaries',
      monthly: '~$520',
      note: 'Frequency × canary count × $0.0012',
    },
    {
      name: 'RUM events',
      unitPrice: '$1 / 100K events',
      example: '10M page-view events',
      monthly: '$100',
      note: 'Real User Monitoring; bills per event',
    },
    {
      name: 'X-Ray traces',
      unitPrice: '$5 / M recorded + $0.50/M scanned',
      example: '50M traces / month',
      monthly: '$250 + scan cost',
      note: '100K recorded + 1M scanned free',
    },
    {
      name: 'Container Insights (EKS)',
      unitPrice: 'Per metric per cluster + Logs ingest',
      example: '50-node cluster',
      monthly: '$500–$2,000 / cluster',
      note: 'Disable on non-prod clusters',
      highlight: true,
    },
  ]}
  footnote="The 14 dimensions here cover the most common CloudWatch line items. Less-common features (Live Tail, Metric Streams, Contributor Insights) have additional pricing."
/>

## 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.

<BillSurpriseCallout
  variant="surprise"
  title="Container logs ingested at default verbosity through FluentBit"
  amount="$500–$5,000 / month per cluster"
>
  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 —
  $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.
</BillSurpriseCallout>

## 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.

<BillSurpriseCallout
  variant="trap"
  title="Metric published with user ID as a dimension"
  amount="$30–$3,000 / month per high-cardinality metric"
>
  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 — $15,000 in the first tier. 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.
</BillSurpriseCallout>

## 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

<PricingDecisionCard
  headline="CloudWatch Logs for active queries; S3 for retention; custom metrics with low cardinality; alarms with hygiene; dashboards consolidated."
  useWhen={[
    'CloudWatch Logs for application logs that get actively queried — last 14–30 days',
    'Logs Insights for ad-hoc investigation; pre-aggregate with metric filters for routine dashboards',
    'Custom metrics with pre-aggregated dimensions — account tier, service name, region — not per-user',
    'EMF (Embedded Metric Format) for high-volume metrics; auto-aggregation reduces cost',
    'High-resolution alarms only on customer-facing SLI metrics where 10-second evaluation matters',
    'Container Insights selectively — production EKS clusters where the observability matters operationally',
  ]}
  avoidWhen={[
    'CloudWatch Logs as the long-term retention store — S3 lifecycle is 80–95% cheaper for compliance retention',
    'Custom metrics with high-cardinality dimensions (user ID, request URL, container ID) — pre-aggregate',
    'Default high-resolution alarming on everything — $0.30 × thousands compounds quickly',
    'Container Insights on dev / staging EKS clusters where the observability is rarely consulted',
    'Synthetics canaries running every 10 seconds when 1-minute would do — 6× cost for usually-no benefit',
    'Dashboards created and never deleted — audit quarterly',
  ]}
  footnote="CloudWatch is rarely the wrong observability primitive. The bill problems are almost always log verbosity, metric cardinality, and alarm/dashboard sprawl — none of which require migrating off CloudWatch."
/>

## 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](/blog/aws-observability-beyond-cloudwatch-otel-prometheus-grafana-2026/) 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](/blog/prometheus-cardinality-explosion-amp-cloudwatch-cost-control/).
- **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](/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 — $25/day, $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–$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–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 can reduce long-term log storage cost by 80–95% 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–100 dashboards at $150–$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.

---

*Source: https://www.factualminds.com/blog/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/*