A Content Delivery Network (CDN), is a network of servers around the world that cache your static assets, reducing the load on your primary web servers. AWS’s CloudFront CDN is easy to use, quick to set up, and cheap to run.

What Is CloudFront?

There are two main uses for a CDN. Most commonly, they are used to host large static content that would be infeasible to host on a traditional web server—things like large videos, images, or other large static media. CloudFront uses S3 for this purpose; you can put all of your images and videos in an S3 bucket, and configure CloudFront to serve that bucket.

Actually, if you don’t need server-side processing, you can even configure an S3 bucket to host an entire website, which works particularly well for client-side JavaScript applications built using frameworks like React. In this setup, CloudFront is used to provide a resilient delivery network around the world, and ensure the lowest possible latency to every user.

Since CDNs cache content around the world, they’re also used as another layer of cache for your entire website. For many pages, you don’t need to be serving it directly from your web server. Especially for WordPress sites, where there is server side processing going on for every request, this can put enormous strain on your servers. Instead, CloudFront sits in front of it, and handles the bulk of the load.

As far as cost goes, CloudFront isn’t that expensive. You simply are charged based on data transferred out (like most AWS services) and the number of HTTP requests being served. Data transfer pricing depends on the region, but is $0.020 per GB for the US and EU. Request pricing is $0.01 per 10,000 HTTPS requests. This is comparable to other competitors like Fastly.

Requesting a Certificate From ACM

If you plan on using your own URL (rather than *.cloudfront.net), you’ll have to request a new SSL/TLS certificate from AWS’s Certificate Manager (ACM). For some reason, there’s no way to refresh the dropdown for choosing a certificate when setting up a CloudFront distribution, so you’ll have to request this certificate beforehand.

It’s worth noting that this is actually entirely free SSL—a service that many companies will charge you hundreds of dollars for. While LetsEncrypt does offer free SSL, it’s something that needs to be renewed every few months with a cron job (granted, it is configured automatically, so it’s not a huge hassle). Certificates provisioned with ACM however will automatically renew, and never expire as long as they’re in use.

Head over the the ACM Management Console, and provision a new public certificate. Enter in the domain names you will be using (e.g., yourdomain.com, and *.yourdomain.com).

For each domain, you’ll have to verify that you own it by creating a new CNAME record in your DNS. If you’re using AWS’s own Route 53 DNS, you can click the button to create these records automatically.

This may take a few minutes to process. Once it’s validated, you’ll see the orange “Pending Validation” turn to a green “Issued,” and you can move on to setting up CloudFront.

Getting Started With CloudFront

Head over to the CloudFront Management Console, and create a new Web distribution. The other option is RTMP, used exclusively for streaming live video. For most cases, web is probably what you want.

First, you’ll have to configure your origin. If you’re using an S3 bucket, you can select the bucket from this dropdown. If you’re using a Load Balancer in front of your EC2 instances, you should select that. Otherwise, enter in the URL of your site.

You’ll want to enter in your site name for the Origin ID, which is just used to identify it to CloudFront. If you want, you can also set custom headers that CloudFront will send to your site when making a pull request.

The default setting is to use both HTTP and HTTPS. You probably should redirect all traffic to HTTPS. Make sure not to choose “HTTPS Only,” as this will cause all HTTP traffic to error out instead of being redirected.

Next up, you’ll need to determine how you want to handle caching. If you leave the default of “Use Origin Cache Headers,” CloudFront will use the Cache-Control headers from your web server.

You can also choose to use CloudFront’s custom behaviours system. Either way, you’ll have to manually protect routes that you don’t want to get cached—things like authenticated user pages should never be cached.

Under SSL Certificate, choose to use a custom SSL certificate from ACM. Select the certificate you created earlier.

That should be all the configuration you’ll need. Click “Create Distribution.” CloudFront will take around twenty minutes to get everything all set up (there’s a lot of edge locations to configure). Once it’s done, you should see your distribution is “Enabled.”

You won’t be able to access it from you custom URL just yet though. Under “Domain Name,” copy your distribution’s domain name, which should like something like this:

You’ll want to add this as a CNAME record in your DNS. This does require two DNS lookups, so if you’re pinching for performance, you’ll want to switch over to AWS’s own Route 53 DNS service, which offers the ability to create “A Alias” records, which will dynamically point towards a specific AWS resource.

Once your DNS updates, your distribution should be available from your own domain name.

Configuring Custom Caching

If you chose to use CloudFront’s custom cache settings, you’ll have to add more rules for specific routes, under the “Behaviors” tab.

If you want to prevent a path from being cached, enter in zero for the maximum and default TTL. You can also manually choose to fetch the Cache-Control headers from the origin for certain paths, even if you’ve set a default, site-wide TTL.