Or why you should pick the right tool for the right job
A number of past clients ask me to automate and configure WordPress on AWS (And a ton of potential clients ask the same). After architecting a number of AWS WordPress solutions, I feel pretty comfortable going over why I advise against their union in the vast majority of cases.
Let’s dig in to why WordPress is often a poor choice for AWS and situations where it may be a good fit.
Short note: This isn’t a hit piece on AWS or WordPress. AWS is an excellent tool, as is WordPress (This website is WordPress based. Surprise!) but unfortunately, they are not tools that often perform well together (though there are exceptions).
Why WordPress is (generally) a poor fit for AWS
Load Balancing
Let’s start with the most important reason first: WordPress was and still is ill suited for load balanced situations as it simply wasn’t designed with these concepts in mind. This is especially true for situations with dynamic scaling (I.E Using EC2 Autoscaling Groups)
WordPress has a good deal of assets and functionality that rely on the Web Servers flat file system for storage (Such as the plugin, theme, and media files).
Let’s do a quick thought experiment.
You have two web servers with WordPress installed behind a load balancer and backed by RDS.
You login to the WordPress admin page and decide to install a theme. You click install on the theme and when you did so, the Load Balancer was communicating with Server A.
Sometimes when you access the site everything works correctly and other times it doesn’t. Why?
Spoiler: WordPress only installed the theme on the Server A, leaving Server B without the proper theme files installed.
For context, the initial release of WordPress was over 15 years ago (It’s 15th anniversary was yesterday. Congrats WordPress!).
It was created in a time where public cloud providers like AWS, Azure, and Google Compute were years from creation and most webmasters would never touch (or possibly even know about) concepts like Load Balancers.
One of AWS’s greatest strengths is it’s high level of scalability (in particular the possibility to automate this scaling). Scaling cleanly is not easily accomplished (one may even argue impossible) without the ability to horizontally scale your application.
Scale
Now it’s hard to blame this one on WordPress but it’s still an important factor when deciding to host AWS on WordPress.
Your idea of “a lot of traffic”, probably isn’t a lot of traffic.
If you have a website with only a few thousand to the low hundred thousands of hits a day, it is almost a guarantee that you shouldn’t be hosting your website on AWS. You won’t really have the traffic to leverage AWS’s biggest weapon (As mentioned earlier, SCALABILITY!)
AWS is a product meant to scale websites up to hundreds of thousands to millions of hits or more. While a scalable solution can also be performant (I.E Fast) that isn’t always the case.
Confused about the difference? You can read a follow up here.
Price
People are told that AWS can save them a lot of money. For the right customer with the right solution (Read: properly architected) that makes heavy use of auto scaling, AWS is likely to save a great deal of money.
If you attempt to utilize AWS like a traditional VPS or Dedicated Server provider you’re likely to find that AWS can be very, very, very, expensive.
For the price, AWS is generally going to offer far worse performance per dollar than an equivalent solution on Digital Ocean, Vultr, or even a good old fashioned dedicated server.
If you look at the above comparison, pay particularly close attention to last section where the DO solution is significantly superior (sustained performance).
Aside from cost of the EC2 instances, some of the solutions in our mitigation section also have significant price tags attached.
So when is AWS the right choice for WordPress?
There are a few check marks I like to tick off before going “Alright, AWS may be the right choice” when working with WordPress.
- The client has a site with a large amount of traffic (Hundreds of thousands plus+).
- The client has very spiky traffic (Periods of very high usage followed by periods of very low usage)
- The client is expecting to see a very large permanent increase in traffic in the near future.
- The client is either willing to make changes to how they manage their site (Largely forgoing the use of the admin panel for tasks like plugin and theme installation) or is willing to take a significant hit to their pocket book with certain mitigation strategies.
- The client intends to make good use AWS scalability features.
- The client requires (or at least wishes to have) a high availability configuration.
- The client intends to make significant use of AWS products such as RDS, IAM, S3, Cloudfront, and others.
In cases where the client meets all or some of the above criteria, AWS may be worthy of consideration for their particular case.
Summary
AWS and WordPress are both terrific products that have their place but heavy consideration should occur before deciding to bring the two together.
In a future article, I’ll go over the pro’s and con’s of various strategies for Load Balanced and Highly Available WordPress deployment on AWS. Stay tuned!
If you’re looking to contract with an experienced Automation Engineer/Linux Sys Admin, I hope you won’t hesitate to schedule a short meeting to talk about how I can help.
You can easily schedule a meeting below or by clicking the blue button at the bottom right.
Want to understand how I can help? Take a look at my article here.
Till next time.
9 comments
Breno Rocha Uchôa
May 28, 2018 at 7:10 pmYou should search about efs…
Robert Tisdale
May 29, 2018 at 3:41 amHowdy Breno,
EFS is one of the possibilities that will be covered in the next part of this article.
EFS has it’s own issues including high latency and high cost. This leads to a solution that might be scalable but isn’t particularly performant or cost effective.
Sean Hull
June 4, 2018 at 9:49 amGreat article. I agree about the complexity.
I host myself, as an ongoing project to hone my devops skills & practice automating all the things. 🙂
For that it works quite nicely, *because* it’s complicated.
Robert Tisdale
June 4, 2018 at 11:05 amExcellent point! It’s a good idea to handle some of these things on your own just to see how they go down.
Anything to share that you’ve found out while working with it?
Let me know if you ever do a write up :).
Sean Hull
June 4, 2018 at 4:04 pmYes. I did blog about this in fact:
Deploy WordPress on AWS by first decoupling assets
https://www.iheavy.com/2016/10/17/deploy-wordpress-on-aws-by-first-decoupling-assets/
How I use Terraform & Composer to automate wordpress on aws
https://www.iheavy.com/2016/10/17/terraform-wordpress-composer-on-aws-deployment-automation/
Robert Tisdale
June 4, 2018 at 4:25 pmVery cool. I have these opened and will be taking a look tomorrow (about midnight where I’m at now).
Heads up, the first image on each of these posts isn’t 404ing but they don’t seem to display on the post.
Sean Hull
June 4, 2018 at 6:10 pmThx. Yeah. Some of the older images didn’t get moved over to S3 somewhere along the line…
Speaks to your point about managing WordPress 🙂
Rob Mullineux
October 14, 2018 at 7:58 pmI have found that AWS can also have very strict file permissions that can often conflict with plugin and core updates. Not a huge issue, just annoying one having to constantly monitor and fix permissions issues with WordPress.
Robert Tisdale
October 15, 2018 at 7:24 amHowdy Rob. Thanks for commenting!
AWS is generally using Linux on it’s EC2 instances. You shouldn’t run into any issues on AWS that you couldn’t run into elsewhere. This should remain true even if you’re utilizing EFS as it’s effectively a standard NFS share.
You may want to double check how you’ve setup your Apache/Nginx/PHP setup as well as the default permissions on new files (All handled within your Linux distribution of choice).
Good luck!
Comments are closed.