{"id":965,"date":"2019-10-04T16:36:33","date_gmt":"2019-10-04T14:36:33","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=965"},"modified":"2021-03-24T17:53:31","modified_gmt":"2021-03-24T16:53:31","slug":"autoscaling-like-a-pro-how-to-use-ec2-auto-scaling-lifecycle-hooks-the-right-way","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/autoscaling-like-a-pro-how-to-use-ec2-auto-scaling-lifecycle-hooks-the-right-way\/","title":{"rendered":"Autoscaling like a pro: how to use EC2 Auto Scaling Lifecycle Hooks, the right way."},"content":{"rendered":"
Have you ever found it useful to access an EC2 instance, belonging to an Auto Scaling Group,<\/strong> to configure it or to simply get an idea of what went wrong before an unexpected termination?<\/span><\/p>\n Well, in those cases EC2 Auto Scaling Lifecycle Hooks come in handy. In this article, we will give you a deep understanding of how Lifecycle Hooks work and what are their common use cases.<\/strong><\/span><\/p>\n Just for clarity let\u2019s review EC2 Auto Scaling’s main characteristics and features, before going in detail with EC2 Auto Scaling Lifecycle Hooks. EC2 Auto Scaling<\/strong> is an AWS service that allows you to adapt the number of EC2 instances, serving your application, to meet the incoming load.<\/strong> These instances are logically grouped into Auto Scaling groups<\/strong> for which you can set the minimum, maximum and desired capacity.<\/strong> If there are no scaling policies attached to the Auto Scaling group, by default it maintains the desired amount of healthy instances, performing periodic health checks. Unhealthy instances will be terminated and replaced with new ones.<\/span><\/p>\n Besides manual scaling, in which you actively change minimum, maximum or desired capacity, there are two automatic scaling<\/strong> types: Scheduled Scaling and Dynamic Scaling.<\/strong><\/span><\/p>\n Scheduled Scaling<\/strong> should be used if you know in advance how your application\u2019s traffic patterns<\/strong> behave. In this case, you have to create a rule, called scheduled action, that instructs Auto Scaling to increase and decrease the Auto Scaling group\u2019s capacity based on predicted load changes.<\/strong><\/span><\/p>\n Instead, when you need to scale in response to load changes that are not predictable<\/strong> Dynamic Scaling comes to the rescue.<\/strong> It provides different policy types that you can use to instruct Auto Scaling how to react to demand changes. There are three types of Dynamic Scaling policies:<\/span><\/p>\n Pending, Detaching, EnteringStandby and Terminating can be considered transitional states<\/strong> that anticipate, respectively, InService, Detached, StandBy and Terminated states.<\/strong><\/span><\/p>\n Pending and Terminating transitional states can be paused<\/strong> through EC2 Auto Scaling Lifecycle Hooks, to perform custom logics during instances\u2019 launch or termination.<\/span><\/p>\n Pending state\u2019s Lifecycle Hook is called EC2_INSTANCE_LAUNCHING<\/strong> and it handles Pending:Wait<\/strong> and Pending:Proceed<\/strong> additional states.<\/span><\/p>\n In the same way, Terminating the state\u2019s Lifecycle Hook is called EC2_INSTANCE_TERMINATING<\/strong> and it handles Terminating:Wait<\/strong> and Terminating:Proceed<\/strong> additional states.<\/span><\/p>\n In both cases, EC2 instances remain in a Wait state until the timeout period<\/strong> ends. There is also the possibility to conclude the Lifecycle Hook and continue to the next state before the timeout period expires.<\/span><\/p>\n Lifecycle Hook\u2019s result can be either CONTINUE or ABANDON.<\/strong> EC2_INSTANCE_LAUNCHING\u2019s result determines whether the instance should be terminated or put into InService state. On the other hand, EC2_INSTANCE_TERMINATING\u2019s result does not affect EC2 instance\u2019s lifecycle; it always ends up in the Terminated state.<\/span><\/p>\n You may be wondering why you should hook Pending and Terminating states<\/strong>! Well, it obviously depends on your application scenario.<\/span><\/p>\n\n
\nWhen a new instance is launched in response to a scale-out event,<\/strong> it first enters the Pending state.<\/strong> This state is designed to allow you to configure (preferably automatically) the EC2 instance and to check its healthiness before moving into the InService state.While into the InService state, the EC2 instance can potentially move to one of the following three states:<\/strong><\/span><\/p>\n\n