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
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.
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.
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.
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.