This site is hosted on AWS using S3 to store the content and CloudFront to serve it over HTTPS. I registered the domain with Route 53.

Content management comes courtesy of eleventy and the visual presentation comes from eleventy duo by yinkakun.

Hosting with AWS

I used AWS SAM to set up the infrastructure for this website. AWS SAM is an abstraction layer that sits on top of CloudFormation and simplifies some common use cases (e.g. setting up a REST API powered by Lambda functions).

High-level info on what's required to provision a website using AWS is available at the AWS knowledge centre. A step-by-step walkthrough of all the pieces required to make this work are part of AWS's documentation. More details, including the CloudFormation templates you'll need to repeatably deploy this via the AWS SAM CLI are available on GitHub.

Default root object

We're building a static site, which means that for permalinks to work, we must serve the index.html file from a folder when a folder name is requested. For a traditional web server like Apache, we use mod_rewrite to rewrite URLs as follows:

https://karlstanley.com/blog/ -> https://karlstanley.com/blog/index.html

With AWS and other serverless technologies, we don't have a web server to configure, so this approach won't work. But not to worry, CloudFront provides a way to run functions on the incoming HTTPS requests, meaning we can do our URL rewriting inside a CloudFront function.

This StackOverflow post covers the details of how to set this up.

Content Management with Eleventy

I like the Jamstack approach to building web sites, as it uses concepts and tools that are familiar to me, given my engineering background, such as:

• Create content using markup (e.g. MarkDown) and compile it to its final form, rather than writing HTML directly or using a WYSIWYG editor.
• Store content in a source-control system (e.g. GitHub) rather than in a content database (like WordPress).
• Work offline and publish the entire site at once every time it needs to be updated, rather than creating a site that gets deployed once and then evolves over time as it is updated.

The end result is a web site that uses familar management tools, has fewer security concerns (no user logins or databases to hack) and performs better than a typical LAMP site (content is static and can be efficiently cached by a CDN).

Why eleventy?

Eleventy wasn't my first choice of tool for this site. I originally tried to set it up using Hugo, but I found it hard to adapt to my needs. Hugo's main selling point is its compile speed, which I'm sure is critical when working on large scale websites, but for my own needs I'm OK to wait a few seconds for my site to render when I update it.

The attraction of eleventy is its relative simplicity compared to Hugo - I found that modifying system behaviour with JavaScript had a much shallower on-ramp compared to learning advanced Hugo features such as shortcodes in Hugo.

Useful videos

This 20 minute intro tells you everything you need to know to get started with eleventy:

Once you have the key concepts from the video above, follow this one to give you just exactly what you need in 3 minutes, a bit like a reference manual in video form:

Content Security Policy

The great strength of the Web is that we can link things from different places together, e.g. we can use an img tag to display an image hosted somewhere else or we can import a javascript library from a CDN using the script tag. So far so good. However, we might not want to allow anyone to link anything from anywhere, especially when it comes to active content like scripts or iframes that could be used for nefarious purposes. Whether or not a browser will allow a piece of content to be embedded in a web page is set by the Content Security Policy (CSP) header.

CSP in AWS

In a traditional set up, the Content-Security-Policy settings are part of the webserver configuration. In a serverless deployment, we don't have a web server - instead we have a CloudFront distribution that exhibits a set of 'behaviours' defined by 'policies'.

By default, a CloudFront distribution does not set CSP headers, meaning you can embed whatever you like in your web page. We might prefer to lock this down somewhat so we don't have to worry about exposing our site visitors to potentially malicious content. Add the setting below to 'Content-Security-Policy' under CloudFront -> Policies -> Response headers -> <POLICY_ID> to prevent anything other than scripts or images hosted on this website domain to be added to the content.

default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self';

This works fine up until the point where we want to embed a YouTube video on a page or use a specific font. Because the browser won't allow anything to be embedded in the page other than scripts and images from the same host, we see the following instead of our YouTube video. And our 'IBM Plex Sans' font has been replaced by the default Times New Roman.

We solve this by whitelisting the domains we want to allow content for. For this site, we want to be able to embed YouTube thumbnail images, some node.js packages, YouTube videos and google fonts. To see what the browser is blocking, right-click on the web page in Chrome and click 'Inspect'. You'll see an angry looking red list of errors like the below:

Each error will tell you which domain the blocked content is coming from. Add these domains to the appropriate section of the CSP header in the Policies screen mentioned above. I ended up with the following:

default-src 'none'; img-src 'self' https://i.ytimg.com/; script-src 'self' https://cdn.jsdelivr.net/npm/; style-src 'self' https://fonts.googleapis.com; frame-src https://www.youtube.com/; font-src https://fonts.googleapis.com https://fonts.gstatic.com/

Notice that the special sources 'none' and 'self' are surrounded by single quotes, while domain names are not (if you put the domain names in quotes they will not work!). Multiple sources for the same type of content are separated by spaces. Each content type is separated by a semicolon. The AWS documentation says there's a 1783 character limit for CSP headers.

Conclusion

Content-Security-Policy protects site visitors from malicious content, but if it's set too restrictively it can cause unintended behaviour. If your YouTube videos are not embedding correctly, inspect the page using your browser's developer tools to make sure the content isn't being blocked by policy.