From Single Instance to Scalability: My AWS Adventure with WordPress

Introduction

When I first started exploring AWS, I set up a WordPress site using a LAMP stack on a single EC2 instance. It was a great learning experience, allowing me to experiment with Let’s Encrypt SSL certificates, Elastic IPs, and Route 53 for DNS management. However, as I delved deeper, I realized the setup lacked in two critical areas: security and fault tolerance. Eager to expand my AWS knowledge and skills, I embarked on a journey to build a more secure and fault-tolerant architecture.

AWS Services Used and Their Roles

In my quest to enhance my setup, I employed several AWS services, each playing a pivotal role:

1. Amazon EC2 (Elastic Compute Cloud) – Hosts the web servers for WordPress. EC2 instances provide the compute capacity, making it the backbone of the setup.
2. Amazon RDS (Relational Database Service) – Manages the WordPress database. RDS offers high availability and security for the database, crucial for any dynamic website.
3. Elastic Load Balancing (ELB) – Distributes incoming application traffic across multiple targets, such as EC2 instances. This ensures reliability and fault tolerance.
4. Amazon EFS (Elastic File System) – Provides a simple, scalable file storage for use with Amazon EC2. EFS is critical for centrally managing WordPress files.
5. Amazon Route 53 – A scalable and highly available Domain Name System (DNS) web service, used for effectively connecting user requests to infrastructure running in AWS.
6. AWS S3 (Simple Storage Service) – Offers backup storage. It’s essential for safely storing and retrieving key data like the WordPress files and database backups.
7. AWS Certificate Manager (ACM) – Handles the SSL/TLS certificates, providing secure connections to the WordPress site.
8. Amazon Virtual Private Cloud (VPC) – Delivers a logically isolated section of AWS where AWS resources can be launched in a defined virtual network.

Here is a look at the Highly available Architecture and its flow of traffic:

Migration Steps and Learning Curve

You can download the user guide I created at the following link:

https://jordansuserguidebuck.s3.ca-central-1.amazonaws.com/Guide+to+migrating+LAMP+to+HA+set+up2.pdf

Step 1: Deploying the ELB and Configuring ACM

I began with deploying the ELB to manage incoming traffic and used ACM for SSL/TLS certificates. This setup replaced the previous Elastic IP approach, marking the first significant enhancement in my architecture.

Step 2: Configuring WordPress for HTTPS

• With the original Ec2 deployment, I faced challenges with “too many redirections” when transitioning to HTTPS, commonly caused by conflicting redirection settings at the Apache server level. Following the advice from Lawrence Mcdaniel’s blog (https://blog.lawrencemcdaniel.com/wordpress-aws-elb-ssl/), I successfully resolved this by configuring HTTPS redirection in WordPress’s wp-config.php file, which proved to be more efficient for your setup at that time.
• With the establishment of an AWS Elastic Load Balancer (ELB), I now have the option to handle HTTP to HTTPS redirections at the ELB level, using an HTTP listener rule. This method offers a centralized and streamlined approach. However, if WordPress-level redirections are still required for specific use cases, those steps are detailed in the user guide I provided.

Step 3: Migrating Database to RDS

Moving the database to RDS was a learning curve for me. It involved exporting the database from the EC2 instance and importing it into RDS. This not only improved the database’s security but also its availability.

Step 4: Configuring EFS

EFS played a crucial role in centralizing WordPress files. I mounted it to the /var/www/html/ directory on my web servers, creating a single, unified file system accessible to both EC2 instances.

Step 5: Deploying the Second EC2 Instance

Creating an AMI of the original instance and deploying it in a different Availability Zone was a step towards achieving high availability. This ensured that even if one instance goes down, the other keeps the site running.

Step 6: Testing High Availability

The final step was testing. I simulated failures to ensure that the setup could handle real-world scenarios, like instance failures, without downtime.

Takeaway

This project was not just about building a more robust system; it was a journey of learning and growth. Through each step, from configuring load balancers to managing databases, I enhanced my understanding of AWS services. It was a hands-on experience that solidified my knowledge in cloud architecture and high availability setups.

Migrating to a high availability architecture on AWS has been an enriching experience. It’s not just about the technical skills acquired but also about understanding the importance of scalability, security, and reliability in the cloud. The next steps in my journey are quite exciting. I plan to delve deeper into implementing advanced security features, setting up comprehensive monitoring and auditing systems, and exploring the potential for a migration to Amazon ECS (Elastic Container Service) for even more scalable and efficient deployment. These endeavors will not only enhance the security and performance of my current setup but also provide valuable insights into the ever-evolving world of cloud computing. I’m eager to continue this journey, exploring more complex architectures and innovative solutions in AWS.