AWS: Creating a VPC With an Auto-scaling Group Using T2.micro Instances

Maintain a self-healing architecture

Credit: AWS Auto Scaling [*note: although the diagram depicts the use of an Application Load Balancer, this exercise will not use one and focus instead on stressing CPU of instances.]

In this walkthrough, we will discuss the architecture of VPCs within AWS (Amazon Web Services) and the use of auto-scaling groups in EC2 to help maintain a self-healing architecture.

Objectives

1. Create a custom VPC with a CIDR 10.10.0.0/16
2. In EC2, create Launch Configurations in order to define launch specifications that include the custom VPC — each instance will also need to have the Apache webserver installed with the ability to check random IP addresses and produce a test page
3. While in EC2, configure an auto-scaling group for the instances with an instance minimum of 2 and a maximum of 5. The scaling policy will use CloudWatch to scale after the CPU Utilization is above 80%
4. After the auto-scaling group is created, a stress tool will be used to stress an instance above 80% CPU Utilization to make sure the above scaling policy works.

Note: For the purposes of this exercise, I am also using the new AWS Management Console. I will be configuring a custom VPC rather than using the default created by AWS. My region is set to us-east-1.

Creating a custom VPC with a CIDR of 10.10.0.0/16

1. From the AWS Management Console, use the search bar to navigate to VPC. From this page, you have the ability to configure the VPC and all network settings from the Dashboard options or us the Launch wizard to guide you through the creation of all settings at once.
2. Using Launch Wizard: Select VPC, subnets, etc., name the VPC, and ensure the CIDR is set to 10.10.0.0/16. Keep all other defaults and click Create VPC.

VPC settings

Preview of VPC architecture automatically created as settings are configured

The VPC will be created with all necessary components and ids. Viewing the VPC will allow you to view this as well.

EC2 and Launch Configurations with Apache Installation

AWS EC2 and Apache Webserver

1. From the AWS Management Console, use the search bar to navigate to EC2. From the Dashboard, scroll down to Instances and select Launch Templates.
2. Include the following settings for each section of the template:

Create a Launch template name | check “Provide guidance to help me set up a template that I can use with EC2 Auto Scaling.”

AMI — select Amazon Linux 2 (from catalog or using Recents) | Instance type →t2.micro (Free tier)

Key pair (login) → create new key pair or select existing key pair

Network Settings → Create security group (so we may attach the newly created VPC)

Security group rules: In a real-world scenario, I would not allow all IP addresses access, but for the purpose of this exercise, I am not restricting access.

Advanced network configuration → Select “Enable” to Auto-assign public IP to allow us to view the instances’ Apache test page in the browser later.

Advanced Details: Select “Enable” for Detailed CloudWatch monitoring

Advanced Details → User data — include the bootstrap that will update packages, install Apache, and include the stress tool we will use.

#!/bin/bash
yum update -y
yum install httpd -y
systemctl start httpd
systemctl enable httpd
amazon-linux-extras install epel -y
yum install stress -y

3. After all settings have been configured, click “Launch Template”. From the next screen, you should be able to select the option to “Create an Auto Scaling group from your template”.

Create an Auto Scaling group

Credit: AWS Documentation — Amazon EC2 Auto Scaling User Guide

1. After clicking “Create an Auto Scaling group from your template”, complete steps 1–7 with the specifications listed below.

Step 1: Create the Auto Scaling group name and select the Launch template created in the previous section

Step 2: Network → Select the VPC created in the first section, select only the public subnets to allow the instances to be able to display the Apache test page.

Step 4- Part 1: Since this exercise specifies a Minimum capacity of 2 and Maximum capacity of 5, I selected a Desired capacity of 2 to test.

Step 4 — Part 2: Add ( and name!) a Target tracking scaling policy to be able to specify the metrics that will be used by the Auto Scaling group. For this exercise, the metrics included a Target value of 80, which would allow more instances to be created when the CPU Utilization if surpassed.

The Auto Scaling group was successfully created

Confirming the success of the Auto Scaling group and using a stress tool

1. Confirm Apache has been installed on each instance: After a few minutes after launching the Auto Scaling group, the instances will begin to initialize and launch. Once an instance is running and has passed both status checks, select the instance id to view the details and copy the public ip. In the search bar of the browser, type http://<public_ip> and hit “Enter”. If you reach the Apache test page, the installation from the bootstrap was a success.

Apache test page

2. From the AWS Management Console, use the search bar to navigate to CloudWatch. Because we checked off options earlier in the process to track the CPU Utilization metric in CloudWatch, there should already be alarms created for the Auto Scaling group in the CloudWatch dashboard.

3. To run the stress tool we bootstrapped into the Auto Scaling group instances, open the terminal, change directory using $ cd <name_of_directory> to make sure you are in the same directory as the keypair .pem file. If necessary, use the command $chmod 400 <nameofkeypair>.pem to secure it from being viewable. Then, log into one of the running EC2 instances using the following code:

$ ssh -i "<nameofkeypair>.pem" ec2-user@<public_ip_of_instance>
$ sudo stress --cpu 1 --timeout 300

• Since my instances will require 60 seconds to warm up (as configured in the Auto Scaling group), the stress tool will need to have enough stress on the CPU to max out and trigger the CloudWatch alarm configured in the Target Tracking Policy. The --timeout value represents the length of the stress test. The stress test will end and produce the following result:

In the local terminal, the stress tool will stress the instance I have chosen for a period of 300 seconds (5 minutes), allowing CloudWatch to track the specified metric (CPU Utilization).

CloudWatch → Widget with CPU Utilization metric set, tracking the maximum over a 5 minute time period. The stress test yielded 100% CPU Utilization, which means the stress test was successful. (This can be viewed in CloudWatch or when you select a running instance in EC2).

** I spent a lot of time adjusting the stress test with different values to see how CloudWatch adjusted the graphs. I also experimented with the values for monitoring for the same purpose. During this stage of the exercise, it was helpful to see how these adjustments affected the outcome.