My personal website is now hosted securely on AWS behind CloudFront, it is now based on React, and it has a new CI/CD automated workflow built with Github Actions. As a bonus I've updated my existing Github hosted samples page with a new layout, in the process discovering an alternative way of hosting static content through Github Pages. It's been a busy weekend.
For while I wanted to update my mytkowski.ca hosting solution on AWS. So far I have been relying on the very simple and inexpensive method of using S3 configured to host a static website with Route 53 redirection. This is a simple solution for quick static content hosting. It does not however provide HTTPS and S3 kept showing that ugly warning about the public access policy on the bucket.
As a learning exercise I decided to change the implementation to use CloudFront for content delivery.
The general plan
Before I started on the new config, I had two assets already in place:
- S3 bucket with public access policy and setup for 'static web hosting'
- Route 53 hosted zone pointing to my S3 bucket
Adding CloudFront to the mix should be fairly straightforward and would require the following general steps:
- Setup of CloudFront distribution with S3 as origin for the web content, removing the need for S3 to be configured as a 'static web host'.
- Configure the CloudFront distribution to serve HTTPS content, this will require SSL/TLS certificates.
- Redirection of Route 53 records in the hosted zone from S3 to CloudFront.
- Update of S3 bucket to remove the public access permissions and authorize CloudFront to access the bucket.
Stretch goal
As a stretch goal, I decided to update the website content to use a UI framework, and React seemed like a good candidate. An engine like Gatsby would probably be more reasonable, however I still don't know where I will take this site, so React it is for now.
This goal would require some sort of automated deploy pipeline. More on that below.
Starting the conversion: CloudFront distribution setup
AWS CloudFront Developer's Guide has really good step by step instructions. I relied on the 'Getting started with a simple distribution' article to create the initial CloudFront distribution setup with S3 configured as origin.
During this step I also updated the S3 bucket to remove the 'static web hosting' property, however left the public access policy in place for now.
This allowed me to build a path from CloudFront to S3 and test it using the assigned Distribution domain name.
Route 53 redirect and SSL
Once again the AWS Developer's Guide provides very good instruction set on what is needed to configure CloudFront with a custom URL. Unfortunately I did not read the instructions fully and I made a minor blunder.
The blunder: To get ahead of the Route 53 setup, I opted to blindly remove the existing records pointing at S3 and just rebuild the hosted zone from scratch. This nuclear option was maybe too much.
In the process I had also destroyed the Name Server records which were pointing to the Route 53 delegation set of name servers. When I recreated the zone and got new hosted zone NS records in place, these were pointing to a new delegation set. However the registrar domain record was still referencing the old DNS servers, as a result the site became unreachable.
I ended up spending an evening trying to figure out what I did wrong since I did not initially clue into the issue being in the domain record. The clue I needed I found in the warning message on this page (emphasis mine):
When you create a hosted zone, Route 53 assigns a set of four name servers to the hosted zone. If you delete a hosted zone and then create a new one, Route 53 assigns another set of four name servers. Typically, none of the name servers for the new hosted zone match any of the name servers for the previous hosted zone. If you don't update the domain configuration to use the name servers for the new hosted zone, the domain will remain unavailable on the internet.
I am not a network guy. Lesson learned though, I had to update the domain record with the new list of DNS servers to get my website to work.
Back on track: with the DNS entries fixed, I completed the instructions at the link above to complete setup of the TLS certificate and point Route 53 records at CloudFront and serve my web content.
S3 bucket access permissions
Once the website could be served through CloudFront, it was relatively trivial to restrict access to the S3 resources with an origin access policy. AWS Developer Guide for CloudFront has very clear instructions on this.
This effectively removed the 'public access' policy from the buckets, improving the overall security posture of the resource.
Automated deploys
During all this work I noticed that my previously configured CD pipeline did not work. In any case with React I would also need to include a CI step. I ended up using Github Actions, but more on that later another time.
Learnings
- CloudFront setup is relatively simple when following AWS instructions. Implementing the solution in stages helps to simplify the problem resolution.
- CloudFormation has a template for this, however I opted do configure this manually to learn how the components interact.
- The cost of this implementation seems negligible, with low volume sites there would be very little changes, and CloudFront provides some options for pricing with Price Classes. Shifting to CloudFront does not seem to be adding much cost to the solution.
- CICD workflow seems to be a cheaper option if orchestrated through Github, and not through AWS CodePipeline.
- Github Pages is a strong contender for hosting static web content, it's a good option to know about. A repo requires some minor tweaking to prepare it for hosting, and with Github Actions, deployment of a framework based website with a build step can be easily automated.
- TODO: Need to setup server logging, this is an example of something that would have been handled by CloudFormation.
- TODO: Actually build some web content.
