Auto Scaling Groups - Dynamic Scaling for Production Workloads

What you will learn

• What an Auto Scaling Group is and the problem it solves
• The three numbers that every ASG is built around
• How Launch Templates tell ASG exactly what to launch
• How CloudWatch alarms trigger scaling decisions
• The four scaling policies and when to use each
• How ASG and Load Balancer work together for self-healing
• Cooldown periods and how to make them shorter

Why this matters

Imagine Swiggy running on 4 EC2 instances on a normal Tuesday. Then IPL final starts. 10x traffic hits in minutes. The 4 instances buckle, response times climb, users see errors. By the time an engineer wakes up and manually adds servers, the moment has passed.

Auto Scaling Groups solve this without any human involvement. The fleet grows automatically when traffic spikes and shrinks when traffic drops. And even on quiet days at 3 AM — if one instance crashes, ASG notices, terminates it, and launches a fresh replacement. Nobody wakes up.

That is the core idea. One setup. Permanent protection.

What is an Auto Scaling Group

An ASG is a managed fleet of EC2 instances. You define the rules. AWS handles the rest.

ASG itself costs nothing. You only pay for the EC2 instances it creates.

The Three Numbers

Every ASG has exactly three numbers. Everything else flows from these.

When a scaling event fires, ASG changes the desired number first. Then it launches or terminates instances to match that number. Min and Max are hard walls desired can never cross.

Remember

Always set minimum to at least 2 and spread across 2 Availability Zones. Minimum of 1 means one AZ failure takes your whole app down until ASG can replace the instance — that takes minutes.

Launch Template — What Gets Launched

When ASG needs to add a new instance, it follows a Launch Template. You create this once and ASG uses it every time forever.

Every new instance launched by ASG is identical. No manual setup. No snowflake servers.

Remember

Launch Configurations are the old version of Launch Templates and are deprecated. Always use Launch Templates — never Launch Configurations — for any new ASG.

Pre-baked AMI vs plain Amazon Linux

If your Launch Template uses a standard Amazon Linux AMI and installs your app via User Data, every new instance takes 5 to 10 minutes to become ready. During that time it cannot serve traffic.

Faster boot time means shorter cooldown. Shorter cooldown means ASG reacts faster to real spikes. Pre-baking your app into a custom AMI is one of the highest-impact changes you can make to an ASG setup.

ASG and Load Balancer Together

In production, ASG and Load Balancer are always used together. They do different jobs but depend on each other.

The teamwork looks like this:

And when something goes wrong:

This whole cycle takes 3 to 5 minutes. No engineer involved. This is self-healing infrastructure.

Remember

Use health check type ELB, not EC2. EC2 health check only verifies the instance is running — not that your app is actually working. An instance can be up and returning errors on every request. ELB health check catches that. EC2 health check does not.

CloudWatch Alarms — How ASG Decides to Scale

ASG does not watch your traffic on its own. CloudWatch watches it and tells ASG what to do.

What to scale on:

RequestCountPerTarget is excellent for APIs. Say "keep 1000 requests per instance" and ASG maintains that automatically by adding or removing instances. More meaningful than raw CPU for web workloads.

For queue-based workers, scale on ApproximateNumberOfMessages. Queue grows → scale out. Queue empties → scale in. CPU tells you nothing useful when your app is just reading from a queue.

The Four Scaling Policies

Target Tracking — start here for most things

You pick a target metric value. ASG automatically creates the CloudWatch alarms and figures out how many instances to add or remove. You do nothing else.

This is the simplest policy and the right starting point for most workloads.

Step Scaling — different responses for different severity

A mild spike adds 2 instances. A severe spike adds 5. You define the thresholds and the steps.

Useful when a small traffic bump and a major traffic event need very different responses.

Scheduled Scaling — for predictable patterns

Zerodha knows market opens at 9:15 AM every weekday. Traffic spikes then. Every night it is quiet.

Schedule it once. Never worry about it again.

Predictive Scaling — scale before traffic arrives

AWS looks at 14 days of your traffic history, predicts when the next surge will come, and pre-scales 30 minutes before it hits. Instead of reacting after the spike arrives and waiting 2-3 minutes for instances to boot, you are already ready.

Works best when you have consistent daily or weekly patterns.

Cooldown Periods

After ASG launches new instances, it waits before launching more. This waiting time is the cooldown. Default is 300 seconds.

Why it exists:

Without cooldown, ASG would keep launching instances every 60 seconds while the first batch boots. You would end up with 3x more instances than needed.

Tip

Pre-bake your app into a custom AMI so instances boot in 60-90 seconds instead of 8-10 minutes. Then set a 90-second cooldown instead of 300. ASG reacts faster, scales more precisely, and never over-provisions. This single change often cuts scaling overshoot by 60-70%.

Lifecycle Hooks — Pause Before Traffic

Sometimes a new instance needs to do something before it starts receiving traffic — register with a service discovery tool, pull secrets, warm up a cache.

Lifecycle hooks let you pause the instance at a specific point and run custom logic before it joins the fleet.

The instance never receives a single request until your custom initialisation is complete.

Termination Policy — Which Instance Gets Removed

When ASG scales in, it needs to decide which instance to terminate. The default logic:

You can override with: OldestInstance, NewestInstance, OldestLaunchTemplate, or ClosestToNextInstanceHour.

Hands-on Lab — Create ASG, Test Self-Healing, Watch Scale-Out

This lab creates a working ASG, confirms self-healing works, and generates real CPU load to watch the scaling fire.

Step 1 — Create the Launch Template in the Console

Step 2 — Create the Auto Scaling Group

Step 3 — Attach a Target Tracking Policy

This creates CloudWatch alarms automatically. No extra work needed.

Step 4 — Verify both instances are healthy

Step 5 — Test self-healing

Step 6 — Generate CPU load and watch scale-out

Step 7 — Cleanup

Common Mistakes to Avoid

Common Mistake

Setting minimum to 1. One instance means one Availability Zone. If that AZ has hardware trouble your app goes down until ASG replaces the instance — which takes minutes. Always set minimum to at least 2 across 2 AZs. High availability requires at least 2 copies.

Common Mistake

Using EC2 health check type instead of ELB. An instance can be running perfectly but your application crashing on every request. EC2 health check calls it healthy. ELB health check calls it unhealthy and ASG replaces it. Always use ELB health check for application workloads.

Common Mistake

Using a plain Amazon Linux AMI when you could pre-bake. Every 8-minute boot time is 8 minutes your new instances cannot serve traffic. Pre-bake your app. Boot in 90 seconds. Cooldown drops from 300 to 90 seconds. ASG reacts 3x faster to real spikes.

Security

Set Maximum to a number your budget can handle. During a traffic spike or a bug causing infinite scaling, the Maximum capacity is the only thing protecting your bill. Calculate your maximum based on cost, not just technical need.

Tip

For queue-based workers reading from SQS — scale on ApproximateNumberOfMessages not CPU. Set a target of messages-per-instance (say 1000 per worker). Queue builds up → instances scale out. Queue drains → instances scale in. Perfect matching between work and compute. CPU is irrelevant for a queue consumer.

Instance Refresh — Rolling Updates Without Downtime

When you update your Launch Template — new AMI, new instance type, new User Data — existing instances are still running the old version. Instance Refresh replaces them gradually without taking your application offline.

Tip

Always trigger an Instance Refresh after updating a Launch Template. Without it, old instances keep running the old version indefinitely. Only new scale-out instances use the new template.