Leveraging high availability by creating an AWS Auto scaling group & application load balancer

Intro

Two of the hallmarks of AWS services are high availability and elasticity. Highly available systems operate continuously without failure for long periods of time. Elastic systems provision resources/capacity based on demand and scale as needed. As Dev Op/Cloud engineers, part of our job is to find ways to streamline processes and keep your application running smoothly.

One method of ensuring this is by dynamically scaling EC2 resources and intelligently directing traffic based on workloads and inbound activity. Enter, Auto scaling groups (ASG) and Application load balancers (ALB). This guide will show you how to create an ASG and ALB that will dynamically scale web server resources based on incoming internet traffic.

I highly recommend reviewing my previous article on installing an Apache web server on an AWS EC2 instance, as much of the terminology and concepts I will be using will be explained in more detail.

What is an Auto Scaling Group?

An auto scaling group adds, removes, or replaces EC2 instances across multiple availability zones based on need or changing demand. It reduces the impact of system failures and improves the availability of our applications.

What is an Application Load Balancer?

An Application Load Balancer distributes incoming application traffic across multiple EC2 instances and availability zones.

What we’ll be doing

1. Create our network environment including the VPC, subnets, internet gateway, and route table.
2. Create a security group to allow SSH and incoming HTTP traffic.
3. Create a launch template that will inform the type of EC2 instances the auto scaling group should create.
4. Create an Auto scaling group (ASG).
5. Create our Application Load Balancer (ALB) to properly route internet traffic to the auto scaling group across multiple subnets.

Step 1: Create our environment

First, let's create the environment, in which our auto scaling group will live. In this environment, we will have to:

1. Create a VPC
2. Create three (3) public subnets, where our EC2 instances will be dynamically stored.
3. Create an internet gateway to allow our subnets to connect to the internet.
4. Configure the route table to properly direct traffic from the subnets to the internet gateway.

1. Create a VPC

Via the VPC console, we will create a VPC with a CIDR block of 10.10.0.0/16

2. Create our subnets

Within this VPC, we’ll need three public subnets. Each subnet will be assigned to a separate availability zone (us-east-1a, us-east-1b, and us-east-1c) and its own CIDR block (10.10.1.0/24, 10.10.2.0/24, 10.10.3.0/24).

Having three subnets across multiple zones ensures high availability for our web application. If one availability zone should happen to go down, the application load balancer will direct traffic to the other subnets, and the auto scaling group will scale up or down EC2 instances, as needed.

Don’t forget to check the ‘Enable auto-assign public IPv4 address’ box for all three subnets.

3. Create an internet gateway

Next, we’ll need to create an internet gateway so our eventual EC2 instances in our subnets can connect to the internet. Make sure the gateway is attached to the VPC we just created.

4. Configure the route table

Finally, we need to configure the route table so network traffic can properly be directed from our subnets to the internet gateway and users.

When we created our VPC, a route table was automatically created. Let’s find that route table and configure it so it knows to connect the subnets to the internet gateway. In the ‘Route Tables’ dashboard, you should see the new entry, which is attached to our VPC.

We need to explicitly associate the route table with our three subnets. So under ‘Actions > Edit subnet associations,’ let’s add the subnets to the route table.

Lastly, we need to route all traffic (0.0.0.0/0) from the subnets to the internet gateway, so let’s add a route (‘Actions > Edit routes’).

Select ‘Internet Gateway’ and then the gateway we created.

Alright! We’ve successfully created our basic environment. Now it’s time to create the security group.

Step 2: Create a security group

To provide proper inbound/outbound traffic rules to our VPC, we need to create a security group to allow SSH and HTTP access. In the EC2 console, let’s create a new security group that will be used by our auto scaling group. Make sure the group is attached to the correct VPC.

Now add inbound SSH and HTTP rules.

Step 3: Create an EC2 launch template

An EC2 launch template allows you to reuse instance configurations, so when we create our auto scaling group, we can use this template to dictate what kind of EC2 instances should be created on demand.

Let’s create a template in the EC2 console.

We’ll be using the Amazon Linux 2 AMI and a t2.micro instance type.

An already existing key pair can be used, or you can create a new one.

Under ‘Network settings,’ we can select the security group we created in the last step. We’ll also need to enable ‘Auto-assign public IP’ under the advanced network configuration.

Finally, let’s add a script that will install and run an Apache web server every time an instance is launched.

Paste the script in the ‘User data’ field under the ‘Advanced details’ section.

#!/bin/bash

#update all
sudo yum update -y

#install apache
sudo yum install -y httpd

#enable and start apache
sudo systemctl enable httpd
sudo systemctl start httpd

sudo echo '<!DOCTYPE html>

<html lang="en">
 <head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />

  <title>Web Server Started</title> />

  <link rel="preconnect" href="https://fonts.googleapis.com" />
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
  <link
   href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;700;800&display=swap"
   rel="stylesheet"
  />

  <link rel="stylesheet" href="css/styles.css?v=1.0" />
 </head>

 <body>
  <div class="wrapper">
   <div class="container">
    <h1>Welcome! An Apache web server has been started successfully.</h1>
    <p>Replace this with your own index.html file in /var/www/html.</p>
   </div>
  </div>
 </body>
</html>

<style>
 body {
  background-color: #34333d;
  padding-top: 128px;
 }

 .container {
  box-sizing: border-box;
  width: 740px;
  height: 440px;
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: flex-start;
  padding: 48px;
  box-shadow: 0px 1px 32px 11px rgba(38, 37, 44, 0.49);
  background-color: #5d5b6b;
  overflow: hidden;
  flex-wrap: nowrap;
  gap: 24;
  border-radius: 24px;
 }

 .container h1 {
  flex-shrink: 0;
  width: 100%;
  position: relative;
  color: #ffffff;
  line-height: 1.2;
  font-size: 40px;
 }
 .container p {
  position: relative;
  color: #ffffff;
  line-height: 1.2;
  font-size: 18px;
 }
</style>
' > index.html

Great! We’ve successfully created an EC2 launch template for our auto scaling group to refer to when it needs to create instances.

Step 4: Create an auto scaling group

We’re ready to create our auto scaling group! In the EC2 console, create a new group.

Name your ASG and select the launch template we created in the last step.

Select the VPC and three subnets where our ASG will create the EC2 instances.

We will create a load balancer in the next step, so we can skip this step for now.

The group size sets the base rules for how many EC2 the ASG can create. These are the rules we will use:

• Desired capacity: 2.
  In ideal conditions, the ASG will create 2 instances.
• Minimum capacity: 2.
  The minimum number of instances available.
• Maximum capacity: 5.
  The maximum number of instances available.

We can skip the next couple of settings and keep the defaults. Review the ASG settings and create the group.

Success! The ASG for our web application is now live. It might take one or two minutes to fully initialize, but if we go to our EC2 Instances dashboard, we should see that two instances are up and running!

We should be able to go to their public IP addresses to see if the Apache web servers have been installed.

Success!

Step 4: Create an Application Load Balancer

Now that we have our ASG up and running, we need to create an application load balancer (ALB), which will distribute incoming application traffic to the proper targets, such as specific EC2 instances in multiple availability zones. There are two main components of an ALB: the Listener and the Target.

The Listener checks what type of connection request is coming from the client. The balancer then routes the request to the proper target/target group based on predetermined rules or policies.

Create the target group

First, we’re going to create a target group for our ALB to direct traffic to.

To create a target group, go to the ‘Target groups’ dashboard under the ‘Load balancing section’ in the EC2 console.

1. Our target type will be our EC2 instances, so make sure ‘Instances’ is selected and give your group a name.
2. We’re going to direct traffic to HTTP | port 80, so make sure the ‘Protocol’ is HTTP.
3. Select the same VPC we used for our ASG and EC2 instances.
4. On the next page, we should see the 2 running instances available to select, but we’ll leave it be for now. Create the group and we’re ready for the next step.

Create the ALB

To create an ALB, go to the ‘Load balancing’ dashboard in the EC2 console and select Application Load Balancer.

1. Give your ALB a name and make sure the ‘Scheme’ is ‘Internet-facing.’
2. Under ‘Network mapping,’ select the proper VPC and three subnets.
3. Select the proper security group (you can add up to 5, but make sure only the one we created is attached).
4. For our ‘Listener,’ we are going to listen for HTTP requests and forward them to our target group, so select the target group we created. Create the ALB!

Connect the ALB to the ASG

Last step! Now that we've created our load balancer, we need to connect it to our ASG. So let’s go back to our ASG and scroll down to ‘Load balancing.’ Select the Application load balancer and the target group we created.

This may take a couple of minutes to start working, but if we go back to our target group, we should see that the two instances have been successfully registered.

Let’s double-check our work by going to the load balancer DNS and see if our site still loads properly

Success!

We’ve successfully created an auto scaling web app environment that dynamically scales our EC2 instances and properly routes traffic to the right target groups!

Note: Once you’re done using your ASG and ALB, be sure to delete them or you’ll get charged for the running EC2 instances. The instances will automatically terminate.

Thank you!

Thank you for following me on my AWS cloud computing journey. I hope this article was helpful and informative. Please give me a follow as I continue my journey, and I will share more articles like this!