The focus of this article is on showing how to configure your WordPress installation to improve speed using the AWS CloudFront CDN and enhance security using AWS WAF. This builds on the earlier posts where we have deployed WordPress on an AWS EC2 instance, configured its database on an AWS MySQL RDS instance and enabled ElastiCache for memcached. Obviously, you don’t need to do all that, but you can! At least, it is important to show you what we did earlier so that you have an idea of our existing configuration, i.e., what we are working with here.
Create your AWS CloudFront distribution
Presuming your WordPress site is up and running already, what we need to do now is to create your AWS CloudFront distribution. In this case, we are looking at a HTTPS only distribution, with default settings and the latest (secure at this time) version of TLS 1.2 enabled only. I entered my domain name, you enter yours instead (wherever you see “ars.md” in the screenshots below).
You can enable Origin Shield if desired, although not mandatory, and a setting you can return to later if need be. It does incur additional charges on AWS.
Cache behavior is set as shown below and we will forward HTTP to HTTPS.
The default cache policy will be set as shown below, but we will return to this section later on.
You can proceed if you wish, without enabling WAF. If you do so, you will gain the advantages and speed of the CloudFront CDN, without the security benefits of WAF. Perhaps you have a 3rd party WAF enabled or, for now, are not interested in this functionality. That’s fine. You can always change this later.
If you already changed your mind, or decided to enable WAF, it may be a good idea to start it in Monitoring mode initially. Depending on your WordPress setup and the plugins you have running, the WAF can wreck your installation badly, i.e., break things. Enabling SQL protection is a good idea, and if monitoring mode is enabled, this will also be in monitoring mode, but can be un-monitored separately later on.
Now, to continue with the CloudFront setup, I use it to create a new certificate for my domain and serve the website using the CloudFront certificate. Before, the site was served using a Let’s Encrypt certificate. Once the configuration is updated, you should see the SSL certificate changed to the Amazon one. As far as I know, this SSL certificate is provided free of charge.
And finally, some last options to look into (below). I am disabling IPv6 as I do not use it, but that is up to you.
At last, you should see your distribution deploying and fingers crossed, soon ready.
Add custom policies to CloudFront
We will need to add four custom policies which we will use when setting up the behaviors in the next section below.
The four policies are named in this case: wp-default, wp-admin-login, wp-contnet-includes and WordPressDynamicContent. Here is the configuration for each starting with wp-default:
The policy “wp-admin-login”:
The policy “wp-content-includes”:
And, finally, WordPressDynamicContent:
Add behaviors to your CloudFront distribution
This is an important “make it or break it” part of this article. I tried several configurations and this is the one that worked for me, hence it is the one that I share and hope it works for you also. If you navigate to your CloudFront distribution, and then to Behaviors, you need to add the following behaviors.
Let’s go ahead and create a behavior. Here is the configuration of the wp-admin behavior. Your “Origin and origin groups” should display your own domain which should be selected for all the behaviors below.
Same for wp-login:
And the settings for the default behavior:
Configuration of AWS WAF
Assuming you have created a WAF distribution above, you should see it once you browse to the AWS WAF page. Try this link if it helps. If you do not see your WAF distribution, then make sure to change region from the region dropdown to Global (if set to something else).
Click on the Distribution name. Under rules, you can add the managed rule groups that are relevant to you. These are the ones I think should be relevant here:
- Amazon IP reputation list,
- Known bad inputs,
- Linux operating system,
- PHP application,
- SQL database, and
- WordPress application. You will find all these under the category “Free rule groups” once you click on “Add rules” (below top right) and “Add managed rule groups”.
Final step – Setting up Route 53
For this to work, you will need to have your WordPress domain (hosting zone) on Route 53. What I did nexy is to edit the A records for both “ars.md” and “www.ars.md”, enabling the alias mode, and selecting the newly created CloudFront distribution from under the US East (N. Virginia) option. I had to select a region but see the actual CloudFront distribution in the list.
If you have any problems with this step, go change the settings of your CloudFront distribution and add your domain(s) in its configuration. See below. Then return to Route 53 and try again.
If you made it this far, I’m impressed. I hope this helped you and if not, please let me know what can be improved or clarified in the steps above.
Note: If you use W3 Total Cache or another caching plugin, I have had issues with CloudFront and “Browser caching”. The browser caching rules that were added by W3 Total Cache into the default WordPress .htaccess file, especially any Expires directives, were breaking the site via CloudFront. For now, I opted to keep Browser Caching enabled in W3 Total Cache but disabled all options under it. That seems to work well with CloudFront. May need to get back to this in the future.