AWS Auto scaling group (ASG) comes into the picture when we want to have a declarative control and fault tolerant over the infrastructure. By declarative It meant describing how many Instances one wants to run at a given time. Providing min, max and desired count of the Instances.
Based on the values given for min, max and desired as and when there is any change in these values because of any external or internal failures of EC2 instances, ASG will try to bring the system back to desired state.
ASG also supports scaling EC2 instances Horizontally, based on different parameters which could be Average CPU usage or Cloud watch alarms just to name some.
In this article we are going to discuss on ASG scaling policy and their importance from SysOps Admin Certification Examination.
ASG Scaling policies, are configured while setting up the ASG configuration.
Page looks something like below.
In Step 1 screenshot, Group Size parameters defines the desired state of the ASG being created.
In Subnets block we are setting all the subnets where ASG can start instances based on scaling polices, good practice selecting all the AZ’s under a region to give you maximum High Availability and Fault Tolerance.
For this demo I’m keeping Group Size parameter to 1, you can change it to 5 or 10 or any other number depending on the need. ASG will start those many instances first and that number will become the desired state of the application under ASG.
Moving to Step 2, we have two settings here.
1. Keep this group to its initial size – which means there will not be any scaling operation in any event of increased traffic situation(Which is not encouraged) though it can come handy when you know you will not encounter any spike or high load situation for the application which is behind ASG.
2. Use scaling policies to adjust the capacity of this group – (this is where magic happens) We have selected this settings. This means we can have policies based on which we can increase or decrease the number of instance. Imagine a situation when you don’t have to interfere and your application automatically scales to the need of the hour and be functional in the event of high traffic it’s being subjected to encounter. Sounds like a fairytale ?
Let’s see how we can achieve this !
Here Scale between block, provides us minimum and maximum number of instances against which ASG would be scaled too.
Now let’s focus on Scaling our ASG based on some parameter. We will move our focus to Scale group size block now and options it provides.
Scale group size have 4 main settings for us which are explained below :
1. Metric Type : This has values against which metric we want to scale our ASG with. Values could be Avg. CPU utilisation of the Instances running as part of ASG. Other values available are network though put in and out etc.
2. Target Value : In this block we have to enter the value at which our Scaling out operation will trigger. Consider if we have selected Avg CPU Utilisation as metric, and we want our ASG to scale once CPU usage crosses 80% we can enter 80 here.
3. Instance Needs : This block hold time in seconds, that an Instance needs after which it can start receiving traffic. Consider some bootstrap script needs to be run to install some software.
4. Disable scale In : This saves us money :), when load decreases ASG auto scales in.
Thats all folks ! we will have subsequent ASG tutorials where we will discuss about ASG notification, Step Scaling policies and more. Stay tuned 🙂