Wordpress on AWS

With a market share of 37% of all websites and 63% of all content management systems, Wordpress will often be the right choice to host your business or private website [1].

If you are looking for architecture examples on how to deploy Wordpress on AWS, I compiled a list of different proposals on how to deploy Wordpress on AWS for different needs:

  1. Production ready
  2. Small business
  3. Private blog

Production ready#

A cloud architecture that is capable to serve many users at once with a scalable, durable and highly available infrastructure [1][2][3]:

Diagram

Features

  1. Route 53 will be the DNS service which will link your domain and subdomains to the right CloudFront distribution.
  2. CloudFront is used as a CDN to cache static content and as a DDos protection for your Wordpress cluster. Static content like media files will be cached on edge locations in the CloudFront network to serve users content from a near location to reduce latency and load on the Wordpress cluster.
  3. The static content will be stored in Amazon S3 for a durable and highly available storage solution. The CloudFront distribution will link to the Amazon S3 bucket for all static content.
  4. EC2 instances running Wordpress will be deployed in a Auto Scaling group spanning over two Availability Zones in one Region. The Auto Scaling group will scale the amount of running instances based on the load on the Wordpress cluster. Every EC2 instance uses a shared Elastic File System (EFS) for the Wordpress installation files. The EC2 instances are in a private subnet and can not be reached directly over the internet.
  5. To make the EC2 instances in the Auto Scaling group accessible to the internet, at Application Load Balancer (ALB) is used. The ALB distributes the incoming traffic to the EC2 instances in the Auto Scaling group. The ALB needs to be deployed in a VPC with a Internet Gateway.
  6. Amazon Aurora is used as the MySQL database for all Wordpress instances. Every instance is connection the the Aurora Master DB. Whenever a failure occurs in the Master DB, the database is switched over to the Aurora Standby DB. As Aurora uses synchronous replication between the Master and the Standby node, no data is lost in the event of a failover.
  7. To cache frequently used database queries and dynamic assets, the Wordpress instances are using an ElastiCache Memcached Cluster. Wordpress and the W3 Total Cache plugin can be configured to use Memcached as a caching device.
  8. To provide internet access for the EC2 instances for updates on Wordpress and plugins, a NAT Gateway is deployed in both Availability Zones. The EC2 instances are not directly exposed to the internet, but can connect to the internet through the NAT Gateway in a public subnet.
  9. To get SSH access to the EC2 instances, a Bastion host in a public subnet is used. The Auto Scaling group for the Bastion hosts ensures that there are always enough instances running to connect to with SSH.

Disaster Recovery

This architecture is resilient against a failure of one Availability Zone. If one Availability Zone fails, the traffic will be routed to the other Availability Zone without downtime.

The architecture is not resilient against a failure of the entire AWS Region. Disaster Recovery strategies for a region failure can be:

  1. Backup & Restore

    A backup of the database and the EFS files has to be stored in a different region. Using a Cloudformation template, EC2 AMIs, the backup database snapshot and the EFS backup files a replication of the infrastructure an be deployed in a backup region. After the new stack in the backup region is running, the CloudFront distribution and DNS service will be updated to point to the new Application Load Balancer.

  2. Pilot light

    A similar infrastructure to the main region is deployed to a different region. In the new region no EC2 instances are running, but everything else is ready to go. The database is continuously replicated to the backup region with the Amazon Aurora Global Database Service. The EFS files are continuously replicated to the backup region using AWS DataSync. In the event of a failure of the main region, the Auto Scaling group will spin up EC2 instances in the backup region and CloudFront and Route 53 will direct traffic to the new region. This solution has a better recovery time objective (RTO), as most services are already running. This solution also has a better recovery point objective (RPO), as the data is continuously replicated and not only at predefined snapshot times.

  3. Warm standby

    This strategy is similar to Pilot light with the difference that some EC2 instances are already running. With no time to boot up the EC2 instances, this solution has a better RTO as Pilot light.

  4. Multi-Site

    This strategy is similar to Warm standby, but instead of switching the region at a failure event, CloudFront and Route 53 will route traffic to both regions all the time. The health checks in Route 53 will automatically detect a failing region and redirect the traffic to the remaining region. At normal operation times, different routing policies can be used, to serve users content from specific regions.

Small business#

A cloud architecture for a small business website with less scalability, availability and durability.

Diagram

To save costs on features that are not needed for the use case, you have the option to save money with these measures:

  1. No ElastiCache Memcached Cluster for caching database queries and dynamic content. A local installed version of Memcached or caching to disk can be enough in a lot of use cases.
  2. Amazon RDS instead of Amazon Aurora. RDS can be used as a managed database service which provides similar features to Amazon Aurora but with less availability, durability and speed. RDS is still a good choice for a lot of use cases.
  3. No second Availability Zone. This architecture will be not resilient against a Availability Zone failure, but disaster recovery strategies can be used get the Wordpress cluster running again in a different Availability Zone.
  4. To connect to the EC2 instances, only one Bastion host without a Auto Scaling group will be used.

Private blog#

A cloud architecture for a Wordpress site in development or a private blog without any business critical parts.

Diagram

A simple way to host a Wordpress site on AWS:

  1. The Wordpress EC2 Instance uses EBS instead of EFS for all data.
  2. Instead of a Auto Scaling group only one EC2 instance is used. This instance is sized to fit the needs of the website traffic. To scale the website on increased traffic, EC2 instance types with burst modes like T2 and T3 can be used. For permanent scaling a snapshot of the EC2 instance’s EBS volume can be used to create a more powerful EC2 instance.
  3. The Wordpress database is hosted on the same EC2 instance as the Wordpress installation. Backups of the data are made with EBS snapshots.
  4. The EC2 instance is accessible through the internet. A SSH connection will be made directly to the instance.
  5. No load balancer is need as there is only one EC2 instance.

Sources#

  1. https://kinsta.com/wordpress-market-share/
  2. https://github.com/aws-samples/aws-refarch-wordpress
  3. https://aws.amazon.com/marketplace/pp/B07PW4R98M
  4. https://d0.awsstatic.com/whitepapers/wordpress-best-practices-on-aws.pdf