CODEX
Configuring and Testing Auto-Scaling in AWS EC2
This guide documents the steps required in AWS to configure an auto scaling group (ASG) with a launch configuration for creating EC2 instances with an Apache web server. We will then test the implemented ASG’s ability to scale out with changes in instance state and handle increased traffic.
Objectives:
- Create a Launch Configuration for launching t3.nano EC2 instances, with an Apache web server bootstrap script in the user data section.
- Create an ASG with a minimum of 2 and a maximum of 5 instances running.
- The ASG should include a target scaling policy to scale in and out depending on average CPU usage.
- Test the scaling policy by stopping an instance. If your Auto Scaling policy works, the number of running instances should scale out.
- Test the ASG’s ability to balance high loads with Apache Bench.
Before beginning with launch configurations and ASG’s, some preparation of the environment is recommended.
Step 1: Create an EC2 Instance
First, log into the AWS Management Console. From the Services list, choose EC2:
Select “Launch an instance,” and follow the instructions to create a public-facing EC2 instance with a security group allowing public HTTP access and SSH access to your personal IP address. I used a t2.micro instance type to take advantage of its Free Tier status.
Under Step 3, make sure “Auto-Assign Public IP” is enabled in the Network Interface settings.
After entering the VPC, subnet, and Availability Zone settings, scroll to the bottom to “Advanced Details”, then to “User Data.” Enter the following provisioning script in the “User Data” section to automate updating the instance and installing the Apache2 web server:
#!/bin/bash
apt-get update -y
apt-get upgrade -y
apt-get install apache2 -y
systemctl start apache2
systemctl enable — now apache2
Complete the instance setup, and view the new instance running in the EC2 console. To test if the instance has followed the bootstrap instructions, copy the instance’s public IPv4 address into a browser. The instance is working properly if the Apache default page appears.
In the EC2 console, select the new EC2 instance, and under the “Actions” drop-down, select “Create Image.” Follow the simple instructions to create your custom Amazon Machine Image (AMI). The new AMI will be used in the auto scaling configuration, but is also available to use in launching a new web server instance.
Step 2: Create a Launch Template Using the Custom AMI
AWS is currently discouraging use of launch configurations as they do not support all of EC2’s features. For best practice, AWS recommends using launch templates instead:
In the left menu of the EC2 console, select “Launch Templates.”
Select the new AMI you created in Step 2 as the launch template’s required AMI. Follow the self-explanatory instructions to set up the launch template based on your custom AMI.
You should see the following confirmation page for your launch template :
Step 3: Create a Target Group
A target group will also be necessary in configuring the ASG’s load balancer. Click on “Target Groups” in the EC2 console left menu, and click “Create target group.”
At the top of the “Create target group” page, select “Instances” as the target type, and give the Target Group a name. On the next page, “Register targets,” you should see your EC2 instance created in Step 1 listed. To add the instance to the targets, select the instance, then click “Include as pending below”:
You should then see your instance as “Pending” and being registered as a target:
Click “Create target group” to complete its setup.
Step 4: Create an Auto Scaling Group
In the EC2 console, scroll to the bottom of the left menu to select “Auto Scaling Groups,” then click “Create auto scaling group.”
First, enter a name to identify your ASG, and ensure the default version of the launch template selected is the same we created earlier.
Second, on the “Configure settings” page, select the radial for “Adhere to launch template.” The VPC, subnets, and Availability Zones should be the same as you used for the deployed template instance.
Third, on the “Configure advanced options” step, select “Enable load balancing,” and choose the target group created earlier.
Also, under “Listeners and routing,” select the Default routing as your target group:
Fourth, we have the option to configure the ASG’s group size and scaling policies. Set the desired capacity at 3 instances, the minimum capacity at 2 instances, and maximum capacity at 5 instances.
For the scaling policy, select “Target tracking scaling policy” and enter a target value for the average CPU utilization:
In the “Instances need ___ seconds warm up before including in metric,” enter the recommended 300 seconds.
The next two ASG setup pages allow adding notifications and tags. While these would be advisable in a real-world setting, they are not essential to demonstrate the auto scaling group’s functionality.
Finally, double check the settings as listed on the “Review” page to ensure everything is configured and ready to go.
Step 5: Test the Auto Scaling Group
After the ASG loads and activates, head back to the EC2 console, and select “Instances” to view the instances generated by the ASG running:
To test the ASG’s ability to detect unhealthy instances and replace them according to our policy settings, select the three new instances, and select “Stop” from the “Instance state” menu:
After the 300 seconds have passed, the ASG discovers the stopped instances and generates three new instances in different Availability Zones as directed:
Viewing the “Actions” tab on the “Auto Scaling Groups” page, we can confirm that the activity log has recorded the new ASG’s detection and correction of our instances.
Finally, head to your command line and use Apache Bench to send large loads to each new instance. To see if our ASG can handle 100 requests, with a maximum of 10 requests running concurrently, I entered:
~ % ab -n 100 -c 10 http://52.3.231.143/test.cfm > test1.txt
~ % ab -n 100 -c 10 http://18.205.19.144/test.cfm > test2.txt
~ % ab -n 100 -c 10 http://44.192.47.196/test.cfm > test3.txt
Three .txt files were created in my home directory. Representative of the performance of each instance in the ASG, below is the output for the first instance, showing zero failed requests:
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/Benchmarking 52.3.231.143 (be patient)…..done
Server Software: Apache/2.4.41
Server Hostname: 52.3.231.143
Server Port: 80Document Path: /test.cfm
Document Length: 274 bytesConcurrency Level: 10
Time taken for tests: 2.659 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 45400 bytes
HTML transferred: 27400 bytes
Requests per second: 37.61 [#/sec] (mean)
Time per request: 265.892 [ms] (mean)
Time per request: 26.589 [ms] (mean, across all concurrent requests)
Transfer rate: 16.67 [Kbytes/sec] receivedConnection Times (ms)
min mean[+/-sd] median max
Connect: 61 66 4.1 66 80
Processing: 60 146 154.2 68 502
Waiting: 60 146 154.2 68 501
Total: 122 212 157.1 133 563Percentage of the requests served within a certain time (ms)
50% 133
66% 135
75% 139
80% 513
90% 513
95% 513
98% 513
99% 563
100% 563 (longest request)
