aws lightsail wordpress

Boosting Lightsail WordPress performance with a CDN on AWS Cloudfront

Tutorials / By

Amazon Lightsail performance

AWS Lightsail is very fast, as long as you set it up properly. To improve the page loading speed for clients you need to use a CDN, so that copies of pages are stored at different locations around the world and the viewer gets a copy from the location closest to them.

It’s quite easy to set up a Cloudfront CDN for WordPress AWS and it doesn’t affect the Lightsail cost very much because transfers between Lightsail and Cloudfront are free. Instead of paying for traffic served directly by Lightsail you instead pay fro traffic served by Cloudfront.

You can also specify geo-blocking with white lists or black lists to reduce cost from serving pages to countries you aren’t interested in.

AWS Lightsail CDN documentation and terminology

Cloudfront documentation – https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-overview.html

Lightsail docs – https://d1.awsstatic.com/whitepapers/wordpress-best-practices-on-aws.pdf

Terminology

  • Origin – where you store the original version of your content
  • Cloudfront domain name – generated by AWS, the address of your Cloudfront distribution. domain.cloudfront.net
  • Alternate domain names – CNAMEs specified when creating distribution, can be used instead of the Cloudfront domain name
  • Behaviour – configure how CDN uses caching when serving content from the origin

Setting up an AWS Cloudfront CDN for Amazon Lightsail

If you’ve just set up Lightsail you will most likely have Route 53 DNS record sets pointing your domain name at the IP address of your Lightsail server. After creating a cloudfront distribution those records are changed to point at the distribution.

For the distribution to see your Lightsail server, create a new sub-domain Alias record pointing at your Lightsail IP, called lightsail.yourdomain.etc.

Create an SSL Certificate

We will require HTTPS between viewers and Cloudfront, and between Cloudfront and your origin, assuming you have set up HTTPS on your origin (ie your Lightsail instance).

You must use US East to create an SSL cert when requiring HTTPS between viewers and Cloudfront.
Between Cloudfront and your origin you can use any region when creating SSL Cert.

Go to AWS Certificate Manager, choose US East 1, and Request new public certificate.

Add your domain name. If you want to cover subdomains like www.domain.etc or images.domain.etc then add another domain name and enter *.yourdomain.etc

Choose DNS validation. Expand the domain and click create record in route 53. Refresh & confirm, wait for validation.

Create a Cloudfront distribution

Choose a Web distribution and then it’s just a case of filling in all the values. Note: you’ll see different form entries depending on what you specify as the origin domain name.

  1. Origin domain name: lightsail.yourdomain.etc (you need a Route 53 Alias record for this subdomain aliasing your Lightsail IP)
  2. Origin path: blank
  3. Origin ID: whatever name you like
  4. Origin protocol policy: HTTPS Only – we want HTTPS between Cloudfront and Lightsail
  5. Viewer protocol policy: redirect HTTP to HTTPS
  6. Allowed HTTP methods: For WordPress, you need to allow all
  7. For cached HTTP methods, check OPTIONS as this can safely be cached with WordPress
  8. Create a cache policy as discussed below
  9. Also choose Compress objects automatically
  10. Alternate domain names: yourdomain.etc and *.yourdomain.etc

Leave others as defaults and create the distribution.

Cloudfront cache settings for Lightsail

For caching there is a new option to use a managed caching policy.

The caching settings here control the CDN cache TTL when there are no cache control headers from the origin. The default CachingOptimized policy will default to 24 hours where there are no cache control headers from the origin. You could reduce this to 5 mintues or whatever you need, by creating your own policy.

In the next article we will see how to specify cache control headers from the origin.

You can’t use the CachingOptimized policy with Lightsail. Instead you need to create a new policy and whitelist headers and cookies so that they are forwarded to the server. Without doing this, there will be one cache for all viewers regardless of headers that WordPress uses to control the display.

Whitelist these headers:

Cloudfront-Forwarded-Proto
Cloudfront-Is-Desktop-Viewer
Cloudfront-Is-Mobile-Viewer
Cloudfront-Is-Tablet-Viewer
Host
Options

You also need to whitelist these cookies for WordPress to function properly:

comment_*
wordpress_*
wordpress_sec_*
wordpress_test_cookie
worpdress_logged_in_*
wp-settings-*

For query strings choose All.

Additional distribution behaviours required for Lightsail WordPress

The default distribution will work for most things but not all. We need to add some behaviours with different cache settings for different WordPress functions. Go to the behaviours tab. We have one default behaviour.

We need behaviours for the following paths:

*-login.php
wp-admin/*
wp-json/*

Click Create behaviour and specify the path pattern. For all these paths we don’t want caching because it is dynamic content for administrators. Choose the managed CachingDisabled policy.

You can also create behaviours for additional paths *.css and *.jpg, *.js, *.png etc. For these you want to only allow methods GET, HEAD, OPTIONS, whitelist the headers Cloudfront-Forwarded-Proto and Host, and do not cache on cookies (forward no cookies) but do forward all query strings (to support versioning)

Connect your domain to the distribution

In Route 53, change the domain Alias that points to your Lightsail IP, updating it to the domain of your new Cloudfront distribution (shown in the Cloudfront distributions list).

Settings for Cloudfront distributions

Documentation for all available values when creating distribution.

Here are what all the various values mean.

  1. Delivery method – Web. Use RMTP for Flash Media Server
  2. Origins – one or more S3 buckets or webservers
    1. Domain name – DNS domain name, not an IP address
      1. S3 bucket or S3 website my-s3.blah.amazonaws.com or https://my-bucket.blah.amazonaws.com
      2. EC2 instance – my-ec2.blah.amazonaws.com
      3. ELB load balancer – my-elb.blah.amazonaws.com
      4. Web server eg https://my.com
    2. Origin path – if you want to serve from a sub-directory
    3. Origin ID – unique ID for this origin, used in behaviours
    4. Origin access identity – only if using S3 bucket with restricted access
    5. Minimum Origin SSL protocol – protocol Cloudfront will use when connecting to your origin with HTTPS
    6. Origin protocol policy – How Cloudfront will connect to your origin
    7. Timeouts – use defaults
    8. Ports – use defaults
    9. Custom headers – optional, if you need to pass headers to your origin server, for example if you want to restrict access to only come through your CDN instead of direct to the server IP
  3. Cache behaviour
    1. Path pattern – eg just images *.jpg. Remember sequence of behaviours matters
      1. Applies to sub directories. Ignores query strings or cookies
      2. Use * (0 or more chars) or ? (exactly 1 char)
    2. Viewer protocol – redirect to HTTPS
    3. Allowed HTTP methods
      1. Choose according what’s being served
      2. Only GET, HEAD, OPTIONS will ever be cached, but you can allow or disallow others
    4. Cache on headers – All means no caching. Whitelist headers if there is different content for different users based on headers.
    5. Object caching – rely on origin cache headers, or override them. origin cache headers may be configured for end-users browser caching so you may want to adjust CDN caching. eg Max TTL lower to force CDN to update even if browser caching set for a long time
    6. Cookies – forward what your app uses. More cookies means less caching
    7. Smooth streaming – real-time video streaming optimisation.
    8. Compress automatically – yes to enable gzip
  4. Details
    1. Price class – Choose the cheapest according to where your users will be
    2. Alternate domain names – the domain you want to serve on, and have an SSL cert for
    3. SSL cert – choose custom and select SSL cert created in part 3 step 2
  5. Default root object – not needed
  6. Logging – will incur S3 storage costs
  7. Restrictions – Geo restrictions to limit cost and hacking, eg if you don’t expect users in specific countries to use it
Scroll to Top