Patching EC2 Instances in Auto Scaling Groups

Quick Answer

This question tests the same core idea as many Auto Scaling patching scenarios: downtime is avoided by never taking capacity away before replacement capacity is ready, rather than by patching instances where they stand. Building a new AMI that already has the latest OS patches applied, updating the launch configuration to reference it, and then performing a rolling update of the Auto Scaling group means new, already-patched instances are launched and confirmed healthy before the old, unpatched instances are deregistered and terminated, so the group's total serving capacity never drops during the process. This is meaningfully different from applying patches directly to running instances with a tool like Systems Manager Patch Manager, which typically requires rebooting each instance in place, causing a period of unavailability for every instance patched that way. It's also different from stopping the entire Auto Scaling group, which removes all capacity at once and causes a full outage, or from patching every instance simultaneously during a single maintenance window, which would trigger simultaneous reboots across the fleet and again drop capacity to zero at the same moment. The distinguishing idea to hold onto is that rolling replacement, swapping instances one or a few at a time using a pre-built, already-patched image, is what actually prevents downtime, whereas in-place patching of running instances, even when automated, still generally requires a reboot that interrupts service on that instance. Expect this AMI-plus-rolling-update pattern whenever a question asks for zero-downtime OS patching inside an Auto Scaling group.