Comment by BayesianDice | Hacker News Reader

Comment by BayesianDice | Hacker News Reader

I did find one catch with the S3/CloudFront approach, relating to default document, when I was looking at hosting a static Hugo site a few months ago. With S3 web hosting, you can specify a default object which also works for subdirectories (e.g. so http://www.example.com returns http://www.example.com/index.html and http://www.example.com/foo returns http://www.example.com/foo/index.html). With Cloudfront, the default document doesn't apply to subdirectories, which would have broken my site.

(For the author of this article, it looks like the combination of CLoudFront's default document and custom error handling did the job for their site - just flagging this as something to look out for in cases where it doesn't work :-) )

AWS suggest a workaround using Lambda@Edge (https://aws.amazon.com/blogs/compute/implementing-default-di...) to rewrite the requests at the CloudFront layer - but at that point I decided that actually getting the site published was more important than adding more to the technology stack, so it's now happily hosted on Netlify's free tier.

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.

Reply on news.ycombinator.com