learn

Amazon S3 AccessDenied — Troubleshooting Guide

A practical path for diagnosing S3 AccessDenied errors across identity, bucket policy, encryption, and ownership controls.

Troubleshooting

Start with the symptom. End with a verified fix.

What’s wrong?

An application or user receives AccessDenied while reading, writing, or listing an S3 resource.

Possible causes

  1. Missing identity permission
  2. restrictive bucket policy
  3. explicit deny
  4. KMS permission issue
  5. object ownership or resource mismatch

Diagnosis

  1. Identify the caller
  2. identify the exact S3 action and resource
  3. inspect identity and bucket policies
  4. look for explicit denies
  5. inspect encryption and ownership requirements

2 · Fix

Grant only the missing permission at the narrowest required scope or remove the confirmed conflicting control.

Verify

Repeat the exact operation and confirm CloudTrail or application evidence where available.

3 · Prevent

Use least privilege, policy tests, clear ownership rules, and documented encryption requirements.

Amazon S3 AccessDenied

Start with who is calling, what action is being attempted, and which resource is affected.

Diagnose

  1. Identify the IAM principal or workload role.
  2. Identify the exact action: GetObject, PutObject, ListBucket, and so on.
  3. Confirm the object/bucket ARN is the one your policy actually targets.
  4. Inspect identity policies and bucket policies for both allows and explicit denies.
  5. If SSE-KMS is involved, verify the caller can use the required KMS key.
  6. Check ownership and cross-account requirements.

Fix → Verify → Prevent

Avoid * permissions as a shortcut. Make the smallest policy change that explains the evidence, repeat the failed operation, and retain a policy test or runbook entry for future incidents.

Engineering companion

Learn → troubleshoot → design → prepare → test

Explore the knowledge graph

Knowledge path

Connected concepts

Explore the knowledge graph