AWS CloudWatch
Amazon CloudWatch is AWS's native observability service — it collects metrics (numeric measurements), logs (event records), and traces from AWS resources and your applications, and lets you alarm, dashboard, and automate on them. Nearly every AWS service publishes metrics to CloudWatch automatically (EC2 CPU, Lambda invocations, RDS connections), and its alarms are the trigger mechanism behind autoscaling, notifications, and automated responses.
CloudWatch is the default answer to "how is my AWS infrastructure doing, and how do I know when something's wrong?" It spans the observability pillars — metrics, logs, and (via X-Ray integration) tracing — for the AWS ecosystem, and its tight integration is both its strength (everything's already wired up) and the reason you reach for it first on AWS. Everything on the general monitoring page applies; this is the AWS-native implementation.
TL;DR
- CloudWatch collects metrics, logs, and alarms for AWS resources and your apps — AWS's built-in observability layer.
- Most AWS services publish metrics automatically (CPU, invocations, errors, latency); you can also publish custom metrics from your app.
- CloudWatch Logs centralizes logs (from Lambda, ECS, EC2 agents), searchable with Logs Insights (a query language).
- Alarms watch a metric against a threshold and trigger actions: notify (via SNS), autoscale (EC2/ECS scaling is CloudWatch-alarm-driven), or run automation.
- Dashboards visualize metrics; X-Ray adds distributed tracing for request flows.
- Watch the cost — high-cardinality custom metrics, verbose logs, and frequent API calls add up; and default metrics can be coarse (e.g. no memory metric without the agent).
Core Concepts
Metrics
CloudWatch metrics are time-series numeric data. AWS services publish them automatically — EC2 CPU utilization, Lambda invocations/errors/duration, RDS connections, S3 request counts, load balancer request/latency — so basic monitoring works with zero setup. You can also publish custom metrics from your application (business metrics, app-specific measurements). Metrics have dimensions (labels like instance ID) for filtering, and you view them as graphs, aggregate them (avg/sum/p99), and alarm on them. The golden-signal thinking from metrics applies.
⚠️ A classic gotcha: CloudWatch does not collect OS-level metrics like memory or disk usage by default (it sees the hypervisor's view). You install the CloudWatch agent on EC2 to get memory, disk, and custom OS metrics.
Logs
CloudWatch Logs centralizes log data — Lambda functions log there automatically, ECS/EKS containers ship logs to it, and the CloudWatch agent forwards EC2/on-prem logs. Logs are organized into log groups (per application/service) and log streams. CloudWatch Logs Insights provides a query language to search and analyze them at scale:
This is AWS's log aggregation — centralized, searchable logs without running your own ELK stack, though many teams still ship to dedicated tools (Datadog, OpenSearch) for richer analysis.
Alarms: The Automation Trigger
Alarms are CloudWatch's most consequential feature — they watch a metric against a threshold over a period and enter ALARM/OK/INSUFFICIENT_DATA states, triggering actions:
Crucially, AWS autoscaling is built on CloudWatch alarms — scaling policies fire when a metric alarm (CPU, request count, custom) crosses a threshold. Alarms also drive alerting (via SNS to your notification channels) and automated remediation. Best practice, from SRE: alarm on user-impacting symptoms (error rates, latency, queue depth), not just resource metrics, to avoid noise.
Dashboards and Tracing
- Dashboards — customizable views of metrics and alarms across services, for at-a-glance health.
- X-Ray — AWS's distributed tracing, integrated with CloudWatch, follows requests across services to find bottlenecks and errors.
- Container/Lambda Insights — curated dashboards and metrics for ECS/EKS and Lambda.
- Synthetics — canaries that continuously probe endpoints (uptime/functionality checks).
Common Mistakes
Assuming Memory/Disk Metrics Exist by Default
CloudWatch's default EC2 metrics are hypervisor-level (CPU, network, disk I/O) — not memory usage or disk space. You must install the CloudWatch agent to get those. Teams debugging a memory issue are surprised there's no memory metric until they add the agent.
Alarming on Everything (Alert Fatigue)
Creating alarms on every metric and paging on all of them trains the team to ignore CloudWatch — the alerting failure mode. Alarm on user-impacting symptoms (error rate, latency, availability) with meaningful thresholds; route noise to dashboards/tickets, not pages. See SRE.
Ignoring CloudWatch Costs
Custom metrics (billed per metric), high-resolution metrics, verbose log ingestion/storage, and frequent PutMetricData/GetMetricData API calls add up — CloudWatch can become a surprising line item. Set log retention (don't keep logs forever by default), avoid high-cardinality custom metrics, and monitor the CloudWatch bill itself. See cloud costs.
Logs Without Retention Policies
CloudWatch Logs default to never expire — logs accumulate and bill for storage indefinitely. Set retention periods per log group (e.g. 30/90 days) matched to your needs, and export long-term archives to cheaper S3 if required.
Treating It as Full APM
CloudWatch covers metrics, logs, alarms, and basic tracing well, but for deep application performance monitoring, error grouping, and rich developer-focused observability, dedicated tools (Datadog, Sentry, New Relic) often do more. Many AWS shops use CloudWatch for infrastructure and a specialized tool for app-level observability.
FAQ
What does CloudWatch monitor automatically?
Most AWS services publish metrics to CloudWatch with no setup — EC2 CPU/network/disk-I/O, Lambda invocations/errors/duration, RDS connections/CPU, load balancer request counts/latency, and many more. This gives baseline monitoring immediately. What it does not capture by default is OS-level memory and disk-space usage — those need the CloudWatch agent.
How does CloudWatch relate to autoscaling?
AWS autoscaling is driven by CloudWatch alarms — you define scaling policies that trigger when a metric alarm crosses a threshold (e.g. average CPU > 70% → add instances; < 30% → remove). So CloudWatch isn't just monitoring; its alarms are the mechanism that makes EC2 Auto Scaling and ECS service scaling respond to load.
CloudWatch or Datadog/Prometheus?
CloudWatch is the built-in, zero-setup choice for AWS resources, with tight integration and alarm-driven automation. Dedicated tools (Datadog, Prometheus/Grafana, Sentry) offer richer dashboards, better cross-service correlation, and stronger app-level observability. Many AWS teams use CloudWatch for infrastructure metrics/alarms and a specialized tool for application observability — or ship CloudWatch data into their central platform.
How do I search my logs?
Use CloudWatch Logs Insights — a query language over your log groups (filter, stats, sort, fields) to search, aggregate, and analyze logs at scale. It's AWS's built-in log aggregation query tool. For very large-scale or complex analysis, teams sometimes forward logs to OpenSearch or a dedicated platform.
How do I control CloudWatch costs?
Set log retention (don't keep logs forever — the default), avoid high-cardinality custom metrics (each is billed), reduce high-resolution metrics where not needed, batch PutMetricData calls, and archive long-term logs to S3. CloudWatch costs creep up quietly through logs and custom metrics — audit them. See cloud costs.
Related Topics
- Monitoring — The concept CloudWatch implements
- Metrics — Time-series measurements and golden signals
- Logging / Log Aggregation — What CloudWatch Logs does
- Distributed Tracing — X-Ray integration
- Alerting — Building good alarms, not noise
- SRE — Symptom-based alerting and observability practice
- AWS — The provider overview