Addendum – I’ve published a second post containing a workaround for the problems described in this document.
While working on a tiny project today to demonstrate publishing a static website through to S3, I was surprised to find that despite almost nonstop improvements since its release, there are still some key features missing from the AWS static hosting offering.
A common technique for static website builders like Hugo to generate “pretty”
/about instead of
/about.html) is to generate a folder
/about), put a default file in it (
index.html), and rely on a frontend web
server to detect and serve it implicitly without incoming users being any the
wiser. Amazon was obviously aware of this, and their static website hosting for
S3 allows you to specify an “index document” which will be served when a
directory is accessed.
So everything’s fine right? Well, no. The problems begin with S3 not supporting HTTPS access on its static website endpoints 1; a decision that makes things awkward for would-be customers, but presumably one that was made with difficulty for reasons related to limitations in internal architecture.
Luckily, Amazon gives you a way to serve files in S3 over HTTPS through the use
of CloudFront, their global CDN service that can be easily linked to a bucket.
So that gets us easy, fast, and secure static hosting right? Well, almost, but
no. The problem now is that Cloudfront doesn’t support index documents like S3
does. It allows you to specify a “default root object” that will forward
example.com along to
example.com/index.html, but this applies
only at the top level; subdirectories below the root aren’t
allowed any special treatment (so
/about cannot go to
So with S3 you can have index documents but no HTTPS, and with CloudFront you can have HTTPS but no index documents; not the end of the world (determined customers can give up the pretty URIs), but a sad state of affairs nonetheless for a product that’s ostensibly in a mature state.