AWS Wants You to Deploy WordPress Like It's a Mars Mission

You don’t need nine AWS services to run WordPress. You need a Linux box, a web server, MySQL, and PHP. That’s it. You can set this up on a $5 VPS in about twenty minutes. High schoolers have been doing it since the mid-2000s.

AWS would like you to do it differently.

The Reference Architecture

AWS published an official whitepaper called “Best Practices for WordPress on AWS” with a reference architecture that has been circulating on developer Twitter recently (credit to Ben Visness for surfacing it). The diagram looks like something you’d present to a Pentagon procurement committee.

Here’s what AWS recommends for running WordPress:

Amazon Route 53 for DNS. Amazon CloudFront as your CDN. An S3 bucket for static assets. An Application Load Balancer sitting in a public subnet. Behind that, an Auto Scaling group of EC2 instances spread across multiple Availability Zones. Each AZ gets its own private app subnet and private data subnet. ElastiCache for Memcached in the data subnet. Amazon Aurora MySQL with read replicas. Amazon EFS with mount targets in every AZ. NAT Gateways in each public subnet so your private instances can reach the internet. A bastion host for SSH access. All of it wrapped in a VPC with an Internet Gateway.

Nine AWS services. Multiple subnets. Two Availability Zones minimum. A CloudFormation template to stitch it together.

For WordPress.

What WordPress Actually Needs

I’ve deployed WordPress probably a hundred times over the years. The recipe hasn’t changed much since 2005.

You get a server. Any server. Install Nginx (or Apache if you’re feeling nostalgic), PHP-FPM, and MySQL. Download WordPress, edit wp-config.php with your database credentials, point Nginx at the directory. Done. If you want HTTPS, you run Certbot and get a Let’s Encrypt cert. Maybe you throw WP Super Cache on it if you’re getting real traffic. Total cost: somewhere between $5 and $20 a month.

A WordPress site configured this way can handle tens of thousands of visitors per month without breaking a sweat. For most blogs and small business sites, that’s more traffic than they’ll ever see.

Counting the Bill

Let’s rough out what the AWS architecture actually costs before a single visitor shows up.

Two NAT Gateways alone run about $65/month ($0.045/hour each). An Application Load Balancer is another $16/month minimum. Aurora MySQL starts around $60/month for the smallest instance, and you need a read replica in another AZ, so double that. ElastiCache nodes, EFS storage, EC2 instances across two AZs. CloudFront has a free tier but you’ll blow past it with any real traffic.

Conservative estimate: $300 to $500 per month. For a WordPress site. That’s before you factor in the engineering time to set it up, maintain it, debug it when the Auto Scaling group does something weird at 3am, or figure out why your EFS mount is adding 200ms of latency to every page load.

Meanwhile, the same site on a $10 Hetzner VPS would serve the same traffic, probably faster, because there’s no network hop between your app and your database.

Who Is This Actually For?

There is a version of this that makes sense. If you’re running WordPress as a platform (think WordPress.com itself, or a large media company with dozens of high-traffic properties), you actually need multi-AZ redundancy, auto-scaling, and managed databases. If your WordPress site handles millions of page views a day with authenticated users doing complex queries, okay, sure, bring in Aurora.

But that’s maybe 0.1% of WordPress installations. The other 99.9% are blogs, brochure sites, and personal projects. AWS calling this a “reference architecture” and publishing it as a best practice is the issue. That framing implies this is what you should do. New engineers and non-technical founders read this and think they need nine managed services to put a blog on the internet. Cloud vendors have a financial incentive to make simple things look complicated, because complexity is how they bill.

The Simplicity Premium

There’s an underappreciated advantage to running simple infrastructure: you can actually understand it. When your WordPress site is one server running Nginx, PHP, and MySQL, and something breaks, you know where to look. You check the web server, you check the database, you check PHP. Probably fixed in ten minutes.

When your WordPress site is spread across nine services in two Availability Zones with auto-scaling and managed caching layers, debugging becomes an archaeology project. Is it the load balancer health checks? The EFS mount? The ElastiCache eviction policy? The Aurora failover? The NAT Gateway? You need a different kind of engineer to troubleshoot that setup, and that engineer costs a lot more than the one who can restart Nginx.

Operational simplicity compounds over time. Every service you add is another failure point, another thing that needs monitoring, another pricing model with its own gotchas. The AWS architecture has at minimum nine of those. A single VPS has one.

Update: The $105K/Month PHP File

The day after publishing this post, Pieter Levels accidentally proved our point in the most spectacular way possible. His site photoai.com, which runs on a single Hetzner server, does $105,000/month in revenue. The entire application is one PHP file. 40,870 lines of index.php, served from what’s probably a box costing less than $100/month.

We wrote the full story in 40,000 Lines of PHP, One Server, $105K/Month. If a single PHP file on a single server can generate $1.2 million a year, maybe your WordPress blog doesn’t need nine AWS services either.