beginnerintermediateadvanced

AWS · Auto Scaling

Auto Scaling

A bounded, self-healing group of instances — and an application built to survive any one of them disappearing

min ≤ desired ≤ maxthe three numbers that bound and target group size
Target tracking is reactivescheduled/predictive get ahead of known patterns
ELB health check catches app failuresEC2 status checks alone do not
Any instance can be replaced, any timedesign for it, don't treat it as an edge case

1.Auto Scaling Group vocabulary

An Auto Scaling Group keeps a fleet of instances at a target size — never below min, never above max, and always trying to reach desired — launching them from a launch template, and replacing any instance that fails a health check.

Key features

min/max/desired: the three numbers that bound and target the group's size
Launch template: the recipe (AMI, instance type, user data) for every new instance
Health check: EC2 status checks by default, or a custom check (e.g. an ELB health check)
Lifecycle hooks: pause an instance mid-launch or mid-terminate to run custom actions
A failed instance is replaced automatically to maintain desired capacity

The three capacity numbers and what each one does

The three capacity numbers and what each one does
Setting	Meaning
Minimum	The group never scales below this, regardless of policy
Desired	The target the group actively tries to maintain
Maximum	The group never scales above this, regardless of policy

min ≤ desired ≤ max — the three capacity numbers

Minimum: 2

the group never scales below this

Desired: 4

the active target

Maximum: 10

the group never scales above this

Command

bash

aws autoscaling create-auto-scaling-group --auto-scaling-group-name app-asg \
  --launch-template LaunchTemplateName=app-lt --min-size 2 --max-size 10 --desired-capacity 4 \
  --vpc-zone-identifier "subnet-0a,subnet-0b"

min ≤ desired ≤ max bounds and targets group size; a launch template defines what launches; and a lifecycle hook creates a window to run custom logic before an instance is actually launched or terminated.

2.Target tracking, step, and scheduled scaling

Target tracking is the "just keep this metric near a value" policy — set a target (like 50% CPU) and Auto Scaling adjusts capacity to hold it there, the way a thermostat holds a temperature. Step and scheduled scaling are for cases target tracking doesn't fit: precise multi-tier responses, or capacity known in advance.

Key features

Target tracking: set a metric target (e.g. 50% average CPU), Auto Scaling adjusts capacity continuously
Step scaling: define specific capacity adjustments for different breach magnitudes of a CloudWatch alarm
Scheduled scaling: change capacity at specific, known times — a predictable daily/weekly pattern
Predictive scaling: forecasts future load from historical patterns, scales ahead of it
These are not mutually exclusive — a group can combine target tracking with a scheduled minimum

Scaling policy types and when each fits

Scaling policy types and when each fits
Policy	Fits when
Target tracking	A single metric (CPU, request count) should stay near a value — the default choice
Step scaling	Different alarm breach severities need different, specific capacity responses
Scheduled scaling	Capacity needs are known in advance — a daily traffic pattern, a planned event
Predictive scaling	Load has a recurring, learnable historical pattern worth forecasting ahead of

A predictable morning spike: reactive vs scheduled-ahead

Target tracking alone

Reacts only after the metric moves
New capacity takes real time to launch
A window of degraded performance right when the spike starts

+ Scheduled scaling

Raises the floor ahead of the known time
Capacity is already in place before demand arrives
No reaction lag

Command

bash

aws autoscaling put-scaling-policy --policy-name cpu-target --policy-type TargetTrackingScaling \
  --target-tracking-configuration file://target-tracking.json

Target tracking reacts continuously to a metric; step scaling maps specific alarm severities to specific responses; scheduled scaling gets ahead of a known pattern — they combine rather than compete.

3.Auto Scaling and load balancer integration

An Auto Scaling Group attached to a load balancer's target group automatically registers every new instance and deregisters every instance it terminates — the load balancer's own health check becomes an input to whether Auto Scaling considers an instance healthy.

Key features

Attaching a target group to an ASG makes registration/deregistration automatic
ELB health checks can be used as the ASG's health check source, not just EC2 status checks
A target failing the ELB health check can trigger replacement by the ASG
Connection draining (deregistration delay) lets in-flight requests finish before an instance is removed
Multiple target groups can be attached to one ASG for more complex routing

Command

bash

aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name app-asg \
  --target-group-arns arn:aws:elasticloadbalancing:...:targetgroup/app-tg/...

Attaching a target group automates registration/deregistration — but only setting the ASG's health check type to ELB (not just EC2) lets Auto Scaling react to application-level failures, not just infrastructure ones.

4.Designing for instance replacement, not permanence

An Auto Scaling Group can terminate and replace any instance at any time — for health, for a scale-in, for an instance refresh. An application has to be built assuming that can happen, not as an edge case to handle later.

Key features

Termination can happen for health-check failure, scale-in, instance refresh, or Spot interruption
An application must externalize anything that cannot be lost — session state, in-progress work
A SIGTERM (or ELB deregistration delay) gives a window to shut down gracefully, not indefinitely
Scale-in protection can mark specific instances as not-eligible for termination, for narrow cases
Idempotent, resumable work handles "was this in-flight request actually completed?" safely

What a graceful shutdown does inside the deregistration delay window

health failure,scale-in, or refreshstop acceptingnew requeststimeout ordrained

Running

start

SIGTERM received

Deregistered from target group

Draining in-flight requests

Terminated

end

Command

text

Assume: any instance can be replaced at any time
Design for: externalized state, graceful shutdown window, idempotent work

Any instance in an Auto Scaling Group can be replaced at any time — externalize anything that cannot be lost, handle SIGTERM within the deregistration delay window, and never depend on a specific instance ID persisting.

Spotted a mistake on this page? Tell us.

Read Sheet