CPSC 4440 Final Project

This project was assigned to me as a final project for the cloud architecture course I took at Clemson University. This project was split into five parts using different AWS services: IAM, EC2 with Load Balancing, VPC, RDS, and EC2 Auto-Scaling. Click here to see the project instructions. A diagram of the final product is shown below:

IAM:

For the IAM part of the project, I had to create some IAM users and groups. I assigned the groups policies and then put each user into the group they belonged in following the principle of least privilege.

VPC:

For the VPC part of the project, I had to allocate an elastic IP address, create a VPC that looked identical to the diagram, create an internet gateway, create 4 subnets, create a public route table, and to create a private route table associated with the private subnets.

EC2

For the EC2 part of the project, I had to launch an EC2 instance into the second public subnet. The EC2 instance instance was of type t2.micro, had an Amazon Linux 2 AMI (HVM), and had an SSD volume. Auto Assign public IP was enabled, and there was some user data that started an apache web server. Furthermore, the it had a 17 GiB encrypted volume (type GP2 with 100 IOPS). The instance was in a web security group that allowed SSH and HTTP traffic. After the EC2 instance was up and running, I created an AMI of the instance and then created two new EC2 instances using that image. They were put into separate private subnets. I then made an application load balancer and specified the target group as the two EC2 instances in the private subnets.

RDS:

For the database part of the project, I was instructed to make a new RDS instance running on MYSQL. The first step was to create a DB subnet group called CU-Subnets that included the two private subnets. Then, I created the RDS database. It had a burstable db.t2.micro instance and a general purpose storage type. The database had a Multi-AZ deployment using the VPC already set up and the CU-Subnets subnet group.

EC2 Auto-Scaling

For 10 points extra credit on the project, we had the option to configure EC2 Auto Scaling behind our load balancer. I decided to do this option. Auto Scaling enables your architecture to scale up by add more instances as load increases, and then scale down by removing instances as load decreases. The launch configuration used the AMI I had created earlier. It used a target tracking policy that scaled up when CPU utilization was greater than 60% for 3 minutes.

AWS Academy: Cloud Architecting Capstone Project

The capstone project for the AWS Academy Cloud Architecting course was the last assignment you had to complete in order to obtain the badge for completing the course. It took a combination of the skills learned throughout the previous challenge labs in order to obtain a perfect score. Unfortunately, I do not have a diagram of what the final architecture looked like, but I will go into detail about what the project instructions were. For starters, here six main steps that needed to be completed:

1. Create an EC2 auto-scaling group from an existing launch configuration in the environment
2. Attach an application load balancer to the EC2 auto-scaling group
3. Create an RDS instance that the PHP application can query
4. Create a MYSQL database from a SQL dump file
5. Update application parameters in the AWS Systems Manager Parameter Store
6. Secure the application to prevent public access to backend systems

Setting up auto scaling

Setting up the auto-scaling group was fairly straight forward since the launch configuration was already defined in the environment. It was just a matter of picking the right AWS region and VPC and subnets to deploy the auto-scaling group in. The instances would be placed in 2 private subnets, each in a different availability zone. I set the minimum number of instances to 2, the desired amount to 2, and max amount to 4. It would scale up to when the CPU utilization was above 60% for 3 minutes.

Attaching an Application Load Balancer

An application load balancer spreads HTTP and HTTPS traffic across registered instances equally. After the EC2 auto-scaling group instances had passed their health checks, I created an application load balancer and then selected my auto-scaling group. Under the details tab, I selected load balancing->edit. I then clicked the check mark for application load balancer and selected the right target group. There was 1 already made in the lab environment. The application load balancer will take traffic from the public internet and then distribute the load across the EC2 instances in the private subnets. This ensures greater security.

Creating an RDS instance

Creating an RDS instance is pretty straight forward. First, I created 2 database subnet groups (the private subnet for each availability zone). Then, using the RDS wizard I made a RDS instance running MYSQL. I used a multi availability zone deployment and made sure that only the web application servers could communicate with the database instance.

Creating a MySQL database from a MYSQL dump file and Updating the Parameter Store

The pre-configured environment for the capstone project had a bastion host setup to access the EC2 instances in the private subnets. I gained access to one of the EC2 instances through the bastion host and then used it to run a mysql dump. The EC2 instance already had the mysql dump file in its home directory. The command was similar to this: mysql -h RDS_Endpoint -u username -p databasename < databasename.sql. This command setup the RDS instance with all the data the previous database contained. All that I had to to do now was make the EC2 instances read and write to the RDS instance instead of the old database. This was solved by changing the endpoint and password values in the parameter store. I then deleted the old database since it was no longer needed.

Securing the application

The last step was ensuring that the VPCs, security groups, and route tables were setup correctly. All internet traffic was to be go through the elastic load balancer, which would then distribute the traffic evenly between the EC2 instances. HTTP and HTTPS traffic from any source would be allowed. The bastion host would only accept SSH traffic from my IP address and have outbound rules to the EC2 instances. The EC2 instances would accept inbound traffic from the elastic load balancer and from the RDS instance. The RDS instance would only accept traffic from the EC2 instances and would only send information to the EC2 instances. The architecture was secure.