Reference Architecture - Best Practices for WordPress on AWS

Reference Architecture

The Hosting WordPress on AWS reference architecture available on GitHub outlines best practices for deploying WordPress on AWS and includes a set of AWS CloudFormation templates to get you up and running quickly. The following architecture is based on that reference architecture. The rest of this section will review the reasons behind the architectural choices.



Reference architecture for hosting WordPress on AWS

Figure 2: Reference architecture for hosting WordPress on AWS

The reference architecture illustrates a complete best practice deployment for a WordPress website on AWS. It starts with edge caching in Amazon CloudFront (1) to cache content close to end users for faster delivery. CloudFront pulls static content from an S3 bucket (2) and dynamic content from an Application Load Balancer (4) in front of the web instances. The web instances run in an Auto Scaling group of Amazon EC2 instances (6). An ElastiCache cluster (7) caches frequently queried data to speed up responses. An Amazon Aurora MySQL instance (8) hosts the WordPress database. The WordPress EC2 instances access shared WordPress data on an Amazon EFS file system via an EFS Mount Target (9) in each Availability Zone. An Internet Gateway (3) allows communication between resources in your VPC and the internet. NAT Gateways (5) in each Availability Zone enable EC2 instances in private subnets (App and Data) to access the internet.

Within the Amazon VPC there exist two types of subnets: public (Public Subnet) and private (App Subnet and Data Subnet). Resources deployed into the public subnets will receive a public IP address and will be publicly visible on the internet. The Application Load Balancer (4) and a Bastion host for administration are deployed here. Resources deployed into the private subnets receive only a private IP address and hence are not publicly visible on the internet, improving the security of those resources. The WordPress web server instances (6), ElastiCache cluster instances (7), Aurora MySQL database instances (8), and EFS Mount Targets (9) are all deployed in private subnets.

The remainder of this section covers each of these considerations in more detail.