
Investigating Multi-Account IAM Issues in S3 and CloudFront - kevinslin
https://kevinslin.com/aws/tale_of_two_buckets
======
time0ut
Cool write up. Just went through this exact use case a couple months ago. I
wish there was a simpler way of just making the bucket owner automatically own
anything put into that bucket to simplify use cases like this.

~~~
kevinslin
there is the next best thing - making sure that objects uploaded to your
bucket also give you full ownership over said objects:
[https://aws.amazon.com/premiumsupport/knowledge-
center/s3-re...](https://aws.amazon.com/premiumsupport/knowledge-
center/s3-require-object-ownership/)

------
shortj
For anyone else that is looking at rolling your own static hosting like this
on AWS specifically (including CloudFront cache invalidations and protected
domains), I highly recommend checking out Amplify Console
[https://aws.amazon.com/amplify/console/](https://aws.amazon.com/amplify/console/).
It's a little bit more feature-rich and avoids headaches like the article ran
into. Closer to Netlify than it is to CloudFront + S3.

~~~
mi100hael
Honestly after using Amplify to develop a new app, I have a hard time
recommending it unless your use-case fits their design perfectly and will
never grow beyond those bounds.

If you've already made any design decisions or need to do something
differently than Amplify expects, it is a minor nightmare. It generates
multiple local copies of templates for nested cloudformation stacks and
doesn't really support manual editing. The basic Amplify CLI commands entirely
abstract away what's actually happening with the AWS APIs. "Ejecting" takes
loads of time to basically reverse-engineer the Amplify CLI, clean up the
generated templates, and then create your own build process that you can
tweak.

It would be much easier to recommend Amplify if it wasn't so far removed from
the underlying AWS APIs and it provided an easy way to modify those API calls
or templates instead of being stuck within its guard rails.

~~~
shortj
Amplify CLI and Amplify Console have nothing to do with one another. Confusing
naming, I know.

~~~
mi100hael
Classic AWS. I have a SA Pro cert and I still couldn't reliably articulate the
difference between Lightsail, SAM, and Amplify CLI. It feels like they keep
adding to each without any apparent strategy. I didn't even know there was
another product also branded "Amplify" separate from the CLI.

AWS really needs more centralized decision-making. It feels like individual
product teams are allowed to go way off in the weeds without any frame of
reference for whether their solutions make sense when plugged into the full
suite.

~~~
shortj
The Amplify naming is a special kind of AWS classicality. Amplify, what a
great Netlify like experience! Oh... not that one, you mean the CLI/Framework.
Also pretty cool, we'll see how it plays out with the CDK. No? You mean the
literal Amplify library that makes UI work easier. All of which can work
together, but don't necessarily have to.

I can't complain too much, it's a bit of job assurance for folks like myself
that specialize in only AWS. Exhausting keeping up to speed on everything
though.

------
wgjordan
> A great engineer that I knew at AWS once said:

> > When you see hoof prints, think horses not zebras.

Looked this one up and the original medical aphorism dates back to the 1940s
and was 'When you hear hoofbeats' [1], in case anyone's curious.

[1]
[https://en.wikipedia.org/wiki/Zebra_(medicine)](https://en.wikipedia.org/wiki/Zebra_\(medicine\))

~~~
ShroudedNight
It's worth noting that in a computing context the reliability of this
heuristic is questionable relative to what it would be in medicine:

[https://youtu.be/fE2KDzZaxvE](https://youtu.be/fE2KDzZaxvE)

Zebras All the Way Down - Bryan Cantrill, Uptime 2017

------
jasonpeacock
I _just_ learned this same thing (Object ACLs) last night, and my mind was
blown that a bucket can have objects owned and controlled by other accounts,
which then prevents a third account from accessing those objects even though
it has bucket access.

But when you stop and think about it, it's a similar model as Unix
file/directory ACLs...I just hadn't expected it to apply to S3 buckets too.

I still have the tab open for the docs to fix access:

[https://docs.aws.amazon.com/AmazonS3/latest/dev/example-
walk...](https://docs.aws.amazon.com/AmazonS3/latest/dev/example-walkthroughs-
managing-access-example4.html)

------
kevinslin
author here - curious about interesting AWS issues you've encountered and
lessons learned from them

~~~
jeffnappi
An issue I've encountered with static website hosting on CloudFront+S3 is that
if you want `index.html` to be served at the root path of a URL - e.g.
[https://www.yoursite.com/folder/](https://www.yoursite.com/folder/) vs
[https://www.yoursite.com/folder/index.html](https://www.yoursite.com/folder/index.html),
you must use the s3 website endpoint rather than the S3 Origin. And in that
case, unfortunately, it is not possible to use Origin Access Identity.

~~~
kevinslin
good news is that you can remedy that now by using lambda@edge to rewrite
requests - there's even an aws blog post about it:
[https://aws.amazon.com/blogs/compute/implementing-default-
di...](https://aws.amazon.com/blogs/compute/implementing-default-directory-
indexes-in-amazon-s3-backed-amazon-cloudfront-origins-using-lambdaedge/)

~~~
fishtacos
From the blog post above:

"It does not work on any subdirectory (such as
[http://www.example.com/about/](http://www.example.com/about/)). If you were
to attempt to request this URL through CloudFront, CloudFront would do a S3
GetObject API call against a key that does not exist."

