IaC: Create an Auto Scaling Group & Application Load Balancer with AWS CloudFormation

What is an Auto Scaling Group and Application Load Balancer?

Auto Scaling is a service that monitors and adjusts the number of instances according to changing demands. This service can add instances if the workload increases, and remove instances if the workload decreases. With Auto Scaling Groups (ASG) you can manage a group of EC2 instances based on defined scaling policies that are set.
An Application Load Balancer (ALB) helps by distributing incoming traffic across multiple instances within one or more Availability Zones, which reduces the risk of a single point of failure and helps to prevent performance bottlenecks.

Why Use CloudFormation?

AWS CloudFormation is an Infrastructure as Code (IaC) service that allows users to model and manage resources with programming language in an automated and secure way. The beautiful thing about CloudFormation is that it can be used to provision simple to complex applications and multi-tier environments across multiple regions. And with the use of code templates in JSON or YAML format, users can take advantage of version control and effective collaboration.

Using AWS Cloudformation, we are going to create a VPC, 3 public subnets and an Auto Scaling Group with Apache server hosting a custom page installed on each instance.
The ASG will be set to a desired capacity of 3 instances, with 2 being the minimum and 5 the maximum.
We’re also going to add a target policy for the ASG to scale after CPU utilization exceeds 50% and create an Application Load Balancer to distribute traffic to the ASG.
Once finished, we are going to use the DNS name of the ALB to access the page and stress an instance above 50% to see if the scaling policy works.

Let’s get started…

We can utilize Notepad or VIM text editor to create a file of the code template.
Below is the CloudFormation template in YAML format that accomplishes this. (Be sure to save the text file with .yaml extension or .json if using JSON format.)

To further explain, the template starts with creating a VPC that offers a defined virtual network space. This VPC is spread across three Availability Zones for higher fault tolerance, each containing a Public Subnet. The Internet Gateway allows communication between instances in the VPC and the internet. Route tables ensure that network traffic is correctly directed between subnets and the outside world.

The WebServerSecurityGroup provides specific network traffic permissions, allowing for SSH and HTTP access. The EC2 Launch Template configures the instances with user data, using AutoScaling to ensure that the right number of instances are always running. The AutoScaling uses a CloudWatch Alarm to monitor CPU usage, and if it detects high usage, it can adjust the number of instances in response.

Also, an Application Load Balancer is deployed to distribute incoming traffic across multiple instances, across multiple Availability Zones. This ensures high availability and fault tolerance in your applications.

Now let’s upload the template to CloudFormation.
Go to AWS CloudFormation and click Create stack.

Select Template is ready and Upload a template file.
Once you’ve selected the file, click Next.

Under the Parameters section shows the parameters from the template file.
Enter a Stack name and click Next.

On Step 3 page keep all default stack options and click Next.
On Step 4 page click Submit.
On next page, we will see the stack creation in progress. Wait a few minutes for completion.

Go to Instances in the EC2 Dashboard.
Here we can see 3 instances running across 3 different Availability Zones.

Let’s go to Load balancers and click the name of the ALB that was created.

Click the box next to the DNS name to copy it.

Paste the DNS name in the browser and there we have it! The custom page is reachable!

Now let’s connect to 1 of the instances via SSH so that we can stress the instance above 50% to see if the scaling policy works.
Run stress -c 20 -v to start 20 processes that, as a result, will utilize the CPU. You can adjust the number of processes based on your requirements.

If we go to CloudWatch we can see an alarm was triggered for when the CPU utilization exceeded 50%.

Now let’s go back to Instances in the EC2 Dashboard.
Here we can see 2 additional instances were created. This is an indication that the ASG policy is working.

And that’s it. We’re done.
Make sure to delete the stack so that you’re not charged for resources you don’t need.
Since the DeletionPolicy was set to Delete for all resources, once we delete the stack, we do not have to go and delete each resource individually.
You have the option to set the DeletionPolicy to Retain for any resources you do not want to have automatically deleted.

Ok. That’s enough for today. See you until next time!