{"id":161138,"date":"2017-01-24T13:00:06","date_gmt":"2017-01-24T13:00:06","guid":{"rendered":"https:\/\/premium.wpmudev.org\/blog\/?p=161138"},"modified":"2017-08-09T08:57:47","modified_gmt":"2017-08-09T08:57:47","slug":"host-wordpress-multiple-aws-server-instances","status":"publish","type":"post","link":"https:\/\/wpmudev.com\/blog\/host-wordpress-multiple-aws-server-instances\/","title":{"rendered":"How to Host Your WordPress Site on Multiple AWS Server Instances"},"content":{"rendered":"

You’ve almost definitely heard about Amazon Web Services. And, given that you’re on this site, I’m going to make the obvious assumption that you’ve heard about WordPress, too. But what you might not have heard about is combining WordPress with Amazon Web Services<\/a> (AWS) for web hosting.<\/p>\n

Articles about hosting WordPress on shared hosting, CPanel hosting, managed hosting<\/a> and what have you are a dime a dozen. Yet AWS is yet another infrastructure that can be used to host your WordPress site. Not only that, but given that an AWS infrastructure is elastic, it’s a great place to set up a WordPress installation that can be autoscaled to meet demand.<\/p>\n

So in this article, let’s get down to the business of setting up a WordPress site on multiple instances of AWS servers.<\/p>\n

Note:<\/strong> Here’s a quick guide on how to install WordPress on a single AWS instance<\/a> (like the one that comes with its Free Tier account). Once you know how to set up a WordPress installation on AWS, check out our articles on setting up WordPress for autoscaling to multiple instances to be able to handle spikes in traffic.<\/p>\n

Step 1: Registering an AWS Account<\/h3>\n

First things first: If you still haven’t ever tried Amazon Web Services, head to https:\/\/aws.amazon.com<\/a> and click on Create an AWS account<\/strong>.<\/p>\n

You can use your regular Amazon account to log in, but following the normal login you’re going to have to go through a process for verifying that there is an actual human behind the person registering the account. You’ll go through the process of filling in your details, actually verifying the account through a phone call, setting up a credit card for billing purposes and a whole host of other standard registration stuff.<\/p>\n

Once you get through the registration process, you should finally get access to the AWS Services Dashboard, which looks a little bit similar to this:<\/p>\n

\"Wow
Wow \u2013 which server do I choose?<\/figcaption><\/figure>\n

If it’s the first time you’re getting access to this it’s a little overwhelming. There’s so much stuff to choose that you’ll actually get pretty confused if you’re not used to this.<\/p>\n

Let me run you through a few quick explanations of the most common instances you can use. Truth be told, I don’t even know what half of the services mean, but doesn’t have to worry me (or you) much!<\/p>\n

EC2 – the Amazon Workhorse<\/h4>\n

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale\u00a0cloud computing<\/a>\u00a0easier for developers. In more simple terms, this is computing power on tap. You can simply start instances of virtual machines here which can be used for whatever you need to\u00a0run.<\/p>\n

S3 – Storage on Demand<\/h4>\n

Amazon Simple Storage Service\u00a0(Amazon S3) is object storage (or disk space) with a simple web service interface to store and retrieve any amount of data from anywhere on the web. It is designed to deliver 99.999999999% durability, and scale past trillions of objects worldwide. Simply put, it is very reliable and can get very very big (should you need to). Services such as DropBox are powered by S3.<\/p>\n

RDS – Relational Database in the Cloud<\/h4>\n

Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a\u00a0relational database<\/a>\u00a0in the cloud.\u00a0Amazon RDS provides you six familiar database engines to choose from, including\u00a0Amazon Aurora<\/a>,\u00a0PostgreSQL<\/a>,\u00a0MySQL<\/a>,\u00a0MariaDB<\/a>,\u00a0Oracle<\/a>, and\u00a0Microsoft SQL Server<\/a>.<\/p>\n

CloudFront – Amazon’s Content Delivery Network<\/h4>\n

Amazon CloudFront is a global content delivery network (CDN) service that accelerates delivery of your websites, APIs, video content or other web assets. It integrates with other Amazon Web Services products to give developers and businesses an easy way to accelerate content to end users with no minimum usage commitments.<\/p>\n

SES – Simple Email Service<\/h4>\n

Amazon Simple Email Service (Amazon SES) is a cost-effective email service built on the reliable and scalable infrastructure that Amazon.com developed to serve its own customer base. With Amazon SES, you can send and receive email with no required minimum commitments \u2013 you pay as you go, and you only pay for what you use.<\/p>\n

Step 2: Designing Your AWS WordPress Infrastructure<\/h3>\n

How do these servers relate to our AWS WordPress setup?<\/h4>\n

EC2<\/strong><\/p>\n

We will be using EC2 to create a web server instance to power our AWS WordPress installation. We can also use this to install a MySQL database to power our WordPress database.<\/p>\n

RDS<\/strong><\/p>\n

RDS services are optimized database instances for running database-based applications. We will be using one of these instances for our database since these are highly optimized for performance and scaling.<\/p>\n

CloudFront<\/strong><\/p>\n

A CDN goes hand-in-hand with WordPress performance, so using CloudFront will give us a CDN powered by Amazon Web Services for our WordPress site.<\/p>\n

S3<\/strong><\/p>\n

Our media will be stored on S3 instances and distributed via the CloudFront CDN.<\/p>\n

SES<\/strong><\/p>\n

Whilst you may choose to use your EC2 instance for sending mail, we typically opt to use Simple Email Service instances because, once again, since these are optimized for sending email, we won’t run into such issues as bad neighborhoods and other mail delivery issues. This is particularly relevant if you plan to send mass\u00a0mailings.<\/p>\n

Designing Your Infrastructure: Scaling Out vs Scaling Up<\/h3>\n

There are hundreds of ways you can set up your WordPress infrastructure. If you want a small instance to host your small site, we’re going to discuss LightSail later on, which is Light VPS which Amazon has launched very recently. You can also set up all of your WordPress instance including server, PHP and MySQL database on a single EC2 instance<\/a>. However, this is not going to take your performance\u00a0very far \u2013 once you hit the physical server limit, you’re done.<\/p>\n

So what’s this scaling out vs scaling up jargon? There are two primary ways of increasing the throughput\/performance of your website.<\/p>\n

    \n
  1. Scaling up aka scaling vertically<\/strong> – this means increasing the actual hardware\/memory resources used to power your website. Essentially, you increase the RAM, CPUs and other hardware allocated to your website. If you’re on a shared server, you go to a VPS. If you’re on a VPS, you increase the RAM and\/or CPUs allocated to your server. If you’ve reached the maximum hardware on shared hosting, you buy a dedicated server. When you’ve exhausted the dedicated server, you switch to a more powerful server with better hardware.<\/li>\n
  2. Scaling out aka scaling horizontally<\/strong> – as I’ve hinted slowly in the previous paragraph, you might notice that scaling up has an actual physical limit – the hardware running your website. If your website is exhausting the physical hardware its hosted on, you’ve run into a problem. Scaling out, rather than throwing more hardware at the server, throws more servers<\/strong> at the website. Essentially, we farm out each component of the website to a different server. That, of course, allows our website to handle a much heavier load\u00a0because we have multiple servers handling the load.<\/li>\n<\/ol>\n

    Our setup is designed with scaling out\u00a0in mind. For this reason, we’re going to use different instances for each component of WordPress. This will allow us to scale up (increase the computing power) and scale out (increasing the number of instances doing the work) as part of our infrastructure\u00a0to handle additional load.<\/p>\n

    In particular, we’re going to use multiple web servers to be able to handle large amounts of traffic. We will also be setting up a load balancer, which will determine which server to send requests to.<\/p>\n

    This means we’re going to be creating at the very least the following difference instances:<\/p>\n

      \n
    1. A database component using RDS<\/li>\n
    2. (Multiple)\u00a0WordPress installation component(s) using EC2<\/li>\n
    3. A mailing service component using SES<\/li>\n
    4. (Optional) A CDN component using S3 and CloudFront<\/li>\n<\/ol>\n

      There are also multiple ways of actually designing this infrastructure. AWS also has pre-defined Application Containers. The idea is that certain specific common applications development environments have pre-defined instances that can be activated at the click of a button.<\/p>\n

      A word of warning: Amazon has so many possible configurations and setups possible, that it is quite difficult to understand them without lots of experience, let alone explain them in a single blog. For this reason, we’ll be taking some shortcuts and not explain everything in detail. For further reading, refer to the AWS documentation<\/a>.<\/p>\n

      Scaling Out a Database<\/h4>\n

      Scaling out a database to multiple instances is possible, however, the complexities of performing such a configuration are way beyond such a blog.<\/p>\n

      We’re thus going to restrict our infrastructure to a single instance of the database. Now, although this may seem like a limitation, in reality, having a server instance dedicated solely to the database means that the website would be able to handle significant amounts of traffic.<\/p>\n

      We will also be using Aurora DB, Amazon’s own build of MySQL which is optimized for performance and for the cloud.<\/p>\n

      This, coupled with the fact that our database instance can get pretty high-specked in terms of performance should ensure that the database would never become a real bottleneck.<\/p>\n

      To ease the load of the database components further, one would also enable WordPress caching to ensure that database hits are kept to a minimum.<\/p>\n

      All-in-all, our decision to keep a single instance of the database should be sufficient for most website loads unless your website will be handling tens of thousands of hits per second. In that case, you can probably afford to hire an expert to configure your website!<\/p>\n

      Step 3: Setting up Your WordPress Database Instance<\/h3>\n

      To set up a WordPress installation on Amazon Web Services, you’re going to need a few components. The first you’re going to need is a database service, so go to RDS and launch a MySQL instance.<\/p>\n

      \"Create<\/p>\n

      If you’re just testing out stuff, you can choose to create a DEV\/Test environment. On the other hand, if this is your production environment, you have two choices:<\/p>\n

      Option 1: MySQL<\/h4>\n

      This uses a multiple Availability Zone (i.e. you will have a Primary instance and a secondary instance on standby in case of failure of the primary instance). The creation and failover to the secondary standby instance is completely transport – it is of course designed for High Availability\u00a0and\u00a0Provisioned IOPS Storage<\/a>\u00a0for fast, consistent performance.<\/p>\n

      Option 2: Aurora DB<\/h4>\n

      This is the recommended<\/strong> configuration. Whilst this is not strictly MySQL, Aurora DB is a custom build created by Amazon, specifically optimized for higher performance and better reliability. Tests have shown that instances of WordPress on Aurora DB run up to 3 times faster<\/a>. This is also classified as Enterprise level performance, so if you want absolutely top-notch performance, you should go for this option.<\/p>\n

      \"Use
      Use Aurora DB for top-notch performance.<\/figcaption><\/figure>\n

      Once you’ve selected Aurora DB, you need to specify some basic configurations. You’ll need to figure out what the right DB Instance Class<\/a> for you is. Besides actual throughput, you’ll also need to consider DB Instance\u00a0pricing<\/a>.<\/p>\n

      \"AWS
      AWS Aurora database configuration.<\/figcaption><\/figure>\n

      Take note of the settings you are using, particularly names, because we’re going to need them later on when we’re creating the WordPress instance.<\/p>\n

      Step 4: Creating and Setting up Your Web Server Infrastructure<\/h2>\n

      Once our database has been created, we’re now going to set up our web server. We’re be using an EC2 instance to run our WordPress web server.<\/p>\n

      Once again, you’ve got various options to install WordPress on an EC2 instance. If you head over to the AWS MarketPlace<\/a>, you’ll find preconfigured instances of WordPress which you can get up and running in next to no time. These come with the added benefit of using a tried and tested configuration.<\/p>\n

      The AWS MarketPlace also allows you to install very specific WordPress configurations. For example, if you want to push performance to the limit, you might want to use an Nginx web server rather than an Apache webserver. There are various Nginx configurations available on the AWS Marketplace<\/a>.<\/p>\n

      To create a new EC2 instance, access the AWS Management Console and click the EC2 tab:<\/p>\n