CloudFront Distribution Creation - Best Practices for WordPress on AWS

CloudFront Distribution Creation

Create a CloudFront web distribution by following the Distribution, the default Origin and Behavior automatically created will be used for dynamic content. Create four additional behaviors to further customize the way both static and dynamic requests are treated. The following table summarizes the configuration properties for the five behaviors. You can also skip this manual configuration and use the AWS for WordPress plugin covered in Appendix B: Plugins Installation and Configuration, it is the easiest way to configure CloudFront to accelerate your WordPress site.

Table 1: Summary of configuration properties for CloudFront behaviors

Property Static Dynamic (admin) Dynamic (front end)
Paths (Behaviors)

wp-content/*

wp-includes/*

wp-admin/*

wp-login.php

default (*)
Protocols HTTP and HTTPS Redirect to HTTPS HTTP and HTTPS
HTTP methods GET, HEAD ALL ALL
HTTP headers NONE ALL

Host

CloudFront-Forwarded-Proto

CloudFront-Is-Mobile-Viewer

CloudFront-Is-Tablet-Viewer

CloudFront-Is-Desktop-Viewer

Cookies NONE ALL

comment_*

wordpress_*

wp-settings-*

Query Strings YES (invalidation) YES YES

For the default behavior, we recommend the following configuration:

  • Allow the Origin Protocol Policy to Match Viewer, so that if viewers connect to CloudFront using HTTPS, CloudFront connects to your origin using HTTPS as well, achieving end-to-end encryption. Note that this requires you install a trusted SSL certificate on the load balancer. For details, see Requiring HTTPS for Communication Between CloudFront and Your Custom Origin.

  • Allow all HTTP methods since the dynamic portions of the website require both GET and POST requests (for example, to support POST for the comment submission forms).

  • Forward only the cookies that vary the WordPress output, for example, wordpress_*, wp-settings-* and comment_*. You must extend that list if you have installed any plugins that depend on other cookies not in the list.

  • Forward only the HTTP headers that affect the output of WordPress, for example, Host, CloudFront-Forwarded-Proto, CloudFront-is-Desktop-Viewer, CloudFront-is-Mobile-Viewer, and CloudFront-is-Tablet-Viewer:

    • Host allows multiple WordPress websites to be hosted on the same origin.

    • CloudFront-Forwarded-Proto allows different versions of pages to be cached depending on whether they are accessed via HTTP or HTTPS.

    • CloudFront-is-Desktop-Viewer, CloudFront-is-Mobile-Viewer, CloudFront-is-Tablet-Viewer allow you to customize the output of your themes based on the end user’s device type.

  • Forward all the query strings to cache based on their values because WordPress relies on these, they can also be used to invalidate cached objects.

If you want to serve your website under a custom domain name (that is, not *.cloudfront.net), then enter the appropriate URIs under Alternate Domain Names in the Distribution Settings. In this case, you also need an SSL certificate for your custom domain name. You can request SSL certificates via the AWS Certificate Manager and configure them against a CloudFront distribution.

Now, create two more cache behaviors for dynamic content: one for the login page (path pattern: wp-login.php) and one for the admin dashboard (path pattern: wp-admin/*). These two behaviors have the exact same settings, as follows:

  • Enforce a Viewer Protocol Policy of HTTPS Only.

  • Allow all HTTP methods.

  • Cache based on all HTTP headers.

  • Forward all cookies.

  • Forward and cache based on all query strings.

The reason behind this configuration is that this section of the website is highly personalized and typically has just a few users, so caching efficiency isn’t a primary concern. The focus is to keep the configuration simple to ensure maximum compatibility with any installed plugins by passing all cookies and headers to the origin.

The AWS for WordPress plugin covered in Appendix B automatically creates a CloudFront distribution that meets the preceding configuration.

By default, WordPress stores everything locally on the web server, which is block storage (Amazon EBS) for single server deployment, and file storage (Amazon EFS) for elastic deployment. In addition to reducing storage and data transfer costs, moving static assets to Amazon S3 offers scalability, data availability, security and performance. There are several plugins that make it easy to move static content to Amazon S3; one of them is W3 Total Cache, also covered in Appendix B: Plugins Installation and Configuration.