Add a Custom Domain and HTTPS to Your Website

Overview

Note: This tutorial assumes you've already completed the steps in Create a Static Website.

Adding a custom domain and HTTPS to your AWS website can lend some polish and professionalism. It's also a good idea since Google Chrome (and possibly other browsers) have started to warn users about non-secure HTTP sites.

In addition to S3, there are a few key AWS services we'll need to wire up this type of architecture:

The overall architecture sounds a bit complicated, but it boils down to this:

User -> mydomain.com (Route53) -> CloudFront domain -> S3

And the good news is that because we're using AWS, the overall process is dramatically simpler than a more traditional strategy that involves separately purchasing a domain and (pricey) SSL certificate, setting up a web server, and configuring DNS.

Get a custom domain

You don't necessarily have to purchase a domain through Route 53, but it dramatically simplifies donwstsream DNS configuration.

Acquire an SSL certificate for your domain

Go to the AWS Certificate Manager service to request a public SSL certificate for your domain.

Below, we use example.com to demonstrate the workflow. During this process, you must substitute the domain name you purchased in the prior step of the tutorial (e.g. data-driven.news).

On the next screen in Certificate Manager, you should see that the request is in progress. This process can take a while (about 20-30 minutes). Before leaving this page:

Again, you should do this 3 times - once for each CNAME record.

Now click Continue. You'll likely see that the Status of the certificate is "Pending validation". This process can take a few minutes and is only complete when the certificate has a status of "Issued". You must wait until this process is complete before proceeding to the next stage, where we'll set up the CloudFront Distribution.

Set up HTTPS

The final few steps involve using AWS Route 53 and CloudFront to route viewers of your custom domain to the S3 bucket you set up at the beginning of this process.

This involves:

Create a CloudFront Distribution

In this step, we'll set up a CloudFront distribution that can serve HTTPS requests for the S3 bucket.

Pre-flight check

Before beginning this step, please verify that the SSL certificate you requested in the last step has a Status of "Issued".

In order to create a distribution, we'll need to grab the S3 website endpoint for our bucket. To retrieve this URL:

Create the distribution

With the S3 website URL in hand, we're ready to create the distribution in CloudFront.

You should now see a data entry form for the distribution, which you should fill out as follows:

Once again, this process can take up to 20-30 minutes. You can view the progress by clicking on Distributions in the upper left corner of the CloudFront console, and checking the Status column. When the In Progress indicator has changed to Deployed, you can hop over to Route 53 for the final step in the process.

See these steps for more background on the above.

Before heading to Route 53, be sure to grab the unique domain name generated by CloudFront. This can be retrieved by:

Stash this domain away. You'll need it in the next step.

Create Route 53 Alias

For this final step, you must create a DNS Alias record in Route 53 that points all traffic from your domain to the CloudFront-generated domain.

You should now be able to visit your new site (e.g. https://example.com). We have not set up a CNAME record for the other aliases we requested, so https://www.example.com (with the www subdomain) will not yet work.

Summary

If all these steps went smoothly, you should have a shiny new domain that serves your S3-hosted website over HTTPS. This should lend a degree of professionalism to your new site.

However, it's important to note that this type of architecture is not secure end-to-end. With the current setup, only the traffic between a user's browser and the CloudFront domain is encrypted. Communications inside the Amazon network between CloudFront and S3 continue to be performed over unsecured HTTP.

This type of setup may not be appropriate for hosting sensitive files/information. But for a basic project site, we've chosen to make this trade-off on security to gain simplicity in setup and management of our static website.