Overview

This covers the process I went through to deploy this website using Amazon AWS web services. Since this is a simple static site, with no current ties to any backend services, I wanted to eliminate the overhead of having a dedicated webserver. Since the cost to host a static website using the serverless capabilities of S3 and CloudFront can be as low as $1, this immediately seemed like an appealing solution.

The Architecture

The architecture consists of the below components:

• local workstation used to build static site files using the Hugo static site generator
• Amazon S3 bucket configured for static site hosting
• Amazon CloudFront deployment using the above bucket website url as the origin
• Amazon Route53 hosted zone to handle DNS to the appropriate AWS resource
• Google Domains for leeonglocal.com domain registration

Configuring S3

Amazon S3 is the component that contains the actual files that my website is comprised of. In order to make it publicly accessible, a few settings need to be changed from the default when creating a new bucket. By following the guide provided by AWS documentation, a bucket can be made public with static website hosting enabled

With regards the way this architecture is designed, having the bucket set to static hosting is crucial if we want to also enable HTTPS. Becuase S3 does not handle anything other than serving requested files (this includes negotiating TLS connections), we have to access our content through CloudFront.

Setting the CloudFront origin to our S3 bucket website endpoint allows us to use S3 to determine our default index documents. What this means is that the URLs to our website’s pages don’t need to explicitly contain the ../index.html slug at the end of it. Navigating to https://leeonglocal.com will automatically show us the content of the /index.html found at the top level of our S3 bucket.

Alternatively, if we use the S3 bucket’s API endpoint, we would have to explicitly request the filenames we want to view.

Creating the CloudFront Distribution

CloudFront allows us to serve our website securely over HTTPS. As mentioned above, S3 does not handle TLS negotiation so any access over the internet would be through less secure HTTP sessions.

Since this is a static website with very little to no user interaction, having HTTPS configured is not the biggest deal. But considering that most modern browsers are not requiring websites be served over HTTPS, it’s a good idea to do it anyway. Plus it’s great practice for real world, production deployments.

The only thing required to set up the CloudFront Distribution is a valid TLS certificate. In this case, we used Amazon’s AWS Certificate Manager (ACM) and details for that can be found below. Once we have that, we create a Distribution configured with the respective certificate imported and set the origin to point to the S3 website endpoint. Lastly, the domain name associated with the TLS certificate must be placed in the ‘Alternate Domain Names’ field for CloudFront to respond to requests for that domain.

Configuring DNS

I registered leeonglocal.com using Google Domains a number of months ago, before I decided I would primarily be using Amazon AWS as my backend stack. Instead of going through the process of migrating my domain from Google’s registrar to Amazon’s, I just took advantage of the ability to set custom DNS servers in Google’s domain settings.

To do this, I created a hosted zone in AWS Route53 for leeonglocal.com and created an A Record as an alias to the CloudFront distribution.

Conclusion

These are the steps I took to set up my website in The Cloud. In addition, I also changed the default cache policies for the CloudFront distribution. I’m not entirely sure how much that will effect the number of requests being sent to S3 but I’m sure this site is small enough that any differences will be insignificant. Fortunately usage statistics are easy to get so I’ll be able to look into it if I have to. So far the results have been completely satisfactory and I’m excited about this new set up.

Appendix

Using ACM to create a certificate

AWS Certificate Manager allows TLS certificates to be requested for domains. In order to complete the request, Amazon needs to verify that the person requesting the certificate actually owns the domain and has authority to change it’s settings. They allow for two validation methods: DNS and Email. Since DNS validation is automatic and done once, I opted for this option.

ASIDE: for certificates created in ACM to be seen in CloudFront, they need to be in the N. Virginia (us-east-1) region.

For DNS validation, AWS requires a CNAME record to be created that points At this point, my domain was already pointed to Amazon nameservers so the CNAME records were added in Route53.

I requested a certificate the both leeonglocal.com and *.leeonglocal.com to cover any additional subdomains I might decide to add on in the future and added the specified DNS records. The validation took about 5 minutes, and once it was complete the certificate was immediately available for use in CloudFront. Magic