How cross-account access to an Amazon S3 bucket works
Cross-account S3 access requires a clear trust path between the account that owns the data and the identity that needs it. A bucket policy can grant a named external principal access, while an assumable role can centralize the permissions and trust relationship.
Choose the access pattern
For a direct resource-policy pattern, the bucket owner adds a bucket policy naming the external AWS account or role and the required S3 actions. The external identity also needs an identity-based policy that allows those actions. Access is still subject to applicable explicit denies, organization controls, and encryption-key permissions.
For a role pattern, the bucket-owning account creates a role with narrowly scoped S3 permissions and a trust policy for the external account. A principal in that account must be allowed to assume the role. The caller then uses the role’s temporary credentials to access the bucket.
- Use a bucket policy for a direct, resource-scoped grant to a known account or role.
- Use an assumable role when the bucket owner should own the access policy and callers can switch into that role.
- Grant only the required actions and bucket or object resources; listing a bucket and reading objects use different resource ARNs.
Check object ownership and encryption too
Bucket policies do not automatically grant access to objects owned by a different account. S3 Object Ownership set to Bucket owner enforced disables ACLs and makes the bucket owner own uploaded objects, which simplifies policy-based access. Legacy or intentionally different ownership configurations need their own review.
If objects use SSE-KMS with a customer-managed key, the KMS key policy and caller permissions must also permit the needed cryptographic operations. An S3 allow does not override a missing KMS permission or an explicit deny.
A safe verification sequence
Identify the actual caller ARN and the account that owns the bucket and objects. Then verify the trust or bucket resource policy, the caller’s identity policy, the exact bucket-versus-object resource ARN, and any KMS key policy. Test the intended operation with the same role and request path the application will use.
Common questions
Is a bucket policy alone enough for cross-account access?
Do not assume it is. AWS’s S3 guidance describes cross-account permission as requiring authorization for the external identity as well as the resource grant. Review the caller’s identity policy and every applicable policy boundary or deny.
Should I use ACLs to solve cross-account object access?
First check Object Ownership. With Bucket owner enforced, ACLs are disabled and policies control access. A role or bucket policy is often easier to audit than introducing object ACLs.