As a change of pace from my last post, I now present you with a wonky AWS issue, created mostly by departing from Amazon’s standard pattern of S3 static site hosting; hopefully this will be useful to someone else in a similar position. So, as you may be aware, you can use AWS S3 to host a static website. Furthermore, once you’ve done so it’s not difficult to use AWS CloudFront (the content distribution network service) to serve out your site; the CloudFront workflow is clearly set up for you to put CloudFront in front of a S3-hosted website (such as this blog!). As long as your site is laid out something like the following, you’ll be in good shape: / /index.html /images/ /images/foo.png /images/bar.png ... However, you can run into odd behavior if your site contains paths like this: ... /some_subdirectory/index.html ... and you want to be able to browse to http://your-site.tld/some_subdirectory/ and have the server automatically serve out the index page. Since S3 doesn’t really have a notion of a directory hierarchy, but rather has a flat structure of keys and values with lots of cleverness that enables it to simulate a hierarchical structure, your request to CloudFront gets converted into “hey S3, give me the object whose key is some_subdirectory/”, to which S3 correctly replies “there is no such object”. When you enable S3’s static website hosting mode, however, some additional transformations are performed on inbound requests; these transformations include the ability to translate requests for a “directory” to requests for the default index page inside that “directory” (which is what you want), and this is the key to the solution. In brief: when setting up your CloudFront distribution, don’t set the origin to the name of the S3 bucket; instead, set the origin to the static website endpoint that corresponds to that S3 bucket. Huh? Ok, here’s an example: …