AmazonCloudWatch

AWS monitoring and observability service for collecting metrics, logs, traces, and setting alarms across AWS infrastructure and applications.
Platform & Operations. Last reviewed July 2026.
In this entry

3serious gotchas
3regular gotchas
5tips
Definition
Amazon CloudWatch is AWS’s native monitoring and observability platform. It collects metrics from AWS services and custom applications, ingests logs, supports alarms and automated actions, and hosts dashboards for operational visibility. CloudWatch Logs Insights provides queryable log analytics; CloudWatch Container Insights adds Kubernetes and ECS-focused telemetry; Application Signals (see separate glossary entry) adds APM-style service health on top of the same platform. CloudWatch complements — not replaces — CloudTrail (API audit) and X-Ray/Application Signals (distributed tracing).
When to use it
- Baseline monitoring for every AWS workload — default service metrics, custom metrics, and alarms before adding third-party tools
- Centralized log ingestion from Lambda, EC2 (via CloudWatch Agent), API Gateway, RDS, and VPC Flow Logs
- Operational automation — alarm → SNS, Auto Scaling, Lambda remediation, or EventBridge workflows
- Teams standardizing on AWS-native observability with optional OpenTelemetry export to CloudWatch
When not to use it
- Multi-cloud unified observability as the primary requirement — CloudWatch is AWS-scoped; Datadog, Grafana Cloud, or similar cover cross-cloud
- Indefinite log retention at scale without archival — long retention in CloudWatch Logs is expensive; tier to S3 or OpenSearch
- Replacing a mature third-party APM with dashboards alone — Application Signals or a dedicated APM fills application-level gaps CloudWatch metrics alone miss
Tips
- Enable detailed monitoring (one-minute EC2 metrics) for production instances where five-minute defaults hide spikes
- Set log retention policies explicitly — “never expire” is the default cost trap on busy Lambda log groups
- Attach a runbook link to every production alarm in SNS or ticketing — alarms without response procedures create fatigue
- Use Embedded Metric Format (EMF) or the PutMetricData API for business KPIs alongside infrastructure metrics
- Enable Container Insights on EKS/ECS early — retrofitting daemonsets after an incident is harder than baseline deployment
Gotchas
Serious
- Logs cost surprise: High-volume debug logging to CloudWatch without sampling or retention caps can exceed compute spend.
- Alarm without action: Alarms that notify nobody or trigger no runbook train teams to ignore the monitoring stack entirely.
- Metric gap during incidents: Default EC2 five-minute metrics can miss brief CPU saturation that triggers user-visible latency.
Regular
- CloudWatch and CloudTrail answer different questions — mixing them in postmortems causes confusion about “who” vs “what happened.”
- Cross-account observability requires deliberate setup — dashboards do not automatically aggregate all organization accounts.
- Custom metrics have charges beyond the free tier — high-cardinality dimensions (per-user IDs) explode cost.
Official references
- What is Amazon CloudWatch? — metrics, alarms, and dashboards
- CloudWatch Logs — log groups, streams, and Insights queries
Related FactualMinds content
Ask
Our AWS-certified team implements, audits and tunes Amazon CloudWatch in production. Tell us what you are building.
Pictures:James Murray in the Scriptorium (public domain); Card Division of the Library of Congress, 1900–1920 (public domain); Salle des catalogues, Bibliothèque Mazarine, Paris, Marie-Lan Nguyen (CC BY 2.0); Copyright card catalog drawer, Michael Holley Swtpc6800 (public domain); Type in sort case, Edinburgh City of Print (CC BY 2.0); Widener Library reading room, 1920 (public domain). Via Wikimedia Commons.

