AWS AutoScaling Tutorial [Practical Examples]

In this tutorial, we will walk through the process of implementation of AWS AutoScaling Policy on Auto Scaling Group. But first, let's see what AutoScaling groups are.  

Auto Scaling Group

According to what is mentioned on the official website of AWS.

An Auto Scaling group contains a collection of Amazon EC2 instances that are treated as a logical grouping for the purposes of automatic scaling and management.

• An Auto Scaling group is the place where you define the logic for scaling up and scaling down.
• It has all the rules and policies that govern how the EC2 instances will be terminated or started.
• Auto Scaling groups are the collection of all the EC2 servers running together as a group and dynamically going up or down as per your definitions.
• When you create an Auto Scaling group, first you need to provide the launch configuration that has the details of the instance type, and then you need to choose the scaling plan or scaling policy.

 

Different AWS AutoScaling Policy

First, let's look at the different scaling policies that can be applied to the autoscaling groups.  

Dynamic Scaling

• The biggest advantage of AutoScaling is the dynamic scaling of resources based on the demand.
• There is no limit to the number of servers you can scale up to.
• You can scale up from two servers to hundreds or thousands or tens of thousands of servers almost instantly.
• Using AWS Auto Scaling policy you can make sure that your application always performs optimally and gets additional horsepower in terms of CPU and other resources whenever needed. You are able to provision them in real time.

 

Predictive scaling

• AWS Auto Scaling is now integrated with machine learning (ML), and by using ML Auto Scaling, you can automatically scale your compute capacity in advance based on predicted increase in demand.
• The way it works is AWS AutoScaling Policy collects the data from your actual usage of EC2 and then uses the machine learning models to predict your daily and weekly expected traffic.
• The data is evaluated every 24 hours to create a forecast for the next 48 hours.

 

Scheduled scaling

• If your traffic is predictable and you know that you are going to have an increase in traffic during certain hours, you can have a scaling policy as per the schedule.
• For example, your application may have heaviest usage during the day and hardly any activity at night.
• You can scale the application to have more web servers during the day and scale down during the night.
• To create an AWS AutoScaling policy for scheduled scaling, you need to create a scheduled action that tells the Auto Scaling group to perform the scaling action at the specified time.

  We will be using Dynamic Scaling as our scaling policy for the tutorial. So let's dive deep into the process and get our hands dirty!  

Configuration of an AutoScaling Group

Log in to your AWS account and click on EC2 under Services tab. Now, from  the left pane, click on Auto Scaling Groups and you will see the following screen. Now click on Create Auto Scaling Group. The configuration of Auto Scaling Groups involves seven steps. We will see all of them one by one.  

Step-1: Choose launch template or configuration

Here, first, we will provide the name of our AutoScaling Group. For now, we have set it to My-Test-ASG. Now we will select a launch template that contains the instance-level settings such as the Amazon Machine Image, instance type, key pair, and security groups. Since we don't have any launch template preconfigured, we will create one.   After clicking on Create a launch template we will see the following screen. Firstly, we will provide the name of our launch template.   Then we will specify the Amazon Machine Image type. Here we are selecting it to be Amazon Linux 2 AMI (HVM), SSD Volume Type. Then we will select the Instance type. Here we are selecting it to t2.micro. Note that, it's free tier eligible.   Now we will select our existing Key Pair i.e. EC2 Tutorial. You can also create a new Key Pair.   In the Network Settings, we will select the Networking Platform to be Virtual Private Cloud. Then we will select a Security Group. Since we already have a Security Group preconfigured, we will select that.   This is how the shown Security Group is configured. We can also create a new Security Group.   Then under Advanced details, we will set the user data to the following.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1> Hello World from $(hostname -f)<a/h1>" > /var/www/html/index.html

Now click on Create Launch Template.     After creating the launch template, it can be seen in the list of available launch templates.  

Step-2: Choose instance launch options

In the Network, we will select the default VPC in which our Auto Scaling Group will reside. Then we will define which Availability zones and subnets your Auto Scaling Group can use in the chosen VPC.  

Step-3: Configure advanced options (optional)

Here, we will specify that whether we want to use a load balancer or not, and if yes then whether we want to create a new load balancer or choose from an existing load balancer. Since we have a preconfigured Application Load Balancer available, for now, we will use that. In the upcoming blog, we will see that how we can create an Application Load Balancer from scratch. Now we will select a Target Group from our existing load balancer Target Groups.   In Auto Scaling, EC2 instances are automatically replaced if they fail health checks. If using a load balancer, which in our case we are then we can also enable ELB health check.  

Step-4: Configure group size and scaling policies

Here we will set our Group size. For now, we have set the values of Desired Capacity and Minimum Capacity to 1 and Maximum Capacity to 3. Our group size will change according to the traffic received later on. This is the power of Auto Scaling Groups.   Now we will select Target tracking scaling policy in which we will choose the desired outcome and leave it to the scaling policy to add and remove EC2 instances as needed to achieve that outcome. Here we will select the metric type to Average CPU utilization and set the target value to 40 which means we don't want any of the instances to run on more than 40% of the CPU utilization.  

Step-5: Add notifications (optional)

Here we can add notifications so that they can be sent to SNS topics whenever an Auto Scaling Group launches or terminates an EC2 instance. For now, we are leaving this step since it's optional.  

Step-6: Add tags (optional)

Here we can add tags so that they can be used to search, filter, and track our Auto Scaling group. For now, we are not adding any tag.  

Step-7: Review the AWS AutoScaling Policy configuration

Now the final step is to review all the details configured. With this, we have come to the end of the creation of our Auto Scaling Group.  

Verify and Monitor AWS AutoScaling Policy Behaviour

As soon as we create our AutoScaling group, in the Activity history, we will find some action happening. Here we can see that a new instance has been launched. The newly created EC2 instance can also be viewed after clicking on instances from the left pane. The capacity of Auto Scaling Group has increased from 0 to 1.   Now if we look at the DNS name of Application Load Balancer and enter it in the browser, we can see that our EC2 instance is working.   Now it's time to have some fun. We will increase the CPU utilization of our EC2 instance. As soon as the utilization increases to more than 40% we will see some action happening. First, we will go to our EC2 instance and then click on Connect.   Again we will click on Connect.   Now in the console, we will enter the following command.   Then we will install stress through the following command.   After that, we will type in the following command in order to increase CPU utilization.   After a while, in the Activity history, we will see that more instances are created in our Auto Scaling group and the capacity has been increased from 1 to 3 since we increased the CPU utilization of our first instance.   In the CloudWatch monitoring, we can view the CPU utilization skyrocketing.   Now if we go to CloudWatch Alarms, they can be found under Services tab, we can clearly see that there are two alarms created automatically by our Target Tracking policy in which one is AlarmLow and the other is AlarmHigh. It can bee seen that right now the AlarmHigh is in the InAlarm state since the CPU utilization has been increased.   Now let's revert to our previous conditions. For that, we will reboot all the three instances just to make sure that the stress command is killed.   After that in the Activity history we can clearly see that the capacity is first decreased from 3 to 2 and then 2 to 1. This is the magic of AutoScaling Groups.   In the CloudWatch Alarms, now we can see that AlarmLow is in the InAlarm state.  

Conclusion

In this tutorial, we learned about

• AutoScaling Groups.
• AWS AutoScaling Policy.
• Configuration of an AutoScaling Group with Dynamic Scaling Policy from scratch.
• Changes in the size of our AutoScaling Groups according to CPU utilization.

With this, we have come to the end of our tutorial. Stay tuned for some more exciting stuff coming ahead! Happy learning!