2

It seems there are kind of two ways to host a static website on S3/CloudFront.

  1. Create S3 bucket with full public access and Static Website set to Enabled + CloudFront config
  2. 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?

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
4
  • I guess the other "do not like" about S3 public hosting is that people can access via a the URL like https://mything.s3.us-east-2.amazonaws.com/index.html. But is that a big deal? I really don't know.
    – pbuzz007
    Nov 1, 2021 at 17:13
  • I can't see how the second URL would be an issue. You could exclude robots using robots.txt.
    – Tim
    Nov 1, 2021 at 18:59
  • Okay. I've spent all day on this, and I have a bad feeling that giving public access also means anyone with an AWS account can write to a bucket?? I think this because I created a second bucket to be a "secure" one in which only one of my IAM users can write to. But I found the only way to use the AWS sdk was to turn on public access to the bucket! Ahhh.. can anyone write to a public bucket?
    – pbuzz007
    Nov 2, 2021 at 2:14
  • You control access with your bucket policy docs.aws.amazon.com/AmazonS3/latest/userguide/…
    – Tim
    Nov 2, 2021 at 3:37
1

I would opt for the second option. The S3 bucket remains private with read only access granted to the cloudfront origin access identity (OAI). And you ensure requests are optimized via cloudfront as opposed to the s3 website endpoint.

In order to get around resolving index.html, you can either use lambda@edge functions or cloudfront functions. There's an example for the latter in the AWS docs:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-index.html

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .