AWS Glossary
Amazon CloudWatch
AWS monitoring and observability service for collecting metrics, logs, traces, and setting alarms across AWS infrastructure and applications.
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
Related Services
AWS Security Consulting
AWS security consulting from an AWS Select Tier Partner. 2-week assessment, 4–6 week remediation, zero disruption. IAM hardening, public exposure, compliance gaps, and continuous monitoring.
AWS Managed Services Provider | 24/7 Ops
AWS Managed Services Provider (MSP) — 24/7 monitoring, patching, security, cost optimization, and incident response.
AWS DevOps Consulting
AWS DevOps consulting — CI/CD pipeline setup, infrastructure as code (SAM/CDK), and deployment automation.
Related Articles
AWS CloudWatch Observability: Metrics, Logs, and Alarms Best Practices
CloudWatch is the most underused service on every AWS bill — and the most overspent on the ones that take it seriously. Logs, metrics, and alarm patterns that catch real outages without burying you in noise (or in the bill).
Observability Beyond CloudWatch (2026): When to Add Application Signals, ADOT, Managed Prometheus, and Grafana — and When Not To
The reflex to bolt Amazon Managed Prometheus + Grafana onto every workload is how observability bills quietly double. CloudWatch Application Signals now gives you an auto-discovered service map, SLOs, and traces with near-zero setup; AMP only earns its keep when you are PromQL-native or drowning in high-cardinality metrics — where ingestion (not retention) is the cost driver. Here is the decision matrix, an ADOT dual-export config, and the three levers that actually cut the AMP bill.
Amazon CloudWatch Pricing: The 10 Billing Dimensions Behind Your Observability Bill
CloudWatch bills across ten distinct dimensions — Logs ingestion at $0.50/GB, Logs storage, custom metrics with cardinality multipliers, alarms tiered by resolution and type, dashboards at $3 each, Synthetics canary runs, RUM events, X-Ray traces, Container Insights, and cross-region replication. Logs ingestion is the largest line on most accounts.
AWS Observability Costs: Cardinality Budgets & FinOps Limits
CloudWatch Logs Insights bills $0.005 per GB scanned and high-cardinality custom metrics multiply costs. Cardinality budgets, sampling rules, and FinOps fixes.
Logging Yourself Into Bankruptcy
Observability is not free, and the industry has collectively underpriced it. CloudWatch log ingestion, metrics explosion, and X-Ray trace volume can together exceed your compute bill — especially once AI workloads introduce high-cardinality telemetry at scale.
AWS Well-Architected Framework & Review Guide: The 6 Pillars Explained
Well-Architected reviews used to read like AWS sales decks. The 2026 version is sharper. The 6 pillars walked through with what each costs, what each covers, and how to apply them to a workload before AWS's solutions architects do it for you.
Need help with this topic?
Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.