Summary

In recent past AWS introduced new serverless load-balancing models that are designed to sit in front of your web app architecture and importantly, these new ELB models are both highly-reliable and free.  If you use an AWS EC2 instance to host your WordPress environment then there are many advantages to adding an AWS Elastic Load Balancer (ELB) to your infrastructure architecture.

• Horizontally scale your WordPress site.
• Add an automatically-renewing SSL certificate to your site for free.
• Improved site response times
• Perform maintenance to your server without having to take your site offline

Unfortunately, getting an ELB with an SSL certificate to work with WordPress is tricky. Namely, WordPress can get stuck in an infinite loop of URL redirections whenever you try to redirect traffic to HTTPS. After a long afternoon of banging my head against the keyboard I finally got HTTPS working. This article will hopefully help you to get your own ELB and SSL certificate up and running quickly and painlessly. Let’s get started!

This is not only easier to manage but also provides better page hosting performance. The tricky part is configuring WordPress so that is doesn’t get confused or otherwise behave in a way that would undermine our aim of providing site visitors with a secure browsing experience.

First, this article assumes that your WordPress environment is hosted on a single AWS EC2 instance, largely based on AWS’ Tutorial: Install a LAMP Web Server with the Amazon Linux AMI and Hosting a WordPress Blog with Amazon Linux.

I highly recommend using AWS Certificate Manager to create your SSL certificate. This is an especially good choice if you’re new to SSL because the certificate application process is well-documented and intuitive. Take a look at my how-to article for requesting a SSL certificate from AWS.

Now then, to get the ELB to work at all I had to get creative with a couple of things. One of my more vexing problems regarded Health Checks. The theory behind this is simple: AWS ELB’s will regularly try to ping a certain file. For any EC2 instance included in your Target Pool, if the success code returned matches up with the value in the routing configuration (the, “Success Code”) then the EC2 instance is considered healthy. Mind you, there are additional details which hopefully are self explanatory. Ok, so, in my case i host multiple virtual servers from the same Apache server, and this, along with the fact that all web sites are WordPress sites, caused problems with the default health check, which is to ping index.php. To workaround these problem I created an empty file in the root of each of my WordPress sites named health.aws. Additionally, Apache didn’t necessarily return a 200 status code; even if the file could be pinged. After some investigating I learned that — sometimes, depending on particulars of your server state — Apache might send a redirection code like say, 301, instead of a success code like 200. To work around this I added 301 as a possible valid response code, and voilá, the ELB can correctly determine the health (or lack thereof) of my EC2 instances.

And, that’s a wrap. You’ve configured your first AWS Application ELB! Now that the heavy lifting is behind us we can shift our attention to re-configuring Apache and WordPress on our EC2 instance.

You will not make any changes to your Apache configuration. If that seems counterintuitive then let me explain why. In AWS’ own support documentation they recommend that you add “X-Forwarded-Proto” headers to redirect your HTTP traffic to HTTPS, and while this is in fact the correct methodology, we cannot do this YET because if we did it would cause an infinite loop. Instead, we’re going to add these headers from within our wp-config.php file in the next section.

A little more explanation: by default Apache is installed to use HTTP (port 80), therefore all configuration for this protocol was taken care of for you when your originally setup your server. Importantly, inbound traffic originating from the ELB also is traveling over HTTP as per the diagram above and thus we a) should continue to listen on port 80, and b) we should continue to use HTTP all the way to our WordPress server. Now then, to provide an end-to-end HTTPS connection for our users we’ll need our WordPress server to return all web pages over HTTPS rather than over HTTP. We do that below. Meanwhile, following is a sample Apache virtual server configuration which contains a snippet of the code that AWS actually recommends. You can uncomment the snippet and add to your own config in order to test/verify my claim:

  ServerName blog.lawrencemcdaniel.com
  ServerAlias blog.lawrencemcdaniel.com

  DocumentRoot /var/www/html/blog.lawrencemcdaniel.com
  ServerAdmin lpm0073@gmail.com
  ErrorLog /var/www/logs/error_log_blog.lawrencemcdaniel

  #I'm leaving you with a copy of the snippet referenced above in case you want to experiment.
  #RewriteEngine On
  #RewriteCond %{HTTP:X-Forwarded-Proto} =http
  #RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]

Restart Apache

sudo service httpd restart

Here is some additional reading on how and why this configuration works:

• Apache Docs: Virtual Host Examples
• AWS X-FORWARDED-PROTO request header
• AWS Knowledge Center: How To Redirect ELB Traffic From HTTP to HTPS

We need to update the WordPress Address URL and the Site Address URL; both of which are visible within the Settings -> General console window. However, you’ll need to update these values using your wp-config.php file located in the root directory of your site.

define('WP_HOME','https://blog.lawrencemcdaniel.com');
define('WP_SITEURL','https://blog.lawrencemcdaniel.com');

// Update 8-April-2018: I moved https redirection from the Apache virtual server config to wp-config.php using this snippet.
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
       $_SERVER['HTTPS']='on';

It’s really important to be aware that Google distinguishes between HTTP and HTTPS in terms of recognizing and indexing your site. Make sure that you add your “new” HTTPS site as a new Web Property in Webmaster Tools.