AWS S3 'An error occurred (AccessDenied) when calling the GetObject operation: Access Denied' (or PutObject). How do I find out whether it is the bucket policy, KMS key, Object Ownership/ACLs or an organization policy?

Cause: S3 returns 403 AccessDenied when AWS denies the request, either explicitly (a Deny statement matched) or implicitly (nothing allowed it). Several layers are evaluated together, so an Allow in your IAM policy is not enough if any other layer blocks the request. Common layers: identity-based policy, bucket policy, S3 Block Public Access, ACLs and Object Ownership, SSE-KMS key permissions, VPC endpoint policy, AWS Organizations SCP/RCP, permissions boundary, session policy, Requester Pays, and S3 Object Lock. Fix (work through in order): 1. Read the full error text. When the caller and bucket owner are in the same AWS Organization, S3 returns an enhanced message that states whether the denial was implicit or explicit and which policy type caused it (identity policy, resource policy, SCP, VPC endpoint policy, permissions boundary, session policy). Fix exactly that layer. 2. Confirm who you really are: run aws sts get-caller-identity, and check you are using the profile/role you expect. 3. Check the identity policy and bucket policy grant the right action on the right ARN. Bucket-level actions (s3:ListBucket) need the bucket ARN; object actions (s3:GetObject, s3:PutObject) need the bucket ARN followed by /*. Look for any Deny statement (for example one requiring SSE-KMS, a specific VPC endpoint or source IP). 4. For cross-account access, both the caller's identity policy and the bucket policy must allow the action. Allow statements in a bucket policy only apply to objects owned by the bucket-owning account. 5. Objects and ACLs: check the bucket's Object Ownership setting. With Bucket owner enforced, ACLs are disabled and the bucket owner owns every object, which is the recommended setup. With Bucket owner preferred or Object writer, objects uploaded by another account may be owned by that account, so the bucket owner may be denied; have uploaders use the bucket-owner-full-control ACL or move the bucket to Bucket owner enforced after reviewing existing ACL use. 6. Encryption: for SSE-KMS with a customer managed key, the caller needs kms:GenerateDataKey to upload and kms:Decrypt to download, and the key policy must allow it. With the AWS managed aws/s3 key the requester must be in the account that owns that key, so cross-account reads of such objects fail. 7. Check Block Public Access settings, VPC endpoint policies, SCPs, permissions boundaries and Requester Pays (the caller must opt in with the request-payer option) if the message points there. 8. Use the IAM policy simulator to test identity policies, boundaries and SCPs without making real requests, but treat the result as a guide and retest against the live bucket. Verify: repeat the failing call (for example aws s3api head-object --bucket EXAMPLE-BUCKET --key path/to/object) and confirm it succeeds, then check CloudTrail for no remaining AccessDenied events from that principal. Sources: https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html