What Is Auto Scaling in AWS? Min, Max and Desired Explained

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

1. Why manual scaling fails

With only an alarm and SNS, scaling looks like this:

1. Average CPU stays above 70% for 5 minutes; the alarm fires.
2. SNS emails the admin.
3. The admin reads it, launches a server from the AMI and registers it in the target group.
4. If the admin is asleep, travelling or busy, step 3 doesn't happen, and the servers that are running slow down and can crash.

Suppose we are Hotstar during a big cricket match. Viewers jump within minutes when the match gets exciting. New servers take minutes to be ready, so the launching must start on its own, at once.

2. How Auto Scaling works

1. A CloudWatch alarm watches the group's average CPU.
2. When it fires, it calls the Auto Scaling group's scaling policy directly, for example "add 1 instance". (SNS is only for telling people; it is not needed for the scaling.)
3. The policy raises desired by one.
4. The group launches a server from its launch template, into the subnets you chose.
5. The group registers it in the load balancer's target group automatically. Once its health check passes, it gets traffic.
6. When a low alarm fires (for example average below 30%), the policy lowers desired and the group terminates a server.

Every policy type (simple, step, target tracking, scheduled) is listed in Every Auto Scaling policy.

3. The launch template: the recipe for every new server

The group needs to know exactly what to launch. A launch template holds it once:

1. AMI: the image of your ready web server (Nginx, PHP, your code).
2. Instance type: for example t3.micro.
3. Key pair: for SSH, if you need it.
4. Security group: for example web-sg, which allows 80 from the load balancer's SG only.
5. Storage (EBS): size and type of the root volume.
6. User data: a script that runs at first boot, for example to start the web server or pull the latest code.

A small user data example:

```bash

!/bin/bash

sudo yum install nginx -y sudo service nginx start ```

The subnets are not in the template; you pick them in the group.

The golden AMI: build one development server, install Nginx and your code, test it, then Actions > Image and templates > Create image. That AMI is what the template launches, so every new server is ready in a minute or two instead of installing everything at boot.

Template versions: a launch template keeps numbered versions, like app updates. Version 1 uses the AMI of your app 1.0; when app 2.0 is ready you create a new AMI and save it as version 2 of the same template. The group can then move its servers to the new version (section 11).

4. Min, desired and max

1. Desired: how many servers should run now. The group always works to make the running count equal desired.
2. Min: desired never goes below this, even at 2 AM.
3. Max: desired never goes above this, even when every server is busy.

Worked example 1: scaling out. Suppose min 1, desired 2, max 4.

1. Average CPU stays above 70%: desired 2 → 3. A third server starts.
2. Still above 70%: desired 3 → 4.
3. Still above 70%: desired stays 4. No 5th server, because max is 4.

Worked example 2: scaling in. Same group at 2 AM.

1. Average CPU below 30%: desired 4 → 3, then 3 → 2, then 2 → 1.
2. Still low: desired stays 1. It can't go to 0 while min is 1.

5. How many servers start?

A new group launches desired, not min.

1. Suppose min 2, desired 3, max 6.
2. On creation, 3 servers launch.
3. Later the policies move desired anywhere from 2 to 6.

6. Max protects your bill

1. AWS bills after you use it, for every server that ran.
2. Without a sensible max, a sudden spike, a bug that burns CPU, or a flood of junk traffic could launch far more servers than you planned.
3. So set max to what you can afford. If real growth needs more, raise it yourself, on purpose.

Worked example: what does max cost? Suppose one server costs ₹1 per hour (a made-up round number to keep the math easy) and max is 4. The most this group can cost is 4 × ₹1 × 24 = ₹96 a day. With max 40, the ceiling is ₹960 a day. Use the real price of your instance type for your own numbers.

7. Subnets, AZs, and one group per tier

1. The group launches into the subnets you pick in your VPC, and spreads the servers over their AZs. If one AZ has trouble, the others keep serving.
2. The web tier and the app tier have different work and different load, so each gets its own load balancer and its own Auto Scaling group:
3. Internet → internet-facing load balancer → web Auto Scaling group.
4. Web tier → internal load balancer → app Auto Scaling group.
5. The database is RDS, which scales in its own way (bigger instance, read replicas).

Putting it together, highly available: 2 AZs, each with 4 subnets: a public one (load balancer, NAT gateway, bastion), and private ones for web, app and the database. That is 2 × 4 = 8 subnets.

8. Self-healing: a load balancer alone vs with Auto Scaling

Load balancer alone:

1. A server fails its health check and is marked unhealthy.
2. It gets no traffic, but it stays there, broken, until someone fixes it. You now have one server fewer.

Load balancer + Auto Scaling group with ELB health checks:

1. The group asks the load balancer which of its servers are healthy.
2. An unhealthy server is terminated.
3. A new one is launched from the launch template and registered. The count is back to desired, with no one awake.

The setting that makes this work: the group's health check type is EC2 by default, which only checks that the instance itself is running. Turn on Elastic Load Balancing health checks so a server whose Nginx has stopped is replaced too. Give new servers a grace period (for example 300 seconds) to boot before they are judged.

One more thing: if you terminate a server of the group by hand, the group simply launches a new one to get back to desired. To stop the servers for good, set desired and min to 0, or delete the group.

More on the lab version of all this: Auto Scaling and How this connects to scaling.

9. Scaling policy types

Why: "add a server when CPU is high" is only one way. AWS gives four, for different traffic shapes.

1. Target tracking (dynamic): you give one target, for example "keep average CPU at 50%". The group adds servers when the average goes above it and removes them when it falls well below. It creates and manages the CloudWatch alarms for you. This is the usual choice.
2. Step or simple scaling (dynamic): you create the alarms yourself and say what to do, for example "CPU ≥ 70% for 5 minutes: add 1 server" (section 13, Part C).
3. Predictive scaling: AWS learns from your past traffic and launches servers before a repeating peak. Suppose we are Netflix and traffic jumps every Friday at 6 PM: predictive scaling can have servers running by about 5:55 PM.
4. Scheduled scaling: you set the capacity for a known date and time. Suppose we are Flipkart and a sale starts at 6 AM, or a phone launch at 10 AM, or a cricket match at 6 PM: schedule desired to rise just before.
5. Dynamic policies react after the load arrives; predictive and scheduled get ready before it.

Worked example: why one busy server may not scale out

1. The group has 2 servers and a target tracking policy at 50% average CPU.
2. Stress only one server to 100%; the other stays near 0%.
3. Average = (100 + 0) ÷ 2 = 50%. That's at the target, not above it, so the group may not add a server.
4. Stress both to 100%: average = (100 + 100) ÷ 2 = 100%, well above 50%, so the group launches more servers, up to max 4.

10. Warmup, grace period and the health checks

Instance warmup (for example 60 seconds): a new server needs time to boot and start Nginx, and during that time its CPU numbers are not normal. Until the warmup ends, its metrics are left out of the group's average, so one booting server doesn't trigger more scaling.

Health check grace period (for example 60 to 300 seconds): how long the group waits after launch before it judges the server's health. Too short, and servers that are still booting get terminated in a loop.

Health check types:

1. EC2 (always on): checks that the instance itself is running.
2. Elastic Load Balancing: the server must also pass the target group's health check, for example Nginx answering /.
3. Amazon EBS: marks the instance unhealthy when an attached EBS volume is impaired (an I/O or hardware problem). It does not check how full the disk is; disk usage needs the CloudWatch agent.

11. Updating servers without downtime

Why: suppose 10 servers run your app version 1.0 behind the load balancer, and version 2.0 is ready. Stopping all 10 and starting new ones would take the site down.

1. Build a new AMI with version 2.0 and save it as version 2 of the launch template.
2. Point the group at the new version.
3. Start an Instance refresh on the group. It replaces servers in batches, keeping a minimum healthy percentage, for example 90%, so only 1 of the 10 is replaced at a time.

Instance maintenance policy: what the group does when it replaces a server.

1. Launch before terminating: start the new server, wait until it is healthy, then terminate the old one. Capacity never drops; for a short time you pay for one extra server.
2. Terminate and launch: terminate the old one first, then start the new one. Cheaper, but capacity dips during the swap.

12. Scale-in protection

1. Instance scale-in protection stops the group from terminating that instance when it scales in. Use it for a server that is doing a long job that must not be cut off.
2. Short dips need no protection. Suppose we are streaming a cricket match: during an ad break viewers drop for a few minutes and come back. Target tracking scales in slowly and conservatively, and you can also turn off scale-in for the policy, so the group doesn't remove servers it will need again a minute later.

13. Build it in the console

Part A: the launch template

1. EC2 > Launch templates > Create launch template, name web-lt.
2. Tick Provide guidance to help me set up a template that I can use with EC2 Auto Scaling.
3. AMI: your web server AMI (My AMIs). Instance type: t3.micro. Key pair: yours.
4. Network settings: don't pick a subnet; pick security group web-sg.
5. Advanced details > User data: paste the script from section 3. Create launch template.

Part B: the Auto Scaling group

1. EC2 > Auto Scaling groups > Create Auto Scaling group, name web-asg, launch template web-lt. Next.
2. Network: your VPC, and the web subnets in two AZs. Next.
3. Load balancing: Attach to an existing load balancer, choose target group tg-web (how it was made).
4. Health checks: tick Turn on Elastic Load Balancing health checks, grace period 300 seconds. Next.
5. Group size: desired 2, min 1, max 4.
6. Scaling: choose No scaling policies for now (Part C adds one). Optionally add an SNS notification so people are told about launches. Create Auto Scaling group.
7. Two servers launch and appear as healthy targets in tg-web.

Part C: a scaling policy driven by a CloudWatch alarm

1. CloudWatch > Alarms > Create alarm > Select metric > EC2 > By Auto Scaling Group, web-asg, CPUUtilization. Statistic Average, period 5 minutes, ≥ 70. Remove the notification if you don't need email. Name it web-cpu-high, Create alarm.
2. Make web-cpu-low the same way, with < 30.
3. Open web-asg > Automatic scaling > Create dynamic scaling policy, type Simple scaling, alarm web-cpu-high, action Add 1 capacity units, then wait 300 seconds. Create.
4. Create a second policy with alarm web-cpu-low, action Remove 1 capacity units.
5. (A target tracking policy, "keep average CPU at 50%", creates both alarms for you; it is the usual choice in production.)

Part D: test it

1. SSH to both servers and run sudo yum install stress-ng -y and stress-ng --cpu 2 --timeout 900.
2. In about 5 minutes web-cpu-high goes to In alarm; Activity shows a launch; desired becomes 3, later 4, never 5.
3. When stress ends, web-cpu-low brings it back down, never below 1.
4. Stop Nginx on one server: sudo service nginx stop. It turns unhealthy in tg-web, and the group replaces it.

Part E: let the group create its own load balancer

1. In Create Auto Scaling group, step Load balancing, choose Attach to a new load balancer: Application Load Balancer, Internet-facing, a new target group on port 80.
2. Health checks: turn on Elastic Load Balancing health checks, grace period 60 seconds. Group size: desired 2, min 1, max 4. Policy: Target tracking, Average CPU utilization, target 50, instance warmup 60 seconds. Maintenance policy: Launch before terminating.
3. Activity shows the launches, for example "changing the desired capacity from 0 to 2". Instance management shows both as InService; in the target group they go from initial to healthy.
4. Open the load balancer's DNS name. If it times out, the load balancer's security group doesn't allow HTTP 80 from the internet: add HTTP, 80, 0.0.0.0/0 to it, and the page loads.
5. Allow 80 on the servers' security group from the load balancer's security group only. The servers don't need public IPs: the load balancer reaches them on their private IPs.

Part F: SSH to a server of the group

1. EC2 Instance Connect or SSH needs port 22 open in the servers' security group; prefer My IP to 0.0.0.0/0.
2. For servers in private subnets, go through a jump server: ssh -J ec2-user@<jump-public-ip> ec2-user@<private-ip> (How to Access a Private EC2 with a Bastion Host and NAT Gateway).
3. On Windows, chmod 400 doesn't work in PowerShell. Open the key file's Properties > Security > Advanced, disable inheritance and leave only your own user with Read; or run SSH from Git Bash or WSL.
4. A key with loose permissions gives the warning UNPROTECTED PRIVATE KEY FILE. Connection closed or a timeout before login usually means a network, security group or firewall problem, not the key.

14. When something goes wrong

1. New servers launch but stay unhealthy: the user data failed, the AMI isn't the ready web server, or web-sg doesn't allow 80 from the load balancer SG.
2. Servers keep being terminated and launched in a loop: the grace period is too short for boot time, or the health-check path returns an error.
3. An unhealthy target is never replaced: the group's health check type is still EC2 only. Turn on ELB health checks.
4. The alarm fires but nothing launches: desired is already at max, or the alarm isn't attached to a scaling policy (only to SNS).
5. You terminated the servers but they came back: that is the group doing its job. Set desired and min to 0, or delete the group.

15. The whole class on one page

1. Alarm → SNS → a person is manual scaling; it fails when the person is busy or asleep.
2. Auto Scaling: the alarm calls the group's scaling policy directly; SNS is only for people.
3. Launch template: AMI, instance type, key pair, SG, EBS, user data. Subnets are chosen in the group.
4. Desired = running now; min = floor; max = ceiling. Min 1, desired 2, max 4: up to 4, down to 1.
5. A new group starts with desired, not min (min 2, desired 3, max 6 → 3).
6. Max is your cost ceiling; raise it on purpose.
7. Each tier: its own load balancer (internet-facing / internal) and its own group, across AZs.
8. With ELB health checks on, the group replaces unhealthy servers; a load balancer alone only stops sending them traffic.
9. Terminated by hand → replaced. To stop for good: desired and min 0, or delete the group.
10. Policy types: target tracking (keep a target), step/simple (your alarms), predictive (before repeating peaks), scheduled (known dates).
11. Warmup keeps booting servers out of the average; the grace period delays health judgement; EBS health checks catch impaired volumes, not full disks.
12. New version: new AMI → template version 2 → instance refresh; launch before terminating keeps capacity.
13. Scale-in protection keeps a server with a long job from being terminated.

16. 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.