aws #cloudwatch #monitoring #tutorial
Monitor an EC2 Instance
INTRO
Ever wonder how you'd actually know if something was silently maxing out your server's CPU? That's basically what this lab is about. You set up an alarm that watches an EC2 instance's CPU, wire it to send you an email the moment it spikes, and then you deliberately spike it yourself to prove the whole thing works. It's a simple setup, but it's the same pattern behind real incident alerting — think of the CPU spike as a stand-in for something like malware taking over a box.
WHAT YOU'RE BUILDING
You'll set up three things that talk to each other:
- An SNS topic that emails you when triggered
- A CloudWatch alarm that watches CPU usage and fires the SNS topic if it crosses 60%
- A stress test on the EC2 instance to actually push CPU past that line and prove the alarm works
By the end, you'll also have a CloudWatch dashboard so you can glance at that CPU metric anytime without digging through menus.
STEP 1: SET UP THE SNS TOPIC
First, you need somewhere for the alert to go. Head to SNS and create a topic:
- Type: Standard
- Name:
MyCwAlarm
Once it's created, go to the Subscriptions tab and add a subscription:
- Protocol: Email
- Endpoint: your actual email address
You'll get a confirmation email almost instantly — open it and confirm the subscription. Come back to the console and check that the status flipped to Confirmed. If it still says "Pending confirmation," the alarm won't be able to reach you later, so don't skip this.
STEP 2: CREATE THE CLOUDWATCH ALARM
Now you tell CloudWatch what to watch and when to yell about it.
Jump into CloudWatch → Metrics → EC2 → Per-Instance Metrics, and find CPUUtilization for your Stress Test instance. Right now it should be sitting near 0% — nothing's happened yet.
Then go to Alarms → Create alarm, and pick that same CPUUtilization metric. Set it up like this:
- Statistic: Average
- Period: 1 minute
- Condition: Greater than 60
For the action, point it at the SNS topic you just made (MyCwAlarm), and give the alarm a name like LabCPUUtilizationAlarm.
That's it — the alarm now sits quietly in the background, watching.
STEP 3: SPIKE THE CPU AND WATCH THE ALARM FIRE
This is the part that actually proves it works. Open a terminal into the Stress Test instance and run:
sudo stress --cpu 10 -v --timeout 400s
This pins the CPU at 100% for about 400 seconds, then lets it drop back down on its own.
Open a second terminal to the same instance and run:
top
so you can watch the CPU load live while it's happening.
Now flip back to the CloudWatch alarm page and refresh every minute or so. Give it a few minutes — you'll see the graph climb past the 60% line, and the alarm state will flip to In alarm. Shortly after, check your inbox — you should have a fresh email from AWS Notifications telling you the alarm went off.
STEP 4: BUILD A DASHBOARD
Once you've seen the alarm work, it's worth having a permanent view of that metric instead of hunting for it every time.
Go to CloudWatch → Dashboards → Create dashboard, name it LabEC2Dashboard, and add a Line widget using the same CPUUtilization metric for your Stress Test instance. Save it, and now you've got a one-click view of that instance's CPU health whenever you need it.
WHAT I TOOK AWAY FROM THIS
- An alarm is only as useful as the notification behind it — CloudWatch watches the metric, but SNS is what actually gets a human's attention
- A CPU spike by itself doesn't tell you why it happened — it just tells you that it happened. That's the trigger to go investigate, not the answer
- Confirming the SNS subscription is an easy step to forget, and if you skip it, the whole alert chain silently breaks
- Dashboards aren't just nice-to-have — they turn "let me go find that metric again" into "it's already right there"
Top comments (0)