there's a better and simpler workaround; there are two ways of setting up CloudFront->S3 origin. One is to use the S3 as file storage, the other is to use the S3 web site endpoint as a HTTP origin. With the second option, index documents work with directories, as well as S3 redirect rules etc. CloudFront sends S3 a http request as if it were an external web site, but it's all inside AWS so in effect your costs are the same in both options.

Thanks for that - I certainly agree that's simpler than Lambda@Edge, and option well worth considering.

I looked at that approach at the time but didn't go down that route because, as far as I understood (unless I missed something), that would involve having the S3 bucket directly publicly accessible over HTTP (not HTTPS) with the S3-style URLs, including public access. And my main motivation for adding CloudFront to the mix was to support/enforce TLS - I certainly didn't have traffic levels requiring it!

(But, pragmatically, the key risks of someone going to the effort of finding and using the unpublished S3 URL would seem to be be that (a) the site could stop working if I change the hosting and (b) they, through their own choice, aren't using TLS - which, for a static, low-traffic, personal blog, could be considered pretty low.)

Hello, author here.

Thanks for the information. I guess we never encountered this because our application is in react js framework, so once the build is done it creates just one index.html file and there are no subdirectories.

But this is duly noted

Thanks, that makes sense - I've not used ReactJS, but guessed that your site only needed the top-level index.html, so that was handy.