DEV Community: Muhammad Nadeem

Build a Production-Ready Auto Scaling Infrastructure on AWS

Muhammad Nadeem — Thu, 13 Aug 2026 11:56:13 +0000

**🚀 Introduction

**
Auto Scaling is one of the most powerful features of AWS, but many beginners find it confusing. In this hands-on lab, you'll build a complete auto-scaling infrastructure from scratch and watch servers automatically scale up and down based on demand.

By the end of this guide, you'll understand:

How EC2 Auto Scaling Groups work
Load balancing and traffic distribution
CloudWatch metrics and alarms
Real-world scaling in action

🏗️ Architecture We're Building

**┌─────────────────────────────────────────────────┐
│ User Traffic (Internet) │
└────────────────────┬────────────────────────────┘
│
▼
┌────────────────────────┐
│ Application Load │
│ Balancer (ALB) │
└─────────┬──────────────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ Server │ │ Server │
│ #1 │ │ #2 │
│ (Port80)│ │ (Port80)│
└─────────┘ └─────────┘
│ │
└────────┬────────┘
│
Auto Scaling Group
(Manages server count)
│
CloudWatch Monitoring
(Triggers scaling rules)

Step 1️⃣: Launch Your First EC2 Instance

**
This will be the template for our auto-scaling servers.

1.1 Open AWS Console

Navigate to: https://console.aws.amazon.com → EC2 Dashboard

1.2 Launch an Instance
EC2 → Instances → Launch Instances
1.3 Configure Instance Details

Fill in these settings:

Setting Value
Name MyWebServer
AMI Amazon Linux 2 (Free tier)
Instance Type t2.micro
Key Pair Create new: my-keypair.pem
Security Group Allow SSH (22) + HTTP (80)
Storage 8 GB (default)
1.4 Add Startup Script

In Advanced Details → User Data, paste this script:

bash

!/bin/bash

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

Create simple website

echo "

Server: $(hostname -f)

" > /var/www/html/index.html
echo "

CPU Load: $(uptime)

" >> /var/www/html/index.html

What this does:

Updates system packages
Installs Apache web server (httpd)
Creates a simple HTML page showing server info
1.5 Launch & Verify
Click Launch Instance
Wait 2-3 minutes for it to boot
Note the Public IPv4 address
Open in browser:http://54.245.76.10
_**

Step 2️⃣: Create a Launch Template

**_
A Launch Template is like a blueprint that Auto Scaling will use to create new servers.

2.1 Navigate to Launch Templates
EC2 → Launch Templates → Create Launch Template
2.2 Fill Template Details
Name: MyWebServerTemplate
Description: Web server with auto-startup
AMI: Amazon Linux 2
Instance Type: t2.micro
Key Pair: my-keypair.pem
Security Group: Allow HTTP + SSH
2.3 Add User Data

Paste the same startup script from Step 1.4:

bash

!/bin/bash

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "

Server: $(hostname -f)

" > /var/www/html/index.html
echo "

CPU Load: $(uptime)

" >> /var/www/html/index.html
2.4 Create Template

Click Create Launch Template ✅

What we accomplished:

Template created that can spawn servers automatically
All servers will have identical configuration

Step 3️⃣: Create a Target Group

**
Target Groups tell the Load Balancer which servers to send traffic to.

3.1 Navigate to Target Groups
EC2 → Target Groups → Create Target Group
3.2 Configure Target Group
Name: MyWebServers
Protocol: HTTP
Port: 80
VPC: Default
3.3 Health Check Settings

This is crucial - it monitors if servers are healthy:

Protocol: HTTP
Path: /
Matcher: 200
Interval: 30 seconds
Timeout: 5 seconds
Healthy threshold: 2
Unhealthy threshold: 3

Explanation:

Every 30 seconds, check if server responds with HTTP 200
If 2 checks pass → server is healthy
If 3 checks fail → server is unhealthy (remove from rotation)
3.4 Create Target Group

Click Create Target Group ✅

What we accomplished:

Created health monitoring for our servers
Load Balancer will use this to route traffic

Step 4️⃣: Create Application Load Balancer
**
The Load Balancer distributes traffic across multiple servers.

4.1 Navigate to Load Balancers
EC2 → Load Balancers → Create Load Balancer
4.2 Select Type
Type: Application Load Balancer (ALB)
4.3 Basic Configuration
Name: MyALB
Scheme: Internet-facing
IP Type: IPv4
4.4 Network Configuration
VPC: Default VPC
Subnets: Select ALL (minimum 2)
4.5 Security Group
Allow: HTTP (port 80) from 0.0.0.0/0
4.6 Listener Configuration
Protocol: HTTP
Port: 80
Forward to: MyWebServers (Target Group)

Step 5️⃣: Create Auto Scaling Group (The Main Event!)

**
This is where the magic happens!

5.1 Navigate to Auto Scaling Groups
EC2 → Auto Scaling Groups → Create Auto Scaling Group
5.2 Select Launch Template
Name: MyWebServers-ASG
Launch Template: MyWebServerTemplate
Version: Latest
5.3 Network Configuration
VPC: Default
Subnets: Select ALL (minimum 2 different AZs)
5.4 Load Balancer Settings
✅ Enable load balancing
Target Groups: MyWebServers
5.5 Group Size (IMPORTANT!)
Min Size: 1
Desired Capacity: 2
Max Size: 4

What this means:

Always keep minimum 1 server (no downtime)
Normally run 2 servers (desired state)
Never exceed 4 servers (cost control)
5.6 Scaling Policies

Select: Target Tracking Scaling Policy

Scale UP Rule:
Policy Name: ScaleUp
Metric: Average CPU Utilization
Target Value: 50%
Instance Warmup: 300 seconds

Meaning: If average CPU > 50%, launch more servers

Scale DOWN Rule:
Policy Name: ScaleDown
Metric: Average CPU Utilization
Target Value: 20%

Meaning: If average CPU < 20%, remove servers

5.7 Instance Maintenance
Select: Mixed behavior (No policy)
Healthy percentage: Min 90%, Max 110%

Step 6️⃣: Verify Everything is Running

**6.1 Check Instances
EC2 → Instances

✅ Should see 2 instances launched automatically

6.2 Check Load Balancer Health
EC2 → Load Balancers → MyALB

Note the DNS name, open in browser:

http://MyALB-xxxx.us-west-2.elb.amazonaws.com

✅ Should see your web page

Refresh multiple times - you might see different servers responding!

6.3 Check Auto Scaling Group Status
EC2 → Auto Scaling Groups → MyWebServers-ASG
Activity tab
**

Step 7️⃣: Simulate Traffic & Watch It Scale! 🎯

**
This is the most exciting part!

7.1 Connect to an Instance via SSH
bash

First, make sure your key has correct permissions

chmod 400 ~/Downloads/my-keypair.pem

Connect to instance

ssh -i ~/Downloads/my-keypair.pem ec2-user@54.245.76.10

Or use EC2 Instance Connect in AWS Console (easier!)

7.2 Simulate High CPU Load

Once connected, run:

bash

Create CPU load

yes > /dev/null &
yes > /dev/null &
yes > /dev/null &

⏱️ Watch the Magic Happen:

Open CloudWatch → Dashboards
Monitor CPU Utilization metric
Wait 2-3 minutes...

What you'll see:

CPU usage climbs above 50% 📈
CloudWatch triggers scaling policy
A new server automatically launches! 🚀
Instance count changes from 2 → 3
Time 0:00 → 2 servers (normal)
Time 2:00 → CPU spikes (>50%)
Time 3:00 → CloudWatch detects high CPU
Time 4:00 → Scaling policy triggered
Time 5:00 → New server launched! 3rd instance appears
Time 6:00 → Load distributes across 3 servers
7.3 Watch It Scale Down
bash

Kill the load generators

killall yes

⏳ Wait 5 minutes...

CPU drops below 20%
CloudWatch triggers scale-down policy
Extra server automatically terminates! ✂️

Step 8️⃣: Monitor Everything in CloudWatch

**8.1 Open CloudWatch
AWS Console → CloudWatch → Dashboards
8.2 Create Custom Dashboard (Optional)

Track these metrics:

CPU Utilization (average across ASG)
Network In/Out
Desired/Running instance count
8.3 Check Auto Scaling Activity
EC2 → Auto Scaling Groups → MyWebServers-ASG → Activity

See all scaling events in log:

2024-08-13 16:30:00 | Launching 1 new instance
2024-08-13 16:35:00 | Terminating 1 instance

THUMBNAIL OF A LAB

Monitering EC2 instance

Muhammad Nadeem — Sat, 25 Jul 2026 19:29:00 +0000

TASK 1: Configure Amazon SNS 📧

Objective

Create an Amazon SNS topic and subscribe to email notifications for alerts.

Lab tasks content summary · MD
AWS CloudWatch Monitoring Lab - Complete Task Content 📋
Overview

This lab teaches how to set up a complete monitoring solution on AWS that detects CPU spikes and sends automatic email alerts.

TASK 1: Configure Amazon SNS 📧
Objective

Create an Amazon SNS topic and subscribe to email notifications for alerts.

What is Amazon SNS?
Full Name: Amazon Simple Notification Service
Type: Fully managed messaging service
Use Case: Application-to-Application (A2A) and Application-to-Person (A2P) communication
Purpose: Send real-time notifications via email, SMS, HTTP, SQS, Lambda, etc.
Steps Completed:
Step 1: Navigate to SNS
AWS Console → Search Bar → Type "SNS" → Click "Simple Notification Service"
Step 2: Create SNS Topic
Location: Simple Notification Service Console
Action: Left Menu (☰) → Topics → Create topic

Configuration:
├─ Type: Standard (selected)
├─ Name: MyCwAlarm
└─ Create topic (button clicked)

Result: Topic "MyCwAlarm" successfully created
Step 3: Create Email Subscription
Location: MyCwAlarm Topic Details Page
Action: Subscriptions Tab → Create subscription

Configuration:
├─ Topic ARN: arn:aws:sns:us-west-2:xxx:MyCwAlarm (auto-filled)
├─ Protocol: Email (selected from dropdown)
├─ Endpoint: [Your Email Address]
└─ Create subscription (button clicked)

Status: "Pending confirmation"
Step 4: Confirm Email Subscription
Email Received: AWS Notification - Subscription Confirmation
Action:

Check email inbox
Open AWS notification email
Click "Confirm subscription" link

Result: Status changed to "Confirmed"
Backend: SNS topic now linked to email address
What This Accomplished:

✅ Created messaging topic
✅ Linked email address to topic
✅ Verified email subscription
✅ Ready to send email alerts

Key Takeaway:

SNS acts as a bridge between AWS services (CloudWatch) and end users (your email). When alarms trigger, SNS automatically sends notifications to subscribers.

TASK 2: Create CloudWatch Alarm 🚨

Objective
**

Configure a CloudWatch alarm to monitor EC2 CPU utilization and trigger when threshold is exceeded.

What is CloudWatch?
Full Name: Amazon CloudWatch
Type: Monitoring and observability service
Purpose: Monitor applications, systems, and AWS resources
Data Types: Logs, Metrics, Events
Users: DevOps Engineers, SREs, IT Managers, Developers

TASK 3: Stress Test EC2 Instance ⚡

Objective

Run CPU stress test to simulate high load and verify alarm triggers correctly.

Why Stress Test?
Simulates malware/attack scenarios
Tests alarm responsiveness
Validates monitoring system
Ensures notifications deliver
Security testing practice

TASK 4: Create CloudWatch Dashboard 📊
Objective

Create a customizable dashboard to visualize CPU utilization metrics in one place.

What is a CloudWatch Dashboard?
Purpose: Centralized monitoring interface
Customizable: Add/remove widgets
Multi-region: Monitor resources across regions
Real-time: Live metric updates
Widgets: Graphs, numbers, alarms, logs
Use Case: Quick overview for team monitoring

┌────────────────────────────────────────────────────────┐
│ AWS Monitoring System │
├────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ EC2 Instance (Stress Test) │ │
│ │ ┌──────────────────────────────────────┐ │ │
│ │ │ Application/CPU Process │ │ │
│ │ │ Stress Tool: 100% CPU Load │ │ │
│ │ └──────────────────────────────────────┘ │ │
│ └────────────┬─────────────────────────────────┘ │
│ │ (Emits metrics) │
│ ↓ │
│ ┌──────────────┐ │
│ │ CloudWatch │ │
│ │ (Monitoring)│ │
│ └──────┬───────┘ │
│ │ (Metric: CPUUtilization) │
│ │ (Comparison: 95.2% > 60%) │
│ ↓ │
│ ┌──────────────┐ │
│ │ Alarm │ │
│ │ (Triggered) │ │
│ └──────┬───────┘ │
│ │ (IN ALARM state) │
│ ↓ │
│ ┌──────────────┐ │
│ │ SNS Topic │ │
│ │ (MyCwAlarm) │ │
│ └──────┬───────┘ │
│ │ (Message routing) │
│ ↓ │
│ ┌──────────────┐ │
│ │ Email Alert │ │
│ │ Subscriber │ │
│ └──────┬───────┘ │
│ │ │
│ ↓ │
│ ┌──────────────┐ │
│ │ Your Email │ │
│ │ Inbox │ ✉️ Notification │
│ └──────────────┘ │
│ │
│ Dashboard Display: │
│ ┌──────────────────────────────────────────────┐ │
│ │ LabEC2Dashboard │ │
│ │ ┌──────────────────────────────────────┐ │ │
│ │ │ CPUUtilization Graph │ │ │
│ │ │ ╱╲ │ │ │
│ │ │ ╱ ╲ │ │ │
│ │ │ ╱ ╲ │ │ │
│ │ │ ╱────────────╲─────── │ │ │
│ │ └──────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────┘

Scanning AWS Lambda for Vulnerabilities with Amazon Inspector

Muhammad Nadeem — Mon, 20 Jul 2026 19:10:27 +0000

Recently completed a hands-on lab on using Amazon Inspector to scan AWS Lambda functions for vulnerabilities — here's a quick summary.

The Scenario

A team is building a new application using AWS Lambda and needs an automated way to catch vulnerabilities — not just in dependencies, but within the code itself, right after every deployment.

What I Did

1. Activated Amazon Inspector

Navigated to Amazon Inspector in the AWS Console
Activated the service for the account, which automatically enabled scanning for EC2, ECR, and AWS Lambda
Waited until the dashboard showed Lambda function coverage at 100%

2. Reviewed the Findings

Opened "All findings" and found three vulnerabilities reported at Medium severity
Selected the finding CVE-2023-32681 - requests
Checked the Vulnerability details, including a link to the National Vulnerability Database (NVD) for more context
Reviewed the Remediation section, which flagged the requests package as outdated and recommended an upgrade

3. Remediated the Vulnerability

Opened the affected Lambda function (get-request) in the Lambda console
Edited the requirements.txt file, removing the pinned version (requests==2.20.0) so it just read requests — ensuring the latest secure version installs automatically
Deployed the updated function