Fix AWS S3 403 Access Denied Errors: A Layer-by-Layer Guide

1. Introduction

An S3 403 Access Denied is deceptively simple: the request reached S3, S3 understood it, and S3 refused it. The hard part is that "denied" can originate from at least five independent authorization layers — the caller's IAM policy, the bucket policy, S3 Block Public Access, Object Ownership/ACLs, the KMS key policy, and (for private access) a VPC endpoint policy. Any one of them can veto the request, and the error message rarely tells you which.

This guide gives you a deterministic order to check those layers, the exact CLI commands to inspect each one, and the fixes for the cases that cause the overwhelming majority of production 403s — especially the ones that appear after enabling encryption or turning on Block Public Access.

2. What a 403 Actually Tells You

S3 evaluates every request against the union of all applicable policies. The decision logic is: an explicit Deny anywhere always wins; otherwise you need an explicit Allow from an identity-based or resource-based policy. No matching Allow = implicit deny = 403.

• AccessDenied on GetObject/PutObject — most often IAM or bucket policy, or a KMS permission gap on an encrypted object
• AccessDenied on ListBucket — the s3:ListBucket action is on the bucket ARN, not the object ARN; a very common policy mistake
• 403 when made public — Block Public Access is overriding your bucket policy/ACL
• AccessDenied right after enabling SSE-KMS — the caller lacks kms:Decrypt/kms:GenerateDataKey on the key

3. Common Causes

• IAM policy is missing the action, or scopes it to the wrong ARN (bucket vs object)
• Bucket policy contains an explicit Deny (often "deny if not using TLS" or "deny if wrong VPC/account")
• S3 Block Public Access is on and is overriding a public bucket policy or ACL
• Object was uploaded by another account and, under Object Ownership, ACLs still grant ownership to the uploader
• The bucket uses SSE-KMS and the principal lacks kms:Decrypt or kms:GenerateDataKey on the key
• Requests go through a VPC gateway endpoint whose endpoint policy restricts buckets/actions
• An SCP at the AWS Organizations level denies the action regardless of IAM
• Cross-account access without both an IAM allow (caller side) and a bucket policy allow (resource side)

4. Step-by-Step Diagnosis and Fix

Step 1: Confirm who is actually calling

# Which identity is the request using? (role vs user matters)
aws sts get-caller-identity

# Reproduce the exact failing call with debug to see the request/response
aws s3api get-object --bucket my-bucket --key path/to/key /tmp/out --debug 2>&1 | tail -40

Step 2: Simulate the policy decision (fastest root-cause tool)

# IAM Policy Simulator via CLI — tells you Allow/Deny and WHICH policy decided
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/app-role \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/path/to/key

Step 3: Verify the IAM policy uses the correct ARNs

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"          // OBJECT actions -> /*
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-bucket"             // LIST -> bucket ARN
    }
  ]
}

Step 4: Inspect the bucket policy for explicit Deny

aws s3api get-bucket-policy --bucket my-bucket \
  --query Policy --output text | python -m json.tool

# Watch for a common TLS-only deny that 403s any non-HTTPS request:
# "Effect": "Deny", "Condition": {"Bool": {"aws:SecureTransport": "false"}}
# and account/VPC restrictions like aws:SourceVpce or aws:PrincipalAccount.

Step 5: Check Block Public Access and Object Ownership

# Block Public Access overrides public policies/ACLs when true
aws s3api get-public-access-block --bucket my-bucket

# Object Ownership — "BucketOwnerEnforced" disables ACLs entirely
aws s3api get-bucket-ownership-controls --bucket my-bucket

# If a cross-account upload left ownership with the uploader:
aws s3api get-object-acl --bucket my-bucket --key path/to/key

Step 6: Fix KMS permissions for SSE-KMS buckets

If the bucket enforces SSE-KMS, S3 access is not enough — the caller also needs key permissions. A 403 that started right after enabling encryption is almost always this.

# Find the bucket's default KMS key
aws s3api get-bucket-encryption --bucket my-bucket

# The principal needs these on the KMS key (via key policy or IAM):
#   kms:Decrypt           (GetObject)
#   kms:GenerateDataKey   (PutObject)
{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "arn:aws:kms:us-east-1:111122223333:key/KEY-ID"
}

5. Verification Steps

# List (needs s3:ListBucket on the bucket ARN)
aws s3 ls s3://my-bucket/path/

# Download (needs s3:GetObject on the object ARN + kms:Decrypt if SSE-KMS)
aws s3 cp s3://my-bucket/path/to/key /tmp/ok

# Upload (needs s3:PutObject + kms:GenerateDataKey if SSE-KMS)
echo test | aws s3 cp - s3://my-bucket/path/verify.txt

# Re-run the simulator and confirm it now returns "allowed"
aws iam simulate-principal-policy --policy-source-arn <role-arn> \
  --action-names s3:GetObject --resource-arns arn:aws:s3:::my-bucket/path/to/key

6. Common Mistakes

• Putting s3:ListBucket on the object ARN (/*) instead of the bucket ARN
• Adding S3 permissions but forgetting KMS permissions on an SSE-KMS bucket
• Assuming a bucket is public because the policy says so — Block Public Access silently overrides it
• Debugging the wrong identity: an EC2/EKS workload uses its instance/IRSA role, not your CLI user
• Ignoring an explicit Deny in the bucket policy or an Organizations SCP, which no IAM Allow can override

7. Prevention Tips

• Use the IAM Policy Simulator (or aws s3api ... --dryrun patterns) in CI before shipping policy changes
• Standardize on BucketOwnerEnforced Object Ownership to eliminate ACL-based 403s entirely
• Grant KMS key permissions in the same change that enables SSE-KMS, not after the first failure
• For workloads on EKS, prefer IRSA so each pod has a scoped role instead of node-wide credentials
• Related EKS/IAM denials that aren't S3-specific are covered in Fix AWS AccessDenied (IAM & EKS)

8. FAQ

9. Summary