Score:0

AWS S3 Static Website vs CloudFront OIA

si flag

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?

Score:1
gp flag
Tim

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.

pbuzz007 avatar
si flag
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.
Tim avatar
gp flag
Tim
I can't see how the second URL would be an issue. You could exclude robots using robots.txt.
pbuzz007 avatar
si flag
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?
Tim avatar
gp flag
Tim
You control access with your bucket policy https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteAccessPermissionsReqd.html
Score:0
cn flag

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

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.