Highly Available WordPress on AWS

Highly Available WordPress on AWS

Highly Available WordPress instance

I have a few wordpress sites and I currently have them deployed in docker containers on a single host. I’m going to move these to AWS, migrate my data, test, and then switch DNS. This is a followup to this initial post and this page outlines the migration and Highly Available configuration in AWS.

Tools used

I want to keep everything simple so I’m going with terraform and userdata files to setup the environment and AMI instances.

AWS Components

Here’s a list of the components on AWS I KNOW I’m going to use.

Highly Available ALB
Highly Available ALB instance
  • EC2
  • EFS
  • ELB/ALB
  • EBS
  • RDS
  • Auto-Scaling Groups
  • CloudWatch

Configuration and Deployment

I’m not working out how best for YOU to deploy WP in a HA manner, so let me give you the rundown on how I’ll be deploying this. This post is mainly to illustrate some basic methods and usage of these AWS services. Always remember there’s more than one way to skin a cat.

I’m going to utilize EFS for shared storage between EC2 hosts, this is where wp-content and other shared data will go. NFS isn’t that fast so I really want to only link the wp-content here. I know WP has some S3 plugins and if I wanted to make this more robust I’d go that route.

I’ll use EC2 for docker hosts, I’m just going to make a single image and put that in an Auto-Scaling Group. This image will have all the docker instances I need running for each of my WordPress sites. I’ll spin up this EC2 instance and auto-mount the EFS, link to wp-content, and use docker-compose to spin up the wordpress instances. I currently run 4 wp sites and i don’t want 4 ELB/ALB so I’m going to throw up a HAProxy on the docker host to route traffic to the containers.

ASG Instance
Auto-Scale Group Instance

I’ll be using RDS which is pretty self explanatory. To get true HA make sure to turn this on in multi-AZ mode. I’m not doing that in my example because I don’t need full HA and I don’t want to spend the money on it.

First Iteration

This is my first iteration and I plan on changing a few things up. I built my AMIs by hand, I’d prefer to use packer next. I don’t have a test/dev environment so I’m basically winging it here. All data is backed up and stored in EFS so I’m putting a lot of trust on AWS. My docker use is mainly just because. The only benefit I get right now is that it was super simple to get a good docker image and then docker-compose up. ECS is too pricey for a small wp instance running 4 sites.

Lessons Learned

I’m not a huge fan of EFS, I think I’d get better mileage by taking AWS AMI snapshots of the WP instance before and after making updates. This would mean taking a snapshot before adding/removing content as well, but then I can follow a naming schema and make sure a launch configuration is always launching with a latest AMI of a certain name.

The WP upgrade is taking too long and taking my site down long enough for ALB to terminate the instance.

I need to start adding metric alarms and other monitoring which I’m going to have in my next post.

Using Terraform and AMIs worked out remarkably well besides building the AMIs manually, I’ll include some of this code in the next post as well.

Leave a Reply

Your email address will not be published. Required fields are marked *