Here's the architecture. Plan it on paper first — same discipline as Week 2.
| Component | Configuration |
|---|---|
| VPC | Use your default VPC (saves time — we focused on custom VPCs in Week 2) |
| Subnets | 2 public subnets in 2 different AZs (high availability) |
| EC2 type | t2.micro or t3.micro (free tier) |
| ASG min / desired / max | 2 / 2 / 6 |
| Scaling trigger | Target tracking: CPU > 50% |
An ALB costs ~$0.50/day even with zero traffic. It's small, but it's not free. Delete the ALB the moment you finish this lab — don't leave it running overnight.
A Launch Template is a blueprint for an EC2 instance. The Auto Scaling Group will use it whenever it needs to spin up a new server.
Navigate to EC2 → Launch Templates → Create launch template.
The user data script makes each new EC2 instance auto-install nginx, show its own instance ID (so we can see load balancing in action), and install stress (a tool to artificially spike CPU later):
Click Create launch template.
Launch Templates replaced "Launch Configurations" (the older, deprecated way). On the exam, both might appear — but in real life and the console UI, always use Launch Templates.
The Target Group is the list of EC2 instances the ALB sends traffic to. Think of it as the "team roster".
Navigate to EC2 → Target Groups → Create target group.
| Field | Value |
|---|---|
| Target type | Instances |
| Target group name | cloudwithshad-tg |
| Protocol / Port | HTTP / 80 |
| VPC | Your default VPC |
| Protocol version | HTTP1 |
| Health check path | / |
| Health check interval | 30 seconds |
| Healthy threshold | 2 consecutive successes |
Click Next, then Create target group (don't add any instances yet — the ASG will do that).
The ALB will ping / on each instance every 30 seconds. It only marks the instance as healthy after 2 consecutive successful pings. This prevents accidentally serving traffic to a still-booting server.
Now the star of the show. Navigate to EC2 → Load Balancers → Create load balancer.
- Select Application Load Balancer → Create
- Name:
cloudwithshad-alb - Scheme: Internet-facing
- IP address type: IPv4
- VPC: your default VPC
- Mappings: tick at least 2 AZs and select the public subnets in each
- Security group: create new →
alb-sgwith port 80 open to 0.0.0.0/0 - Listeners and routing: HTTP/80 → forward to
cloudwithshad-tg - Click Create load balancer
ALB takes about 2-3 minutes to provision. While you wait:
ALBs require subnets in at least 2 AZs. This is the same Multi-AZ requirement you saw with RDS in Week 2 — it's how AWS enforces high availability. Even if one AZ has an outage, your ALB keeps routing through the other.
Once the state shows "Active", copy the DNS name (looks like cloudwithshad-alb-1234567890.eu-west-1.elb.amazonaws.com). Save it — we'll need it after Step 5.
This is the magic. Navigate to EC2 → Auto Scaling Groups → Create Auto Scaling Group.
| Setting | Value |
|---|---|
| Name | cloudwithshad-asg |
| Launch template | cloudwithshad-web-template (from Step 2) |
| VPC | Default VPC |
| Availability Zones | Pick at least 2 (same as your ALB) |
| Load balancing | Attach to existing load balancer |
| Target groups | cloudwithshad-tg |
| Health checks | Enable ELB health checks |
| Desired capacity | 2 |
| Min capacity | 2 |
| Max capacity | 6 |
| Scaling policies | Target tracking |
| Metric | Average CPU utilization |
| Target value | 50 |
Click Create Auto Scaling group.
Within 2 minutes, the ASG launches 2 EC2 instances automatically and registers them with your Target Group. Once they pass health checks (about 60 seconds), open the ALB's DNS name in your browser. Refresh the page a few times — you should see different instance IDs each time.
If you see two different instance IDs as you refresh, your load balancer is working. Traffic is being spread across multiple EC2 servers. Take a screenshot of both pages side by side.
Now the fun part — let's force a CPU spike and watch Auto Scaling do its thing.
SSH into one of the EC2 instances:
Now run stress to peg the CPU at 100% for 10 minutes:
Now watch the magic. Open three browser tabs:
- EC2 → Instances — count rises from 2 to 3, then 4...
- EC2 → Auto Scaling Groups → cloudwithshad-asg → Activity — shows live scaling events
- CloudWatch → Metrics → EC2 → CPU utilization — see the spike that triggered it
Within 3-5 minutes, you'll see ASG launch new instances. After your stress test ends and CPU drops, give it 10-15 minutes — ASG will scale back down to the desired capacity (2).
Take a screenshot of the ASG Activity history showing both a scale-out event ("Launching a new EC2 instance") AND a later scale-in event ("Terminating EC2 instance"). That's your Lab 5 submission.
Auto Scaling uses a 5-minute "cooldown" by default — it waits to see if the spike is sustained before reacting. This is intentional. In production you'd never want ASG launching servers for a 30-second CPU spike.
Out of all the labs in this bootcamp, this is the most expensive one to forget about. An ALB left running for a month costs ~$16. Multiple weeks = real money.
⚠ Cleanup order matters!
- Auto Scaling Group: EC2 → ASG → cloudwithshad-asg → Delete. This terminates all EC2 instances automatically. Wait ~2 minutes.
- Load Balancer: EC2 → Load Balancers → cloudwithshad-alb → Actions → Delete
- Target Group: EC2 → Target Groups → cloudwithshad-tg → Actions → Delete
- Launch Template: EC2 → Launch Templates → cloudwithshad-web-template → Actions → Delete
- Security Groups: Delete alb-sg and web-sg (EC2 → Security Groups)
- Confirm: EC2 → Instances should show 0 running instances
If you delete the ALB first, the ASG keeps running and trying to register new instances with a dead target group. Always: ASG → ALB → TG → Template.
Lab 5 complete!
You just built the same auto-scaling pattern that powers every major web service in the world. Netflix, Spotify, Airbnb, your bank — all of them use exactly this.
Next: Lab 6 — CI/CD Pipeline (GitHub → AWS)