Running WordPress and Drupal on AWS

Posted on June 3rd, 2020

WordPress & Drupal are beloved as simple, easy ways to get a site off the ground but they both have reputations as being difficult to manage and scale up when a site gets a lot of traffic. Once you hit the limits of what a single server can manage, it becomes a pain to expand to multiple servers and configure a shared database to meet demand.

At drie, we saw this as an opportunity to show what we can do with our CloudFormation templates, the tool we use to bring our scalable high-traffic architecture to AWS. We’ve built high-performance, configurable templates for both WordPress & Drupal in the AWS cloud. They make it easy to run your blog on anywhere from one server to a pool of hundreds.

For both Drupal and WordPress, we’ve designed templates based around an architecture we know can scale easily. We use Amazon’s high-throughput RDS as a backing store for the site, and configured an auto-scaling pool of Amazon’s EC2 cloud instances as the web servers combined with a load balancer to distribute incoming requests. We’ve engineered the best way to run Drupal and WordPress in the cloud.

By separating the web servers from the database, we allow both of them to run faster and respond to requests with lower latency. And by using an auto-scaling pool, we allow you to choose how many instances are available to serve your blog: more when you’re expecting high traffic, and fewer when you don’t need as much.

One major concern for anyone running off-the-shelf sites is the risk of getting hacked. We’ve brought a lot of security expertise to the design of our CloudFormation templates, and it really shows in the WordPress and Drupal architectures.

To start, we’ve isolated the entire installation in a virtual private cloud (VPC) and firewalled off incoming traffic unrelated to the site. All the servers are completely walled off from the rest of the internet, stopping a whole host of malware and drive-by hacks that Drupal and WordPress are notorious for.

On top of that, we’ve added a few pieces of security preferences and best practices we’ve developed along the way, like our bastion server for SSH access. We’ve also configured the sites themselves to have the latest security updates. The bottom line: while nothing is ever perfectly secure, we’ve moved very far in the right direction.