Stop 04 · Compute ServicesTopics · 3/10

Auto Scaling Groups

Part of the Cloud Computing Roadmap

In short

Results day, a flash sale, a viral reel: traffic jumps without warning. Auto scaling adds servers when they're needed and removes them when they're not, so you don't stay up watching graphs.

Automatically adding or removing VM instances based on demand — a core mechanism for handling variable traffic without manual intervention, paired with a load balancer to distribute traffic to new instances.

The blob character opens a new billing counter as shopping trolleys line up.

Think of it like this

Extra billing counters

On a Sunday evening the supermarket manager sees the queue growing and opens two more counters. When the rush ends, those staff go back to stocking shelves. An auto scaling group is that manager for your servers.

Watch it happen

A traffic spike, handled

CloudWatch
Auto Scaling
New VMs
Load balancer

avg CPU 78% > 60%

1/6The group's average CPU crosses the 60% target you set. CloudWatch tells Auto Scaling.

The big ideas

What you need to know

Min, max, desired

Min is the floor, max is the ceiling, desired is how many should run right now. Scaling changes desired.

Launch template

The recipe for every new instance: image, type, security groups and user data script. Keep it up to date.

Target tracking

Say 'keep CPU around 60%' and the group adds or removes instances to hold that line.

Self-healing

If an instance fails health checks, the group terminates and replaces it. You get this even with no scaling policy.

See it in code

Walk through the code

bash
1aws autoscaling create-auto-scaling-group \2  --auto-scaling-group-name web-asg \3  --launch-template LaunchTemplateName=web-lt \4  --min-size 2 --max-size 6 --desired-capacity 2 \5  --vpc-zone-identifier "subnet-aaa111,subnet-bbb222"6 7aws autoscaling put-scaling-policy \8  --auto-scaling-group-name web-asg \9  --policy-name keep-cpu-60 \10  --policy-type TargetTrackingScaling \11  --target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":60}'

1/3Create the group from an existing launch template.

Two subnets in different zones means one zone going down doesn't take all your servers with it.

Save yourself the pain

Common mistakes

Oops

Storing user uploads or sessions on the instance's own disk.

Do this instead

Instances come and go. Keep state in S3, a database or a cache so any instance can serve any user.

Oops

Setting max size very high with no billing alert.

Do this instead

A bug or attack can scale you to the max. Set a sensible ceiling and a budget alert.

Your mission

Watch it heal

~40 min

Quick check

Your group has min 2, max 8, desired 2. Traffic triples and CPU passes the target. What changes first?

Go deeper

  1. 1Set up an auto scaling group with a minimum, maximum, and desired instance count.
  2. 2Configure a scaling policy based on a metric like CPU utilization.
  3. 3Learn why auto scaling groups are almost always paired with a load balancer.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge