Stop 10 · Cloud Platforms (AWS / GCP / Azure)Topics · 7/11

Auto Scaling

In short

Your site gets a burst of traffic during a festival sale, then goes quiet. Auto Scaling adds servers when load rises and removes them after, so you don't pay for peak all year.

Automatically adding or removing compute capacity based on demand — the cloud-native equivalent of Kubernetes' Horizontal Pod Autoscaler, but at the level of entire virtual machine instances.

The mascot couples an extra coach onto a train at a platform crowded with festival travellers.

Think of it like this

Extra coaches for festival rush

Before Diwali and Chhath, Indian Railways adds extra coaches to packed trains, then removes them once the rush ends. Same train, same route, more seats only when needed. An Auto Scaling group does that with virtual machines behind your load balancer.

Watch it happen

Scaling out during a sale

CloudWatch

ASG

New VM

Load balancer

avg CPU 78% > 60%

1/6A target tracking policy aims for 60% average CPU. CloudWatch sees it climb well above that.

The big ideas

What you need to know

Launch templates

Define the AMI, instance type and startup script once. Every new instance is built the same way.

Min, max, desired

Min keeps you available, max caps cost, desired is what the group aims for right now.

Target tracking

Pick a metric and a target, like 60% CPU. AWS adds or removes instances to stay near it.

Health replaces too

An instance failing health checks is terminated and replaced, so ASGs also give you self-healing.

See it in code

Walk through the code

hcl

1resource "aws_autoscaling_policy" "cpu" {2  name                   = "keep-cpu-at-60"3  autoscaling_group_name = aws_autoscaling_group.web.name4  policy_type            = "TargetTrackingScaling"5  target_tracking_configuration {6    predefined_metric_specification {7      predefined_metric_type = "ASGAverageCPUUtilization"8    }9    target_value = 6010  }11}

1/3A target tracking policy attached to the web Auto Scaling group.

This policy attaches to an aws_autoscaling_group (with min_size, max_size and a launch_template) defined elsewhere.

Save yourself the pain

Common mistakes

Oops

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

Do this instead

Instances can be removed at any time. Keep state in S3, a database or a cache like Redis.

Oops

Setting min and max to the same number and calling it auto scaling.

Do this instead

That's a fixed fleet with self-healing. Leave room between min and max, and test a scale-out before the big day.

Your mission

Design for a sale

~25 min

Quick check

Why should an app behind an Auto Scaling group avoid storing sessions on local disk?

Go deeper

1Explore an auto scaling group's configuration options (min/max instances, scaling triggers).
2Learn why auto scaling requires a load balancer in front of it to distribute traffic to new instances.
3Understand the trade-off between scaling aggressively (cost) and scaling conservatively (risk of being under-provisioned).