2 Answers
Your call. Either will work. The bucket policy is arguably easier on the users from the other account as they don’t need to adopt a role, but they will still need to be able to authenticate to the S3 service in the bucket’s home AWS account.
I agree with Steven that bucket policies are easier to use. AWS mentions this on a dedicated IAM documentation page [1].
@Mattias: I can imagine one situation in which you might not want to add statements into bucket policies. It would be in the case that your bucket policy reaches the 20kb limit and you want to add additional principals for cross-account-access. You could then "complement" your resource-based policy using an IAM role with IAM policies. I understand that this scenario is highly theoretical though. Actually, AWS always depicts the other direction, where IAM policies reach size limits (because they are smaller) and users should switch to bucket policies. [2]
In this (https://www.youtube.com/watch?v=x25FSsXrBqU, around 29:40) re:Invent talk they mention a situation where assuming a role makes sense. (1) Account-A has a bucket, (2) Account-B uploads an object to the bucket, and provides full control to Account-A using an ACL on the object, (3) If Account-B also wants to give access to this object to Account-C and Account-D via the same mechanism, but if you have a large number of objects this could quickly be difficult to administrate, (4) So in this case a role in Account-A can be provided that Account-C and Account-D can assume to gain access to the objects, and Account-B only have to specify Account-A in the ACL.
Great example! The case where the bucket owner (A) is not the object ower (B) and wants to grant access to other accounts (C, D) is a perfect example. Thanks! So, to make it clear for all other readers: a bucket policy applies to objects that account A owns!
It’s definitely easier to use a bucket policy in this case, but I guess there could be situations where you would rather not use one.