AWS S3 Static Website vs CloudFront OIA
It seems there are kind of two ways to host a static website on S3/CloudFront.
- Create S3 bucket with full public access and Static Website set to Enabled + CloudFront config
- Create S3 bucket with no public access and Static Website set to Disabled + CloudFront config
What I don't like about (1) is the glaring "DO NOT DO THIS" red text for public access. But it works perfectly.
What I don't like about (2) is that I lose the Static Website set to Enabled benefits, like everything auto redirected to index.html. Now I see there is a root origin object in the CloudFront settings, but this only works for my base domain (eg mysite.com). My site is an SPA and with (1) if I go to mysite.com/profile it would correctly go to mysite.com/index.html I think because of the 404 redirect I had setup. But with (2) going to mysite.com/profile is not a 404 but rather an 403 access denied, which I don't think is smart to redirect like the 404.
So should I stick with option (1) even with the glaring red text about public access? Or is there a proper way to do an SPA without public access/static website hosting?
Solution 1:
The public access warning can safely be ignored for websites hosted on S3. The bucket / files are deliberately public. AWS should probably disable that warning when website hosting is enabled.
A CloudFront distribution will obviously given better performance, but for a single page application it might not be significant enough to bother with, your call based on knowledge of your users / application. Rather than rely on the web server to issue redirects can you not code it in your application so the links are how you want them? You can do redirects with CloudFront@Edge but that takes extra work and adds some level of extra costs.