AWS S3 PutObject fails with AccessDenied despite an allow policy

Hi, it's BlueByte. If a PutObject keeps failing with AccessDenied and you can see s3:PutObject right there in the policy, adding more allows will not help — something is denying the write, and a deny always wins. Let's find the one policy that actually decides, then fix that instead of piling on permissions and hoping.

What AccessDenied is really saying here

The call fails even though the caller has s3:PutObject:

An error occurred (AccessDenied) when calling the PutObject operation:
Access Denied

In AWS an allow can be overridden. Something in the evaluation chain is denying the write, and another allow will not undo a deny. So the job is not "grant more" — it is to find which policy decides and correct that one.

Why an allow can still be overruled

A request succeeds only if there is an allow and no deny anywhere it is evaluated — the identity policy, the bucket policy, any permission boundary, and the organization's Service Control Policies (SCPs). The usual reasons a valid identity allow still fails:

• The caller is in another account and the bucket policy does not grant it — an identity allow never crosses an account boundary by itself.
• An explicit Deny exists somewhere — for example a bucket policy that denies unless aws:SecureTransport is true (blocking plain HTTP), or an SCP that denies the action.
• The write uses an ACL like bucket-owner-full-control, but the bucket has Object Ownership = Bucket owner enforced, which disables ACLs entirely.
• The KMS key protecting the bucket denies the caller kms:GenerateDataKey, so the encrypted write fails even though S3 would allow it.
• The key or bucket in the request does not match the policy's Resource.

Ask the simulator which statement decides

You do not have to read four policies in your head — ask the IAM policy simulator which statement wins:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/uploader \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::my-bucket/path/key

The result names the allowing or denying statement. If it says allowed but the real call still fails, the deny is in the bucket policy or an SCP the simulator did not include — check those next. Add --debug to the failing CLI call to see the exact resource it targeted and whether a KMS step is involved.

Fix the specific decider

1. Cross-account caller — add the principal to the bucket policy explicitly:

{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/uploader" },
  "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/*" }

2. Explicit deny — find and narrow it. A common one denies non-TLS requests, so make sure your client uses HTTPS.

3. ACL write blocked by ownership — drop the ACL and rely on the bucket-policy grant, or change Object Ownership away from "Bucket owner enforced" only if you truly need ACLs.

A real case: a write that crossed accounts

An uploader role in account B writes to a bucket in account A and gets AccessDenied, even though the role has s3:PutObject. The simulator against the role says "allowed" — which points away from the identity policy. Reading account A's bucket policy, there is no statement granting account B; the identity allow never crossed the account boundary. You add an explicit Allow for the account B role to the bucket policy, and the write succeeds. Nothing about the role changed — the missing grant was on the resource side all along.

Confirm the object actually landed

Retry the exact write, then check it is really there:

aws s3api put-object --bucket my-bucket --key path/key --body ./file
aws s3api head-object --bucket my-bucket --key path/key

A successful head-object means the write went through under the corrected policy — not just that the error message changed.

Keep it from recurring

Prefer bucket-policy grants over ACLs so ownership settings cannot silently block writes, keep SCP denies documented, grant kms:GenerateDataKey on the key when the bucket is encrypted, and run the simulator while you set up any new cross-account access rather than discovering the deny in production.

How this differs from a public-access or Region error

AccessDenied on GetObject from a browser is usually Block Public Access — a different setting. And a NoSuchBucket or a 403 from the wrong Region is not a policy problem at all — check the endpoint and bucket name before you touch policies. Next time a write is denied with the allow clearly present, start at the deny, not the allow.