Auto Scaling and Elasticity
How Auto Scaling works
Auto Scaling manages a fleet of ECS instances via a scaling group (min/max/desired capacity), a scaling configuration or launch template (image, instance type, security group, SLB attachment), and scaling rules driven by triggers (scheduled or metric-based via CloudMonitor alarms). Instances are added or removed to hold desired capacity.
Elasticity patterns
- Reactive scaling - scale on CPU, memory, or queue depth alarms.
- Scheduled scaling - predictable daily/weekly peaks.
- Dynamic + scheduled combined - baseline by schedule, burst by metric.
Cooldown prevents rapid oscillation. Health checks replace unhealthy instances. Removal policies decide which instance is terminated first.
Traps
- Forgetting that scaling configurations are immutable snapshots - you create a new one to change the image or instance type.
- Assuming scale-in is instant or safe - long-lived connections and in-flight work can be dropped; use connection draining and graceful shutdown.
- Confusing desired capacity with min/max - desired is the target, bounded by min and max.
- Expecting Auto Scaling to fix a stateful database tier - it is for stateless, horizontally scalable tiers.
- Ignoring that SLB backend registration must be part of the scaling configuration.
Rule of thumb
Scale stateless tiers horizontally; keep state in managed services (RDS, Redis, OSS). Size min capacity to survive the loss of one zone or one instance, set cooldowns longer than your boot time, and combine scheduled baseline with metric bursts.
Worked example
A web tier needs 2 instances at night and up to 10 at peak. Set min=2, max=10, desired=2, a scheduled rule raising desired to 6 at 08:00, and a CPU>70% alarm rule adding instances. Boot time is 3 minutes, so set cooldown to 5 minutes to avoid thrash.