How to Set Up a CloudWatch CPU Alarm with SNS in AWS

By Ravindra Bagale, trainer · LinkedIn · Last updated: 18 October 2026

1. More users: scale up or scale out

Why: suppose our site gets popular and traffic climbs every week. One t3.micro web server starts to struggle.

1. Scale up (vertical): a bigger instance type. You must stop the instance to change its type, so the site is down for that time. Details: Vertical scaling.
2. Scale out (horizontal): more servers of the same size, side by side. No downtime, and it is the normal way for live apps. Details: Horizontal scaling.

Scaling out raises two questions, and this chapter answers both: how do users reach several servers through one name, and when do we add a server?

2. Two servers, one domain: why DNS alone falls short

Suppose example.com has two web servers. The quick idea is two A records for the same name, one per server IP. DNS then hands out the two IPs in turn (DNS round robin).

It does spread some load, but:

1. Uneven: browsers, phones and ISPs cache the answer. A whole office or a whole mobile network can stick to one IP.
2. No health checks: if server 2 dies, DNS keeps giving out its IP, and those users get an error.
3. Slow to change: removing the dead IP takes effect only as the cached answers expire (the record's TTL).

A load balancer fixes all three: users reach one name, and the load balancer picks a healthy server for each request. Doing it by hand first is in Manual load balancing.

3. When to add a server: CloudWatch, threshold and period

Amazon CloudWatch collects numbers (metrics) from your resources. For EC2 the one we watch here is CPUUtilization, in percent.

Why not "CPU above 70%, add a server"? A single spike would trigger it.

1. Suppose the CPU jumps to 90% for one minute and drops back to 40%.
2. A new server takes a few minutes to boot and become ready. By then the spike is over, and you pay for a server you didn't need.
3. So use a threshold and a period together: average CPU ≥ 70% over 5 minutes.
4. Only a load that stays high for the whole period raises the alarm.

Spiky apps alarm earlier. Suppose we are Instagram during breaking news: users pour in within minutes. New servers take minutes to be ready, so the team sets a lower threshold, for example 50%, or a shorter period, to start adding servers earlier.

More on alarm states and settings: CloudWatch alarm.

Basic vs detailed monitoring

1. Basic monitoring (free, on by default): EC2 sends a data point every 5 minutes.
2. Detailed monitoring (paid): a data point every 1 minute.
3. Worked example: the CPU jumps at 10:05. With basic monitoring the next data point may come only at 10:10, so the alarm reacts up to 5 minutes late, and an overloaded server may fail before new servers arrive. With detailed monitoring the alarm sees it by about 10:06.
4. That's why a new instance's Monitoring tab looks empty at first: the first 5-minute points haven't arrived yet.
5. For live projects that scale on CPU, turn on detailed monitoring.

What CloudWatch sees by default, and what it doesn't

1. Default EC2 metrics come from outside the operating system: CPUUtilization, NetworkIn, NetworkOut, NetworkPacketsIn, NetworkPacketsOut, disk and status checks.
2. Memory (RAM) and disk-space usage are not default metrics. AWS sees the virtual machine from the hypervisor, not inside the OS.
3. To get them, install the CloudWatch agent on the server. It sends memory, disk and your own metrics.
4. Custom metrics: suppose we are building a shopping app and want to count clicks on a "Share" button. The app sends each count to CloudWatch with the PutMetricData API, and you can graph it and alarm on it like CPU.
5. Logs: don't let access logs keep growing on an 8 GB root disk; a flood of requests can fill it and stop the server. The CloudWatch agent can ship them to a CloudWatch Logs log group instead.
6. Teams that run on AWS, Azure and Google Cloud together often use Prometheus and Grafana for one dashboard across all clouds. CloudWatch remains the built-in choice on AWS.

Alarm states:

1. Insufficient data: the alarm has just started, or there aren't enough data points yet.
2. OK: the metric is within the threshold.
3. In alarm: the metric crossed the threshold for the period; the actions (such as SNS) run.

4. Nobody watches graphs at 3 AM: alarm to SNS

Why: a person can't stare at the CPU graph all night.

So the alarm tells people by itself, through Amazon SNS (Simple Notification Service):

1. Topic: a named channel, for example cpu-high-alerts.
2. Publisher: whoever sends a message to the topic. Here, the CloudWatch alarm.
3. Subscribers: whoever receives every message on the topic: email, SMS, mobile push, a Lambda function and more.
4. An email subscriber gets a mail from AWS first and must click Confirm subscription. Until then, nothing is delivered.

More on the email set-up: SNS: email when the alarm changes.

5. The new server comes from an AMI

The alert arrives. What does the admin launch?

1. Make an AMI of the working web server once (Nginx, PHP, your code, all set up).
2. When the alert comes, launch a new instance from that AMI. It is ready in minutes, with nothing to install.
3. Add it behind the load balancer (section 7).

Doing this by hand still needs a person who is awake. Auto Scaling does exactly these steps for you; it is in Auto Scaling.

6. A load balancer from day one

Why, with only one server? Because of DNS.

1. Without a load balancer, your domain points straight to the server's IP (an A record).
2. On the day you need a second server, you must move the domain to the load balancer.
3. That DNS change spreads only as cached answers expire, which depends on the TTL. Some users keep hitting the old IP meanwhile, on your busiest day.
4. With a load balancer from day one, the domain never changes. You only add servers behind it.

Which DNS record points to a load balancer?

1. A record: name → IP address. A load balancer has no single fixed IP you should use.
2. The load balancer gives you a DNS name, for example my-alb-123456.ap-south-1.elb.amazonaws.com (no http:// in front).
3. CNAME: name → another name. Use it for www.example.com at another DNS provider. A CNAME can't be used on the root domain example.com.
4. Alias A record (Route 53): points the name to the load balancer and works on the root domain too. This is the usual choice when your domain is in Route 53.

7. Target groups and the average CPU

A target group is the list of servers that do one job, plus the port and the health check. The load balancer forwards requests to a target group, not to servers directly. Full details: Target groups.

1. Suppose one account runs two apps: one target group for each app's servers.
2. A new server gets traffic only after it is registered in the target group.

Scale on the average, not on one server. Suppose 3 servers are at 80%, 70% and 60% CPU.

1. Average = (80 + 70 + 60) / 3 = 70%.
2. If it stays there for 5 minutes, the alarm fires: add a 4th server.
3. The load now spreads over 4 servers, and the average drops.

In practice the group's average comes from the Auto Scaling group's CPUUtilization metric, which CloudWatch averages across all its servers.

Scale in, too. At 2 AM the average falls low, so remove a server and stop paying for it. A second, low alarm (for example average below 30%) does that.

8. Health checks: who gets no traffic

Why: a server can be running while Nginx on it is stopped. Without a check, the load balancer keeps sending users there.

How it works:

1. Every interval (for example 30 seconds), the load balancer requests a path on each target, such as / or /index.html.
2. HTTP 200 = a pass.
3. Unhealthy threshold = how many checks in a row must fail before the target is marked unhealthy (at least 2).
4. An unhealthy target gets no traffic; the others share it.
5. The load balancer keeps checking it. After the healthy threshold of passes in a row, traffic resumes.

The math: how long do users hit a dead server? The interval can be 5 to 300 seconds.

1. Interval 30 s × unhealthy threshold 2 = up to 1 minute of requests going to a dead server.
2. Interval 5 s × threshold 2 = about 10 seconds.
3. Shorter is faster to react, but a tiny hiccup can mark a server unhealthy too soon. Pick per app.

Health checks are not charged per request. An Application Load Balancer is billed per hour plus by usage (LCUs).

A load balancer only stops sending traffic; the broken server stays. Replacing it automatically is Auto Scaling's job. All the settings are in Health checks.

9. Listener rules: send each path to its own target group

Suppose we are Instagram. Watching reels is light work; uploading a video is heavy (it is received, processed and stored).

1. If both share one pool of servers, a burst of uploads eats the CPU and reels slow down for everyone.
2. So use two target groups: tg-reels with smaller servers (suppose 4 GB RAM) and tg-upload with bigger ones (suppose 32 GB RAM). Each scales on its own.

Who decides which group? The listener.

1. A listener is the protocol and port the load balancer listens on: HTTP:80 or HTTPS:443.
2. Its rules are checked in priority order:
3. Path /reels* → tg-reels.
4. Path /upload* → tg-upload.
5. Default (anything else) → tg-web.

More rule types (host, header) and several groups: Multiple target groups and Different HTTP listeners.

10. Round robin, the login problem, and sticky sessions

Inside a target group, an Application Load Balancer uses round robin by default:

1. Request 1 → server 1.
2. Request 2 → server 2.
3. Request 3 → server 3.
4. Request 4 → server 1 again.

The problem: suppose the app keeps the login session in the memory of the server that handled the login.

1. The user logs in; request 1 went to server 1, which now remembers them.
2. The next click goes to server 2, which has never seen them.
3. Server 2 shows the login screen again.

Fix 1: sticky sessions (a target group setting, no extra cost):

1. On the first response, the load balancer sets a cookie (AWSALB) in the browser that says which target served it.
2. The browser sends that cookie with every later request.
3. The load balancer reads it and sends the user to the same server, for the duration you set (for example 1 day).
4. The load balancer stores nothing about the login; the cookie lives in the browser.

Fix 2, better for the long run: a shared session store. Keep sessions in Redis or the database, so any server can serve any user. Then a server can be removed or replaced without logging anyone out.

Other ways to pick a target (least outstanding requests, weighted): Routing policy. Which load balancer type to choose comes in the next chapter, and in Which load balancer to use.

11. Build it in the console

Part A: the SNS topic

1. SNS > Topics > Create topic, type Standard, name cpu-high-alerts, Create topic.
2. Create subscription, protocol Email, endpoint: your email address.
3. Open the mail from AWS and click Confirm subscription. The status changes to Confirmed.

Part A2: three web servers from one golden AMI

Why: every server behind the load balancer must serve the same site. Build one server, save it as an image (a golden AMI), and launch the others from it.

1. Launch an Amazon Linux 2023 t2.micro in a public subnet, security group with 22 and 80 open.
2. Install and start Nginx:

sudo yum install nginx -y sudo service nginx start sudo systemctl enable nginx

1. The last line makes Nginx start again after every reboot, so servers launched from the image serve pages at once.
2. Put <h1>FIRST</h1> in /usr/share/nginx/html/index.html.
3. Actions > Image and templates > Create image, name firstami. Wait until the AMI is Available.
4. AMIs > firstami > Launch instance from AMI: launch 2 more with the same security group.
5. On them, change the page to <h1>SECOND</h1> and <h1>THIRD</h1> so you can see which server answered.
6. Some AZs don't offer every instance type (for example us-east-1e). If a launch fails for capacity or type, pick us-east-1a or us-east-1b.

Part B: the target group

1. EC2 > Target groups > Create target group, type Instances, name tg-web, protocol HTTP, port 80, your VPC.
2. Health checks: path /index.html. Under Advanced health check settings, set the interval and the unhealthy threshold (section 8).
3. Register targets: tick the web servers, Include as pending below, Create target group.

Worked example: fast health-check settings for a lab

1. Path /index.html, success code 200.
2. Healthy threshold 2, unhealthy threshold 2.
3. Timeout 3 seconds, interval 5 seconds.
4. A stopped server is out after 2 × 5 = about 10 seconds; a fixed one is back after another 2 × 5 = about 10 seconds.
5. In Register targets, a server is added only after you click Include as pending below.

Part C: the load balancer and the listener rules

1. EC2 > Load balancers > Create load balancer > Application Load Balancer, scheme Internet-facing.
2. Pick your VPC and at least two public subnets in different AZs.
3. Security group alb-sg: allow 80 (and 443) from anywhere. The web servers' SG allows 80 from alb-sg only.
4. Listener HTTP:80, default action: forward to tg-web. Create load balancer.
5. Open the listener, Manage rules > Add rule: condition Path /reels*, action forward to tg-reels. Repeat for /upload* → tg-upload.
6. Copy the load balancer's DNS name and open it in the browser. In Route 53, create an Alias A record for your domain pointing to it.

Part D: sticky sessions (only if your app keeps sessions in server memory)

1. Open tg-web > Attributes > Edit.
2. Tick Stickiness, type Load balancer generated cookie, duration 1 day. Save changes.

Part E: the CloudWatch alarm

1. CloudWatch > Alarms > Create alarm > Select metric > EC2 > Per-Instance Metrics, pick CPUUtilization of a web server.
2. Statistic Average, period 5 minutes.
3. Condition Greater/Equal than 70.
4. Notification: In alarm → send to cpu-high-alerts.
5. Name it cpu-high-web, Create alarm.

Part F: test it

1. Stop Nginx on one web server: sudo service nginx stop. After the interval × threshold, the target shows unhealthy, and the site still opens from the other server.
2. Start it again: sudo service nginx start. After the healthy threshold, it is healthy again.
3. To load the CPU, install the stress tool: sudo yum install stress-ng -y, then run stress-ng --cpu 2 --timeout 600. In about 5 minutes the alarm goes to In alarm and the email arrives.

Part G: see round robin

1. Register the three servers (FIRST, SECOND, THIRD) in the target group and open the load balancer's DNS name.
2. Refresh a few times: the page changes, for example FIRST, THIRD, SECOND. An ALB spreads requests over the healthy targets by default with round robin.
3. Try the servers' own public IPs: they still answer. Change the servers' port 80 rule to source = the load balancer's security group, and users can no longer go around the load balancer.

Part H: detailed monitoring and a 1-minute alarm

1. EC2 > Instances, select the server, Actions > Monitor and troubleshoot > Manage detailed monitoring, tick Enable, Confirm.
2. CloudWatch > Alarms > Create alarm > Select metric > EC2 > Per-Instance Metrics > CPUUtilization of that server.
3. Statistic Average, period 1 minute, threshold type Static, Greater/Equal than 50.
4. In alarm → send to your SNS topic. Name it ec2alarm, Create alarm. It starts in Insufficient data, then shows OK.
5. Load the CPU:

sudo yum install stress-ng -y stress-ng --cpu 6 --timeout 120

1. Within a few minutes the alarm goes to In alarm and the email arrives. When the test ends, it returns to OK.

12. When something goes wrong

1. No alert email: the subscription is still Pending confirmation. Click the link in the AWS mail (check spam).
2. All targets unhealthy: the web SG doesn't allow 80 from alb-sg, Nginx is stopped, or the health-check path returns 404.
3. The alarm never fires: wrong metric (another instance), or the threshold is never held for the full period.
4. Users keep getting logged out: sessions are in server memory and stickiness is off. Turn it on, or move sessions to a shared store.
5. /upload hits the wrong servers: the rule order is wrong, or the path pattern is missing the *.
6. SSH to a server times out: check, one by one: the server is in a public subnet; the internet gateway is attached; the subnet's route table has 0.0.0.0/0 to the IGW; the security group allows port 22 from your IP.
7. SSH worked at the office but not at home: a My IP rule stores the public IP you had when you made it. At home your internet provider gives you a different public IP. Edit the rule and pick My IP again.

1. One server never gets traffic: its Availability Zone is not enabled on the load balancer. Select every AZ where you have targets.
2. The bill keeps a small charge after the lab: an AMI you no longer need still keeps its EBS snapshots. Deregister the AMI and delete its snapshots.

13. The whole class on one page

1. Scale up = bigger instance, needs a stop. Scale out = more servers, no downtime.
2. Two A records spread load unevenly and keep sending users to a dead server. A load balancer fixes both.
3. Alarm on threshold + period: average CPU ≥ 70% over 5 minutes. Spiky apps alarm earlier.
4. SNS: topic, publisher (the alarm), subscribers (email, SMS, Lambda...). Email needs Confirm subscription.
5. New servers come from a ready AMI. Auto Scaling automates it.
6. Load balancer from day one. Its DNS name goes in an Alias A record (Route 53) or a CNAME for www.
7. Target group = the servers of one job + health check. Scale on the group's average CPU; scale in at night.
8. Health check: interval 5-300 s, unhealthy threshold at least 2. 30 s × 2 = up to 1 minute; 5 s × 2 ≈ 10 s.
9. Listener rules route by path: /reels and /upload to their own groups, the rest to the default.
10. Round robin can lose a login kept in server memory. Sticky sessions (AWSALB cookie, no extra cost) or, better, a shared session store.

14. Try at home

Recap

Quick revision cards

Revise this lesson in two minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens its lesson.

More cards: Ravi Sir's Cards.