AWS Auto Scaling

Automatically adds and removes capacity so you're running the right number of resources for current demand.

Verified against AWS documentation · 2026-09-09

Key facts

01Three numbers run everything: min, desired, max — the group never drops below min or climbs past max
02Launch template = what to launch; Auto Scaling group = how many and which AZs; scaling policy = when to change
03Failed health check → instance terminated and replaced automatically. This is self-healing, not just scaling
04Four ways to scale: target tracking (metric + target, the default answer), step/simple (alarm thresholds), scheduled (clock), predictive (ML forecast, scales OUT only, needs 24h of data)
05A group spans AZs inside one Region, never across Regions — ASG + ELB across 2–3 AZs is the standard HA answer
06Reality check: launch configurations are legacy. Accounts created on or after Oct 1, 2024 can't create them at all — launch templates only

Phrases and scenarios that point here.

"Match capacity to demand", "handle unpredictable traffic", "elasticity", "scale in and out"
"Always keep N healthy instances" / "replace failed instances automatically" → ASG health checks
Spike at the same time every day → scheduled scaling; spike that follows a learned pattern → predictive
"Add more instances" is scaling out (this service); "use a bigger instance" is scaling up (not this service)
Scaling something that isn't EC2 — DynamoDB capacity, ECS tasks, Aurora replicas → AWS Auto Scaling

Deciding which instance gets the request → ELB (Auto Scaling changes how many, ELB routes to them)
Right-sizing to a bigger or cheaper instance type → Compute Optimizer
Capacity that already scales itself with zero config → Lambda, S3, DynamoDB on-demand

01Web tier behind an ALB that doubles at 9am and halves at 7pm — target tracking on CPU or request count keeps it honest with nobody watching
02A min=1, max=1 group used purely as a babysitter: if the box dies at 3am, a replacement is up before anyone gets paged
03Batch worker fleet on Spot, scaled on SQS queue depth — workers appear when the queue backs up and vanish when it drains
04Flash sale or exam-results day — scheduled scaling warms capacity 30 minutes ahead, because target tracking reacts too slowly for a wall of traffic arriving in 60 seconds
05Dev and test environments scheduled down to zero overnight and on weekends — the cheapest instance is the one that isn't running

01The service itself is free — you pay for what it launches: EC2 instances, EBS volumes, data transfer
02CloudWatch is the hidden line item — scaling policies create alarms, and detailed 1-minute monitoring costs extra but makes scaling react faster
03Scale-in is where the saving actually happens; a group that scales out and never comes back down is just a slower way to overprovision
04A mixed instances policy blends On-Demand and Spot in one group — Spot runs up to 90% below On-Demand and is the biggest lever available here
05Max capacity is your cost blast radius: set it too high and a runaway metric bills you for hundreds of instances. Predictive scaling's max-capacity-breach setting can raise that ceiling permanently