DEV Community: Dave Sugden

Setting up a custom domain in CloudFront

Dave Sugden — Sat, 15 Feb 2020 22:13:45 +0000

A beginner-level tutorial to demonstrate how to set up a custom domain in CloudFront, with a managed SSL Certificate and DNS via Route 53.

This post is part of a wider series documenting my journey in migrating a traditional LAMP website over to a Single Page Application running on the Amazon Web Services platform. Here, I will focus on configuring a custom domain for my CloudFront distribution.

CloudFront is Amazon’s low-latency Content Delivery Network (CDN). Using a CDN speeds up the distribution of content to visitors by serving content from edge locations that are closest to the user.

Delivering content from Amazon S3 using CloudFront edge locations

At the time of writing, Amazon has 216 Points of Presence (205 Edge Locations and 11 Regional Edge Caches) in 84 cities across 42 countries.

When you set up your CloudFront distribution, straight out of the box with the default settings you will have your own cloudfront.net domain.

(that is assuming you have already configured CloudFront in front of an S3 bucket that holds your static web content, but if not check out this guide on serving static content from S3 using CloudFront and come back)

Serving static content from S3 using CloudFront and Origin Access Identity

Dave Sugden ・ Feb 9 ・ 5 min read

#aws #cloudfront #s3 #tutorial

But what if you want to serve your content from my-custom-domain.com.

To use a custom domain requires a combination of Route 53 — Amazon’s highly available and scalable cloud DNS web service — and some additional configuration CloudFront. It doesn’t take too long to set up.

Before we start, I assume that you have your domain managed in Route 53; it doesn’t matter if you don’t, but this guide assumes you do.

There is an initial step to obtain an SSL Certificate within Certificate Manager. This allows you to serve your content over https and is a service provided by Amazon for free, and they’ll also take care of its renewal.

Within the Certificate Manager service, make sure you change your region to North Virginia; I cannot emphasize this one enough as it’s caught me out many a time. Then Request a Certificate.

The form is pretty self explanatory and you’ll need to provide a means to prove you own the domain — if you’re using Route 53, and we assume you are, then selecting the option that Amazon automatically manages the validation is the simplest approach. The process usually takes a few minutes.

Now head over to CloudFront and set up your custom domain. This can be done at the time of creating the distribution, but don’t worry if you forgot — you can go back and edit all these settings later.

The first setting is to list all your Alternative Domain Names in the CloudFront distribution settings.

Add all your domain names to CloudFront distribution settings

The second setting is to reference the SSL Certificate you created. Check the Custom SSL Certificate (example.com) option and pick your SSL Certificate from the list. Warning; your Alternate Domain Names must match those you specified in the SSL Certificate provisioning request — so if you don’t see your certificate in the list, that is probably the reason.

With these settings done, the final step is to configure the DNS in Route 53.

In your domain hosted zone in Route 53, select to Create Record Set.

We will be creating as an A record for IPv4 and we’ll select the Alias option.

In the Alias Target, you will find your CloudFront distribution — select and save. Warning; your Alternate Domain Names you configured in CloudFront must match the record set name — so if you don’t see your CloudFront distribution in the target drop down list, that is probably the reason.

Repeat to create an AAA record for IPv6.

And that’s it. Success. You will find that you;

✔️ are now able to view your website using my-custom-domain.com, with all the added benefits of CloudFront providing edge locations around the world to reduce latency for your visitors.
✔️ have an SSL Certificate that is managed by Amazon and will be automatically renewed for you (at the time of writing, it’s free).

Variations. If you don’t use Route 53, the final step will be to add a CNAME entry in your DNS settings and set the value to your CloudFront domain.

Serving static content from S3 using CloudFront and Origin Access Identity

Dave Sugden — Sun, 09 Feb 2020 19:35:09 +0000

This tutorial demonstrates how to restrict access to an S3 bucket so that your html, css, and images, are only accessible through CloudFront.

This post is part of a wider series documenting my journey in migrating a traditional LAMP website over to a Single Page Application running on the Amazon Web Services platform. Here, I will focus on the static content and setting up CloudFront as my CDN.

Using Amazon Simple Storage Service (Amazon S3) is a cheap and effective way to host static websites and other web content.

You can do so directly from the S3 console by enabling the Static website hosting feature and you’ll get a website of the form http://my-bucket-name.s3-website-eu-west-1.amazonaws.com. You can also create an A-record in Route 53 to use your own custom domain.

Basic set up — hosting a static website in S3

Some solutions may stop here. For some, this is good enough. (but this is not the purpose of our article; it would be incredibly short if it was).

More likely the solution will evolve toward serving content from edge cache locations using CloudFront — Amazon’s low-latency Content Delivery Network (CDN). Using a CDN both speeds up the distribution of content to visitors and will also reduce the overall cost for a busy site.

Introducing CloudFront as our Content Delivery Network

Even with the CDN our visitors can still access the S3 static website directly, and the Solution Architect will now be asked “how do we restrict access to the S3 bucket so that our html, css, and images, are only accessible through CloudFront?” (this question is the purpose of this tutorial).

The answer is to use Origin Access Identity (OAI).

We can restrict public access to objects in the S3 bucket — as of today, this is the default setting when creating a new bucket — and we grant permission to the OAI to distribute the content through CloudFront to our visitors from around the world. We no longer need to configure S3 to host a static website.

The steps we follow to achieve this solution are;

Create the S3 bucket with default settings and upload an index.html file (index.html will not be accessible directly from S3).
Create a CloudFront distribution with the S3 bucket as its origin (index.html still cannot be accessed).
Set up the OAI, and configure a policy that permits CloudFront to serve the index.html file (now it all works).

Steps 2 and 3 would normally be applied at the same time, but I’ll demonstrate separately to show the individual steps and how the OAI is the bit of magic sugar in the solution.

Step 1. Create the bucket in S3 that will hold the static content and use all the default settings. The bucket and its objects are not accessible to the public.

S3 Bucket holding our static website content

When we attempt to reach the index.html file in a browser, we get an Access Denied error as expected.

Hitting index.html on S3 endpoint receives an Access Denied error

Step 2. In CloudFront, create a Web distribution and select the S3 bucket as the origin. At this stage, leave everything else as the default settings, scroll to the bottom and create the distribution. You’ll have to wait until it’s deployed and as this can take 10 minutes, go grab a coffee...

Our CloudFront distribution for our S3 origin

Once its status has changed to “Deployed”, it’s ready. At this stage, the index.html page is not accessible on the CloudFront domain.

Hitting index.html on CloudFront endpoint receives an Access Denied error

Step 3. Create the Origin Access Identity and configure the policy in S3 that grants the OAI permission to access objects.

Since we’re doing this in two stages, we have to edit our existing Origin to access the OAI option; however, usually you would do this at the same time as creating your Web distribution and it’s on the initial list of options.

Select our origin and click Edit

On the next page, select Restrict Bucket Access, allow Amazon to Create a New Identity, and choose Yes, Update Bucket Policy.

Select the options and save

Wait for the status to change to “Deployed” again, and then refresh the page and the index.html page will now be displayed.

Our static content is now served correctly via CloudFront

All set. Success.

✔️ CloudFront edge locations are serving our static content in S3.
✔️ And no one can hit the content in S3 directly.

Check the direct S3 endpoint again just to be sure that remains blocked, and view the Bucket Policy in S3 that was added automatically to learn more.

What we didn’t cover today. Most solutions are also likely to require;

a custom domain that is configured in Route 53 and CloudFront;
an SSL certificate from Amazon Certificate Manager so that content can be served over https;
and have cache expiry limits set on the objects.

AWS - custom domain + CloudFront + SSL + Route 53 | Medium

Dave Sugden ・ May 3, 2020 ・ 4 min read
Medium

In addition, if you have built a Single Page Application (SPA), like Angular or ReactJS, then you may need to configure CORS.

Finally, we didn’t cover off creating signed URLs, which is useful if you are distributing paid-for content and want to limit access to your edge location caches.

These will be subject of further posts in this series.

DEV Community: Dave Sugden

Setting up a custom domain in CloudFront

Serving static content from S3 using CloudFront and Origin Access Identity

Dave Sugden ・ Feb 9 ・ 5 min read

Serving static content from S3 using CloudFront and Origin Access Identity

AWS - custom domain + CloudFront + SSL + Route 53 | Medium

Dave Sugden ・ May 3, 2020 ・ 4 min read Medium

Dave Sugden ・ May 3, 2020 ・ 4 min read
Medium