Handle the work carefully — Auto Scaling and Load Balancing

8 min readSep 12, 2023

In my next venture with becoming a cloud engineer, the Level Up in Tech program has been an awesome platform filled with wonderful, people, information and support.

In this leg of my journey, the next project builds up on the prior projects of deploying EC2 web instances, using application load balancers and Auto Scaling groups to build a more robust, scalable and reliable architecture for the “company” Level Up In Tech Bank. Let’s see how the next phase unfolds…

— — — — — — — — —

We created some instances for Level Up In Tech Bank to be able to deploy their web infrastructure but after a couple of internal meetings, the topic of the bank’s future came to the forefront. For the web presence, they wanted to have the web infrastructure able to take on additional load when necessary, be secure, and be able to flex all of this with the idea of remaining cost effective.

Out of the discussions came the ideas of using a load balancer and autoscaling groups. The load balancer could be used to have a single point of entry for the website (using an application load balancer) and the autoscaling groups could be set to have a min/max number of instances to handle the load at peak times and reduce the number of instances during lean times.

I started with the concept of creating a VPC in our default region of US East and using the auto scaling groups to deploy the instances in separate subnets separated by availability zones in order to minimize the effects of an AZ failure on Amazon’s behalf and have the web traffic to the instances distributed by the application load balancer.

My initial concept presented was as follows:

Things seemed to check out. Now, let’s put it in place.

Create a VPC and add 3 subnets to it. Associate those subnets to 3 different availability zones as shown in the diagram.

2. Add a gateway and configure the route for the subnets as well as for internet access.

3. Adding the gateway to the VPC — it’s gotta know who can talk to it. Since you can have multiple VPCs and you may not want all having internet access, this is important.

4. Now to edit the route tables to direct all non-local traffic from the to the internet. Local traffic would be traffic to endpoints that are inside the local network (i.e. within the VPC’s CIDR block)

Attaching the subnets to the route group

Giving the route table the direction to use the internet gateway.

Next, let’s start working on the autoscaling group. We’ll need to start off with making sure we have a working EC2 instance. Luckily enough, I still have the AMI from a prior project to build on.

So I used it to create a template for the auto scaling group. I went to EC2 > Launch Templates and selected Create Launch Template and started to put in the information needed:

Notice here that I didn’t add a subnet into the template. This should allow for the autoscaling group to use all 3 of the subnets (one in each AZ) to be used for deploying images.

I then clicked on the Advanced details option at the bottom so I could add in the code to deploy that should deploy the web servers and have a page up to identify as the bank and show the AZ that the EC2 instance has been deployed to. (NOTE: Since medium is being a pain about adding code blocks — here’s a screenshot of the user data I’m using (it should update yum, instal and start apache, and add a holder site with the LUIT icon and display a message with the AZ the instance was deployed in)):

Now to start configuring the autoscaling group. So — EC2 -> Auto Scaling groups and create Auto Scaling group (making sure to select the correct Launch Template):

Now to select the correct VPC and Subnets:

Here — it asks if I want to create a load balancer, so of course I say — why not? I’ll take the help if they’re giving it!! I select Attach to a new load balancer, make it Internet-facing and create a target group to direct port 80 (HTTP) traffic through it.

Per the project specs, we were told that the instance count should be 2 minimum, 5 maximum but they wanted at least 1 per AZ up by default. So we configured the group to that specification:

We added notification to our SNS queue in the case something happened:

Clicked through the rest and allow the group to start creating:

The instances are currently deploying! And the Loadbalancer is up!!

Let’s check the load balancer web endpoint:

Something’s wrong here!! I can access the page but this is from the OLD project!! I have learned that I need to recreate the AMI to use the the new code I’m looking to deploy in the way I’ve currently deployed things. I also noticed that I didn’t add IPs for my instances so I don’t have access to check the internals… sheesh!! Still learning though. Gonna go redo the AMI and Auto Scaling group…

Steps — Create instance (configure with proper VPC, Subnet, AutoAssign Public IP, Insert User data).

Ok — instance created and I did the extra setting of enabling the auto-assignment of a public IP address. Then, launched the instance and checked the IP:

IP address found. Let’s check the web page presented.

Cool — Stamped LUIT and shows the information requested.

Now — to make this a template and go back to recreate the autoscaling group. Not gonna bore you with the details since I’ll be doing what I did prior.

AutoScaling group and Load Balancer re-created:

Once they’re provisioned, we can re-check. All looks green!!

We have a response from the ALB endpoint!!

Let’s refresh to see if the balancing act works:

Nice! All three zones are responding. I did note that the EC2 instances do have public IPs. Gonna check to see if they’re responding.

Yuck — it looks like they are. Now I need to change something to make those NOT accessible but leave the load balancer DNS name accessible. I was stumped and my colleague suggested that I try creating a new Security Group to allow all http traffic to the load balancer then edit the group on the Auto Scaling Group to point all web traffic to the load balancer security group.