Visual overview
Policies change desired capacity while the group remains inside its minimum and maximum bounds.
Technical reference
An Auto Scaling group is bounded by capacity parameters and controlled by policies.
Policies cannot reduce desired capacity below this bound.
The group attempts to maintain this amount of capacity.
Policies cannot increase desired capacity above this bound.
Policies respond to a target metric, alarm steps, time, or forecasted recurring demand.
The Auto Scaling group is the core unit
Amazon EC2 Auto Scaling manages collections of EC2 instances called Auto Scaling groups. A group has minimum, maximum and desired capacity settings. Auto Scaling works to maintain the desired amount of healthy capacity within those bounds and can launch replacement instances when managed health checks identify failures. The launch definition—normally a launch template—tells the group how new instances should be created.
This fleet mindset is a major architectural shift from managing individual servers. Applications should expect instances to be launched and terminated as capacity and health change. Durable state, configuration and application deployment therefore need to survive instance replacement. When that is true, replacing an unhealthy server becomes a routine control action rather than an outage-recovery project.
Dynamic, scheduled and predictive scaling
Dynamic scaling adjusts capacity in response to signals. Target tracking is useful when you can define a metric target that represents the desired operating level; other policies can react to CloudWatch alarms and scale in steps. The important design choice is the metric: it should correlate with real application demand and capacity, not simply be a convenient number that changes frequently.
Scheduled scaling changes capacity at known times and suits predictable events. Predictive scaling analyzes historical patterns to forecast future demand and can increase capacity ahead of repeating traffic patterns. These approaches can be combined, but application startup time and cooldown or warmup behavior matter: adding a server is useful only after the new instance is actually ready to serve work.
Availability and load balancing
An Auto Scaling group can span multiple Availability Zones. If capacity becomes unavailable or an instance becomes unhealthy, the group can replace capacity and, depending on configuration, launch in another enabled zone. Multi-AZ placement turns the group into both an elasticity mechanism and part of the availability strategy, although the rest of the application and its dependencies must also tolerate zonal failure.
Auto Scaling is frequently paired with Elastic Load Balancing. The load balancer distributes traffic only to registered healthy targets, while Auto Scaling changes the target fleet and replaces unhealthy instances. Neither service substitutes for the other: the load balancer does not decide how many EC2 instances the application should run, and the Auto Scaling group is not the client-facing traffic router.
Key takeaways
- 01
Auto Scaling groups maintain a desired amount of healthy EC2 capacity between configured minimum and maximum bounds.
- 02
Dynamic, scheduled and predictive scaling solve different demand patterns.
- 03
Launch templates make replacement capacity repeatable; applications should tolerate instance replacement.
- 04
Elastic Load Balancing distributes traffic while Auto Scaling manages the target fleet.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.