WordPress is a very popular platform for running websites.  I have read reports of WordPress hosting up to 27% of websites.   With WordPress powering so much of the web, you might be asking yourself how you can design your website to run on wordpress.

There are many WordPress hosting sites out there that you can use.  That is the easiest solution for you to take. But for one reason or another, you might want to host your own WordPress site instead of relying on someone else for hosting.

The challenge when you want to host your own WordPress site is how do you ensure high availability, and how do you scale the site if you suddenly receive a ton of traffic.  You can always scale up, where you simply increase the size of your server.  But that requires you to shut down the server instance, change the CPU/Memory, then turn it back on, causing downtime.  It also does not give you the high availability you are looking for.

For these reasons, scaling out your WordPress site is a much better answer.  Scaling out means you add more servers as your traffic increases instead of increasing the size of your servers.

Designing your infrastructure

Anytime you are designing your infrastructure, you need to ask yourself 4 questions:

1. Is my design scalable enough for my needs?
2. Will my design meet my Service Level Objectives?
3. How can I simplify things?
4. How can I reduce my cost?

If you go on Amazon Lightsale and provision a WordPress site, you will get a monolithic installation.  This means you have one server running LAMP (Linux, Apache, MySQL, PHP) with a dedicated IP address.  You could just start using the site as is.  But you have only one instance, so your uptime is only going to be around 99.99% uptime.

This uptime percentage comes from what Amazon guarantees you for your EC2 instances.  If all you need is 99.99% uptime, running WordPress on a single instance might be sufficient.  99.99% uptime means your site is down for a total of 11 hours every year. That is a little under 1 hour/month.  If that meets your objectives, then go with the simpler, cheaper architecture that meets your needs.  It will be easier to troubleshoot and save you money.

If you can’t afford that downtime, or if a single instance won’t be able to handle the amount of traffic you anticipate, then you need an alternative solution.  You can pay someone else for WordPress hosting, which may give you a better SLA. Or you can try to build a more resilient infrastructure.

Example Architecture

For those who need a more resilient architecture, or have traffic needs beyond what a single server can provide,  I have included one possible infrastructure design.  See below:

In this architecture, you see we start with 2-3 web servers in an auto-scaling group behind an elastic load balancer.  We use a CloudFront CDN in front of our load balancer to offload as much traffic as possible.  This saves us money, and it also makes the site faster for your users by caching your site closer to those who might be accessing your site.

Next, we have to ask ourselves what is it that we need to persist on each web server.  At its core, WordPress is just a bunch of PHP files. Those files are easily replaced as we can just bake them into our EC2 image as needed.   The things that are really important to us within the site is the wp-content folder and the database.

We use the Relational Database Service (RDS) to give us a scalable MySQL database.  Then we use the Elastic File System (EFS) to give us a shared file system across all of our instances.

One change you could make to this architecture is to use S3 instead of EFS.  I chose EFS in this architecture since it can be done using native WordPress.  To use S3 for WordPress content, you need a 3rd party add-on.

Using S3 instead of EFS would take some of the load off your web servers, which may save you money in the long run.

If you would like another example architecture, Amazon has an article on creating a highly available WordPress site using Elastic Beanstalk here.

Configuration

Today we will give you a brief overview of what it would take to build the previously mentioned architecture.  In the future, we will go more in-depth in what it takes to get this up and running.  To build the reference architecture, you will need to do the following:

1. Create a mySQL RDS database instance.  Instructions here.
2. Create a subnet for your EC2 instances to live in.  Instructions here.
3. Provision your EFS instance to store your WP-Content folder. Instructions here.
4. Create an AMI containing your WordPress installation. Instructions here.
   1. Make sure you configure WordPress to use the RDS database. Instructions here.
   2. Make sure you mount your EFS instance where your WP-Content folder lives. Instructions here.
5. Create Launch Template, Launch Configuration, and Autoscaling group using your new AMI image. Instructions here.
6. Create and configure ELB to point at Autoscaling group.  Instructions here.

Cost

For demonstration purposes, we will assume 1GB data transfer/month, two t2.nano instances for use as web servers, 1 GB of database content, and 1 GB of other content.  In this example, our pricing works out as follows:

• EC2 –  $7.62/Month
• ELB – Application Load Balancer $18.82/Month
• RDS – AuroraDB MySQL Compatible  – $9.09/Month
• EFS – $0.30/Month

Total monthly cost:  $35.83

You can think of this as a starting point.  If you are new to AWS, you might be eligible for the free tier for the first year.  This would save you around ~$20/month.  As your usage increases, so will your costs.

If you want to play around with the numbers yourself, you can find the pricing calculator here.  However, EFS is not available on the calculator as of the time I am writing this article.  You can find pricing for the EFS service here.

Summary

In this article, we discussed how you can utilize AWS to create a scalable WordPress site and some reasons why you might do this.  We also discussed what it might cost to build such a site.