This was written after i soft-bricked multiple BMCs and got stuck in a reboot cycle after successfully un-bricking and updating them. This would also be a great time to rant a little about how running something like this with direct memory access and all that jazz is complete bonkers. But whatevs.

For this to work it’s important that you understand some concepts in IPv6, I’ll briefly cover the most important ones in this post, but I strongly advice you to read up on them in detail. Also, I have absolutely no clue about networking. This setup is tested and working on Get (Telia), a service provider in Norway.

Origin Access Identity (OAI) is a secure way to access S3 buckets from CloudFront, think of it as letting CloudFront use the S3 APIs to request objects instead of H. The alternative is to make the bucket publicly available via bucket policy or ACLs, but that’s not ideal. On S3 you can configure a default index document, which is requested if the specified path doesn’t resolve to anything.

There are many ways to host a static site on S3, either directly on S3 using S3 Website or by setting up CloudFront to serve content from S3. If you want to use your own domain and TLS you more or less have to use CloudFront. However - many roads lead to Rome, and some are both quicker and more secure.

To make key signings as efficient as possible it’s important that all participants comes prepared. We avoid using Key Servers, since they are flakey, slow and might publish more information than you want. Before the event all users should have received a list of keys that will be signed, and imported them into their own keyring.

Web Key Directory (WKD) is a proposal for a new way to discover other users keys, using HTTP and TLS. In short it looks up the UID on the users host. This works since all UIDs are email address, and all email addresses are built up of two parts, the username and host part.

Unless you’ve completely jumped on the container band wagon you probably still need to maintain a number of stateful servers, which typically live in a number of environments, like dev, stg and prd. You probably also have a number of servers in a cluster spread out on different availability zones.

Bla bla bla… You’re here for the solution, not to hear me talk about it. See code example. Improvise, adapt and overcome. One thing though, unless you have a shit metric ton of objects that you want to keep all hot and sizzling in cache I suggest you just invalidate the entire path, and not per object.

You might want to “park” a domain to notify people that they’re no longer in use or whatever. Since we’re using Terraform you can update a ton of parked domains at the same time. Which is nice when business decides to rebrand everything. Like they do. Notice that we’re using a bucket policy and not ACLs to make the contents of the bucket public.

S3 has a few neat features, like letting you publish your webpage or store backups. But one of my favorite features is the ability to set up more or less maintenance-free redirects. This is super useful when you’re in a corporate environment where domain name changes are quite frequent, either due to rebranding or similar.