Redirect root domain to www subdomain with SSL enabled using AWS CloudFront and S3

6 min readAug 4, 2018

If you happen to use a managed CMS service such as Hubspot, that provides a custom domain setting only for subdomains with a CNAME record. Enabling redirection from the root domain with SSL enabled can quite tedious. One way to achieve the redirection is to use AWS S3 and CloudFront. Other methods are for example creating an NGINX server with Lets Encrypt enabled SSL certificates to proxy the request or use Cloudflare. I’ll walk you through how to set up a redirection from the root domain (example.com) to www-subdomain (www.example.com) with SSL enabled, with AWS S3 and CloudFront.

TL;DR aka Summary

Make sure your DNS provider supports ALIAS records. AWS Route53, NS1, and DNSimple for example.
Create an S3 bucket with your root domain name ”example.com”
Enable static website hosting from bucket preferences and configure redirection to your preferred subdomain (www.example.com). Make sure to select HTTPS as the protocol. Copy the site public host to the clipboard, it should be something like example.com.s3-website.eu-central-1.amazonaws.com.
Create new CloudFront distribution with the origin domain name set to the S3 public host copied in the previous step. Also select “HTTP to HTTPS redirect” from Viewer Protocol Policy, select “All” from the “Cache Based on Selected Request Headers” -dropdown, and add the root domain (example.com) into the CNAME list. Use a Custom SSL certificate; create AWS Verified or import your own.
After CloudFront distribution is enabled (it takes 15–30mins) add the distribution host (looks like xxxxxxxx.cloudfront.net) as the ALIAS record of your root domain.

1. Initial DNS setup

Make sure your DNS provider supports ALIAS records, or similar possibility, that makes it possible to set a hostname rather than IP address. Some of the providers that support the ALIAS feature are AWS Route53, DNSimple, and NS1. DNSimple support site explains the ALIAS record well:

An ALIAS record is a virtual record type that we created to provide CNAME-like behaviour on apex domains. (https://support.dnsimple.com/articles/alias-record/)

What ends up in the DNS records are actually A records for the service providers servers that will do the magic to route the traffic to the given host. Thus the A record check on Google MX check will be valid.

If your DNS provider does not support ALIAS records, you need to go with other ways of achieving the redirect. Usually, the DNS providers support’s some kind of redirecting (like GoDaddy), and in most cases that should work fine. However, if you are responsible for your DNS management, I highly recommend using some of the services focused on managing DNS records, such as the NS1 and DNSimple. AWS Route53 is easy to take into use if you are already using AWS.

2. Create S3 Bucket and enable redirection

Create an S3 bucket with the root domain name (example.com).

Enable Static Website Hosting from bucket properties dialog. Add the subdomain (www.example.com) as the redirection host. You probably want to redirect to the HTTPS version of your subdomain, so add HTTPS as the protocol.

Test the redirection by navigating to the endpoint.

Note the endpoint of the bucket. You can actually copy the host to your clipboard (without the protocol).

3. Create CloudFront Distribution

We are going to create a CloudFront distribution that will use the S3 bucket as the origin.

Create new distribution, select “Web” from the Distribution Methods.

Origin Domain Name will be the host you copied from the S3 page. So for example “example.com.s3-website.eu-central-1.amazonaws.com”. Don’t select the bucket from the dropdown list. We want the traffic to be routed to the statically served host, not the bucket contents. (Basically, this host does not need to be S3, it could be an NGINX proxy that does the same as S3, redirects all content to the desired host. S3 is just quite simple to set up.)

You can leave almost everything as it is. We are want to have all the traffic to go through this CloudFront so no path selection or anything.

From the Viewer Protocol Policy select “Redirect HTTP to HTTPS”.

For Allowed HTTP Methods choose which suits your needs best, for a simple website you should be fine with GET, HEAD, and maybe OPTIONS.

To disable all caching select ALL from the “Cache Based on Selected Request Headers” -dropdown. This will show you a yellowish warning that says the objects are not cached, but this is the behavior we want. Any caching will happen on the target system that lives under the subdomain.

Add your root domain to the “Alternate Domain Names (CNAMEs)” list.

For the Certificate select the Custom SSL Certificate, if you have already a matching certificate in AWS it should be in the dropdown list, otherwise, upload your own or create a new AWS Verified Certificate. Creating a certificate with ACM is really straightforward and will take you only a minute. Follow the instructions in the new window.

You might need to refresh the CloudFront setup page if the new certificate does not appear in the dropdown.

Leaving some kind of comment on the purpose of the distribution is always a nice gesture for you or your colleagues and your future self. Write for example “example.com root domain redirection to www.example.com”.

Create your distribution. It will take at least 15min to be up.

4. Setup the distribution as the ALIAS record

If you have AWS Route53 as your DNS create a new record set for the domain, don’t set anything on to the subdomain part, select A record, from the small radio selector choose Alias. In the dropdown, there should be the CloudFront distribution created earlier, select that and hit create. You could also add AAAA record as ALIAS for IPV6 support. You are all set!

If the distribution does not appear, make sure you have the correct CNAME in the distribution settings. Also, make sure the distribution is in the “enabled” state.

For other DNS, note the distribution host address, it’s something like xxxxxxx.cloudfront.net. Paste that as an ALIAS record into your DNS management. Here’s how the dialog looks like in NS1 currently.

Summary

Setting the redirecting up is rather straightforward, but has few gotchas. When enabled you’ll have the advantages of using a CMS platform for managing your web content, not having a duplicate site for the root domain, which helps to get better SEO scores and email sending from your domain is more solid, as Google checks that the A record is set.

I hope this was a helpful and clear description. Please comment out any inconsistencies or incorrect issues, and as I am not an AWS Specialist there probably is more to the setup that I am not aware of, all the insights are highly appreciated.

Additional resources and some of the sources for this aggregate guide:

Intercom custom domain guide: https://developers.intercom.com/installing-intercom/docs/set-up-your-custom-domain?showHidden=f2cb6
The video on the Intercom support page by Trade Defender: https://www.youtube.com/watch?time_continue=249&v=qKOGu0li070
Implementing a WWW Domain Redirect Using AWS CloudFront from an S3 Bucket by Love2Dev https://www.youtube.com/watch?v=jciKxwybxF4