I'm not much into them these days but if I remember correctly in the 4-5 years prior, they just works! In-fact, CloudFront was easier to serve static web assets than serving directly from S3.
Or have I misunderstood what you meant?
The problem is that essentially every time a user goes to the site it will be a 404 status code since they are probably not typing in example.com/index but this has pragmatically not been an issue for a wholly authenticated, private, B2B SaaS app. The marketing website is a separate subdomain.
For a public site this is probably worse than returning 200s that should be 404s occasionally, though.
[0]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Custom...
IE the it would happily resolve / to /index.html would be fine, but if you wanted to do /my-dir and have it resolve to /my-dir/index.html it would 404.
Did some quick searches and I think there seems to be some kinks indeed and of course the solutions. Here are a few;
- https://stackoverflow.com/questions/59634922/how-do-i-serve-...
- https://aws.amazon.com/blogs/networking-and-content-delivery...
Update/Edit: I think the setting to use correct S3 Endpoint makes a difference (which was indeed always my default way when I did).
https://stackoverflow.com/questions/31017105/how-do-you-set-...
Here's the request edge lambda:
https://github.com/radiosilence/cdk-static-web/blob/master/s...
Here's the response edge lambda:
https://github.com/radiosilence/cdk-static-web/blob/master/s...
It's been a while since I've updated that project though.
With nano-web for my current site (https://blit.cc) I am just spinning up a free-tier unikernel instance on EC2 and using it as the CF origin. Possibly even more cost effective than S3, and far simpler.
Response times for the "waiting" portion are usually around 5-10ms with CF and if I am going direct to the origin it's around 2-5ms