AWS CloudWatch Observability

Metrics, logs, traces, and alarms — unified observability for all AWS services and custom apps.

AWSIntermediate

Why

CloudWatch collects metrics/logs/traces from every AWS service automatically. Alarms trigger SNS/Lambda, dashboards visualize, Logs Insights queries with SQL-like syntax. 10 custom metrics free.

When

Use for all AWS monitoring — alarms on metrics, log analysis, X-Ray traces. Avoid for cross-cloud (use Datadog) or long-term storage (use S3 export).

How

1. Metrics — aws cloudwatch put-metric-data, or EMF in logs (auto-extract) 2. Logs — CloudWatch Logs, log groups, retention, Insights queries 3. Alarms — threshold on metric, SNS action, anomaly detection 4. Dashboards — widgets, auto-refresh, share with team 5. Logs Insights — fields @timestamp, @message | filter level="error" | stats count() 6. X-Ray — traces across services, service map, sampling rules 7. Metric filters — extract metrics from log text 8. Synthetics — canary tests, monitor uptime from multiple regions

Example

# Logs Insights query — top errors last hour fields @timestamp, @message, requestId | filter level = "error" | sort @timestamp desc | limit 50 # Alarm on Lambda errors aws cloudwatch put-metric-alarm \ --alarm-name lambda-errors \ --metric-name Errors \ --namespace AWS/Lambda \ --statistic Sum --period 60 \ --threshold 5 --comparison-operator GreaterThanThreshold \ --evaluation-periods 3 \ --alarm-actions arn:aws:sns:...:alerts # EMF — structured log auto-extracts metrics console.log(JSON.stringify({ _aws: { Timestamp: Date.now(), CloudWatchMetrics: [{ Namespace: "MyApp", Dimensions: [["service"]], Metrics: [{ Name: "latency", Unit: "Milliseconds" }] }]}, service: "api", latency: 42 }));

Common Problems

⚠Logs cost explodes — set retention, use Insights not export, sample high-volume
⚠Alarm flapping — set enough evaluation periods, use anomaly detection
⚠Cross-account visibility — use CloudWatch cross-account sharing or Log Insights

Best Practices

✓Use EMF not put-metric-data — structured logs auto-extract metrics, cheaper
✓Set log retention — 7d for dev, 30d for prod, archive to S3 for longer
✓Use Logs Insights not export — query in-place, no S3 export cost

FAQ

What is AWS CloudWatch Observability and what problem does it solve?

Metrics, logs, traces, and alarms — unified observability for all AWS services and custom apps. It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with AWS CloudWatch Observability in 5 minutes?

Two steps to run it: (1) Metrics — aws cloudwatch put-metric-data, or EMF in logs (auto-extract); (2) Logs — CloudWatch Logs, log groups, retention, Insights queries. Validate on the free tier first, then wire into production.

What is the #1 pitfall with AWS CloudWatch Observability?

The most frequent issue is: Logs cost explodes — set retention, use Insights not export, sample high-volume. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for AWS CloudWatch Observability?

Best practices for AWS CloudWatch Observability include: Use EMF not put-metric-data — structured logs auto-extract metrics, cheaper; Set log retention — 7d for dev, 30d for prod, archive to S3 for longer; Use Logs Insights not export — query in-place, no S3 export cost. The first one — "Use EMF not put-metric-data — structured logs auto-extract metrics, cheaper" — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with AWS CloudWatch Observability?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most AWS CloudWatch Observability options offer a free tier — validate within free quota before scaling.