🎯 By the end of this module you should be able to…
- Explain what CloudWatch collects and the difference between metrics, logs, alarms and dashboards.
- Name the EC2 metrics available by default and explain why memory and disk are not among them.
- Set a sensible threshold using period, evaluation periods and datapoints to alarm.
- Describe the three CloudWatch alarm states and what triggers a transition.
- Configure alarm actions: notify, auto scale, or recover the instance.
- Explain the SNS publish/subscribe model and the role of topics and subscriptions.
- Wire a CloudWatch alarm to an SNS topic so a human is actually told.
What Amazon CloudWatch is
CloudWatch is the monitoring and observability service for AWS. It answers two different questions: is this healthy right now? and what happened at 03:40 last night?
| Component | What it holds | You use it to |
|---|---|---|
| Metrics | Time-ordered numbers — CPU %, request count, queue depth | See trends and drive alarms |
| Logs | Text lines from applications, the OS and AWS services | Find out what actually happened |
| Alarms | A rule watching one metric or a metric expression | Trigger a notification or an action |
| Dashboards | Charts and numbers arranged on one page | Give a team a single shared view |
| Events / EventBridge | A stream of state changes in your account | React automatically to things happening |
| Logs Insights | A query language over your logs | Ask "how many 500s, grouped by path?" |
A namespace groups metrics by service, for example AWS/EC2. A metric is the
thing measured, for example CPUUtilization. A dimension is a name/value pair that
identifies which resource, for example InstanceId=i-0abc123. The three together
identify exactly one line on a chart.
EC2 metrics you get for free — and the two you do not
| Metric | What it tells you |
|---|---|
| CPUUtilization | Percentage of allocated compute in use |
| NetworkIn / NetworkOut | Bytes in and out of all network interfaces |
| NetworkPacketsIn / Out | Packet counts |
| DiskReadOps / DiskWriteOps | I/O operations on instance store volumes |
| DiskReadBytes / DiskWriteBytes | Bytes read and written to instance store |
| StatusCheckFailed_System | A problem on the AWS side — host, network, power |
| StatusCheckFailed_Instance | A problem inside your instance — OS, filesystem, network config |
CloudWatch sees the instance from outside the hypervisor, so it cannot see what the guest operating system is doing with RAM or how full a filesystem is. To get those you install the CloudWatch agent, which publishes them as custom metrics. This is the most common gap in a new monitoring setup — and a favourite exam question.
| Basic monitoring | Detailed monitoring | |
|---|---|---|
| Interval | 5 minutes | 1 minute |
| Cost | Free | Charged per instance per month |
| Use for | Development, non-critical workloads | Production, and anything driving auto scaling |
Dashboards
A dashboard is a saved arrangement of widgets. It is global — one dashboard can show metrics from several Regions and several accounts at once, which is exactly what an operations team needs.
What makes a dashboard worth having
- 👁️It answers one question "Is the shop working?" Not "here is every metric we collect."
- ⬆️Most important at the top left People read a screen the way they read a page.
- 📉Four golden signals Latency, traffic, errors, saturation. If you only have room for four charts, use those.
- 📏A threshold line on every chart A number is meaningless without the line that says what "too high" is.
- ⏱️A sensible default time range Three hours for an operations screen; a week for a capacity review.
Widget types
Before you build anything, open the automatic dashboards CloudWatch creates per service. They are free, maintained by AWS, and often good enough. Build a custom dashboard only when you need metrics from several services on one screen.
Metrics, thresholds and statistics
A threshold that is too tight pages you at 3 a.m. for nothing. A threshold that is too loose never fires. Four settings decide the behaviour.
| Setting | What it controls | Sensible starting point |
|---|---|---|
| Statistic | How the raw datapoints are aggregated | Average for CPU; Sum for counts; p90/p99 for latency |
| Period | The length of each aggregation window | 5 minutes (1 minute if detailed monitoring is on) |
| Evaluation periods | How many recent periods are examined | 3 |
| Datapoints to alarm | How many of those must breach | 2 of 3 — rides out a single spike |
"CPU > 80% for 2 out of the last 3 five-minute periods" survives one transient spike but still fires within about ten minutes of a real problem. A plain "1 out of 1" alarm on a noisy metric is how teams learn to ignore alerts.
Which statistic to use
| Statistic | Good for | Careful of |
|---|---|---|
| Average | Utilisation like CPU or memory | Hides a single struggling instance in a fleet |
| Sum | Counts — requests, errors, messages | Meaningless for a percentage |
| Maximum | Catching any single bad datapoint | Very noisy on its own |
| Minimum | Spotting something that stopped reporting | Rarely what you want for load |
| p90 / p99 | Latency — the experience of your slowest users | Needs enough traffic to be meaningful |
If 99 requests take 50 ms and one takes 10 seconds, the average is about 150 ms and everything looks fine — while one customer waited ten seconds. Alarm on p99, chart the average.
Alarms and actions
| State | Meaning |
|---|---|
| OK | The metric is within the threshold |
| ALARM | The threshold has been breached for the configured number of datapoints |
| INSUFFICIENT_DATA | Not enough data — the alarm is new, the resource is stopped, or the metric stopped reporting |
An action fires on the transition into a state, not continuously while in it. That is why you should configure an action for the return to OK as well — otherwise nobody is told that it recovered.
What an alarm can do
📢 Notify
Publish to an SNS topic, which then fans out to email, SMS, a chat webhook, a Lambda function or a ticketing system.
📈 Auto Scaling action
Add or remove instances from an Auto Scaling group. This is how a workload follows demand automatically.
🔧 EC2 action
Stop, terminate, reboot or recover an instance.
Recover is the classic response to StatusCheckFailed_System.
🧩 Systems Manager action
Create an OpsItem or run an Automation document — the bridge to real self-healing.
Composite alarms
A composite alarm combines other alarms with AND, OR and NOT. Instead of five separate pages when one database fails, you raise one alarm that says "the checkout service is unhealthy". This is the main tool against alert fatigue.
A worked configuration
Instead of a fixed number, CloudWatch can learn a metric's normal pattern — including its daily and weekly cycles — and alarm when it leaves the expected band. Use it for metrics whose "normal" changes through the day, where a single fixed threshold would be wrong at some hour.
Amazon SNS
Simple Notification Service is a fully managed publish/subscribe messaging service. A publisher sends one message to a topic; SNS delivers a copy to every subscription on that topic. The publisher never knows or cares who is listening.
Topics and subscriptions
| Step | What you specify | Notes |
|---|---|---|
| 1. Create a topic | Type (Standard or FIFO), name, display name | Standard for notifications; FIFO when strict ordering and exactly-once matter |
| 2. Set access policy | Who may publish, who may subscribe | Least privilege applies here too |
| 3. Create a subscription | Protocol and endpoint | Email, SMS, HTTPS, Lambda, SQS, mobile push, or an email-JSON feed |
| 4. Confirm the subscription | Click the link in the confirmation message | Email and HTTPS subscriptions deliver nothing until confirmed. |
| 5. Publish and test | Send a test message from the console or CLI | Always test before you rely on it |
A subscription sits in PendingConfirmation until the recipient clicks the link in the email AWS sends. Until then the alarm fires, SNS publishes, and nobody hears anything. If an alert "did not arrive", check the subscription status before you check anything else.
Useful features
🧲 Message filtering
A subscription filter policy means one topic can
serve everyone: the database team subscribes only to messages where
service = "rds".
📪 Fan-out to SQS
SNS to several SQS queues is the classic decoupling pattern: each consumer processes at its own pace, and a slow consumer cannot block the others.
♻️ Dead-letter queues
Messages that cannot be delivered after retries go to an SQS DLQ instead of disappearing.
🔐 Encryption
Server-side encryption with KMS, and HTTPS in transit. Worth turning on for anything carrying operational detail.
SNS pushes one message to many subscribers immediately — use it for notifications and fan-out. SQS holds messages in a queue until a consumer pulls them — use it for decoupling and buffering work. They are complementary, and the fan-out pattern uses both together.
Key takeaways
- ✅CloudWatch collects metrics, logs, alarms, dashboards and events.
- ✅EC2 gives CPU, network, disk I/O and status checks for free — memory and disk space need the CloudWatch agent.
- ✅Basic monitoring is 5-minute and free; detailed is 1-minute and charged.
- ✅Use M-out-of-N evaluation to ride out spikes without missing real problems.
- ✅Alarm on p99 latency, not the average.
- ✅Alarm actions fire on the transition into a state — configure the OK action too.
- ✅SNS is publish/subscribe: one topic, many subscriptions, one publish delivered to all.
- ✅Email and HTTPS subscriptions deliver nothing until they are confirmed.