Stress Testing CPUs on AWS Linux

Using AWS CloudFront, Auto Scaling, and Elastic Beanstalk

Introduction

In this article, we will look at stress testing the CPU on Linux for a web application deployed with AWS Elastic Beanstalk with auto-scaling rules applied.

AWS Cloud Services & Technologies

Use Case

You have been tasked with creating an application to collect entries for a raffle at a Cloud Bootcamp conference, expecting 10,000 people to participate. The event will be broadcasted over the Internet and in person. The audience will register their email to guarantee participation in the raffle of ten vouchers for three cloud certifications. The application will need to be responsive for desktop and mobile access.

Solution Architecture

We will use Elastic Beanstalk to deploy a web application and DynamoDB to store the raffle entries. This application must support the high demand of users accessing the application simultaneously, dictating the need for CloudFront to cache static and dynamic files to an Edge Location close to the users.

AWS Solution Architecture

Implementation

First, we must write the application code to collect and store the user’s email. For the data storage, we create a DynamoDB table named “users” with a partition key (primary key): email (String). The application code depends on an environment property to know where to locate the DynamoDB “users” table. We wrote a simple Python web application for this project, which can be downloaded here.

DynamoDB users Table

The application is deployed using Elastic Beanstalk (ELB) to automatically handle the capacity provisioning, load balancing, EC2 instances, auto-scaling, and application health monitoring for the application. Some key settings are pictured below:

Platform Settings

Presets Selection

Network Settings

Note: As of this writing, us-east-1e does not support t2-micro instance types.

Auto Scaling Group Settings

Scaling Trigger Settings

Environment Property Settings

After the Elastic Beanstalk application is created, we will see there is a configuration error that doesn’t allow the application to launch. AWS has changed the default way of creating S3 buckets; all S3 buckets are now created without default ACLs. Therefore, S3 object ownership for the Elastic Beanstalk generated S3 bucket must be edited:

S3 Object Ownership Settings

Hopefully, Amazon will add this setting as an option in the Elastic Beanstalk configuration settings in the future.

The aws-elasticbeanstalk-ec2-role must also be granted permission to WRITE to the DynamoDB “users” table; otherwise, every user sees a 500 error when submitting their raffle entry. You can attach the “AmazonDynamoDBFullAccess” policy or create your own to minimize access permissions to comply with the least access security principle.

The last step is creating the CloudFront distribution to accelerate static and dynamic web content distribution utilizing Edge Locations. Select the Elastic Load Balancer created for the application and change the allowed HTTP methods to include the PUT and POST verbs. This will allow the application to make the HTTP calls to write to the DynamoDB “users” table. To ensure everything works, open a browser, and navigate to the CloudFront Distribution domain name. Manually test the application by entering an email address and clicking the register button. Don’t forget to check for your entry in the DynamoDB “users” table item listing.

Stress Testing the Solution

Now for the fun part. When you open the EC2 dashboard, you will see two instances running, the load balancer and the auto-scaling group. Open the instance listing and get the IP address of the first instance running. Log in and run the following commands:

sudo amazon-linux-extras install epel -y
sudo yum install stress -y
stress -c 4

After starting the stress test on the first instance, we see a Health warning.

Elastic Beanstalk Environment showing Health Warning

Elastic Beanstalk Event Excerpt

And we can see that a new instance is started based on the rules set up for auto-scaling:

Elastic Beanstalk Instance Health Status Showing Degraded Instance and a New Instance

When you shut down the CPU stress test, you’ll see that the auto scaler has reduced the number of instances.

Elastic Beanstalk Instance Health Status Showing Two Status Ok Instances

Summary

We walked through the essential required settings for deploying a web application with high availability capacity through auto-scaling using Aws services. And we looked at stress testing the CPU to prove the auto-scaling works as required.

If you enjoyed reading this article or found it helpful, don’t forget to click the like button or follow me. You can also reach out to me on LinkedIn.