Host a secure website in S3 using your own custom domain — Part II

Fact: Studies show that having a custom domain name for your site makes you fitter, funnier and more interesting at dinner parties.

OK, so like last time — I’m sort of making these up. That being said, there are advantages to setting up a custom domain name e.g. better SEO, quicker AdSense approvals and, more generally, higher trust amongst your visitors. If none of those seem tempting then what about having a more unique email address e.g. [e-mail] — maybe this could actually make you more interesting at (really lame) dinner parties? P.S. I don't use that email.

If you hadn’t guessed from the ‘Part II’ in the title, this article is the follow-up to Part I which stepped through how to setup an S3 bucket for static site hosting and details on configuring the CloudFront CDN.

Again, like last time, I’m going to use the .tech domain I purchased from GoDaddy — connectr.tech. I have no major plans for this domain so if you’d like to make me a generous offer to buy it, I’m sure we can come to an agreement 🤑

By the end of this article you will have transferred your custom domain to Amazon’s Route 53 service, setup a custom SSL certificate and made your S3 static side available at your custom domain. Let’s get going.

Part IIA — Transferring your domain name to Amazon Route 53

Route 53 is Amazon’s highly available and scalable DNS service — I’ve dealt with other DNS services before and in my opinion the usability of Route 53 is far superior, especially if you’re primarily building out AWS infrastructure (like we are here).

In this guide, I’ll be migrating away from GoDaddy which is great because, quite frankly, using GoDaddy to manage DNS entries is like trying to drive whilst someone throws vinegar in your eyes.

• Login to the AWS console and open up Route 53.
• Create a new Hosted Zone and complete the panel on the right by filling in your naked domain name (without the www), an identifying comment and a type of Public Hosted Zone.
• Click Create and you should see that a number of DNS records have been created — the NS record lists a number of name servers and the SOA record indicates the host name of the primary name server.
• Now we need to export the Zone File (in unix format) from the existing provider (in my case GoDaddy) so that we can import these additional records into the Route 53 record set. Your DNS provider should provide documentation on how to do this so I won’t repeat that here.
• Ensure that the A record in your Zone File includes a valid IP (typically the IP of your site) before importing. For example if your website is still ‘Parked’ then you won’t be able to use it until you update the value to an IP — we’ll be changing this record later so don’t worry about the exact value too much.
• Once you have your valid Zone File you need to import this into Route 53 using the Import Zone File (visible in the image above). Simply copy the contents of your .txt file into the text field and press Import to import the additional DNS entries.
• You now need to repoint the name servers on your existing provider (e.g. GoDaddy) to the new name servers provided in Route 53. You’ll want to check your providers documentation on this but essentially you need to add a name server for each of the four lines in the NS record within Route 53 (e.g. ns-1446.awsdns-52.org. and the other three)

Part IIB — Setting up a new SSL certificate for your custom domain

In order to provide secure access over https using your custom domain, we’ll need to create a new SSL certificate and associate it with our domain. The Amazon Certificate Manager (ACM) makes this quite simple.

• Open up the ACM service in the AWS console and change to the us-east-1 region — currently, certificates created in other regions cannot be associated with CloudFront distributions correctly.
• Press Request a Certificate and then choose to Request a public certificate in step 1 of the wizard.
• You will now need to add your custom domain to the certificate — I would recommend adding both the naked domain e.g. connectr.tech and a wildcard entry for all subdomains (e.g. *.connectr.tech) so that www.connectr.tech and api.connectr.tech will be protected.
• Click Next and choose DNS validation. Add a tag if you wish, then click Review and finally Confirm and Request.
• Before ACM will provision your certificate, you need to prove you own the domain. Fortunately, because we’re now using Route 53 to manage our DNS records, it’s a simple case of expanding each entry in the validation table and clicking the button Create Record in Route 53.
• Once you’ve done this for both domains, press Continue and then you’ll need to wait (up to 30 minutes) for the DNS changes to propagate. Once propagated, ACM will know that you are the true overlord of this domain, and allow you to generate the certificate. Drink a beer or maybe attempt the t-shirt handstand challenge and then come back to check the status.
• Eventually, your certificates should move to the Issued status 😎

Part IIC — Configuring CloudFront to use your custom domain and cert

Currently, our CloudFront distribution is associated with the S3 provided endpoint and the default CloudFront certificate — we need to amend the distribution settings to sort this out.

• Open up the CloudFront service in the AWS Console and select your distribution from the list. Press Distribution Settings to see the current config.
• Press Edit so we can start tweaking things.
• Under Alternate Domain Names you will want to add any domains that you want your users to be able to use to access your site (e.g. www.connectr.tech and connectr.tech).
• Under SSL Certificate you will need to select the Custom SSL Certificate option and then select the certificate you created in Part IIB.
• Save your changes and start getting ready for your next attempt at the t-shirt challenge — we’re almost done.

Add DNS aliases to direct visitors to the CloudFront Distro

Now all we need to do is add a couple of DNS records that will ensure visitors to your site will be directed to the CloudFront distribution.

• Make a note of the Domain Name of your CloudFront distribution (e.g. d32gg49xh8c4xx.cloudfront.net) as we’ll need this later.
• Swap to the Route 53 service and select the Hosted Zone for your site.
• Select the A Record for the naked domain from the existing Record Set. In the Edit Record Set pane on the right, change the entry to Alias: Yes so that we can use a domain name rather than an IP. Change the Alias Target to the domain name of your CloudFront distribution and save the record set.
• You will almost certainly want to add another A Record to direct the www subdomain to the same CloudFront distribution using an Alias. You can do this by pressing Create Record Set at the top of the page and then following the exact same instructions as you did for the naked domain. In some cases you may first need to remove the CNAME entry with the same name.

Great, only 27 more steps to go…only joking — that’s it. You may need to wait a while for some of the DNS settings to propagate but pretty soon you should be able to visit your new domain name and see your site, served over https using your custom SSL certificate! 😎

Thanks for following along and well done for persevering. If you managed to perfect the t-shirt-handstand challenge whilst reading through this then you have my utmost respect and admiration — if you didn’t then at least you’ve got your custom domain up and running!

Next time, I’ll be looking at how you can use a couple of free tools to setup a CI/CD pipeline for a simple React site 👍