In this project based on a real-world scenario, I was responsible for implementing a web application that needed to support the high demand of a large number of users accessing it simultaneously. This application would be used in a large conference which has more than 10,000 attendees, both in-person and online, with participants from all over the world.
This event was to be broadcast online and in-person, and 10 vouchers would be raffled-off for various Cloud certification exams. At that moment, more than 10,000 people in the audience would register their e-mails to participate in the raffle for the exam vouchers. The application needed to be able to scale up to accommodate the rapid increase in the number of users, and scale down once demand decreased.
I used the AWS Elastic Beanstalk service to deploy the web application, DynamoDB to store the raffle participant email addresses, and CloudFront to cache the static and dynamic files in Edge locations close to the users.
I configured Elastic Beanstalk with an Auto Scaling group with a minimum of 2 EC2 instances, and a maximum of 4. It was configured to add an EC2 instance if CPU utilization stayed over 50% for more than a minute, and to remove an EC2 instance if CPU utilization dropped below 40% for more than a minute.
I had an opportunity to troubleshoot an issue with the application during testing. I encountered an error when initially attempting to register an email address using the web application. I utilized the Elastic Beanstalk application environment logs to investigate the error and discovered that the application was encountering an ‘access denied’ error when trying to perform a PutItem action on DynamoDB. I was able to resolve the issue by adding the appropriate permissions to the IAM role being used by the application to perform the PutItem action, which I confirmed by verifying that the test email addresses were successfully added to the DynamoDB ‘users’ table.
Once the application was performing as expected I deployed a new CloudFront distribution to cache the application files at edge locations close to the users so that the application would be more responsive.
After CloudFront was up and running I performed stress testing on the EC2 instances to confirm that Elastic Beanstalk detected the change in environment health, that the Auto Scaling group added additional EC2 instances as needed, and that the new EC2 instance was successfully registered by the Elastic Load Balancer.
To continue the testing, I removed the stress from the EC2 instance and confirmed that Elastic Beanstalk environment health returned to OK, and that the addition EC2 instance was terminated automatically by the Auto Scaling group, as designed.
This project really shines at demonstrating the power of the Elastic Beanstalk service, especially when compared to the last project, where each of the services for the application deployment such as the EC2 instances and Auto Scaling groups were created and configured manually via the AWS management console. The deployment of each of these services was handled by Elastic Beanstalk for this project, and while it still required significant effort to properly configure Elastic Beanstalk, it provided a much more streamlined process for deploying an application and all its backend components.
I’m truly enjoying the way these AWS projects are building on the skills I’ve developed in each of the previous projects, and I’m looking forward to continuing my cloud journey and sharing my progress.
