- The EC2 instances in an Auto Scaling group have a lifecycle that differs from that of other EC2 instances.
- The lifecycle starts when the Auto Scaling group launches an instance and put it into service.
- The lifecycle ends when the instance is terminated either by the user, or the Auto Scaling group takes the instance out of service and terminates it.
- You are changed for the instances as soon as they are launched, including the time it is not in Service.
Scale out event flow
- Instances start in the Pending state
- If an autoscaling: EC2_INSTANCE_LAUNCHING lifecycle hook is added, the state is moved to Pending:Wait
- After the lifecycle action is completed, instances enter to Pending:Proceed
- When the instances are fully configured, they are attached to the Auto Scaling group and moved to the InService state
Scale in event flow
- Instances are detached from the Auto Scaling group and enter the Terminating state.
- If an autoscaling: EC2_INSTANCE_TERMINATING lifecycle hook is added, the state is moved to Terminating:Wait
- After the lifecycle action is completed, the instances enter the Terminating:Proceed state.
- When the instances are fully terminated, they enter the Terminated state.
- Custom actions can be added via the lifecycle hook to Auto Scaling group when instances launch or terminate by 'pausing' instances, when the instance is paused, it remains in a wait state either until you complete the lifecycle action using the 'complete-lifecycle-action' command or the 'CompletedLifecycleAction' operation or until the timeout period ends.(one hour by default)
- Each Auto Scaling group can have multiple lifecycle hooks, however, there is a limit on the number of hooks per Auto Scaling group.
- Instances can remain in a wait state for a finite period of time. The default is one hour (3600 seconds). You can adjust this time in the following ways:
- Set the heartbeat timeout for the lifecycle hook when you create the lifecycle hook. With the put-lifecycle-hook command, use the --heartbeat-timeout parameter. With the PutLifecycleHook operation, use the HeartbeatTimeout parameter.
- complete-lifecycle-action command or the CompleteLifecycleAction operation, continue to the next state before the timeout period ends.
- Postpone the end of the timeout period by recording a heartbeat, using the record-lifecycle-action-heartbeat command or the RecordLifecycleActionHeartbeat operation. This extends the timeout period by the timeout value specified when you created the lifecycle hook. For example, if the timeout value is one hour, and you call this command after 30 minutes, the instance remains in a wait state for an additional hour, or a total of 90 minutes.
- The maximum amount of time that you can keep an instance in a wait state is 48 hours or 100 times the heartbeat timeout, whichever is smaller.
Lifecycle event flow
After you add lifecycle hooks to your Auto Scaling group, they work as follows:
- The Auto Scaling group responds to scale-out events by launching instances and scale-in events by terminating instances.
- The lifecycle hook puts the instance into a wait state (Pending:Wait or Terminating:Wait). The instance is paused until you continue or the timeout period ends.
- You can perform a custom action using one or more of the following options:
- CloudWatch Events target to invoke a Lambda function when a lifecycle action occurs. The Lambda function is invoked when Amazon EC2 Auto Scaling submits an event for a lifecycle action to CloudWatch Events. The event contains information about the instance that is launching or terminating, and a token that you can use to control the lifecycle action.
- Notification target(CloudWatch events, SNS, SQS) for the lifecycle hook. Amazon EC2 Auto Scaling sends a message to the notification target. The message contains information about the instance that is launching or terminating, and a token that you can use to control the lifecycle action.
- Create a script that runs on the instance as the instance starts. The script can control the lifecycle action using the ID of the instance on which it runs.
Cooldowns and Custom Actions
- Cooldown period helps ensure that the Auto Scaling group does not launch or terminate more instances than needed
- Cooldown period starts when the instance enters the InService state. Any suspended scaling actions resume after cooldown period expires
- the default cooldown period is not provided, its default value is 300 seconds, you can create cooldowns that apply to a specific simple scaling policy and manual scaling. A scaling-specific cooldown period overrides the default cooldown period.
Cooldowns and Lifecycle Hooks
Lifecycle hooks can affect the impact of any cooldown periods configured for the Auto Scaling group. The cooldown period does not begin until after the instance moves out of the wait state (after the lifecycle hook execution is complete).
Consider an Auto Scaling group that has a lifecycle hook that supports a custom action at instance launch. When the application experiences an increase in demand due to a simple scaling policy, the group launches an instance to add capacity. Because there is a lifecycle hook, the instance is put into the Pending:Wait state, which means that it is not available to handle traffic yet. When the instance enters the wait state, scaling activities due to simple scaling policies are paused. When the instance enters the InService state, the cooldown period starts. When the cooldown period expires, any scaling activities that are triggered after the cooldown period can resume.
Auto Scaling scale-out event flow.
Lifecycle Action Result
- Result of lifecycle hook is either ABANDON or CONTINUE
- If the instance is launching,
- CONTINUE indicates a successful action, and the instance can be put into service.
- ABANDON indicates the custom actions were unsuccessful, and that the instance can be terminated.
- If the instance is terminating,
- ABANDON and CONTINUE allow the instance to terminate.
- However, ABANDON stops any remaining actions from other lifecycle hooks, while CONTINUE allows them to complete
- Spot Instances
Lifecycle hooks can be used with Spot Instances. However, a lifecycle hook does not prevent an instance from terminating due to a change in the Spot Price, which can happen at any time
- Your application is running on EC2 in an Auto Scaling group. Bootstrapping is taking 20 minutes to complete. You find out that instances are shown as InService although the bootstrapping has not completed. How can you make sure that new instances are not added until the bootstrapping has finished. Choose the correct answer:
- Create a CloudWatch alarm with an SNS topic to send alarms to your DevOps engineer.
- Create a lifecycle hook to keep the instance in pending:wait state until the bootstrapping has finished and then put the instance in pending:proceed state.
- Increase the number of instances in your Auto Scaling group.
- Create a lifecycle hook to keep the instance in standby state until the bootstrapping has finished and then put the instance in pending:proceed state.
- When a scale out event occurs, the Auto Scaling group launches the required number of EC2 instances using its assigned launch configuration. What instance state do these instances start in? Choose the correct answer:
- With AWS Auto Scaling, once we apply a hook and the action is complete or the default wait state timeout runs out, the state changes to what, depending on which hook we have applied and what the instance is doing? Select two. Choose the 2 correct answers:
- For AWS Auto Scaling, what is the first transition state an existing instance enters after leaving steady state in Standby mode?
- Pending (You can put any instance that is in an InService state into a Standby state. This enables you to remove the instance from service, troubleshoot or make changes to it, and then put it back into service. Instances in a Standby state continue to be managed by the Auto Scaling group. However, they are not an active part of your application until you put them back into service.)
- For AWS Auto Scaling, what is the first transition state an instance enters after leaving steady state when scaling in due to health check failure or decreased load?
- Terminating (When Auto Scaling responds to a scale in event, it terminates one or more instances. These instances are detached from the Auto Scaling group and enter the Terminating state. Refer link)