Create a Highly Available WordPress Web Application : AWS Project

AWS Project: Create a Highly Available WordPress Web Application

Introduction

This project focuses on designing a resilient, scalable WordPress web application on AWS. Using key AWS services like Amazon VPC, Amazon RDS, Amazon EFS, EC2, and Application Load Balancer (ALB), it establishes a robust architecture that ensures high availability, scalability, and fault tolerance for a WordPress site, making it suitable for high-traffic applications.

By deploying WordPress in a multi-tier architecture, I learned how to leverage AWS infrastructure to meet the needs of high-traffic applications, ensuring both availability and fault tolerance.

Tech Stack

• Amazon VPC: Provides isolated network environments and security controls.




• Amazon RDS: Hosts a reliable, highly available MySQL database for WordPress.




• Amazon EFS: A scalable, shared storage solution for dynamic content, enabling multiple EC2 instances to access the same data.




• Amazon EC2: Hosts WordPress instances and dynamically scales with Auto Scaling groups.




• Application Load Balancer (ALB): Distributes incoming traffic across multiple instances for enhanced availability.

Prerequisites

• AWS Account: Required to access and configure AWS services.




• AWS CLI: For resource management and deployment tasks.




• Basic AWS Networking Knowledge: Understanding of VPCs, subnets, and security groups.




• WordPress Setup Knowledge: Familiarity with WordPress installation and configuration.

Problem Statement or Use Case

Problem: WordPress applications often face challenges around scalability and availability, especially with traditional hosting environments where capacity may not automatically adjust to traffic demands.

Solution: Using AWS, this project demonstrates how to set up WordPress in a highly available, scalable architecture that can handle fluctuations in traffic and ensure minimal downtime. AWS’s managed services enable the environment to scale automatically, handle failover, and improve the user experience.

Real-World Relevance: This approach is ideal for production-grade WordPress applications with high traffic, such as e-commerce sites, news platforms, and corporate blogs. By implementing this architecture, companies can reduce manual management, lower costs, and improve their WordPress application’s reliability and speed.

Step-by-Step Implementation

Configure the network

After creating the VPC, on the VPC details page click on Actions and then select Edit VPC Settings.

Make sure to enable both DNS resolution and DNS hostnames under DNS Settings and click Save.

Once the VPC has been created, the next step is to create the subnets that will be used to host the application across two different Availability Zones. We are going to create six subnets in total, three for each AZ, as shown in the following diagram:

The screenshots in this lab were taken from a deployment in the Ireland (eu-west-1) region, if you are building in a different AWS region please just ensure that you create your subnets in 2 different availability zones in the same region, such as us-west-2a and us-west-2b.

For each subnet specify a name and a CIDR range for the subnet. Be sure and create a public, application, and data subnet in each of two availability zones as detailed in the table below.

The following steps will allow connectivity from the Internet to the public subnets and also connectivity from the private subnets to the Internet via NAT gateways.

First you need to create a new Internet Gateway (IGW) from your VPC dashboard and attach it to the wordpress-workshop VPC. Start by clicking Internet gateways on the left hand side of the VPC console and then click the Create Internet gateway button. Enter a name for your IGW such as WP Internet Gateway and click Create Internet gateway.

The gateway will be used by instances and services running in the public subnets (e.g. Public Subnet A and Public Subnet B) to communicate to the Internet.

Once the gateway is created you will need to create a new routing table and associate it with the public subnets.

Create a new route table by selecting Route tables in the left-hand menu of the console and then clicking on the Create route table button.

Give it a Name and select the wordpress-workshop from the drop-down, then click on Create route table.

Finally, you need to associate the newly created route table with the public subnets. To do that, click on the public route table, then click on Subnet Associations, edit by clicking on Edit subnet associations and select the two public subnets created earlier and click on Save associations.

The Wordpress instances will need to be able to connect to the Internet and download application and OS updates. To avoid dependencies across Availability Zones, you are going to create two NAT gateways, one for each Availability Zone where the application is deployed.

To do this, you will create one NAT Gateway in each Availability Zone, then create one route table for each application subnet, update the route table with a default route through the NAT gateway in the same AZ, and then associate the route table to the respective application subnet.

Now we need to create route tables for each of the two Application subnets and use the NAT gateways created earlier as the default gateway:

Associate the route table with Application Subnet A:

You have now created a virtual private cloud network across two availability zones within an AWS region. You have created six subnets, three in each availability zone, and have configured a route so that the Internet can communicate with resources in the public subnets and vice versa. The application subnets have been configured, via routing table, to communicate with the Internet via NAT gateways in the public subnets, and the data subnets can only communicate with resources in the six subnets, but not the Internet.

Please note that the information below is based on a VPC deployed in the Ireland (eu-west-1) region. If you had choosen a different region for your setup you need to adjust the region name accordingly.

You can compare your own configuration based on the screenshot below and move along when you have verified your setup.

Check the Resource map section of your VPC which shows your VPC, subnets, route tables, Internet gateways, NAT gateways which helps you visualise the resources.

You will create 2 security groups:

• WP Database Clients will be attached to the EC2 instances running the web servers




• WP Database will be attached to the RDS DB instance

Visit the

Now create the WP Database security group:

• In the Inbound Rules section, click on Add rule




• Select Type MySQL/Aurora which allows traffic on port 3306 from Custom source WP Database Clients security group.

Amazon RDS is an easy to manage relational database service. When you use Amazon RDS to deploy a database in a highly available setup, it will create 2 instances in 2 different availability zones. To do this, when you create a database you specify a subnet group which tells RDS in which subnets it can deploy your database instances.

To create a DB subnet group browse to the

Scroll down and add the two Data subnets created earlier (one for each AZ) to your new subnet group and click Create.

of the VPC console. From the list of subnets select the one you are interested in. On the bottom of the screen you will then be able to copy the Subnet ID by clicking the Copy to clipboard icon beside the id.

, select Databases **from the menu on the left and click **Create database.

Enter the following details:

• Database creation method: Standard create




• Engine options: Aurora (MySQL Compatible)




• Keep the default Engine Version

Select the DB instance size together with a Multi-AZ deployment, required for high availability. To keep costs low, for this workshop we recommend using a burstable instance class (db.t4g.medium or similar). Burstable instances might not be suited for production environments.

Expand Additional configuration section and specify an Initial database name of wordpress.

The active / passive database should now be available and running in two different availability zones, waiting for connections from any EC2 resource with the client security group associated to it.

Please compare your own configuration based on the screenshots below and move along when you have verified your setup.

Security Groups

Database setup

When using Amazon EFS, you specify Amazon EC2 security groups for your EC2 instances and security groups for the EFS mount targets associated with the file system. A security group acts as a firewall, and the rules that you add define the traffic flow.

In this workshop, you will create 2 security groups:

• WP EFS Clients will be attached to the EC2 instances running the web servers




• WP EFS will be attached to the EFS mount targets

Visit the

Amazon EFS creates a shared file system and exposes it as a NFS share. The security group attached to the EFS mount points will need to allow inbound connections on the NFS TCP port 2049.

Create the WP EFS security group:

• In the Inbound Rules section, click on Add rule




• Select Type NFS and specify Custom source WP EFS Clients security group.

To create an EFS file system visit the

On the creation page, uncheck Enable automatic backups to avoid backing up the contents of the file system. It’s recommended to keep it enabled when deploying a production environment.

Keep all other settings unchanged and click Next.

Accept the defaults on the next screen for File system policy

Build the Application Tier

Create the load balancer

To distribute traffic across your Wordpress application servers you will need a load balancer. In this lab you will create an Application Load Balancer.

Application Load Balancer operates at the request level (layer 7), routing traffic to targets (EC2 instances, containers, IP addresses, and Lambda functions) based on the content of the request

to create the security groups.

First, create the WP Load Balancer security group:

• Click on Create security group




• Fill in the Security group name and Description fields




• Select the wordpress-workshop from the drop-down




• In the Inbound Rules section, click on Add rule




• Select Type HTTP which allows traffic on port 80 from My IP source to limit access to your current public IP.




• Scroll to the bottom of the page and click on Create security group

Outside of a workshop environment you would likely want to modify the security group to allow access from any IP address. To learn more about security in and of the cloud please visit the

Now create the WP Web Servers security group:

• In the Inbound Rules section, click on Add rule




• Select Type HTTP which allows traffic on port 80 from Custom source WP Load Balancer security group.

A load balancer distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones, increasing the availability of the Wordpress platform.

From the

Give your load balancer a name and under Network mapping select the wordpress-workshop VPC.

Then tick the checkbox for both availability zones and select the public subnets created in the first lab.

Under the Security groups select the WP Load Balancer created earlier and remove any default security group.

This opens a new window for you to create a new target group. Use the following details

• Wordpress-TargetGroup as Traget group name




• wordpress-workshopas VPC

Click on Next and then on Create target group without defining any targets.

In the Summary section, review and click Create load balancer to create the load balancer.

Make a note of the DNS name created for your load balancer as you will need this in the following steps.

Create a launch Template

You have created a software-defined network across multiple fault-isolated Availability Zones, deployed a highly-available Aurora MySQL database and an EFS file system for shared storage. In this lab you will define the templates for the application servers running PHP as part of a scalable Wordpress installation.

, then click on Create launch template.

• Give the Launch template the name WP-WebServers-LT

• Select the t3.micro instance type:

Expand Advanced details and use the script below to populate the User Data field as text.

.

DB_NAME

This is the name of the database which Wordpress should use to store its data. If you entered the default values in Lab 2 this should be a value of wordpress. To confirm visit the details page for your RDS database and look for DB name under Configuraiton.

DB_HOST

This is the hostname of your database Writer instance. To obtain this visit the details page for your RDS database and look under Connectivity & Security. Use the Writer type instance hostname, a value such as wordpress-workshop.cluster-ctdnyvvewl6s.eu-west-1.rds.amazonaws.com.

DB_USERNAME

This will be the database username you specified in Lab 2. It can be found as Master username under Configuration on the details page for your RDS instance.

DB_PASSWORD

This is the password for the database user created in Lab 2.

CODE Kopieren

    #!/bin/bash



    DB_NAME="wordpress"

    DB_USERNAME="wpadmin"

    DB_PASSWORD=""

    DB_HOST="wordpress-workshop.cluster-xxxxxxxxxx.eu-west-1.rds.amazonaws.com"

    EFS_FS_ID="fs-xxxxxxxxx"



    dnf update -y



    #install wget, apache server, php and efs utils

    dnf install -y httpd wget php-fpm php-mysqli php-json php amazon-efs-utils



    #create wp-content mountpoint

    mkdir -p /var/www/html/wp-content

    mount -t efs $EFS_FS_ID:/ /var/www/html/wp-content



    #install wordpress

    cd /var/www

    wget https://wordpress.org/latest.tar.gz

    tar -xzf latest.tar.gz

    cp wordpress/wp-config-sample.php wordpress/wp-config.php

    rm -f latest.tar.gz



    #change wp-config with DB details

    cp -rn wordpress/* /var/www/html/

    sed -i "s/database_name_here/$DB_NAME/g" /var/www/html/wp-config.php

    sed -i "s/username_here/$DB_USERNAME/g" /var/www/html/wp-config.php

    sed -i "s/password_here/$DB_PASSWORD/g" /var/www/html/wp-config.php

    sed -i "s/localhost/$DB_HOST/g" /var/www/html/wp-config.php

#change httpd.conf file to allowoverride

# enable .htaccess files in Apache config using sed command

sed -i '//,/<\/Directory>/ s/AllowOverride None/AllowOverride All/' /etc/httpd/conf/httpd.conf

CODE Kopieren

# create phpinfo file

echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php



# Recursively change OWNER of directory /var/www and all its contents

chown -R apache:apache /var/www



systemctl restart httpd

systemctl enable httpd

Review the final configuration under Summary and click Create launch template. You can disregard warnings about being able to SSH into the server and can also choose Proceed without keypair as you will not need to remotely access these servers.

Create the app server

In this lab you will use the load balancer and launch configuration from the previous 2 labs to create an auto scaling fleet of Wordpress application servers.

In the next screen make sure that the wordpress-workshop VPC is selected, together with the Application Subnet A and Application Subnet B subnets for the web servers:

In the Health checks section, make sure to Turn on Elastic Load Balancing health checks.

Click through and accept the remaining defaults to complete the creation of Auto Scaling Group by clicking on Create Auto Scaling group.

The autoscaling group will now begin creating the desired number of EC2 instances based on the launch template you created. As the systems come online, the target group is updated with the instance details for your EC2 instances and the load balancer will begin distributing traffic across the instances. As instances are added or removed, the autoscaling group and load balancer will work in concert with one another to ensure that only healthy instances receive traffic.

Go to the Auto Scaling Groups section of the EC2 Console, select the Autoscaling Group created in

, open the Actions **menu and select **Delete load balancer. To confirm deletion, type confirm in the text field of the dialog that will open and click Delete.

Go to the Target Groups section, select the Target Group created in

, open the Actions menu **and select **Delete template.

To confirm deletion, type Delete in the field and click Delete

Once you delete the Auto Scaling Group, the instances will begin shutting down and eventually they will be terminated. Verify that all instances launched by the Auto Scaling Group have been terminated correctly.

You can use the aws:autoscaling:groupName attribute to filter instances launched by the Auto Scaling Group created in

, select the wordpress-workshop ***Regional cluster *and click **Modify.

Scroll to the bottom of the page, unckeck Enable deletion protection and click on Continue

1. On the
   
   
   
   
   

   1. Now select the Writer instance, go to the **Actions* menu and select Delete.
      
      To confirm deletion, type delete me into the field and click Delete.

   
   

   2. You can delete the Regional cluster now. Select it, go to the Actions menu and select Delete.
      
      Make sure to

   
   
   
   
   
   
   

   • uncheck Create final snapshot

   
   

   • check the acknowledgement

   
   
   
   
   

   To confirm deletion, type delete me into the field and click on Delete DB cluster

   
   
   

   
   

Once the RDS Aurora Cluster has been completely deleted, move to the

Go to the and click Delete.

Confirm the deletion by entering the file system’s ID in the dialog that will appear and click Confirm.

page of the VPC Console, select one NAT Gateway at a time, go to the Actions **menu and select **Delete NAT gateway.

To confirm deletion, type delete in the field and click Delete

Select the wordpress-workshop VPC from

You will be able to delete the VPC only if no network interfaces are still present in any of the subnets of the VPC. The dialog that will appear when you click on Delete VPC will show any remaining ENIs.

page of the VPC Console, select all unassociated Elastic IPs (Association ID *value is -), open the **Actions **menu and select **Release Elastic IP addresses*.

If you created the workshop-user IAM User to follow the workshop labs, make sure to delete it from the

Challenges Faced and Solutions

• Database Connection Issues: When setting up RDS, there were some configuration issues with access control.




• Solution: Adjusted VPC security groups and ensured that EC2 instances had the correct permissions to access RDS.




• WordPress File Management: Managing WordPress media files on multiple instances was initially challenging.




• Solution: Implemented Amazon EFS as a shared file system, enabling seamless media management across instances.

Conclusion

This AWS project demonstrates how to create a highly available, scalable WordPress environment, ideal for production-grade sites with high traffic. It showcases AWS’s capabilities in managing infrastructure to minimize manual intervention while maximizing uptime.

Explore my ,