Achieving High Availability with AWS Application Load Balancing (ALB) with Auto Scaling for Production-Level Load Balancing

Himanshu Srivastava
8 min readApr 26, 2024

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
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

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!

Testing: 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 !!

𝐈𝐟 𝐲𝐨𝐮 𝐥𝐢𝐤𝐞 𝐦𝐲 𝐜𝐨𝐧𝐭𝐞𝐧𝐭 𝐲𝐨𝐮 𝐜𝐚𝐧 𝐟𝐨𝐥𝐥𝐨𝐰 𝐦𝐞 𝐨𝐧 𝐋𝐢𝐧𝐤𝐞𝐝𝐢𝐧 https://www.linkedin.com/in/himanshu-srivastava-76474b170/

--

--

Himanshu Srivastava
0 Followers

DevOps Engineer | AWS | Linux | Git | Jenkins | Docker | Kubernetes | Terraform | Python Scripting | Prometheus | Grafana | CircleCI | Datadog