How much does it cost to run WordPress at scale on AWS?

WordPress at scale is a caching problem dressed up as a hosting problem. The software will happily generate every page from scratch on every request, running dozens of database queries to do it. Almost all the money in a WordPress architecture is spent either on caching or on the compute you need because caching is not working.

The workload we are pricing

Assume a content site in us-east-1 with 2 million page views and 400,000 unique visitors a month. There are roughly 8,000 published posts, 50 GB of media in the library, and around 20 editors publishing 100 pieces a month. Average page weight is 1.5 MB including images, giving about 3 TB of CDN egress. The site runs a commercial theme and about 25 plugins, which is typical and which is why the database is busier than a clean install would be.

The monthly breakdown

Full-page caching changes the whole shape

The table above assumes object caching (query results cached in Redis) but pages still rendered by PHP on every request. Two million page views a month is about 0.77 requests per second average and maybe 15 per second at peak, and each uncached page view is 30 to 60 database queries plus PHP execution. That is what keeps 2.5 t3.large instances and a db.m5.large busy.

Turn on full-page caching at the CDN, with a sensible TTL and cache invalidation on publish, and the picture inverts. A 95 percent edge hit ratio means the origin sees 100,000 page renders a month instead of 2 million, which one t3.large handles with room to spare, and the database drops to db.t3.medium.

That is a 24 percent saving from a configuration change. The complication is logged-in users and personalized content, which cannot be served from a shared edge cache. Most content sites have very few logged-in visitors, so a cache rule that bypasses the edge cache when a session cookie is present gives you the saving for the 99 percent while keeping the 1 percent correct.

The database is the fragile part

A db.m5.large at 136 dollars is not an extravagant database, but WordPress makes it work hard. Autoloaded options, plugin-generated transients, and post meta queries are the usual culprits. The failure mode is not gradual: when the cache expires across many keys at once, or a crawler hits uncached archive pages, query volume spikes 10x and the database saturates. The instinct is to upsize, which doubles the cost to 273 dollars and treats the symptom.

A read replica at 124.83 dollars is a better answer for read-heavy content sites, since almost all WordPress traffic is reads and a replica absorbs archive and search queries. The economics are covered inread replica cost. Better still is fixing the autoload table, which is free.

Where the remaining money goes

After caching, the CDN at 280 dollars is 45 percent of the bill and responds to the same image work that helps any content site: modern formats, responsive sizes, lazy loading below the fold. Cutting page weight from 1.5 MB to 900 KB takes egress from 3 TB to 1.8 TB and the CDN line to about 170 dollars. The EFS volume at 15 dollars for wp-content is worth revisiting too; offloading the media library entirely to object storage removes the shared filesystem and makes instances genuinely stateless.

At 825 dollars for 2 million page views, hosting costs 0.41 dollars per thousand views; after caching and image work, about 0.22 dollars. For a site monetizing at a 5 dollar RPM, that is 4 percent of revenue falling to 2 percent. Price the architecture from Terraform against theresource catalog before the next traffic milestone so the scaling step is planned rather than reactive.

FAQ

What to do next

Plan your next traffic milestone with real numbers. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.