Do Something Easy in AWS Link to heading

AWS is all about making undifferentiated heavy lifting easy. Here, I will talk about serving static web content. The AWS way to serve static web content involves putting that content in an S3 bucket, and then delivering it using their CloudFront CDN. There are a few other parts involved, but here are the things you will need to bring to the party.

  1. A registered DNS domain. AWS will sell you this pretty much at cost and that’s the easiest way to do this. Registering a new domain will walk you through it.
  2. A Route53 Zone to manage this domain. We’ll be using this to both manage the DNS names for the site and to validate an ACM certificate. Working with public hosted zones will tell you all about it, but if you registered with AWS, then this is already done for you. This is a good time to configure a CAA Record for your new zone, since we’re doing things properly.
  3. A GitHub repository hosting your Hugo code. See getting-started-with-hugo for an example.

How Will This Work? Link to heading

There are a number of moving pieces here.

You, or whoever’s writing your content makes a PR in GitHub. This triggers CodeBuild to render the site and provide feedback on the PR to GitHub. You merge that PR and GitHub fires another webhook over to CodeBuild. This time, not only does it render the site, it uploads the rendered files to an S3 bucket, and sends a cache invalidation to CloudFront.

Meanwhile, we’ve used Route53 to configure the DNS for the site, and also to validate an ACM certificate.

CloudFront is central to this picture. It’s where the Route53 record points, and it is using that ACM cert we generated. It receives the https request from the user, rewrites those requests as necessary by calling out to a lambda function, fetches content from the S3 bucket where it lives, and serves it up to the user’s browser.

This is the canonical way to serve static content with AWS. Well, the rewrites and redirects are somewhat Hugo specific.

Ok, but Seriously Why? Link to heading

All this seems like a lot of bother. I’m guessing you probably already know how to spin up a VM in the cloud and install nginx. That’s the way things were done for something like a decade before now, and it still works. So… why? It comes down to cost / benefit. There are a number of costs associated with serving a web page the traditional way. Hardware, even the least expensive VMs isn’t cheap. Sysadmin time is expensive. Not being caught up on security patches is very expensive.

The typical computer is 99% idle, and that adds up to a lot of wasted resources. Every component in the above architecture is serverless and on-demand. That means that your costs scale down to match your usage. I expect this blog to cost me less than $1 / year. The other benefit is that this architecture will scale up to match pretty much any level of demand. And of course AWS has excellent support for budgets, if you want to adjust the cap on how big you will scale.