CloudFront Setup for Media Offloaded to Amazon S3
This doc aims to help you start delivering your WordPress Media Library items via Amazon CloudFront as quickly as possible.
It is assumed that you’ve already set up an Amazon S3 bucket and followed the steps within our Amazon S3 Quick Start Guide.
This article covers the following steps:
- Create a free HTTPS Certificate
- Create an Amazon CloudFront Origin Access Identity
- Create an Amazon CloudFront distribution
- Add a Custom Domain (CNAME) to the distribution
- Configure WP Offload Media to use Amazon CloudFront
- Block All Public Access to Bucket
- Next Steps: Deliver private media via Amazon CloudFront
For improved SEO and more professional private media URLs when using Amazon CloudFront, we recommend following the entire doc and using a subdomain of your site’s domain for the distribution.
However, if for some reason you do not wish to use a custom subdomain for your distribution and would instead like to just use the default random domain generated by Amazon CloudFront, feel free to skip the Create a free HTTPS Certificate and Add a Custom Domain (CNAME) to the distribution sections. Other sections will mention any changes to their instructions should you not be wanting a custom subdomain.
Create a Free HTTPS Certificate
Log into the AWS Console and visit the Certificate Manager page.
Because your new certificate is to be used with the “global” Amazon CloudFront service, you must create the certificate in the default us-east-1 (N. Virginia) region. To ensure you are working in the default us-east-1 (N. Virginia) region, pick it from the top-right menu.
If you have never provisioned a certificate on your Amazon AWS account, you’ll be presented with this landing page. Click Get Started under “Provision Certificates”.
If you already have provisioned certificates, click the Request a certificate button at the top of the list of certificates.
You’ll be given the choice of creating a public or private certificate, choose Request a public certificate and then click the Request a certificate button at the bottom right of the page.
It’s now time to enter the domain name you wish the certificate to be for.
We strongly recommend using a wildcard certificate that is able to protect multiple subdomains of your site’s primary (often called Apex) domain. For this example the site is hosted at “www.hellfish.media”. In that case you should enter the domain “*.hellfish.media” so that the certificate can automatically protect the domain “cdn.hellfish.media”, but also “assets.hellfish.media” or any other subdomain of “hellfish.media” that you might want to later use with an Amazon AWS service.
If you do not wish to have the flexibility of being able to use any subdomain with other Amazon CloudFront distributions or AWS services, then you can enter the full subdomain you wish to use for the distribution, e.g. “cdn.hellfish.media”.
You can also have a certificate cover more than one domain by clicking the Add another domain to this certificate button.
Whether you add a single wildcard domain, full domain, or many domains, click the Next button to proceed.
Next you’ll be given the opportunity to add tags. Adding tags is purely optional, if you’re a heavy user of AWS you may have a reason to add tags here to help with management tasks. Whether you add tags here or not, click the Review button at the bottom of the page to continue.
You’re now presented with the domain name and method of validation that’s about to be used for the certificate request, if all looks good, click that Confirm and request button to get things started.
On the Validation page you should see that the request is “Pending” as you have not completed the validation yet.
If you didn’t take our recommendation to use DNS validation and instead picked the Email validation method, please go check your email and click a link in one of the emails you just got from Amazon AWS (you may get duplicate emails to various domain admin addresses, just use one of them).
In our example we picked DNS validation, so we need to click the little triangle next to our domain name to expand the details and see our instructions.
Once expanded you’ll see the “Name” and “Value” that need to be used to create a new CNAME entry with your DNS provider.
Tip: When copying and pasting the “Name” and “Value” from the Amazon Certificate Manager to enter into your DNS provider, you only need to hover over the “Name” and “Value” fields and use your usual copy hotkey, no need to explicitly select the text.
Open a new browser tab and log into the control panel of the DNS provider for your site’s domain. Every DNS provider has wildly different setups, but you should be able to create a new CNAME record for your domain and enter the “Name” specified by Amazon along with the “Value” as the alias or target.
For most DNS providers you only need to enter the first part of the name specified by Amazon as the provider already knows the rest of the name. You usually need to enter the full “Value”, but often the full stop (period) at the end isn’t required.
Once you’ve added the CNAME record to your DNS or clicked the link in the validation email, switch back to the AWS Console and click the Continue button on the Validation page to be taken to your list of certificates. With luck your certificate will already be validated and shows a status of “Issued” with validation status of “Success”, but it can take a few minutes for DNS changes to propagate and for AWS to see them.
Create an Amazon CloudFront Origin Access Identity
For added security and cost savings, once you have created an Amazon CloudFront distribution to deliver the media offloaded to your bucket, it’s good practice to Block All Public Access to the bucket. This ensures your media can only be accessed via your Amazon CloudFront distribution. But we must also give our Amazon CloudFront distribution access to the bucket by creating an Origin Access Identity.
You can create an Origin Access Identity later and then edit the Amazon CloudFront distribution to make it use it, but it’s much easier to create it up front so you can use it when creating a new Amazon CloudFront distribution.
If you’ve never created an Origin Access Identity, you’ll be presented with the “Get Started” page. Click Create OAI to create a new Origin Access Identity.
If you have already created Origin Access Identities elsewhere, Click the Create Origin Access Identity button at the top of the list.
Enter a clear and concise comment for your new identity that reflects which site or bucket you intend to use it with. Click the Create button to save your new Origin Access Identity.
Create an Amazon CloudFront distribution
Ensure you’re in the “Distributions” section of the AWS Console’s CloudFront page.
If you have never created a distribution on your Amazon AWS account, you’ll be presented with this landing page. Click Create Distribution.
If you already have distributions, click Create Distribution at the top of the Distributions list.
Step 1 is to select a delivery method, click the Get Started button within the top “Web” section of the page.
In the “Origin Settings” section of the “Create Distribution” page, populate “Origin Domain Name” with the Amazon S3 bucket you’ve already set up WP Offload Media to offload to. When you click into that “Origin Domain Name” field you should get a list of all your buckets, typing the first few characters of the bucket’s name will help you find it if you have a lot.
Leave “Origin Path” blank and for “Enable Origin Sheild” select the No radio button.
If you are going to follow our recommendation and later restrict direct access to the bucket by enabling Block All Public Access on the bucket, select the Restrict Bucket Access radio button. Ensure the Use an Existing Identity radio button is selected as the “Origin Access Identity”, and then select the Origin Access Identity you created earlier.
For the “Grant Read Permissions on Bucket” field, select Yes, Update Bucket Policy.
The “Default Cache Behavior” section can be left alone, its default values are fine in most cases.
Please do not be tempted to select the Restrict Viewer Access (Use Signed URLs or Signed Cookies) option, even if you intend to use Signed URLs for WooCommerce or Easy Digital Download product file downloads. We have a doc for enabling Private Media that helps you use signed CloudFront URLs with WP Offload Media while still being able to serve offloaded images and other media to general site visitors.
In the final Distribution Settings section of the Create Distribution page, enter the custom subdomain you’d like to use for delivering the offloaded media into the Alternate Domain Names (CNAMEs) field. If you’re not using a custom domain, leave this blank. In the example below we’re using “cdn.hellfish.media” as the domain we’d like to serve offloaded media from.
For the SSL Certificate option, select Custom SSL Certificate (example.com), then pick the certificate you created earlier. If you’re not using a custom domain for the delivery of media skip this and leave Default CloudFront Certificate (*.cloudfront.net) selected.
Feel free to customize the remaining options if required, but the defaults are fine in most cases.
Click Create Distribution. Amazon CloudFront will begin deploying the new distribution configuration to its edge servers. This can take a while.
Once the Distribution is created, take a note of the default “cloudfront.net” domain name assigned to the distribution, you’ll need that when adding the CNAME record to your DNS for your custom domain.
Add a Custom Domain (CNAME) to the distribution
While the new Amazon CloudFront distribution is deploying, you can go ahead and add the CNAME record to your DNS to point your custom domain at your distribution.
Log back into your DNS provider’s control panel and create a new CNAME entry for the chosen subdomain.
In the example below we’ve entered “cdn” as the subdomain which means the full domain will be “cdn.hellfish.media”, and then for the target we’ve entered the default “cloudfront.net” domain that was assigned to our new Amazon CloudFront distribution.
If you’re also using Cloudflare, make sure to turn off the proxy cache by clicking the orange cloud image and change the “Proxy status” from “Proxied” to “DNS only”.
Configure WP Offload Media to use Amazon CloudFront
Once the new Amazon CloudFront distribution’s Status has changed from In Progress to Deployed, you can configure WP Offload Media to start using the custom or default domain associated with it.
Head over to your WordPress site. Visit the WP Offload Media settings page and click the Change link next to the Delivery Provider, which should currently say “Amazon S3”.
Pick Amazon CloudFront as the new Delivery Provider, then click the Save Delivery Provider button to save your changes.
In the Delivery section of WP Offload Media’s settings page you should now see “Amazon CloudFront” as the Provider, and a new Custom Domain (CNAME) option, which is turned off by default. Toggle that switch on.
You now have a text box where you should enter the custom domain you chose for the Amazon CloudFront distribution, in our example we’ve entered “cdn.hellfish.media”. If you chose not to use a custom domain for your Amazon CloudFront distribution, enter your distribution’s cloudfront.net domain.
You’ll also see a new Private Media option. Leave that turned off for the moment. Later you can use our Private Media doc to configure signed CloudFront URLs for any private media or downloads you wish to serve to customers.
Click the Save Changes button to start serving your offloaded Media Library items via Amazon CloudFront while using your custom domain.
It’s a good idea to quickly check that all is in order, and an offloaded Media Library item is being served by Amazon CloudFront. Hop on over to the site’s Media Library and find an offloaded image, click on it to view its details.
If you used grid mode for viewing the Media Library, then you should see something like below, with the image displayed, and “File URL” near the bottom of the right-hand sidebar showing the expected custom domain.
If you used list mode for viewing the Media Library, then you should see something like below, with the image displayed, and “File URL” near the top of the right-hand sidebar showing the expected custom domain.
Block All Public Access to Bucket
Now that your Media Library is being served via Amazon CloudFront, you can now lock down the bucket so that no one can access its files directly. Blocking all public access to the bucket improves security, but also ensures no one accidentally uses the slower direct S3 URLs that also incur charges per request.
This of course means that if you are aware of any external links to your offloaded media that use the default raw S3 URL format (e.g.
https://hellfish-media.s3.us-east-1.amazonaws.com/…), you should not enable Block All Public Access. If there are raw S3 links on other sites other than the site that offloaded the media, but you do not care about breaking those links or explicitly want to break those links because their unauthorized use is costing you money, then by all means carry on and enable Block All Public Access to the bucket.
Before we turn on Block All Public Access for the bucket, let’s double-check that when we set up the Amazon CloudFront distribution and told it to update the Origin bucket’s policy to specifically grant the distribution’s Origin Access Identity permission, that it actually did so.
Visit the AWS Console’s S3 page and click on the name of the bucket your site is offloading to. You should see something like below.
Click on the Permissions tab, and then scroll down to the “Bucket Policy” section.
You should see something similar to below, but most importantly, it should include a “Principal” element that includes a reference to a CloudFront Origin Access Identity.
If you do not see something similar in the bucket’s policy, please return to the CloudFront section of the AWS Console, edit the CloudFront distribution’s Origin, and re-select Yes, Update Bucket Policy again before saving it. There’s further details in our Block All Public Access to Bucket doc.
To turn on Block All Public Access to Bucket and ensure WP Offload Media knows about it, switch back to WP Offload Media’s settings page and click the “Change” link next to the bucket name in the Storage section.
On the “What bucket would you like to use?” prompt, just click the Save Bucket Setting button as there are no changes needed here.
You’re now given the opportunity to change the bucket’s Block All Public Access setting. Check the box to confirm that you’ve set up the Origin Access Identity and have a correct bucket policy, then click the Enable “Block All Public Access” button.
WP Offload Media will now update the bucket’s Block All Public Access setting to fully enable it. You should be returned to WP Offload Media’s settings page and be able to see that the bucket is now reporting that Block All Public Access is enabled (this info is retrieved by WP Offload Media via the S3 API).
At this point it’s probably a good idea to visit your Media Library and add a new image to confirm that it is correctly offloaded to the Amazon S3 bucket and delivered via Amazon CloudFront. If there are any errors please review the instructions above and check that the bucket and distribution are set up correctly.
Next Steps: Deliver private media via Amazon CloudFront
Now that your WordPress site is offloading its Media Library items to a protected Amazon S3 bucket, and delivering that media via an Amazon CloudFront distribution, you may also want to serve private files via signed CloudFront URLs that expire after a few seconds. Offering WooCommerce or Easy Digital Downloads product files is a good example of this.
By default WP Offload Media creates signed expiring URLs that use the raw S3 URL format (e.g. https://hellfish-media.s3.use-east-1.amazonaws.com/…), this will continue to work even if Block All Public Access has been enabled. However, wouldn’t it be nice to serve those product downloads via Amazon CloudFront for improved speed, reduced costs, and better branded URLs?
Hop on over to our How to Serve Private Media via Signed Amazon CloudFront URLs doc to configure WP Offload Media’s “Private Media” setting.