Every SAA-C03 candidate learns why an Auto Scaling group matters — it maintains capacity, replaces unhealthy instances, and scales with demand, the resilience story told in the designing resilient architectures guide. This article is about the layer underneath that story: how you actually configure and operate an Auto Scaling group (ASG), and the operational details the exam quietly tests once it’s satisfied you know what an ASG is for.
We’ll deliberately not re-derive the scaling policy types (target tracking, step, simple, scheduled, predictive) — the resilient architectures guide owns that table and it’s recapped in one row below. Instead we’ll go deep on the mechanics that decide what gets launched, when an instance is considered healthy, which instance dies on scale-in, how you blend On-Demand and Spot, and how you roll a change across a running fleet without downtime. These are the details that separate a plausible-looking wrong answer from the right one.
The Anatomy of an Auto Scaling Group
An ASG is defined by a handful of settings you should be able to recite:
- Minimum, desired, and maximum capacity — the ASG works to keep the number of running instances at desired, never dropping below minimum or rising above maximum.
- A launch template (or legacy launch configuration) — the blueprint for what to launch.
- One or more subnets across Availability Zones — the ASG spreads instances across AZs and rebalances them to stay evenly distributed, which is how it survives an AZ impairment.
- Optional load balancer / target group attachment — so new instances are automatically registered to receive traffic and drained on termination.
- Health checks, termination policies, and scaling policies — the operational behavior we unpack below.
The min/desired/max model is what makes an ASG self-healing: if an instance is terminated or fails a health check, the group falls below desired and launches a replacement automatically, no human in the loop.
Launch Templates vs Launch Configurations
Before an ASG can launch anything, it needs a blueprint describing the instance: AMI, instance type, key pair, security groups, IAM instance profile, user data, block device mappings, and so on. There are two ways to provide it, and the exam wants you to know which one to reach for.
| Launch template (use this) | Launch configuration (legacy) | |
|---|---|---|
| Status | Current, recommended by AWS | No longer receiving new features; being phased out |
| Versioning | Versioned — create v1, v2, v3; set a default and a “latest” | Immutable — can’t be edited, must be recreated |
| Newer capabilities | T2/T3 unlimited, mixed instance types, multiple network interfaces, placement groups, newest instance families | Not supported |
| Mixed instances / multiple purchase options | Supported | Not supported |
| Partial specification | Can define a subset and override the rest at launch | All-or-nothing |
The takeaways for the exam: launch templates are the modern default, they are versioned (so you can stage a change and roll it out — see instance refresh below), and several features — most importantly mixed instance types and combining On-Demand with Spot — are only available with launch templates. If a question describes needing multiple instance types or a Spot/On-Demand blend, the correct foundation is a launch template, never a launch configuration.
Health Checks: What “Healthy” Means to an ASG
An ASG only replaces an instance when it decides the instance is unhealthy. How it decides is a classic exam trap, because there are three distinct health-check sources:
- EC2 status checks (default) — the ASG watches the instance’s system and instance status checks. This catches a stopped, terminated, or hardware-impaired instance, but it does not catch an instance that is running yet failing to serve the application.
- Elastic Load Balancing health checks — when you enable ELB health checks, the ASG also treats an instance that fails its target group / load balancer health check as unhealthy and replaces it. This is what catches the “instance is up but the app returned 500s / the process crashed” case.
- Custom health checks — your own logic can call
SetInstanceHealthto mark an instance unhealthy.
Exam cue: “instances are running but not serving traffic, and the ASG isn’t replacing them” → the ASG is using only EC2 status checks; enable ELB health checks so application-level failures trigger replacement. This is one of the most frequently tested ASG details.
The Health Check Grace Period
New instances need time to boot, run user data, start the application, and register with the load balancer before they can pass a health check. The health check grace period (default 300 seconds) tells the ASG to ignore health checks for that long after an instance launches.
Set it too short and the ASG will kill a perfectly good instance that simply hasn’t finished booting — then launch a replacement, which also gets killed too early, producing a launch-terminate loop. Set it to comfortably cover your application’s real startup time.
Exam cue: “the ASG keeps terminating and relaunching new instances in a loop” → the health check grace period is too short for the application’s startup time. Increase it.
Termination Policies: Which Instance Dies on Scale-In
When an ASG scales in (removes capacity), it has to choose which instance to terminate. The termination policy controls that choice:
| Termination policy | Behavior |
|---|---|
| Default | Balance across AZs first, then terminate the instance with the oldest launch template/configuration; break ties on the instance closest to the next billing hour. |
| OldestInstance / NewestInstance | Terminate the oldest (good for upgrading to new types) or newest (good for keeping a stable baseline) instance. |
| OldestLaunchTemplate / OldestLaunchConfiguration | Terminate instances using the oldest blueprint first — handy while migrating to a new template. |
| ClosestToNextInstanceHour | Terminate whatever is nearest its next billing boundary to squeeze cost. |
| AllocationStrategy | Align the fleet to your chosen Spot/On-Demand allocation strategy after a change. |
The default policy already does the sensible thing: it keeps AZs balanced and prefers to retire instances on the oldest blueprint. You only override it for a specific goal (e.g., OldestInstance to age out an old instance family).
Instance Scale-In Protection
Sometimes an instance must not be terminated automatically on scale-in — for example, one that is mid-way through processing a long batch job. Instance scale-in protection exempts a specific instance (or new instances by default) from termination during scale-in events. The ASG will still count it toward capacity, but it looks elsewhere for something to terminate. (Scale-in protection does not protect against a health-check replacement or a manual termination — only against automatic scale-in.)
Mixed Instances: Blending On-Demand and Spot
A mixed instances policy (launch-template-only) lets a single ASG launch multiple instance types across multiple purchase options — combining On-Demand and Spot in one group. This is a favorite of cost-optimization questions and pairs naturally with the cost-optimized architectures guide.
Two dials control the blend:
- On-Demand base capacity — a fixed number of instances always launched as On-Demand (your reliable floor).
- On-Demand percentage above base — for capacity beyond the base, what fraction is On-Demand vs. Spot. Set the base to your minimum reliable capacity and let Spot absorb the spiky, interruption-tolerant remainder.
For the Spot portion, the allocation strategy decides which Spot pools (instance-type + AZ combinations) to draw from:
| Spot allocation strategy | Optimizes for |
|---|---|
| price-capacity-optimized (recommended default) | The best balance of low price and low interruption risk — AWS’s current recommendation for most workloads. |
| capacity-optimized | The lowest interruption risk — launch from the pools with the most spare capacity. Best when interruptions are costly. |
| lowest-price | The cheapest pools — cheapest per hour but higher interruption risk and pool concentration. |
The exam rewards this reasoning: “minimize Spot interruptions for a stateful-ish workload” → capacity-optimized (or price-capacity-optimized); “cheapest possible, fully interruption-tolerant batch” → leans toward lowest-price. Providing many instance types across many AZs deepens the pool diversity that makes Spot resilient — a mixed instances policy with a single instance type largely defeats the purpose.
Cooldowns vs. Instance Warmup
Two settings prevent an ASG from overreacting to metrics during scaling, and they belong to different scaling mechanisms:
- Cooldown period — used with simple scaling policies. After a scaling activity, the ASG pauses further simple-scaling actions for the cooldown window (default 300s) so a burst of alarms doesn’t stack multiple scale-outs before the first instances start absorbing load.
- Instance warmup — used with target tracking and step scaling (and instance refresh). It tells the ASG how long a newly launched instance needs before it’s contributing and its metrics are trustworthy, so its half-warmed CloudWatch data isn’t counted in aggregate metrics and doesn’t trigger premature scaling.
Modern target-tracking and step policies use instance warmup rather than cooldowns; cooldowns are the older simple-scaling mechanism. If a question mentions “simple scaling” and repeated over-scaling, the lever is the cooldown.
Instance Refresh: Rolling Out a Change to a Running Fleet
Here’s the operational payoff of launch-template versioning. Suppose you bake a new AMI (a patched OS, a new app build) into v2 of the launch template. How do you get every running instance onto v2 without downtime?
Instance refresh performs a rolling replacement of the instances in the ASG:
- You set a minimum healthy percentage — how much of the fleet must stay in service while instances are replaced in batches (e.g., 90% keeps nearly all capacity serving traffic throughout).
- You set an instance warmup so each new instance is given time to become healthy before the next batch starts.
- Checkpoints let you replace a fraction, pause, verify, and then continue — a canary-style rollout of the fleet itself.
- You can trigger a refresh automatically whenever the launch template or a configuration setting changes, and roll back if health checks fail.
Exam cue: “update every instance in the ASG to a new AMI with no downtime” → instance refresh (with a new launch template version and a minimum-healthy-percentage). This is the ASG-native answer, distinct from a blue/green or CodeDeploy deployment.
What This Article Deliberately Leaves to Its Siblings
To keep clean boundaries (and because those topics are owned elsewhere):
- Scaling policy types — target tracking, step, simple, scheduled, and predictive scaling, with their exam cues — are covered in the resilient architectures guide. One-row recap: “keep CPU at ~50%” → target tracking; “scale at 9 a.m. every weekday” → scheduled; “scale ahead of a predictable surge” → predictive.
- Lifecycle hooks and warm pools — pausing instances at launch/terminate to run setup or teardown, and pre-initializing a pool of stopped instances for faster scale-out — are covered from the operations angle in the DevOps resilient cloud solutions guide. Reach for a warm pool when instance boot/warmup time is too slow for your scale-out SLA, and a lifecycle hook when you need to run an action before an instance enters service or before it’s terminated.
Scenario Cues Cheat Sheet
| Scenario cue | Right mechanism |
|---|---|
| ”Running instances aren’t serving traffic and aren’t replaced” | Enable ELB health checks |
| ”ASG keeps terminating brand-new instances in a loop” | Increase the health check grace period |
| ”Need multiple instance types or an On-Demand + Spot blend” | Launch template + mixed instances policy |
| ”Minimize Spot interruptions” | capacity-optimized / price-capacity-optimized allocation |
| ”Guaranteed reliable floor, cheap burst capacity” | On-Demand base + Spot above base |
| ”Don’t terminate this busy instance on scale-in” | Instance scale-in protection |
| ”Retire the old instance family first” | OldestInstance / OldestLaunchTemplate termination policy |
| ”Update every instance to a new AMI, no downtime” | Instance refresh (min healthy %) |
| “Pre-warm instances for faster scale-out” | Warm pool (see DevOps guide) |
Common Mistakes to Avoid
| Mistake | Reality |
|---|---|
| Using a launch configuration for a Spot/On-Demand mix | Mixed instances and multiple purchase options require a launch template. |
| Expecting EC2 status checks to catch a crashed app | EC2 checks catch a dead instance; ELB health checks catch a dead application. |
| Leaving the grace period at 300s for a slow-booting app | Too short → launch-terminate loop; size it to real startup time. |
| Thinking scale-in protection stops all termination | It only blocks automatic scale-in, not health-check replacement or manual termination. |
| Running a single instance type in a Spot-heavy ASG | Diversify instance types and AZs so Spot has deep, resilient pools. |
| Editing instances in place to change the AMI | Bake a new launch template version and roll it with instance refresh. |
| Confusing cooldown with instance warmup | Cooldown = simple scaling; instance warmup = target-tracking/step and instance refresh. |
Frequently Asked Questions
Should I still use launch configurations? No. AWS recommends launch templates for all new work; launch configurations don’t receive new features and can’t do mixed instances or newer instance capabilities. Launch templates are also versioned, which is what makes instance refresh practical.
What’s the difference between EC2 and ELB health checks in an ASG? EC2 status checks detect an instance that is stopped, terminated, or hardware-impaired. ELB health checks additionally detect an instance that is running but failing the application health check (the target group check). Enable ELB health checks when “up but not serving” must trigger replacement.
Why does my ASG keep launching and terminating new instances? Almost always the health check grace period is too short — the ASG marks an instance unhealthy before it finishes booting and starting the app, terminates it, launches a replacement, and repeats. Increase the grace period to cover real startup time.
How do I blend On-Demand and Spot in one Auto Scaling group? Use a launch template with a mixed instances policy. Set an On-Demand base capacity as your reliable floor and an On-Demand percentage above base for the rest, then pick a Spot allocation strategy (price-capacity-optimized or capacity-optimized to minimize interruptions). Offer several instance types across AZs for pool diversity.
How do I roll out a new AMI to every instance without downtime? Create a new launch template version referencing the new AMI, then start an instance refresh with a minimum healthy percentage (e.g., 90%) and an instance warmup. The ASG replaces instances in batches while keeping most of the fleet in service, and can roll back if health checks fail.
Which instance does the ASG terminate when it scales in?
By default it balances AZs first, then retires the instance on the oldest launch template/configuration, breaking ties on whichever is closest to its next billing hour. Override with a termination policy like OldestInstance for a specific goal, and use scale-in protection to exempt instances that must not be interrupted.
Practice These Distinctions Under Exam Conditions
The compute-and-resilience domain is the largest slice of the SAA-C03, and Auto Scaling questions reward precision on exactly the details above: EC2 vs ELB health checks, the grace-period loop, the Spot allocation strategies, and instance refresh. Sailor.sh’s AWS Solutions Architect Associate mock exam bundle — 8 full-length exams with 520+ scenario questions — drills these under timed, exam-realistic conditions, and a good set of practice questions is the fastest way to turn the cues into reflexes.
Pair this with the resilient architectures guide for the scaling-policy types and the overall HA/DR story, the high-performing architectures guide for scaling as a performance lever, the cost-optimized architectures guide for Spot economics, and EC2 placement groups & tenancy for how instances are physically placed. Map your whole prep with the SAA-C03 study plan and the 2026 exam guide.