Migrated MariaDB to MySQL RDS and Hosted Wordpress on EC2 instance

Services Used

CloudFormation, EC2, CloudWatch, RDS, EFS, WordPress, Load Balancer, Auto Scaling Group.

Three-Tier Web Application Explanation

The three-tier web application have one public subnet and two private ones. The public subnet is hosting the EC2 instance with internet access while one private subnet is hosting the EFS for its storage, and the other private subnet for the database.

Diagram

This will be the final architecture throughout the project

CloudFormation Template

I used it to deploy all of the physical resources with one click deployment. And used automation to have the resources ready to use.

EC2 Instance hosting WordPress

Created an EC2 instance to host the WordPress database. I used the Amazon Linux AMI and the t2.micro type (because it is within the free tier).

I did not create a key pair, because I will use Session Manager to connect to my instance. I selected the HAWA VPC with the public subnet in availability zone 1a. And left the configuration for the storage as default.

For the advanced details, I chose an IAM instance profile with a role that has all of the permission policies for CloudWatch Agent, EFS, and Session Manager.

System Manager Parameter Store

I used it to save the parameters in it because it provides secure management of password and database strings. I created the parameters below:

Manually installation of WordPress

Now I will install WordPress in the EC2 instance. Running all of the commands below to bring the parameter store command values. And also installed all of the updates and prerequisites needed for the WordPress to work.

More commands to set the database and HTTPD server to run and start as default.

The following command help me download and install the WordPress packets.

Now with the next block of command I will configure the WordPress to use the values from the AWS System Manager Parameter Store that I set up earlier.

I created a blog post with a Coffee Shop (because we all love coffee). We a picture of the coffee my friend and I got from the AWS- IAD Café.

This metadata will be stored in the local MariaDB database. The application and database have been built manually in the same EC2 instance. Now all this process took a while, so I will automate the process by using a launch template. This helps to specify all of the details in advance to launch one or many instances.

The configuration is very similar to what I previously did with the last EC2 instance, but now I will add some user data to allow bootstrapping information to be saved there. Then, I added all the command I previously ran to configure the database and everything. The great thing now is that I am automating it by putting all of the commands in the user data of my launch template.

In this next step I am creating an EC2 instance from the launch template, and all the details will be prepopulated. Like the example below.

Migrating the MariaDB to RDS

I am created the DB subnet groups for the migration of the database which is in the DB tier in the private subnets. For this step I created a RDS with a MySQL engine database, and kept it within the free tier. I deployed it in the three availability zones. And made the database private and selected the private subnet.

Parameter Store

I have stored the database username and password stored in AWS System Manager Parameter Store to have those database strings within the service. That would allow the applications to retrieve settings automatically.

Migration

Now I will migrate the data to this new database. I still need to run some commands to load the data from the Parameter Store. And I copied the endpoint of the database to add it to the new endpoint parameter on the Parameter Store, so it can point to the DNS of the RDS instance.

Setting up the RDS Database
These commands help to restore the MariaDB database into RDS. And they also update to point it to the new endpoint parameter. MariaDB is not going to intent to start every time we try to access the WordPress post, instead it accesses the data from the RDS instance. Because these commands stopped it from doing so.

Setting up the RDS Database
These commands help to restore the MariaDB database into RDS. And they also update to point it to the new endpoint parameter. MariaDB is not going to intent to start every time we try to access the WordPress post, instead it accesses the data from the RDS instance. Because these commands stopped it from doing so.

I updated the launch template data and version, so it does not try to start the MariaDB in the EC2 instance.

Elastic File System

In this part, I will use EFS because it has the advantages of sharing files across availability zones.

Now I will use the EFS ID to store it in the Parameter Store. After that, there are some commands that need to be run in the EC2 instance, so that way it can connect to the EFS, mount and use it as its storage.

And because I have data already store in the EC2 about the WordPress application, it will be configured to use it.

Here I am mounting the file system onto the EC2 instance. After rebooting the instance with all of its configuration set up, the instance should have the EFS mounted. And now, the WordPress should have the wp-content running from the network file system.

Now this architecture is fully elastic because the WordPress application and the database live outside of the EC2 instance.

Now I updated the launch template with the EFS information it needed. As it is shown below.

I will make this architecture highly available by adding an elastic load balancer and auto scaling groups. So, they can do health checks, route traffic across AZs, and scale in or up as needed.

I created an application load balancer and a target group. Then, I added another parameter to the Parameter Store to use the DNS of the load balancer.

Now I will update the launch template, so it can use the DNS name of the load balancer and that way the WordPress application is not hard coded into the IP address of the instance. I added the DNS code to the user data.

And here are the extra commands added to be automatically launched from the template

The advantage of this is that I can now provision EC2 instances already configured and ready to run.

The following steps will be to set up the autoscaling groups to launch EC2 instance from the launch template every time the application has a high demand.

Auto Scaling Group

Here the auto scaling group will do the health checks

Dynamic Scaling Policy

Now I have set up a dynamic scaling policy with high and low CPU utilization so it can add or remove instances depending on the load if it goes above or below 40 percent with the help of CloudWatch metrics to monitor it.

I have run the stress command to increase the CPU utilization and cause the autoscaling group to launch another EC2 instance.

Here below we can see that the auto scaling group is working because there has been a high usage in the CPU utilization that has increased the load on the website.

Now the auto scaling is launching another instance because there is a high CPU utilization.

Standby Replica

I created a standby replica because if something happens to the primary database, the standby replica has failover capabilities.

Conclusion

This is the end of the project. I originally created one EC2 instance with a WordPress application and a MariaDB database to show how it was tightly coupled and then did a migration to make it more scalable. I used EFS as a shared storage across AZs, and then migrated the database from the instance to MySQL RDS. I added an application load balancer to distribute traffic across the three availability zones. Then, added the autoscaling group to scale up or down depending on the demand with the help of CloudWatch to monitor on the CPU utilization. Finally, I created a standby replica in a different AZ to make it highly available.