A single EC2 instance is a single point of failure, and a fixed fleet is either too small at peak or wasted at night. EC2 Auto Scaling fixes both: it keeps a group of instances at the size you need, replaces unhealthy ones automatically, and grows or shrinks the group as load changes.
The three building blocks
- A launch template: what to launch (AMI, instance type, security groups, IAM instance profile, user data, EBS settings).
- An Auto Scaling group (ASG): where and how many (subnets across AZs, minimum, maximum and desired capacity, attached target groups).
- Scaling policies: when to change the desired capacity.
Capacity: min, max and desired
The ASG always tries to keep desired capacity instances running, never fewer than min or more than max. Scaling policies only change the desired number. Setting min to at least 2 across two Availability Zones gives you resilience even when nothing is scaling; setting a sensible max protects you from runaway costs if a policy misbehaves.
The ASG also balances across AZs. If one zone has more instances than another, it launches in the emptier zone first, and after an AZ outage it rebalances once the zone recovers.
Health checks: replace, don't just ignore
By default, an ASG only uses EC2 status checks: it replaces instances whose hardware or OS fails. If the application inside crashes, EC2 still reports the instance as healthy. Enable the ELB health check type on the ASG so that instances failing the load balancer's health check are terminated and replaced.
Set a health check grace period long enough for instances to boot and start the app, or the ASG may kill new instances before they are ready, causing a launch-terminate loop.
Scaling policies
| Policy | How it works | Use when |
|---|---|---|
| Target tracking | Keeps a metric near a target (like a thermostat), e.g. average CPU 50% or 1,000 requests per target | Default choice for most web workloads |
| Step scaling | Adds or removes set amounts based on how far an alarm is breached | You need different responses for small and large spikes |
| Simple scaling | One adjustment per alarm, then a cooldown | Legacy; prefer step or target tracking |
| Scheduled actions | Changes capacity at set times | Known patterns: business hours, nightly batch, non-prod shutdown |
| Predictive scaling | Forecasts load from history and scales ahead of it | Strong daily or weekly cycles with slow-booting instances |
For web apps behind an ALB, ALBRequestCountPerTarget is often a better target-tracking metric than CPU, because it measures the actual work arriving.
Warm-up and cooldown
A new instance does not help until it is serving traffic. The default instance warm-up tells the ASG how long to wait before counting a new instance's metrics, preventing it from launching even more instances while the first ones are still starting. Keep boot times short: bake dependencies into the AMI instead of installing them in user data on every launch.
Lifecycle hooks
Lifecycle hooks pause an instance in Pending:Wait or Terminating:Wait so you can run custom steps: register with a configuration system, warm a cache, drain work or copy logs before termination. A Lambda function or script completes the hook when done, or it times out and proceeds.
Updating instances: instance refresh
When you publish a new launch template version (new AMI, new instance type), instance refresh replaces instances gradually while keeping a minimum healthy percentage, optionally with checkpoints and automatic rollback if alarms fire. It is the simplest safe rollout mechanism for EC2 fleets.
Saving money with Auto Scaling
- Mixed instances policy: combine On-Demand base capacity with Spot instances across several instance types for large discounts with acceptable risk.
- Scheduled scale-to-zero for dev and test environments outside working hours.
- Graviton instance types in the launch template for better price-performance.
Common problems
- Instances launch and terminate in a loop: grace period too short, health check path wrong, or the app fails to start (check user data logs).
- ASG never scales in: scale-in protection enabled, or the metric never drops below the target because of background load.
- Desired capacity stuck at zero: someone set it manually or a scheduled action did; check the activity history, which explains every change.
Practice it
Build the classic pattern in Build a Scalable Web Application Using ALB and Auto Scaling Group, add Spot in Mixed Instances ASG, and self-heal with Self-Healing Web Tier: ELB Health Checks and Lifecycle Hooks. For a live outage, try Store Down: Auto Scaling Fleet at Zero.
FAQ
Is Auto Scaling free?
Yes. You pay only for the instances and other resources it launches, plus any CloudWatch alarms you create.
Launch template or launch configuration?
Launch templates. Launch configurations are a legacy feature and do not support newer capabilities like mixed instances.
Can Auto Scaling work without a load balancer?
Yes, for workers that pull from a queue, for example scaling on SQS queue depth per instance.