
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
What Amazon CloudWatch uses
- Amazon CloudWatchreceives logs and metrics by default fromAWS Lambda
- Amazon CloudWatchgathers metrics and logs via its agent fromAmazon EC2
- Amazon CloudWatchcollects request and target metrics fromAWS Application Load Balancer
- Amazon CloudWatchmonitors clusters with Container Insights inAmazon EKS
- Amazon CloudWatchingests OTLP metrics, logs and traces fromOpenTelemetry
- Amazon CloudWatchaccepts PromQL queries written forPrometheus
- Amazon CloudWatchis queried by a built-in data source inGrafana
- Amazon CloudWatchsends alarm notifications throughAmazon SNS
- Amazon CloudWatchstreams logs via subscription filters toAmazon Kinesis Data Streams
- Amazon CloudWatchexports log groups toAmazon S3
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.
| Meter | Price | Notes |
|---|---|---|
| Basic metrics from AWS services | Free | EC2 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 ingested | Includes 15 months of storage, with no charge per series or per API call |
| Logs ingested (Standard class) | $0.50 per GB | Storage is billed per GB compressed; the Infrequent Access class has a lower ingestion price and a subset of features |
| Logs Insights queries | Per GB scanned | Narrow 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 minute | Streaming 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
- 2009
Launches on 18 May with Elastic Load Balancing and Auto Scaling
- 2011
Custom metrics in May
- 2014
CloudWatch Logs in July
- 2018
Logs Insights in November
- 2021
Real-user monitoring (RUM) in November
- 2024
Application Signals generally available in June
- 2026
OpenTelemetry metrics with PromQL in June; CloudWatch Omni in September
- Amazon press release: AWS launches CloudWatch, Auto Scaling and Elastic Load Balancing (May 2009)
- Werner Vogels: Automating the management of Amazon EC2 using CloudWatch, Auto Scaling and ELB (May 2009)
- AWS News Blog: New, custom metrics for Amazon CloudWatch (May 2011)
- AWS News Blog: Store and monitor OS and application log files with Amazon CloudWatch (July 2014)
- AWS News Blog: CloudWatch dashboards, create and use customized metrics views (Oct 2015)
- AWS News Blog: New, Amazon CloudWatch Logs Insights (Nov 2018)
- AWS News Blog: New, use CloudWatch Synthetics to monitor sites, API endpoints and web workflows (Apr 2020)
- AWS News Blog: New, real-user monitoring for Amazon CloudWatch (Nov 2021)
- AWS What’s New: CloudWatch Application Signals is generally available (June 2024)
- AWS What’s New: CloudWatch introduces native OpenTelemetry metrics with PromQL querying (June 2026)
- AWS What’s New: CloudWatch announces managed Prometheus collectors (July 2026)
- AWS What’s New: Amazon CloudWatch Omni (Sep 2026)
Sources21 · facts checked 6 October 2026
- AWS docs: What is Amazon CloudWatch?
- Amazon CloudWatch pricing (worked examples)
- AWS docs: CloudWatch concepts (dimensions, retention of metric data)
- AWS docs: Manage detailed monitoring for EC2 instances
- AWS docs: Alarm actions
- AWS docs: Working with log groups and log streams (retention)
- AWS docs: Analyzing log data with CloudWatch Logs Insights (three query languages)
- AWS docs: CloudWatch Logs subscription filters
- AWS docs: Exporting log data to Amazon S3
- AWS docs: Sending Lambda function logs to CloudWatch Logs
- AWS docs: CloudWatch Logs log classes (Standard and Infrequent Access)
- AWS docs: Synthetic monitoring (canaries)
- AWS docs: CloudWatch Transaction Search
- AWS X-Ray docs: Use a console (X-Ray in the CloudWatch console)
- AWS X-Ray docs: Instrumenting your application (SDK and daemon maintenance notice)
- AWS docs: CloudWatch cross-account observability
- AWS docs: Application Load Balancer CloudWatch metrics
- AWS CLI reference: put-metric-data
- AWS CLI reference: put-metric-alarm
- AWS CLI reference: logs start-query
- Grafana docs: Amazon CloudWatch data source (built in)