Scaling WordPress: AWS is no silver bullet

There is a common misconception that hosting WordPress on AWS makes it scalable automatically. Every online WordPress community I visit has a fair number of posts asking about solutions for a growing site. 10 out of 10 times, these posts have a suggestion that says, “If you need scalable infrastructure, AWS is the only option.”

Suggestions like this lead to a scenario we often see when onboarding new customers at Scale Dynamix. It goes something like this:

The site starts to grow and runs into scaling troubles. Developers suggest a CDN. When the site still has issues, management decides to move the site to AWS.

At this point, either the IT dept., or the agency managing WordPress launches a new EC2 instance. Since AWS recommends using Bitnami’s WordPress AMIs, most people go with that.

While these EC2 images are an excellent way to launch development environments, using them in production doesn’t provide any of the scalability or high-availability features that AWS offers. In other words, users trade their bare-metal servers and VPSs in favor of EC2 VMs and are no better off than before. And now, they also need to have a plan for backups, security, and staging sites (Most AMIs only support one WordPress install).

Here’s how I like to design a scalable and highly-available stack for WordPress using AWS:

• Start with appropriately sized EC2 instances (At least two).
• Use an application load balancer to route traffic across instances.
• Use RDS / Aurora for database hosting. A separate database server facilitates horizontal scaling of web nodes.
• Offload static assets to S3

With a stack like this, you can add more EC2 instances as the traffic increases and delete them as needed. Elastic Beanstalk can handle this automatically if the traffic is highly variable.

You can make this stack more reliable and cost-effective by using multiple availability zones for EC2 and using spot instances to handle traffic spikes.

Granted, this is more work, but it helps WordPress scale a lot further than using a pre-created image meant for prototype sites.