On self-hosting a static website: Trying out a DIY serverless approach

Based on the message being returned, the DNS record is routing to the bucket just fine - except it's not accessing the content, as the bucket's URL above does. This can be remedied by adding /index.html.

Something about proxying with Cloudflare doesn't play well with object-based static site hosting (remember in object storage, it's not a file system - everything is an object with a key, metadata and data). It's fine hitting actual objects themselves, but not the 'pretty URL'. So /posts/my-first-post/index.html is okay, but /posts/my-first-post is not.

Contrast this to a non-proxied record obj-ws-1b.peterkeenan.net, which behaves as expected. You can hit the pretty URL and get the underlying object just fine.

The non-proxied version doesn't benefit from Cloudflare's caching. This is not ideal.

At this stage, it seems we're choosing between forms of UX/UI. Do we want low latency, or simpler, nicer user-friendly URLs?

Adding the DNS record to my Cloudflare zone for peterkeenan.net to create obj-ws-2-1.peterkeenan.net yielded a slightly new result: it benefits from being proxied by Cloudflare, so gets caching, but there's a little certificate configuration to be done.

Cloudflare provides four options for TLS/SSL, but this is applied at 'zone' level (ie, for the entire domain), rather than isolated subdomains. I tend to opt for 'Full', but I believe we could opt for 'Flexible' here and be up and running, sort of - but let's press on.

Amazon has their own service for caching called CloudFront. I set up a CloudFront distribution pointing at the bucket's website URL.¹ This gives us a new URL to hit. Here we enjoy:

• caching
• TLS/SSL
• pretty URLs

Great! Job done? Not quite. There's a bit of extra leg work involved in using our own domain. Again, this is well documented, so I'm not doing a step-by-step, but in summary we have to:

• request a certificate for the domain(s) in ACM
• add unique records to our DNS in order to confirm ownership of the domain(s)
• add the domain(s) we want to use to the CloudFront distribution, and associate them with the certificate

Only once the above is done can we then add a DNS record for the desired subdomain to the CloudFront distribution. Here it is in all its glory: obj-ws-2-1a.peterkeenan.net

There's nothing wrong with the above solution, and I have a feeling its quite commonly used. I really don't like the trail of unused 'entrypoints' we have left though…

• http://obj-ws-2-1.peterkeenan.net.s3-website-eu-west-1.amazonaws.com/
• https://d2w1tge9bnpkc.cloudfront.net/
• https://obj-ws-2-1a.peterkeenan.net/

One is borderline acceptable. Two feels messy… There's nothing to be done about the CloudFront URL, but we should be able to remove the S3 website URL from the mix as we're in AWS world, and we can be specific and grant internal resources access to each other.

I created a new bucket, this time not configuring it as a website. This bucket is entirely locked down and private. I created a new CloudFront distribution, this time using the Origin Access Controls and a bucket policy, allowing the distribution to access objects. This is, like all the other AWS stuff, pretty well documented.

The certificate I created in the previous step was good for a handful of subdomains, so I added this new subdomain: https://obj-ws-2-2.peterkeenan.net/

Landing on the home page actually serves content, unlike previously where it would give an access error, but this is purely because we get the option to define a default root object, index.html in this case. When navigating to the first post, we are back at square one: we get access denied on the pretty URL, but are fine if we explicitly hit the underlying object - /posts/my-first-post/index.html

This is one instance where I actually expected this to occur, as the bucket is not configured to serve websites, so requests are purely looking for an object at a path (key). It shouldn't serve an object from /posts/my-first-post because there is no object there.

The issue outlined in the 'problem #4' can be remedied, but it is a bit hacky. Returning to the bucket that has been set up to serve website content, we can add a bucket policy that only allows traffic that contains a Referer header with a pre-defined secret. Something like this:

{
    "Version": "2008-10-17",
    "Id": "PolicyForRefererHeader",
    "Statement": [
        {
            "Sid": "AllowTrafficWithRefererSecret",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<BUCKET_NAME>/*",
            "Condition": {
                "StringEquals": {
                    "aws:Referer": "<YOUR_SECRET_VALUE>"
                }
            }
        }
    ]
}

We can then set CloudFront to add this header and secret value when it requests content from the origin. While it doesn't remove the S3 website URL from the equation, it basically makes it useless to everything but the CloudFront distribution itself, provided the secret remains … uh … secret.

I haven't ruled out moving things to S3/CloudFront. It's probably the best option for a DIY serverless approach. I think there's something to be said for not being all in on cloud stuff though. It's good to mix and match and not become overly reliant on one cloud provider.

I'm not big a fan of Cloudflare - I pretty much only use it for its CDN-like feature. I could manage my DNS records anywhere, but in order to benefit from Cloudflare's caching, you basically have to use their DNS service. You also have to use their proxy. I do question whether or not I even need to serve content 'globally', and wouldn't be fussed about abandoning Cloudflare, but the classic serverless site would typically combine object storage and a CDN.

Am I a weirdo for not liking that trail of endpoints? Probably… I reckon this is common. For my simple static website, it's harmless provided there's clarity over the canonical URL. But as a pattern, it feels messy and needless.

This is how Cloudflare Pages, Netlify and such operate. They create a URL of their own and the customer optionally adds their own domain. Whether using a custom domain or not, that service URL doesn't disappear. This is unavoidable when using managed services online. I just don't like it.

VPSs have a single IPv4 and a single IPv6. I create a thing. I decide what meaningful domain I want that thing to have. I setup DNS records to point that meaningful domain to those source IP addresses. That's it. It's simple, elegant, clean. My thing has a single user-friendly URL. The only other way to access that thing is by using the IP address itself (which the URL does for you).