Auto Scaling the infrastructure in AWS - Learn Amazon Web Services Autoscaling

Week 7 in AWS and we are now getting down to the good stuff! AWS auto-scaling monitors your applications and automatically adjusts in capacity to maintain steady, predictable performance for the lowest possible cost. You can set up application scaling for multiple resources across multiple services in mere minutes.

Prerequisites:

AWS Account

Steps:

1. Create a VPC with CIDR 10.10.0.0/16
2. Create three public subnets with 10.10.1.0/24 & 10.10.2.0/24 & 10.10.3.0/24
3. Create an auto-scaling group using t2.micro instances. All instances should have apache installed on each instance with the ability to check any random IP address and be able to produce a test page. Ensure the auto-scaling group is using the public subnets from #2
4. The auto-scaling min and max should be 2 and  5
5. Create an Application Load Balancer to distribute traffic to the auto-scaling group
6. Create web server security group that allows inbound traffic from HTTP from your Application Load Balancer
7. Create a load balancer security group that allows inbound traffic from HTTP from 0.0.0.0/0

Head over to the VPC pane and let's create a VPC. Click on VPC and more and start filling in the information:

Note: Using VPC and more allows you to create your VPC, subnets, route tables and availability zones all in one go. After I found this out I had to start over as it was a much smoother process.

Fill in the information for your availability zones as well as your subnets. Note: make sure you use more than one availability zone as you want your instances to be fault-tolerant.

Create the VPC and let's head over to the Launch Templates pane in the EC2 service.

Create a launch template.

Fill in the information.

As usual, we like free!

Create security group and use your created VPC.

Enable HTTP and SSH to allow all traffic. Note: this is only for project purposes!

DO NOT FORGET to enable auto-assign public IP! This gives your instance an IP address to connect to once you've created it.

This is the Bash script that will be used to enable Apache on all of your instances. Create your launch template, then let's head over to the Auto-Scaling Groups pane.

Create Auto-Scaling Group.

Fill in the information, then click next.

One of the objectives of this project is to make sure your auto-scaling group uses all three subnets. Choose each subnet as well as the correct VPC and click next.

Create an application load balancer with HTTP access that is internet-facing, giving us access to the internet.

Make sure all availability zones and subnets are selected, as well as your listener set to port 80. C reate your target group.

Enable CloudWatch to get monitoring info on your instances, then click next.

Per our project, the minimum amount of instances for our auto-scaling group will be two, while the maximum will be up to five instances. This will give better fault-tolerance if one instance gets stressed past a set threshold.

On our tracking policy, we want our group to scale an instance once it reaches past a CPU utilization value of 50%. Like before, this gives more fault-tolerance and scalability for our service. Click next all the way through and create your group.

Now let's make sure our instances are working. Head over to the Instances pane:

Our instances are running and status checks are 2/2. Copy the public IPv4 address into the URL for each instance and make sure your Apache webpage comes up.

Good to go! Now let's try out our stress tool

For the advanced portion of the project we've been delegated with the task of running a tool to stress our instance above 50% CPU. This will in turn create another instance to keep resources running and scalability high. After you have grabbed your SSH command from the connect page of either instance, login to your command line interface. I'm using PowerShell for this one. Note: this is an optional part of the project.

Copy the SSH command and let's go to the terminal

Went to our downloads folder then input our SSH command to remote into our instance

I ran into a roadblock trying to get the stress tool to work:

I tried switching between the SSH command and the AWS Configure command to try and see why my stress tool wasn't working. Then after some time, I checked my user-data and found out that the package has to be installed before the instance runs. I turned the auto-scaling group capacity down to zero and stopped my instances so that more wouldn't be created. I went to my launch templa te, clicked on the one I was using, went to actions, modify template, and updated the user-data:

Updated Bash script for stress tool.

After updating the template I went down to actions and set default version. I changed it to the latest one that I created, which was 3:

Now, in my auto-scaling group, I increased the capacity to 2 for the desired and minimum fields. Afterwards, I restarted my instances, used the SSH command to get back into my instance, and ran the tool:

Trying the stress tool with different times.

I headed over to CloudWatch to look at my graph:

The CPU was stressed up to 100%

Because I stressed the CPU for 450 seconds, the scaling group created three more instances just to keep up with the workload. Pretty neat stuff!

This project was a fun one. A lot of the steps I over-thought which made it harder on myself. Things like the stress tool not working, which security groups go where, and the load balancer not having enough availability zones to operate. After some help from my cohort I managed to pull through and complete the project. Any feedback is welcome and I appreciate you all for stopping by!

---

Auto-Scaling in AWS was originally published in Towards AWS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Namaste Devops is a one stop solution view, read and learn Devops Articles selected from worlds Top Devops content publishers inclusing AWS, Azure and others. All the credit/appreciations/issues apart from the Clean UI and faster loading time goes to original author.