Amazon CloudWatch

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

• AWS Cloud Security Services
• AWS Managed Services
• AWS Well-Architected Review Checklist