Host a secure website in S3 using your own custom domain — Part II
Tags: aws, devops, webdev, tutorial
Published: 2020-05-17 08:17:06

**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. _luke@connectr.com_ — 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](https://dev.to/lukeojones/host-a-secure-website-in-s3-using-your-own-custom-domain-part-i-19k5) 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_.<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3jxu8pc9u6p88gp034v1.png)<br>
- 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.<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/7c0x2ri84vle98pvi0m6.png)
- 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.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ahixfdp44u9vch3xwjsc.png)
- 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.<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/yl7f9lcxk926hi7i9q4i.png)
- 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_.<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zchdjm4t7qccommzepjn.png)
- 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](https://www.hitc.com/en-gb/2020/04/09/the-topless-handstand-challenge-what-is-it-and-who-is-involved/) and then come back to check the status.
- Eventually, your certificates should move to the _Issued_ status 😎<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3o9e9u37p276eyhttnt7.png)

#### 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](https://console.aws.amazon.com/cloudfront/home?region=us-east-1) 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.<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/w15nmvq1kuxkt660wo2m.png)
- 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.<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/phldfj1u6sgxjj2jd2iy.png)
- 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.<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/d8fdyt98q5ph8cttgv8f.png)
- 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! 😎<br>
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hnhe1zt6n1yl52jbs7kn.png)

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 👍