DEV Community

Cover image for Host a secure website in S3 using your own custom domain — Part I
lukeojones
lukeojones

Posted on

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

Fact: Studies show that developers hosting their sites in S3 are healthier, wealthier and have better hair than their peers.

If you weren’t convinced by the above then at least know that the combination of Amazon S3 and CloudFront offers a simple, cheap and performant way to host static sites and serve them over https. In this two-part series, we’ll spend a little time going over the steps required to get your site live and using a custom domain. We’ll cover the following:

  • Part I — Configuring an S3 bucket and CloudFront distribution to host and deliver your content.
  • Part II — Transferring your domain to Amazon Route 53 and configuring an SSL certificate using Amazon Certificate Manager.

Each part will be pretty short — so don’t be put off by the breakdown above — the whole series can be completed in well under an hour.

For the purposes of this guide, I’m going to use a .tech domain I purchased from GoDaddy. I decided to go with connectr.tech as it was cheap, relatively non-specific and sufficiently hipster to be used in a dev.to article 🧐

Part IA— Creating and configuring an S3 bucket to host your site

  • Login to the AWS console and navigate to the S3 bucket creation page.
  • Create a new bucket e.g. connectr-site and temporarily remove all public-access blocks as shown below

    Alt Text

  • Select your newly created bucket and then head to Properties : Static Website Hosting to configure the static hosting options.

    Alt Text

  • Configure the index and error pages as index.html and error.html. You’ll also see the public endpoint of your soon-to-be site!

  • Copy the endpoint and open it up in another tab — you should receive a 403 (forbidden) response because the bucket policy has not yet been configured. To sort this out, go to the Permissions tab (next to Properties) and add the following Bucket Policy using the Bucket Policy Editor.

  • Save the bucket policy and try hitting your new public endpoint again — this time you should receive a 404 as S3 tries to serve the non-existent index.html and error.html pages. This is what we want at this stage 👍

  • Create an index.html and error.html file that you are happy to share with the world. For example, I created some ‘awesome’ pages below…

  • Whilst still in S3, select the Overview tab and then upload the error.html file to your S3 bucket. Make sure you provide public read access on the second page of the upload wizard before pressing Upload.

    Alt Text

  • Once the upload is finished, navigate to your site’s endpoint again and your custom error page should be displayed.

    Alt Text

  • Repeat the process for your index.html — when you navigate to the site again, you should see your lovingly crafted html! (notice the connection is plain http and not secure)

    Alt Text

  • Finally, to improve security and make sure we’re following best practices, we can lock down the bucket policy a little more. Head back to the Permissions tab for your bucket and block public access for ACLs and new bucket policies as shown:

    Alt Text

  • Double check you can still access your index.html page and that’s it — you’re good to go.

Part IB— Configuring a CloudFront distribution for content delivery

To improve how your users access your content, you’ll want to make use of a CDN — in this case CloudFront — to distribute your content using a global network of proxy servers.

  • In AWS, navigate to the CloudFront service and select Create Distribution to get started. When asked to choose a delivery method, choose Web.
  • Under Origin Settings you should attach the S3 domain name that was created in Part IA e.g. connectr-site.s3.amazonaws.com Alt Text
  • Secondly, you’ll want to redirect all http traffic over https by selecting Redirect HTTP to HTTPS as the Viewer Protocol Policy option Alt Text
  • Now set the Default Root Object to index.html (or whatever site root you may have decided to configure). Alt Text
  • Now, create the distribution and wait for it to show the status Deployed in the Distributions overview table (this can take 5–10 minutes so find a cat video on Youtube).

    Alt Text

  • Copy the CloudFront domain name e.g. d32gg49xh8c4xx.cloudfront.net (catchy right?) and paste it into a new browser tab. If everything has gone to plan — you should see your lovingly crafted html again — this time served over the CloudFront CDN and transferred using the https protocol!

    Alt Text

And that’s it — you’re done for Part I. Hopefully that was relatively painless and you were able to follow along at a decent pace.

In Part II, I’ll go through the process of transferring your custom domain to Route 53, creating an individual SSL certificate and associating these both with the CloudFront distribution we’ve just created here.

Good work! Grab a refreshing drink and smile smugly for a few minutes…

Alt Text

Top comments (3)

Collapse
 
yourtechbud profile image
Noorain Panjwani

You should also include a step to automate the process of uploading files directly from the terminal or something

Collapse
 
lukeojones profile image
lukeojones

Thanks for the suggestion Noorain, I didn't want to derail this article too much by getting into details of how to authenticate with S3. I will cover this in another story when I setup a CI/CD pipeline as it will fit more naturally in that document 👍.

Collapse
 
yourtechbud profile image
Noorain Panjwani

Looking forward to it.