AWS Certified Cloud Practitioner / ELB & ASG - Elastic Load Balancing & Auto Scaling Groups

Auto-Scaling Groups (ASG Overview)

1️⃣ Why Auto Scaling?

Real traffic is never constant 📊

  • 🌞 Day → high traffic

  • 🌙 Night → low traffic

If you size your servers for one fixed number, you always lose:

  • Size for peak traffic → you overpay 💸 during quiet hours, running servers nobody needs

  • Size for average traffic → you crash ❌ the moment traffic spikes above it

💡 The fix: an Auto Scaling Group (ASG) watches real demand and adjusts the number of EC2 instances for you — automatically, in both directions.

2️⃣ What an ASG Actually Does

An ASG constantly compares current load against your configured thresholds and reacts:

➕ Scale out — add instances

When traffic climbs 📈, the ASG launches more EC2 instances 💻💻💻 to absorb the load.

➖ Scale in — remove instances

When traffic drops 📉, the ASG terminates instances it no longer needs, so you stop paying for idle capacity.

🎯 The goal isn't "more" or "fewer" servers — it's always running the right number for current demand.

3️⃣ Architecture: ALB + ASG Together

Users 🌍 → ⚖️ Load Balancer → ⚙️ Auto Scaling Group → 💻 EC2 Instances

The load balancer is the fixed entry point traffic hits first. Behind it, the ASG owns the instances — deciding how many exist at any moment and handing that live pool to the load balancer to distribute traffic across.

!image.png

4️⃣ Key ASG Settings

Every ASG is defined by three numbers that set its scaling boundaries:

🔢 Minimum capacity

The floor — the ASG will never run fewer than this many instances, even at zero traffic. 👉 Example: 1

🎯 Desired capacity

The target it maintains under normal conditions — what "steady state" looks like for your app. 👉 Example: 2

🚀 Maximum capacity

The ceiling — the most instances the ASG is allowed to launch, no matter how high traffic spikes. This caps your worst-case cost. 👉 Example: 5

Put together:

Min = 1
Desired = 2
Max = 5

👉 Day to day, the ASG sits at 2 instances. Under load, it can scale anywhere between 1 and 5 — but never outside that range.

5️⃣ ASG + Load Balancer: The Key Integration

Scaling only helps if new traffic actually finds the new instances — and that's handled automatically:

  • Instance created ➕ → it's automatically registered with the ALB's target group and starts receiving traffic

  • Instance removed ➖ → it's automatically deregistered, so the ALB stops sending it traffic before it disappears

👉 You never manually add or remove targets — the ASG and ALB stay in sync on their own 🤖

6️⃣ Self-Healing: Free Fault Tolerance

Auto scaling isn't just about load — it also protects against failure.

💥 If an instance fails:

  1. The ASG detects it's unhealthy ❌ (via the same health checks the ALB uses)

  2. It terminates the failed instance 🧹

  3. It immediately launches a fresh replacement ✅ to keep the group at its desired capacity

🎯 Result: your app recovers from a crashed server without you touching anything.

7️⃣ Cost Optimization

  • Without ASG: you provision for peak traffic and pay for that capacity 24/7 💸, even while most of it sits idle

  • With ASG: capacity tracks demand in real time — you pay for roughly what you actually use 🎯

👉 This is what "elastic" in elastic cloud computing really means.

⚖️ ASG vs Load Balancer — Different Jobs

They're often used together, but they solve different problems:

  • Role: the Load Balancer distributes traffic; the ASG manages how many instances exist

  • Handles failures: both do — the ALB routes around an unhealthy instance, the ASG replaces it

  • Scaling: only the ASG scales capacity up or down

  • Entry point: only the ALB is a traffic entry point; the ASG has no public address

📝 Exam Tips (very important)

  • ASG = elasticity ⚡

  • Scale out = add instances ➕

  • Scale in = remove instances ➖

  • Works together with an ALB ⚖️

  • Self-healing = automatically replaces unhealthy instances 🛡️