Cloud Parts

Amazon CloudWatch

AWS’s built-in monitoring service: metrics from every AWS service, logs, alarms and dashboards, and now traces, OpenTelemetry and PromQL, billed per metric, per GB and per alarm.

What it is
Observability
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
6 October 2026

What it is

Most AWS services publish metrics to CloudWatch automatically and at no charge; EC2, for example, reports every five minutes, or every minute if you pay for detailed monitoring. You add your own numbers with the PutMetricData API or, since June 2026, as OpenTelemetry metrics sent over OTLP, which CloudWatch keeps for 15 months and lets you query in PromQL. A classic metric is identified by a namespace, a name and up to 30 dimensions; CloudWatch keeps 1-minute points for 15 days, 5-minute points for 63 days and hourly points for 455 days. Alarms compare a metric with a threshold and, when it’s crossed, notify an SNS topic, scale an Auto Scaling group, stop or recover an EC2 instance, or invoke a Lambda function. Dashboards chart metrics and logs, across accounts and Regions if you want.

CloudWatch Logs stores log events in log groups and streams. Lambda sends every function’s logs there by default, and the CloudWatch agent ships files from EC2 and on-premises servers. Logs Insights queries them in its own query language, OpenSearch PPL or SQL, billed per GB scanned; metric filters turn matching lines into metrics you can alarm on, and subscription filters stream events to Kinesis, Firehose, Lambda or OpenSearch. Log data is kept forever unless you set a retention period on the group.

Around that core AWS keeps adding services under the CloudWatch name: Synthetics canaries (scheduled scripts in Node.js, Python or Java that run as Lambda functions against your endpoints), RUM for real browser sessions, Application Signals for automatic latency, error and request dashboards with SLOs, Container, Lambda and Database Insights, and tracing: X-Ray’s trace map and traces now live in the CloudWatch console, and Transaction Search can store every span as structured logs. In September 2026 AWS launched CloudWatch Omni, an AI-assisted layer that discovers services from your telemetry and writes SQL or PromQL from plain-language questions. The X-Ray SDKs and daemon entered maintenance mode in February 2026, and AWS recommends OpenTelemetry instead.

Why teams pick it

  • Already on: AWS services send metrics, and often logs, with no setup, and basic metrics cost nothing
  • Alarms act on AWS directly: scale an Auto Scaling group, recover an instance, page through SNS, run a Lambda function
  • Native OTLP endpoints for metrics, logs and traces, and PromQL for metrics, so instrumentation and queries aren’t CloudWatch-specific
  • Cross-account observability: one monitoring account can see metrics, logs and traces from many source accounts, linked through AWS Organizations

Watch out for

  • Many meters: custom metrics, GB of logs ingested and stored, GB scanned by queries, alarms, canary runs, RUM events and each Insights feature. A dimension with many values multiplies classic custom metrics, each billed per month
  • Log groups keep data forever by default, so storage grows until someone sets a retention period
  • Two metric systems side by side, Classic (per metric, Metrics Insights) and OpenTelemetry (per GB, PromQL), with different prices and query languages
  • Built around AWS accounts and Regions: other clouds and on-premises servers need the CloudWatch agent or an OpenTelemetry collector to send data in

Alternatives

What all observability have in common →

How it fits with other technologies

Publish a metric, alarm on load balancer errors, query logs · bash

aws cloudwatch put-metric-data --namespace Shop --metric-name OrdersPlaced \
  --dimensions Service=checkout --value 1 --unit Count

# page on-call when targets behind the ALB return more than 50 5xx in 5 minutes
aws cloudwatch put-metric-alarm --alarm-name api-5xx \
  --namespace AWS/ApplicationELB --metric-name HTTPCode_Target_5XX_Count \
  --dimensions Name=LoadBalancer,Value=app/shop/50dc6c495c0c9188 \
  --statistic Sum --period 300 --evaluation-periods 1 --threshold 50 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:oncall

# errors per 5 minutes over the last hour, with Logs Insights
aws logs start-query --log-group-name /ecs/checkout \
  --start-time $(date -d '-1 hour' +%s) --end-time $(date +%s) \
  --query-string 'filter level = "error" | stats count(*) by bin(5m)'

What you pay for#

The main meters, as the CloudWatch pricing page’s worked examples use them for US East. Other Regions differ, and most features have a small free tier.

MeterPriceNotes
Basic metrics from AWS servicesFreeEC2 at 5-minute resolution; 1-minute detailed monitoring is charged per metric
Custom metrics (Classic)$0.30 per metric per month for the first 10,000$0.10 from 10,001 to 250,000, less beyond; each unique combination of dimensions is a separate metric
OpenTelemetry metrics$0.50 per GB ingestedIncludes 15 months of storage, with no charge per series or per API call
Logs ingested (Standard class)$0.50 per GBStorage is billed per GB compressed; the Infrequent Access class has a lower ingestion price and a subset of features
Logs Insights queriesPer GB scannedNarrow the time range and log groups to scan less
Alarms$0.10 per standard-resolution alarm metric per month$0.30 for high resolution; $0.50 per composite alarm
Live Tail$0.01 per minuteStreaming log events to the console as they arrive

See it in a real stack

No architecture uses Amazon CloudWatch yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2009–2026

CloudWatch launched in public beta on 18 May 2009, together with Elastic Load Balancing and Auto Scaling, as three parts of one idea: measure EC2 instances and load balancers (CPU, disk and network use, request rates and latency) and act on the numbers automatically. Werner Vogels wrote that Amazon itself monitored every resource in real time and automated new capacity from that data, and the launch gave customers the same tools. Auto Scaling ran on CloudWatch metrics from the first day, at no extra charge.

The service grew outward from EC2: custom metrics for your own numbers in May 2011, CloudWatch Logs for operating system and application log files in July 2014, dashboards in October 2015, Logs Insights for interactive log queries in November 2018, Synthetics canaries generally available in April 2020, real-user monitoring in November 2021, and Application Signals for application performance monitoring in June 2024.

In 2026 AWS moved CloudWatch onto open standards: native OpenTelemetry metrics with PromQL in June, managed Prometheus collectors in July and, in September, CloudWatch Omni, which also brings in Azure workloads. X-Ray’s traces moved into the CloudWatch console, and its own SDKs gave way to OpenTelemetry.

Why it’s built this way

Free basic metrics for every AWS service
Monitoring came bundled so that customers could build scaling and recovery on it without deploying anything. Auto Scaling ran on that data from the first day.
Older data rolled up, not deleted
CloudWatch keeps full 1-minute resolution for 15 days, then 5-minute points to 63 days and hourly points to 455 days, so you get 15 months of history without keeping every raw point.
Logs as a separate store, joined by metric filters
CloudWatch Logs arrived five years after metrics. Metric filters extract numbers from log lines and turn them into CloudWatch metrics, so the same alarms and Auto Scaling actions work on log data.
Speak OpenTelemetry and PromQL
AWS’s own pitch for the 2026 change: teams already using OpenTelemetry, Prometheus or Grafana can make CloudWatch a destination that fits their existing tools, instead of rewriting instrumentation and queries.

Timeline

  1. 2009

    Launches on 18 May with Elastic Load Balancing and Auto Scaling

  2. 2011

    Custom metrics in May

  3. 2014

    CloudWatch Logs in July

  4. 2018

    Logs Insights in November

  5. 2021

    Real-user monitoring (RUM) in November

  6. 2024

    Application Signals generally available in June

  7. 2026

    OpenTelemetry metrics with PromQL in June; CloudWatch Omni in September

Sources21 · facts checked 6 October 2026

Improve this page on GitHub