Auto Scaling groups are a tool to manage supply and demand of infrastructure. In this case, EC2 instances that your application can leverage to match the expectation of your users. When more compute units are required based on a certain metrics such as; CPU usage, number of web visitors, or total number of orders in queue, you can make an informed decision of whether to scale your Auto Scaling group, in or out. Scale in, means that you eliminate on use instances, and scale out means that you will add additional instances to keep up with demand. When an instance is launched during a scale out event, it will start with a state of pending. This allows times around any bootstrapping scripts that you may have specified in your user data section of the launch template.

Once this is complete, the instance will immediately go into in service state. On the other hand, when an instance is terminated by a scale in event or because it has failed to respond to health checks, it will be moved to a state called terminating until it's actually terminated. There are two problems here; Number one, when launching an instance, say for example, you're running a JBoss Java Application Server. Just because your user data script completed a service start command, it does not mean your application is ready to receive requests. You may need additional time to initialize custom resources, process configuration files, connect to back-end databases, and more. All this can take many seconds, sometimes minutes to complete. During this time, your Auto Scaling group already switched your instance to in service status, and because of this it may already be getting pings from health checks coming from a load balancer for example.

These checks will likely fail because your application is still loading. We need a way to delay telling our Auto Scaling group that our instance has just launched and it's not ready yet and it will need additional time to prepare to receive requests. Problem number two would be that, one of your instances has been targeted for termination during scale in event. However, your instance is still in the middle of processing a request, and in addition it has valuable logs that can be used for troubleshooting potential problems and improve performance in the future. Both the in progress requests and the logs will be lost if the instance is suddenly terminated. We need a way to hold the termination process long enough for us to gracefully shut down our service and move our logs to a permanent storage such as Amazon S3, and only then allow the instance to be terminated. Lifecycle hooks can help solve both of these problems.

An instance launching lifecycle hook prevents the instance from becoming in service, and instead puts it in a pending-wait state. During this event, you can ensure that the application loads and gets to a proper stable state. Once the lifecycle hook ends, the instance will go into pending-proceed state, and then the Auto Scaling group will take over once again and attempt to move it to in service. In a similar fashion, an instance terminating lifecycle hook will put your instance in a terminating:wait state. During which you can do your final cleanup tasks as needed. Such as preserving copies of logs by moving them to S3 for example. And once you're done, or a preset timer expires, the instance will switch to terminating:proceed state, and then the Auto Scaling group will take over and proceed to terminate the instance.