What an Auto Scaling Group Does
An Auto Scaling Group (ASG) maintains a fleet of EC2 instances within a defined minimum, maximum, and desired capacity, automatically launching new instances when demand rises and terminating instances when demand falls or when instances fail health checks. Every ASG references a Launch Template (the modern replacement for the older Launch Configuration) that specifies the AMI, instance type, key pair, security groups, and user-data script used to configure each new instance identically, and the ASG spreads instances across multiple Availability Zones within one or more subnets to survive the loss of an entire data center.
Cricket analogy: An Auto Scaling Group is like a franchise's squad management policy that keeps a minimum of 15 fit players, calls up reserves from the domestic circuit when injuries strike during a series, and releases players once the tournament roster cap is reached again.
Scaling Policies: Target Tracking, Step, and Scheduled
Target tracking scaling policies are the simplest and most common approach: you pick a metric such as average CPU utilization and a target value, like 50%, and the ASG automatically calculates how many instances to add or remove to keep that metric near the target, similar to how a thermostat maintains a room temperature. Step scaling policies give finer control by defining specific scaling adjustments tied to CloudWatch alarm breach magnitudes — for example, add 2 instances if CPU exceeds 70% but add 4 instances if it exceeds 90% — while scheduled scaling proactively sets capacity ahead of known, predictable demand patterns like a retailer's Black Friday traffic surge that doesn't need to wait for a reactive metric to trigger.
Cricket analogy: Target tracking scaling is like a captain automatically rotating bowlers to keep the economy rate near a target of 6 runs per over, continuously adjusting the attack without needing a specific triggered instruction each time.
# Create a launch template
aws ec2 create-launch-template \
--launch-template-name web-app-template \
--version-description v1 \
--launch-template-data '{"ImageId":"ami-0c101f26f147fa7fd","InstanceType":"t3.medium","SecurityGroupIds":["sg-0123456789abcdef0"]}'
# Create an Auto Scaling group across two subnets
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name web-app-asg \
--launch-template LaunchTemplateName=web-app-template,Version='$Latest' \
--min-size 2 --max-size 10 --desired-capacity 2 \
--vpc-zone-identifier "subnet-aaa111,subnet-bbb222" \
--target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-tg/abc123
# Attach a target tracking policy for 50% average CPU utilization
aws autoscaling put-scaling-policy \
--auto-scaling-group-name web-app-asg \
--policy-name cpu-target-tracking \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":50.0}'Health Checks and Instance Replacement
An ASG continuously monitors instance health using either EC2 status checks (detecting hardware or hypervisor failures) or, when integrated with an Elastic Load Balancer, ELB health checks that probe the application itself via HTTP requests to confirm it's actually serving traffic correctly, not just that the OS is running. When an instance is marked unhealthy, the ASG automatically terminates it and launches a replacement to restore the desired capacity, and a configurable health check grace period gives newly launched instances time to boot, install dependencies, and start serving traffic before health checks begin evaluating them, preventing a slow-starting instance from being prematurely killed in a replacement loop.
Cricket analogy: ELB-integrated health checks are like a fitness test that goes beyond checking a player can physically stand, actually testing whether they can bowl a full over at match pace, before clearing them to take the field rather than just confirming they showed up.
When an ASG is attached to an Application Load Balancer's target group, it can use the ALB's own health check results (HTTP path, expected status code) as the source of truth for instance health, in addition to or instead of basic EC2 status checks — giving much more accurate signal about whether the application layer, not just the OS, is functioning.
Setting the health check grace period too short for a slow-starting application (one that needs time to warm caches or connect to a database) can trigger a scaling loop where instances are repeatedly killed before they finish booting and never actually serve traffic — always size the grace period to comfortably exceed your application's real startup time.
- An Auto Scaling Group maintains desired capacity between a minimum and maximum, spreading instances across multiple Availability Zones.
- Launch Templates define the AMI, instance type, and configuration used for every new instance the ASG launches.
- Target tracking policies continuously adjust capacity to hold a metric like CPU utilization near a target value.
- Step scaling applies proportionally larger capacity changes for larger alarm breaches; scheduled scaling proactively sets capacity ahead of known demand.
- ELB health checks validate application-level responsiveness, catching failures EC2 status checks alone would miss.
- The health check grace period protects newly launched instances from premature termination during startup.
- Unhealthy instances are automatically terminated and replaced to keep the group at its desired capacity.
Practice what you learned
1. What does a target tracking scaling policy do?
2. What is the purpose of the health check grace period on an Auto Scaling Group?
3. What does a Launch Template specify for an Auto Scaling Group?
4. Why might an ASG use ELB health checks instead of relying solely on EC2 status checks?
Was this page helpful?
You May Also Like
EC2 Fundamentals
Learn what Amazon EC2 is, how virtual server instances work in the cloud, and how to launch, connect to, and manage them safely.
EC2 Instance Types and Pricing
Understand EC2 instance family naming, how to pick the right instance size for a workload, and the trade-offs between On-Demand, Reserved, and Spot pricing.
Elastic Load Balancing
Learn how AWS Elastic Load Balancing distributes traffic across healthy targets, and the differences between Application, Network, and Gateway Load Balancers.