Warm Pools for AWS Auto Scaling Groups

So Auto Scaling Group is Amazon’s solution for easy to scale applications using EC2 instances. We know that sometimes applications need to have more capacity or to increase the capacity according to the needs of the application. And it has benefits like having full tolerance for an application because the Auto Scaling Groups can determine if an EC2 instance is unhealthy and can replace it if there is a need for. Also, we improve the availability of the application and this ensures that your application has the right amount of capacity, right. If there is a need to have like or to provide capacity in order for the application to support demand of requests. We can increase this using the Auto Scaling Group. So there are also benefits and cost savings because we know that for Auto Scaling Groups, we can increase capacity and decrease the capacity for Auto Scaling Groups. And this can be done using scaling policies on the basis of CPU or request or if we have the CloudWatch agent installed, we can have a memory as well. That’s basically how Auto Scaling Group works, right.

So we know this is like a basic architecture of an application using Auto Scaling Group, we may have servers, web servers and application servers. And we will have a base capacity, where we know that our application will be good at serving the users correctly. But in case we need to increase this capacity, Auto Scaling Groups can take care of adding more servers or adding more capacity into our application right in order to increase the user experience so the users have a better user experience for that. So this is basically how the Auto Scaling Group works and we can have Auto Scaling Group behind a load balancer right.

With this, we also know that Auto Scaling Group has life cycles, right? We know that whenever an EC2 instance has been launched, this EC2 instance goes into pending state and we can have lifecycle hooks between a pending state and in service. This means that we can do some custom actions in this part of the life cycle. And we can go into service as well. And after being the instancing service, we can either detach it from the discussion group or terminate the instance from the Auto Scaling Group whenever we scale in or scale out. So this is basically the lifecycle hook – the life cycles of the Auto Scaling group back. And we can have lifecycle hooks in two phases of this life cycle, which is when the instance has been launched, and also when the instance is being terminated. So this is basically how the Auto Scaling Groups works.

But with the Auto Scaling Groups, we also have some kind of downsides sometimes, it depends on the application. But some of the downsides that I had the experience of taking a look into is that sometimes the resources are too slow when they’re being launched. Sometimes application startup is really slow. So, this can be a really bad problem in case we need to scale up quickly. Also, there is latency of your applications that have long term boot times. For example, I had experience of servers that run like tomcat and these Tomcat servers it takes like a lot of time in order to be ready, in order to be part of the Auto Scaling Groups and start serving traffic right. And for trying to solve these issues, we sometimes over provision capacity in Auto Scaling Groups in order to have capacity that we can handle in case of an increasing request or maybe CPU or memory inside of an Auto Scaling Group. Right So, these are some of the cons of the Auto Scaling Group.

But but here is where warm pools come in. And so warm pools, what are they? Well, this is a feature that has been launched from AWS since April of 2021. So, it helps the application scale faster and basically a warm up pool is a group of pre-initialized EC2 instances that sits alongside the Auto Scaling Group. And this means that we have already configured instances that can be either stopped or running that are already part of our Auto Scaling Group and the Auto Scaling group can use those instances to provision capacity when there is a need for it. These warm up pools can help to have instances ready to serve traffic and can help to accelerate the response in the case of a scale out event. Also, this is a good solution for applications that takes several minutes to be ready to serve traffic. The instance can be pre initialized and then stopped in order to be ready when the capacity is needed. And also like I already said the instances can be either be in a stop state or a running state.

Also we know that in Auto Scaling Groups, we have a life cycle. For warm pools, we have another part of the lifecycle of the instance. And this is the the lifecycle. In this case, if you can see the diagram here, we have some extra steps that an instance goes when it is ready to go into the warm up pool. The instance goes into a warm pending state and then if we have a lifecycle hook, which I am going to explain later, we can attach a lifecycle hook into the Auto Scaling Group and do some custom configurations in this state of the instance when it is been started. And after the lifecycle hooks finishes, or custom configuration finishes, we can have the instance being part of the warm up pool or in a running state or in a stop state. After that, these instance can be part of the Auto Scaling Group to serve traffic when we need it right. In this case, if you see here we have the steps or the phases of the lifecycle that normally an instance in Auto Scaling Groups goes through. An important thing that we need to take a look into is that if we attach a lifecycle hook, when an instance is being launched, the place the hook will be running when the instance is being warmed up for the pool. And also when the instance is being added into the Auto Scaling Group, when it is from a stopped state into a running state. So this is something that we need to take into consideration when using a lifecycle hook in this case.

Okay, so let’s go into a quick demo in the AWS console to see how this works. So here I have a simple Auto Scaling Group, which only has one instance here. I only have one instance running and my current capacity is one and I want a minimum of one. And if I take a look into here, in instance management, I can see that I have a warm up pool with zero instances here. And you can see that I don’t have any instances yet. So I will be adding this configuration. And also I will be adding lifecycle hooks here just for you guys to see how this works. Okay, first of all, I will just create a simple lifecycle hook, which I’m going to call it demo and I will use the lifecycle hook whenever the instance is being launched. I will just wait 30 seconds, which is the minimum in this case, just to mark an application being ready, whenever the instance is being launched. And my default result instead of abandon if I do abandon the instance will be terminated. So I will continue. So the instance will be ready after 30 seconds. The lifecycle hooks as you guys know, we can manage them using the AWS CLI in order to sync the lifecycle hook that the application or the instance is ready to be part of the Auto Scaling Group. So in this case, I will just be waiting 30 seconds and the instance will be ready just to simulate that the application is getting ready into an instance So we’ll create the lifecycle hook and I have it here. And I will just provision some instances here for my warm up pool. This case, I will just do a quick TerraForm here. I will just say that I want a minimum of one, which is the same minimum that I have for my Auto Scaling Group, and I will do a maximum of seven, which is the max size I have in my Auto Scaling Group. And I will just do this and apply these changes to my Auto Scaling Group. So, the idea here is that I’m going to start adding instances into my warm up pool. And I will see that in this case, I will have six instances here. Because what I saw from how this warm up pool works is that the instances in the warm up pool will always be the difference between the minimum capacity that I have and the maximum capacity that I have in my Auto Scaling Group configure. So let’s wait for a little bit. So here, you see some instances are being launched. In this case, I will keep my instances running, I could be changing these two to stop, but I will keep them running. And if you see here, I haven’t touched lifecycle hooks. So we will take a look at that whenever the instance has been launched, the lifecycle hook will be the instance will be waiting for the signal from the lifecycle hook in order to go into a running state in the warm up pool. So you see here, some of the instances are already waiting to be configured or to be ready. In this case, I’m just mocking the server configuration with the lifecycle hook. And whenever these instances are ready, they will be in a running state. Warm with running state, which I can start using them into and adding capacity into my Auto Scaling Group. So let’s wait for a little bit. Okay, in the meantime, I will just show how we see the configuration in the AWS web console. So here, you can see this is the configuration for adding a warm up pool. It’s important to notice that we can only have one warm up pool per Auto Scaling Group. So in this case, I keep my instances running so we can have it in a stop state. And I can set up the minimum number of instances that I have in my warm up and also what is the max capacity that I want to give into my warm up pool. I can either choose to always equal the Auto Scaling Group max capacity in this case. Because I used TerraForm, I had seven, add it into the maximum. Okay. So if you see here, some of the instances went from waiting into running here proceeding in state, some of them are being ready. And soon all of them will be running. So we see that we have six instances already warmed up and running. And we can have them ready to be part of an Auto Scaling Group. So let’s do that. Okay. So in this case, I will just be adding two more instances into my Auto Scaling Group. And in this case, instead of the Auto Scaling Group going to launch like a new instance from scratch, I already have servers running. The Auto Scaling Group will go to the pool and use two of the instances. In this case, one of the instances that I already have running in order to increase the capacity for my Auto Scaling Group. Let’s wait for a little bit.

As you can see, here, we have one less instance from the warm up pool. And we have one instance which has been added into the Auto Scaling Group just to be already ready to serve traffic into my Auto Scaling Group. So, in this case, if I want to add more, I will be adding more instances here, more minimum capacity here. And in this case, you also see the lifecycle hooks run whenever an instance is being added into the Auto Scaling Group, just to mock that the instance can be ready. And we see that the instance is already serving traffic for our Auto Scaling Group. So in this case, if I want to add more or increase the capacity in the Auto Scaling Group, what we’ll do is just grab the instances from the warm up pool and add them into the Auto Scaling Group. So this is how warm up pools work.

And in this case, there are some things to consider. The first of all, is the pricing. Warm up pools have no additional costs from the resources point of view. We only have a cost for the resources that we are using. In this case, if we have a warm up pool in a stop state, we are paying for the EBS volumes and any elastic IPs that we have not assigned to an instance. And also if we are running the instances, we have a warm up pool running. In running state, we paid for the instances running, which is something that is kind of a downside in this case, but this is how AWS works. But this is a good solution to have an instance already configured whenever we want to increase capacity for our Auto Scaling Groups.

Some of the limitations for these warm up pools is that we cannot use warm up pools whenever we have an Auto Scaling Groups with mixed instance policies or when we are using the Spot Instances and also we cannot use warm up pools whenever we are using instance store as a root volume for the instance. We only can use it when we are using EBS volumes. And if we want to use warm up pools with ECS or EKS, there could be a chance that some of the jobs can be scheduled in the instance before reaching the warm up pools. So this could be like a test use case to see how the warm up pools will work with ECS or EKS. So yeah, that’s basically it from my side. Thank you for listening and paying attention. Thank you guys.