CloudWatch & Cost Management
AWS Fundamentals
Chapter 9 · CloudWatch & Cost Management
CloudWatch launched alongside Elastic Load Balancing and Auto Scaling, on the exact same real day — 18 May 2009 — as part of one coordinated announcement. That's not a coincidence: Chapter 8's own auto scaling policies (target tracking, step scaling) work specifically because CloudWatch supplies the real metrics they scale against.
CloudWatch Metrics — and a Real, Common Gotcha
CloudWatch automatically collects real infrastructure metrics — CPU utilization, disk I/O, network traffic, even RDS replica lag (Chapter 6) — with zero setup required.
Custom Metrics
Since May 2011, CloudWatch has accepted real, custom application-level metrics submitted programmatically via its own API — anything your own code wants to track (queue depth, business-specific counters, cache hit rate) that AWS's own infrastructure-level metrics could never know about.
CloudWatch Logs
CloudWatch Logs, available since July 2014, centralizes real log data from EC2 instances, Lambda functions (Chapter 7), and other AWS services in one searchable place. Retention is real and configurable per log group — anywhere from 1 day up to 10 years, or set to never expire — and a genuinely easy real mistake is leaving it at its own default of indefinite retention, quietly accumulating real storage cost over months and years for logs nobody ever looks at again.
Alarms & Dashboards
A CloudWatch alarm watches a real metric against a defined threshold and triggers an action once it's crossed — directly feeding Chapter 8's own Auto Scaling target tracking policies, or sending a real notification (via SNS) to alert a human. A dashboard is a real, customizable visualization combining multiple metrics from across services into one view.
Real Cost Management Tools
Two real, distinct tools handle cost specifically:
- Cost Explorer — a real, visual tool for analyzing spend over time, broken down by service, account, or tag — the place to answer "where is our money actually going, and why did it change."
- AWS Budgets — set a real, specific dollar (or usage) threshold, and get notified as actual or forecasted spend approaches or crosses it.
CloudWatch vs. Cost Explorer vs. Budgets
| Tool | Answers | Takes Action? |
|---|---|---|
| CloudWatch | "Is this resource healthy right now?" | Yes — alarms can trigger scaling or notifications |
| Cost Explorer | "Where has money been spent, and why?" | No — analysis only |
| AWS Budgets | "Are we approaching a spending threshold?" | Notification only — does not stop spending on its own |
Hands-On Exercises
A team assumes CloudWatch is already alerting them if an EC2 instance's own disk fills up, but no alert ever fires before the disk actually runs out. Explain, in your own words, why this happened, and what real step was missing.
📄 View solutionA company sets an AWS Budget alert at $5,000/month, and a compromised access key is later used to launch a large amount of unauthorized compute. Explain, in your own words, why the Budget alert alone would not have prevented the unexpected charges from accumulating.
📄 View solutionA team wants to know exactly which specific service caused their AWS bill to increase by 20% last month. Recommend the real, correct tool for this from the chapter, and explain why CloudWatch alone wouldn't answer this question.
📄 View solutionChapter 9 Quick Reference
- CloudWatch — launched 18 May 2009, alongside ELB & Auto Scaling
- Real gotcha: memory & disk-space metrics need the CloudWatch Agent (since Dec 2017) — not automatic
- Custom metrics (since 2011), CloudWatch Logs (since 2014, configurable 1 day–10 years retention)
- Alarms — trigger Auto Scaling (Chapter 8) or SNS notifications when a threshold is crossed
- Cost Explorer — analyzes past spend; AWS Budgets — alerts on a threshold, but does NOT stop spending on its own