Instance Refresh and Lifecycle Hooks

When you update a Launch Template (new AMI, new user data, new instance type), existing running instances in the ASG do not automatically get replaced—they keep running the old configuration. To propagate changes you must replace instances. Manually terminating and relaunching instances is risky and error-prone. Instance Refresh automates this process with configurable safety controls.

Instance Refresh replaces ASG instances in rolling batches. At each step it terminates a batch of old instances, waits for the new instances to pass health checks, and then proceeds to the next batch. You control the pace with a MinHealthyPercentage (the minimum percentage of capacity that must remain healthy during the refresh) and an optional InstanceWarmup time.

MinHealthyPercentage defines the floor of healthy capacity during refresh. If you set it to 90%, only 10% of the fleet is replaced at a time—slower but safer. A value of 50% replaces half the fleet at once—faster but with less redundancy. ASG automatically calculates batch sizes based on this percentage and your current desired capacity. Choose a higher percentage for production workloads to maintain availability.

Checkpoints allow you to pause Instance Refresh at predefined percentage milestones. For example, you can refresh 20% of instances, pause for 10 minutes to run smoke tests, and then continue. If you detect a problem at any checkpoint you can cancel the refresh—ASG stops replacing additional instances but leaves already-replaced instances running (they are already on the new template). This is effectively a canary deployment pattern for EC2.

You can cancel an in-progress Instance Refresh at any time; it stops further replacements but does not roll back completed ones. Use describe-instance-refreshes to check status, progress percentage, and any instances that failed to launch. Integrate Instance Refresh with your CI/CD pipeline to automatically trigger a refresh after pushing a new AMI to the Launch Template, completing a fully automated blue/green-style deployment.

Lifecycle Hooks pause ASG instance transitions at key moments so you can run custom logic before an instance becomes active or before it is terminated. There are two hook points: EC2_INSTANCE_LAUNCHING (after launch, before the instance is put InService) and EC2_INSTANCE_TERMINATING (after the termination decision, before the instance is actually terminated). During a hook the instance is in a Pending:Wait or Terminating:Wait state.

The launching hook is ideal for tasks that must complete before an instance serves traffic: installing additional software, pulling configuration from Parameter Store, registering with a service discovery registry, or running integration tests. The ASG will not add the instance to the load balancer target group until the hook completes (or times out). This prevents traffic from reaching an incompletely configured instance.

The termination hook runs before an instance is actually terminated. Use cases include: draining in-flight requests from an application-level queue, flushing cached data to a persistent store, deregistering from a service registry, or copying log files to S3. Without a termination hook, in-flight work on a terminating instance may be lost. The hook gives you up to 2 hours (heartbeat timeout) to complete graceful shutdown tasks.

The custom logic running on (or triggered by) the instance must signal the hook when it is done. Use complete-lifecycle-action with either CONTINUE (proceed normally) or ABANDON (on a launching hook, terminate the instance; on a terminating hook, ignore and proceed). You can also extend the hook's timeout by sending a heartbeat every interval up to the maximum duration. If the hook times out, the DefaultResult is applied.

The cleanest way to respond to lifecycle hooks is via Amazon EventBridge. When a lifecycle hook fires, ASG emits an event to EventBridge. An EventBridge rule routes this event to a Lambda function that performs the required work and then calls complete-lifecycle-action. This architecture is fully serverless, requires no polling, and scales automatically. SQS and SNS notifications are older alternatives but EventBridge is preferred for new designs.

When Instance Refresh replaces an instance, both lifecycle hooks still fire: the termination hook on the old instance and the launching hook on the new one. This means your graceful shutdown and initialisation logic runs automatically during a rolling update, not just during normal scale events. Always test your lifecycle hook logic during a staged Instance Refresh before a production rollout to verify correct behaviour.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Instance Refresh replaces ASG instances in rolling batches controlled by MinHealthyPercentage and optional checkpoints for canary-style validation, Lifecycle Hooks pause instance transitions at launch or termination to run custom initialisation or graceful shutdown logic, and EventBridge + Lambda is the recommended pattern for responding to lifecycle hook events without polling. Next up we explore AWS Lambda functions, runtimes, triggers, and handlers.