How to Run Wordpress on AWS
twitter.com
twitter.com
First of all, lets bare in mind this is talking about larger, enterprisey installs. So what would you need if you hosted on-prem:
- a DB with a read replica in case your main DB died (RDS can actually build read replicas for you pretty easily so this part of the deployment would be much easier than doing the same MySQL replication config on-prem)
- Redis for caching (my experience with WP is a couple of years out of date now but when I last managed an highly popular WP install (several in fact) Redis or Memcached caching was a necessity to get the kind of page load times our visitors expected)
- Shared storage (bare in mind you're running more than one WP web server - if this was on prem you'd be hosting those files off a SAN)
- A load balancer (I don't think I need to explain a justification for that one)
- And probably a CDN too (reduce the stress on your web-servers and internet gateway)
That's literally the bare minimum any large Wordpress application would need and that's all that AWS architecture is outlying. Sure there's a few more items on there like NAT gateways but those are just network stacks that are deployed as part of your VPC (or in on-prem terms, that's just the VLAN and/or subnet management that you'd assign to your load balancer).
If you don't need multiple web-servers nor high availability then your architecture becomes drastically simpler (no load balancer, no shared storage, no replica DB, etc) but also you would run the risk of downtime and even data loss. Which might not be an issue for some people but it's also not one of the selling points of AWS. So you'd be better off with shared hosting or a managed WP service -- or to put it another way, AWS was never going to be a good fit.
edit: Personally I think the issue here is more WP -- or rather the classical CMS design -- than it is AWS. A static site generator style of CMS would be a lot simpler cloud design and run a lot cheaper too. WP is designed from an era when web shops had this infrastructure set up by default.
The example included was to show HA for any CMS/dynamic application. You could easily sub in Wordpress for just about anything. It accounts as an example and not a complete recommended solution, though it could be one depending on your needs. But because it comes from QuinnyPig it gets more Internet points.
AWS feels like hosting on IIS back in the day. It was extremely expensive and pointless for more than 50% of their customers, but people kept saying “but we’re enterprise!” and throwing money away until the world finally woke up.
You need this complexity in an enterprise environment because the web teams don't have access to databases, and the DBAs aren't allowed to manage databases outside of the data network, etc. That's why enterprise content management exists. Big companies and public sector value repeatability and seperation of duties over cash and time.
12F apps, microservices, etc. are much _cheaper_ to run on AWS because you don't have to worry about scaling/provisioning/and HA/DR capabilities are basically baked in. A lambda that processes 100,000 requests/day is, on average from the teams I've worked with, significantly cheaper to run than a machine in a DC that is always up.
Where AWS really comes into is stuff like serverless (yeah, I hate that term too), auto-scaling, object storage, etc. I've got a few static sites that are compiled in AWS Code Build whenever I push new markdown to GitHub (literally just using shell scripts and pandoc). They're then pushed to S3 and sat behind CloudFront. It costs me a few dollars a month to host, I don't need to think about scaling and I get near instant page load times. Running that kind of thing on-prem wouldn't even come close to being as cheap nor convenient as AWS.
This is why I commented about WP being ill-suited for modern cloud deployments in my edit.
To be clear, I'm not claiming AWS are the only hosting providers to offer the aforementioned. The same arguments can be made for and against GCP, Azure and so on and so forth. I'm also not advocating that everyone should switch away from WP or adapt their workloads for the cloud. People should just use what works for them the best. I'm only commenting on why that AWS architecture isn't as insane as it first appears.
I used to unequivocally scoff at "the cloud", but I used to think it was "MySQL as a service" or "VMs as a service" when it is able to be so much more with cloud native tooling.`
A MediaWiki install I manage has a more complicated deployment, files reside on DigitalOcean spaces so there’s no NFS bullshit but there’s still multiple instances each of nginx-ingress, trafficserver, memcached, mysql, nginx/php-fpm, keycloak, cronjobs to run background tasks and a managed load balancer in front of it all.
Still, then bill in comparison to AWS is cheap - base costs are $125USD/mo for the 6 droplets and spaces storage. We just enabled auto scaling for the MediaWiki instances so it can vary a bit now, but traffic is bursty so it won’t go up by much.
In reality, when we had to add Wordpress to our workloads, there was nothing special we had to do except for introducing EFS. All our workloads before that didn't require keeping state on a file level.
And just like that we had a scalable/HA Wordpress setup with pretty decent performance.
I self-hosted Wordpress for years and yes this architecture is not unreasonable for a high volume site. Now I pay WP Engine a fixed annual fee and all this comes out of the box with a few clicks.
wordpress may not, the org deploying it might.
Otherwise agree with your post. All depends on the business needs.
https://github.com/aws-samples/aws-refarch-wordpress
Good luck automating it that much on-premise.
If you're just running a simple WP blog, you could host it on a cheap shared hosting package and not worry about devops, and as long as you use a cache plugin that will serve your entire site as static content, you'll be able to handle a large volume of traffic easily.
It's amazing what runs on Wordpress and how relatively easy it is to scale with straightforward infrastructure. I think the diagram is for to enterprises which adore the complexity (because the enterprise architects won't be doing any of the maintenance), and is conditioning people to solutions which will have high consumption cost (because your money is best left with whatever cloud provider you choose.)
That doesn't mean you shouldn't go all in on taking advantage of your cloud provider when you have a good model of costs and performance. However, you are best starting with the needs of the application and working from that point as you allude to.
Bingo. Anecdotal experience: I saw this happen at my last position where they did an over-complicated/fragile WordPress setup with K8s.
We went over to K8s for "performance optimization", "security", and "system stability"... what bothers me the most as a WordPress expert (specifically with HUGE/redundant rollouts) is that none of these reasons/bottlenecks were studied before designing the infrastructure. K8s is great, but if we start throwing arbitrary infra at our problems all we see is increased complexity without addressing the core tech issues.
When I pushed to load test the new infra it was met with crickets - likely because that was never the goal in the first place. The goal was to jam a sexy technology into our stack so someone's quarterly goals were met with some lookin' pretty/SF-deluded engineering director that touts not knowing development/architecture makes him better in his role.
Honestly - it's just job security, chasing a dragon, and cargo-cult for most of these orgs... if we were actually on the hook for "more with less" you would NEVER see an atrocity like what was posted. KISS is sure out of style when it comes to these fool's outrageous egos/budgets.
We will see how it survives this potential long-term economic downturn we are in, or approaching. I laughed out loud when you mentioned K8s for "security".
If you are building out infrastructure like this, then you're probably not using Wordpress as an application framework.
I run our organization's WordPress sites on Elastic Beanstalk (just do a "eb deploy" from your Git repo of the site and it gets up there), plus RDS (Amazon Aurora) and CloudFront. EB and Aurora auto-scale and CloudFront does its CDN thing.
I highly, highly recommend Elastic Beanstalk ( https://aws.amazon.com/elasticbeanstalk/ ) to anyone who wants their org to concentrate on creating value (new/better code) and being cost-efficient (use the compute power needed that minute instead of overprovisioning) instead of fiddling with custom server configs and wondering if you're fully patched up. It was a game changer for us.
Personally I've found EB to be a great development tool but it's really hard to manage once you step up into the enterprise scale. By that point you'd be writing your CloudFormation scripts by hand (or better yet, using Hashicorp Terraform) and "building stuff to fail" (as the adage goes).
edit: getting downvoted. I'm guessing some people are using EB for sites that generate millions of visitors a day (let alone minute like some services I manage). I'd be interested to hear how you overcame EB's shortcomings with resource failures breaking the entire EB build pipeline in often unrecoverable ways.
In fact theses days there are a lot of Infrastructure as Code solutions out there. If you deal mainly with lambdas then there’s Serverless[1] or CDK[2] (Cloud Developer Kit). EB is itself ostensibly “just” a frontend for CloudFormation[3] (as I hinted at in my earlier post). Personally I use HashiCorp Terraform[4] the most but every single one of the aforementioned bar CDK has been used in production by my team.
However if none of those float your boat then there are a whole plethora of other IaC tools out there I’ve not mentioned.
So if you’re hitting the limitations of EB then your time is well spent learning another tool. In fact I’d go further than that and say I think it is worth your while learning Terraform (or any other IaC tool) even if you aren’t hitting the limitations of EB —- but I’m biased because of having wasted so much time in the past fixing deployments that EB has completely mismanaged.
[2] https://aws.amazon.com/cdk/
If you are read heavy, offloading static assets to a CDN and having good caching will get you very far. If need be, you can load-balance between databases and you’ll still go very far.
Micro-services is not necessarily synonymous with scale.
1. If you need multiple WP instances, you'll need to duplicate that setup with read replica + load balancer
2. If you want to do things enterprise-proper, you'll want to set up a VPC, which means you need the internet gateway + some routing setup
And voila, thats the above architecture. If you don't need it you don't need it. But none of this is particulary complicated to set up if you know what youre doing, especially if you're using Terraform.
Don't forget that wordpress is not stateless. It'll need write access to its code directory, which complicates scaling. AWS has EFS which support up to 1000 clients, but at that point you'll probably better off rewriting your website with something else that easier to scale on the cloud.
Honestly - it's a pretty painless, AWS-takes-it-from-there setup.
Also, WP works "mostly" but if you rely on shared assets (temp files, etc) and log files written to disk like woocommerce, mailchimp, and more do, those are silently inconsistent. most people don't care, but it's not 100% "correct"
So while it appears to work 100%, there are things under the hood that simply are misbehaving and out of sync.
Personally I prefer doing my own ASG or other methods than rely on EB anymore. I've had it break too much, and I can get a lot more scaling out of a completely custom AMI build.
If you're thinking long term and beyond the time period that you yourself will be employed at your org, you should put serious thought into making as vanilla and out-of-the-box a build as possible. My organization has a simple path to getting new developers up to speed on how to maintain and further update our Elastic Beanstalk-served sites: Learn the basics of how EB works and you're good to go.
On the other hand, if I had put together a superbly optimized AMI and grafted each site onto it, a whole lot of question marks start to appear. What distro is being run? Who/what's keeping it up to date? How do you connect to it? (On EB, you type "eb ssh" and it logs you in.) What's the load balancer setup look like? Where is all of this documented?
I think the trade-off of a few percentage points of optimization versus the fully-documented nature of a packaged service and the simplicity of getting someone new up to speed... I'll drop the few percentage points any day.
In fact, a few weeks ago a media org I frequent often had a site outage - they run WordPress so I offered to help (it was the weekend and I figured their IT guy might not be available) and they took me up on it. It took me five minutes to solve the issue and twenty-five minutes to understand how their custom, minimally documented setup was designed. I don't think that should be the norm.
And I just did a WordPress demo site using AWS Lightsail for $3.50 USD per month (obv the lowest tier).
Took me less than an hour to get it all rolling.
Just check out the feature list: https://aws.amazon.com/lightsail/features/
There are some oddball finicky things about it (like not seeing the instance except in the Lightsail interface unless you manually fix or migrate it) but it was easy as pie.
I used to use AWS when I was at a startup. this light sail seems similar to Digital Ocean's built in templates.
I appreciate the easy set up of the database and code and that it gives you a sane path to https.
cPanel > Install on a lot of shared hosting accounts made it insanely easy.
Writing to EFS however means that you can just treat your EC2 instance as a stateless front-end server that can be swapped out whenever needed.
Couple that with an autoscaling group and when the instance inevitably dies, it'll automatically come back up on a new host.
I don't have an ops team so I prefer AWS to be responsible for stuff like this wherever possible.
It is powered by a Linode. I have literally never needed to manage the server unless I was actively working on something, like changing the theme.
People overcomplicate things these days. You could spend X hours creating some autoscaling, autorecovering setup; but for 99% of projects, it'd maybe encounter an outage that requires your intervention, once a decade.
Too many people are getting hung up on it being WP. AMZN doesn't care what the application is and has no vested interest (that I'm aware of) in WP.
EDIT: clarity
Where a long enough timeline is 700 years (before you're more likely than not to have suffered a full or partial failure).
Taking regular snapshots decreases the chance of an EBS drive failing.
Bah meant for the comment below!
Amen. It's also becoming the "safe" thing to do to put all of your eggs in the Amazon basket. Also just think about all of that data we're giving them... gah.
They're laughing all the way to the bank.
The secret: a la carte bare metal (packet.net, datapacket.com) for high-load and especially high-bandwidth stuff combined with a simple not-over-engineered services deployment in Google GKS with instances tuned for our work load (high CPU, low memory) so we are not paying for RAM we do not need. We are really only using Kubernetes to keep stuff up and auto-scale. We are not even close to using all K8S's features.
GKS is most of the price tag. We could go down to about 1/4 the monthly cost if we rolled our own Kubernetes cluster with Rancher or something at packet.net, but the added labor might negate the savings. We may still do this if we grow significantly, since at larger scales the added labor may be justified by geometric cost savings.
In general the bigger you are the more sense it makes to roll your own. Small and growing: use managed stuff. Bigger: consider bare metal and DIY clusters. Even bigger: co-location can start to make sense. HUGE: build your own data center! It's always a pure spreadsheet decision though. Also keep in mind that you can sometimes split your stack and do managed for one part and bare metal for another. For us the split is between things that are micro-service based, database backed, and need to auto-scale vs. dumb simple bandwidth and CPU pumping services that are trivial to deploy and require little attention. The latter is what goes on bare metal for massive operational cost savings. The former goes in GKS for labor cost savings.
... and yes, it's very stable, and probably more stable than finicky over-engineered Rube Goldberg machine AWS deployments that engineers constantly have to fiddle with.
It's so refreshing to see someone taking this sort of complexity into account when planning new infrastructure. There's a HUGE cost to training and supporting a new infra paradigm that I often see decision makers ignore completely... in their defense it's a difficult thing to predict but that's not a reason to ignore the overhead!
The last time we did the math it was kind of a toss-up between roll your own bare metal cluster and GKS when labor costs were considered, but those are estimated labor costs and we also didn't want to deal with the hassle. GKS meanwhile destroys Amazon, so all the big clouds are not equal.
We decided we might make the leap when the savings for bare metal over GKE are 2X or more, since that leaves a good margin for under-estimating labor (which is probably the case).
I edited the parent to add a point about rolling your own making progressively more sense the bigger you get. That's because modern devops lets you leverage a skilled admin across a big deployment, so the labor cost becomes somewhat fixed and allows you to leverage the economy of scale and the cost advantages of bare metal (to a point).
But do your own estimates! There are many details. One detail is that bare metal bandwidth (especially egress) is radically, ridiculously, nonsensically cheaper than any of the big cloud providers. I italicized those because damn do the big cloud providers ever rape you on bandwidth. The same is true to a less absurd degree for raw CPU power. It mystifies me when I see people doing deep learning on AWS. Storage on the other hand is far cheaper on Amazon and other major cloud providers, especially when you factor in the cost of achieving high reliability and uptime. If you are warehousing a ton of data, you might never want to leave these (unless you actually get bit enough to build your own racks!).
Edit: caveat on storage: check out Backblaze B2 and using it from a nearby bare metal data center if you are mostly warehousing and not heavily accessing. Again: there are many many devils in these details, so do your own shopping and cost estimates for your unique workload and factor in everything: compute, storage, bandwidth, labor, uptime requirements, agility, rapid auto-scaling needs, geographic location and/or multi-location needs, etc. Hosting/cloud is a huge market with a dizzying array of choices each making sense for different mixtures of customer profiles. Expect to spend a day or two just surfing around and shopping.
FYI the bare metal hosts we've had good luck with are packet.net, datapacket.com, and OVH, in approximately that order. (For OVH we have only used their bare metal hosts and can't comment on their other services.) There are others. We had lots of odd issues with Hetzner but they are dirt cheap partly because they cut corners like using desktop-grade hardware. Hetzner may actually make sense if you need a ton of super-cheap compute and have a load that is very tolerant of node failures, since as far as I can see nobody sells CPU as cheap as they do. If I were doing a ton of deep learning model training I'd consider using Hetzner for raw compute power cheap and I'd treat the nodes operationally like on-demand/spot instances.
You might look at Digital Ocean and Vultr too. DO is adding some managed services and apparently they're decent. In the past the simple "we give you a VM" hosts have occupied an uncanny valley though: not as cheap in price/performance terms as bare metal "rent-a-box" hosting, and not rich enough in services and value-adds to compete with big cloud.
I work in the ISP space specifically with folks who help place businesses in datacenters. This is 100% accurate - sometimes it can literally be pennies on the dollar for egress.
> Storage on the other hand is far cheaper
Agree - S3 will always be a backbone component of my toolbox when building out infrastructure. It's been solid from day-1 when I was in my early 20's using it on remix competition sites (wavs are big... 10-20 wavs per-song oh god). The awe still hasn't worn off for me as to how quick I can scale large-scale web-friendly/secure storage with tools like that.
---
On the VPS hosts... I'm weirdly loyal to them and have kept infra on Linode for years. I also have had extraordinary positive experiences with DO as well. I find they have the customer service that solutions like AWS lack for the little guys... if we're talking about a big spend then yea I will totally go to a more formal provider, but for my stuff I prefer knowing that there's solid engineers on the hosting side that I can actually talk to.
I'm REALLY excited to see folks like Linode/DO support things like S3-compatible APIs, K8s, etc. I think that's important for those solutions to stay relevant.
---
Thanks for such a great response - conversations like these are invaluable, and I've definitely learned from this! I am VERY interested in Vultr - totally could have used them 5-6 months ago for GIS crunching (fiber maps, lit building lists, geocoding, census blocks, etc). Once I open that up as a service to my users I'll likely be on the hunt for SSD-backed high-compute on-demand instances.
I for one welcome the description of high-traffic production level architecture description. Usually on the internet, it is hard to find a real setup description. Most of architecture examples are simple, not something you would use in production yourself. Plus, simplifying architecture is always simpler, than thinking how to make it scalable properly.
If you run the Wordpress instance locally or otherwise secure it from public access, you don't have to worry about keeping WP and its plugins updated, which saves considerable time and expense. This is my go-to solution whenever a WP install is requested.
This design really isn't so far out from what I planned but the NAT gateways aren't necessary and I was going to use Fargate instead of EC2 to host it. Also, I was going to host it in a single availability zone as the impact of downtime is minimal.
EFS seems like a natural choice also for upload directories, etc, and you can attach EFS volumes to Fargate containers now.
I'd be interested to hear if anyone else has done this and what their experiences are.
https://aws.amazon.com/lightsail/features/
It's super easy...
I've racked up around 10 years of AWS experience now so it's not so hard for me to throw something like that together. If I had to use Azure then I'd certainly do something simpler.
All the configuration is passed via environment variables so you don't even have to keep the config files in EFS.
It’s possible I’m sure to lock down Wordpress and also to segment your AWS network but ... why? Unless it needs access to other assets in your AWS account then quarantining it on a dedicated account on a different service provider is easy.
Then there's https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfro... to offload all media files to S3 (consider putting a Cloudfront distribution in front to get a custom domain + HTTPS).
I've been there and I can't honestly recommend it. You'll be on your own. Also, it really really feels like Wordpress wasn't made to be deployed this way. If I were you I'd rather use a good hosting provider like WPEngine and spend my time on more valuable things.
I say it's an anti-pattern because we're talking about WP - a platform that allows you to arbitrarily update PHP files from a web admin/install plugins/etc... It's this sort of flexibility that our clients/end users want and when we start designing that BS out due to security reasons it typically ends up in a user yelling at me for "WHY CAN'T I JUST INSTALL A PLUGIN LIKE THE WORDPRESS TUTORIAL SAYS?!"
When you come back with "security", and "I have to review that code" it almost always falls on deaf ears. When you start designing the flaws out of WP infra you start to realize those same flaws are why marketing is hellbent on keeping it as a CMS - they hate working with/waiting on devs to get things done.
I think the only reason someone would do this is when a company that's using WordPress want to migrate to AWS to use "cloud" technology but don't want to invest in rewriting their website, which is odd. If they have engineering capability to move their WordPress site to AWS with complicated architecture, surely they have the chop to rebuild the website with something else that more compatible with cloud technology?
The real headache is when you need a load-balanced setup. You'll need to keep the whole wordpress directory (not just the upload directory) synced between instances, which you can't do over S3. NFS is a popular option, but NFS server usually have a hard limit on the number of connected clients, which ultimately limit the number of your instances (e.g. if you need 20 instances but your NFS server crap out when >12 clients connected, you're out of luck). Amazon EFS supposed to solve this since it supports up to 1000 connected clients, but people often complain about slow performance.
That being said, scaling wordpress to handle high traffic is a headache unless you write your own theme and plugins. The majority of wordpress sites use those visual editor plugins and mega themes, which is a nightmare when you hit by high traffic as they are often impossible to cache (crazy stuff such as css/ generator that vary its output depending on user agents, etc) and often rely on wordpress statefulness (write arbitrary files to arbitrary locations, which means typical load-balanced/autoscaling architecture will not work as it assume your application is stateless). Personally, I'd rather rewrite the whole site with something else than trying to setup a load-balanced wordpress installation.
We custom compiled PHP from source to run in the lambda environment then got node to pass the requests to PHP cli.
Took some tinkering but we got it working.
And you can keep using AWS until you're part of Fortune 500
WordPress on EFS (and they explicitly mention PHP files on their EFS description) is unbearably slow!
The networking is the bit that most people don't care about or see, but it's there, and that's it.