WordPress on AWS, begrudgingly

WordPress and AWS have a lot in common. They are both insanely popular, very accessible, and even launched within a year of each other. They are both very easy to get started with and even easier to get tangled up in complexity if you’re not careful. What follows is an overview of what it takes to run WordPress on AWS if you so choose to.

General Advice

Don’t do it

A bit of background about myself. I have a lot of WordPress experience, I’ve created sites, written plugins, and developed themes. I’ve run WordPress on single servers and deployed massively autoscaling and highly available container based solutions. I’ve deployed sites and multi-sites for family members and large enterprises. I even architected the original infrastructure for WP-Tide

This is why the site you’re on now is hosted on WP Engine.

The reason is that self-hosting just isn’t worth the time and hassle. WordPress is so huge at this point that companies that can host it for you are mature, affordable, and have all the features you need. There are a few good reasons for hosting on AWS however.

1. You must – Orders from above or something. It’s not your decision but you still need to implement it. This is where I get my experience from.
2. Your scale is huge – Maybe you work for a massive company and your site takes in billions of hits a day. Maybe you have an enterprise discount with Amazon that gives you dirt cheap EC2 instances. I’d still go with Pantheon but if you’re at an enterprise and the one building it then reason 1 probably applies here as well.
3. You want to – You really don’t care about cost or headache because you’re planning on hosting this on a server for fun, or maybe you want to learn AWS. Great!
4. You have some really custom stuff going on – If you need direct control of the underlying VMs, if you have modified the core, or if this needs to be on your network then your only option may be to self-host.
5. It’s dev – Ok fair enough, if you’re a WordPress developer and need to constantly spin up dev instances for a few min then yeah go and self-host.
6. You’ve already been at it for a while and it would look bad if you gave up now.

You’ll notice that saving money isn’t on here. Once you add in things like VPCs, managed NATs, Load balancers, patch management, backups, and employees’ time self-hosting rarely saves you money.

If you’re going to do it anyway, keep it as simple as you can

If you’re going to self-host on AWS try to at least be boring about it. I’ve seen people (including myself) get very excited about best practices. It feels good to build something right. To build it scalable, to automate everything. However… In this case, I’d recommend doing it simply. Don’t think about a massively scalable docker based system or building the entire thing to self bootstrap (I’ve done both). What you should be focused on is getting a single server that patches and is easy to restore if something happens. If you need to scale, you just make it bigger.

Comparing Approaches

Single Web Server

If at all possible try to keep it to a single web server. You can always decouple the database for additional scaling and control but remember that WordPress wasn’t designed to run on multiple web servers. AWS offers very large compute instances so in all likelihood a single server will almost always give you enough power for your site.

Lightsail

Lightsail is Amazon’s version of Digital Ocean. It’s comparable in cost and has the option to convert whatever you transition to “real” AWS when you’re ready. If the goal is to “self-host on AWS” congratulations this is it. You can get up and running in just a few minutes and because it’s Lightsail you don’t need to worry about hidden charges. Once it’s up and running make sure you enable unattended-upgrades for OS level patching (you’ll still need to update WordPress separately) and enable snapshots. The best way to get started is by using the wizard, you can find a video guide and resources here:
https://aws.amazon.com/lightsail/projects/wordpress/

EC2

If you have special networking needs, or already know AWS pretty well and want it integrated into your environment then you can just build it in EC2. You can either use an AMI from the marketplace to get started or just install it yourself. If going this route and you want to “scale” I’d recommend also setting up an RDS database. You can add a load balancer for SSL termination and have AWS automatically rotate the certificates for you and make sure you enable scheduled AMI and/or RDS snapshots for backups. For OS patching you can use either unattended-upgrades or AWS patch manager. A benefit of this method is that it can be pretty well automated with CloudFormation. Such as with this AWS Labs template:
https://github.com/awslabs/aws-cloudformation-templates/blob/master/aws/solutions/WordPress_Single_Instance.yaml

Multiple Web Servers

You almost certainly don’t need this and it will lead to problems both with the core application and with many plugins. WordPress was always designed to run on one server and backwards compatibility is a core principle of its development. Here are a few things to consider:

• Complexity; instead of storing files and session information locally, you’ll need to create a way to do both. This looks easy on a whiteboard but implementation is hard and requires changing a lot of things you didn’t know existed.
• Updates and upgrades will be harder, everything needs to write to the right place, refresh properly, and be coordinated. Upgrades will be harder. You”ll probably need a dedicated admin node.
• Cost: this will add a lot more resources
• Plugins and themes will break; oftentimes developers assume that their software runs on single server implementations. Though it’s possible to make plugins that work fine otherwise many don’t support it since the market is not large enough.
• You’ll be on your own. WordPress has a fantastic community with a lot of people sharing knowledge, the amount of people doing a multi-server setup on the other hand is very small and usually limited to larger companies that don’t share externally as much.

If you want “multi-az” for reliability reasons then consider that this setup will almost certainly lead to more downtime due to errors and unexpected behavior.

If you’re doing this for performance reasons just remember that a single web server can handle a lot of traffic if it’s big enough. Unless you’re serving billions of requests you probably don’t need it. If your site is slow and you’re reading this article because someone at Amazon told you this is the “best” solution. Take a step back and read this article first:
https://wordpress.org/support/article/optimization/

Elastic Beanstalk

This is the old standard, Amazon has a bunch of labs and tutorials for how to do it. If you need to go multi-server this is a good place to start:
https://aws.amazon.com/getting-started/hands-on/build-wordpress-website/

Custom solution

This would probably make a good standalone article. However, if you’re going to be building this yourself here are some pointers:

• Use Amazon EFS for the WordPress directory. You’ll get a bit of a performance hit but it will make upgrading easier and hopefully mitigate any plugin compatibility issues.
• Create a dedicated Admin Node, this will be used for all uploads, database updates, and upgrades… it can be smaller than your other nodes.
• User uploads (if needed) should go to S3, use a plugin to make this happen. Otherwise, the user experience should be read-only
• You can set up AutoScalling on EC2, or use ECS. Although there’s really no reason to containerize this. This isn’t micro-services and you’re not going to be constantly redeploying the application.
• Terminate SSL at the load balancer. This will get WordPress confused on whether its getting encrypted traffic or not. Set the following in your wp-config.php file

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

So there you have. In short, it’s cheaper, easier, and more stable to pay someone else to host for you. If you still want to self-host do it on a single VM or with at most a separate database server. If you want to be more complicated than that review the tips and good luck!