Topic 2.3
Launch Templates & Auto Scaling Groups
In one line
A launch template describes how to build one instance; an Auto Scaling group keeps the right number of those instances running across AZs, replaces unhealthy ones, and adds or removes capacity as load changes.
Think of it like this
A restaurant manager with a staffing rule. The LAUNCH TEMPLATE is the job description (skills, uniform, station). The AUTO SCALING GROUP is the manager who keeps at least 4 cooks on shift, calls in more when orders pile up, sends people home when it's quiet, and immediately replaces anyone who calls in sick.
Key ideas
- 01
A LAUNCH TEMPLATE captures everything from Topic 2.1 — AMI, instance type, instance profile, security groups, user data, IMDSv2 — as a versioned object. Every change creates a new version; you point the ASG at
$Latestor a specific version. - 02
An AUTO SCALING GROUP (ASG) has MIN, MAX, and DESIRED capacity and a list of subnets across multiple AZs. It keeps
desiredinstances running, spreading them evenly across AZs, and relaunches in a healthy AZ if one fails. - 03
HEALTH CHECKS: by default the ASG only checks EC2 status (is the VM running?). Enable ELB health checks so an instance whose app is broken — VM up, process crashed — is also replaced. This single setting is the difference between 'self-healing' and 'self-healing unless the app dies'.
- 04
SCALING POLICIES: TARGET TRACKING is the default choice ('keep average CPU at 50%', or 'keep ALB requests per target at 1000') — AWS computes the adjustments. STEP scaling reacts to alarm thresholds with explicit step sizes; SCHEDULED scaling handles known patterns (scale up at 9am). Predictive scaling forecasts from history.
- 05
Deploying a new version: update the launch template, then run an INSTANCE REFRESH, which replaces instances in batches while keeping a minimum healthy percentage. Treat instances as cattle: nothing important lives only on one instance, since the ASG will terminate it without asking.
Code & diagrams
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name api \
--launch-template LaunchTemplateName=api,Version='$Latest' \
--min-size 2 --max-size 10 --desired-capacity 2 \
--vpc-zone-identifier "subnet-a,subnet-b,subnet-c" \
--target-group-arns arn:aws:elasticloadbalancing:ap-south-1:123456789012:targetgroup/api/abc \
--health-check-type ELB --health-check-grace-period 90
# Target tracking: keep average CPU around 50%
aws autoscaling put-scaling-policy \
--auto-scaling-group-name api --policy-name cpu50 \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
"TargetValue": 50
}'
# Roll out a new launch template version, 90% of capacity stays healthy
aws autoscaling start-instance-refresh --auto-scaling-group-name api \
--preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 90}'Explain it without notes
An ASG uses only EC2 health checks. The app process on one instance crashes but the VM stays up. What happens, and how do you fix it?
Why does target tracking usually beat hand-tuned step scaling for a web API?
Practice
Your ASG has min=2, max=10, desired=2 across 3 AZs. How are instances placed, and what happens if AZ b has an outage?
Why might scaling on CPU be the wrong metric for a service that mostly waits on a database?
Trade-offs
- ↔
Aggressive scale-in saves money but risks thrashing (removing capacity just before the next spike) and cuts in-flight work; conservative cooldowns and warmups cost a bit more but keep latency stable.
Done when you can
I can build an ASG from a launch template across multiple AZs.
I always enable ELB health checks on ASGs behind a load balancer.
I can configure a target-tracking policy and pick a metric that matches the workload.
I deploy new versions with an instance refresh, not by editing live instances.