petewilcock
commented
3 years ago This is true and I've thought about this method, but there's a secondary advantage of using Lambda@edge which you can see in the function itself - it'll also look for requests for index.php and rewrite those to index.html. This is particularly useful (as was in my case) when several search engines and incoming links had linked to index.php directly. With a website endpoint there's no way to accommodate both scenarios.
Might be possible to make this optional though, although the cost impact of Lamda@edge is pretty fractional in my observations so far.
I noticed that you're using Lambda@Edge to handle default root objects in subdirectories. That's a good solution that works with OAI, but there's another way to do this. This is documented at https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serve-static-website/ under "Using a website endpoint as the origin, with access restricted by a Referer header"
1) S3 bucket policy configured to allow access based on referrer header (set to a secret key) 2) S3 static website hosting, with index document enabled as index.html - unlike cloudfront, this works on subfolders 3) Cloudfront distribution pointing to the static website URL (rather than the S3 bucket) with referrer header set