Fix S3 Access Denied (403 Forbidden) Errors in AWS

Quick answer

S3 Access Denied errors come from one of these sources:

• IAM policy: the calling principal lacks the required S3 action in their identity policy
• Bucket policy: an explicit Deny in the bucket policy, or no Allow for a cross-account request
• Block Public Access: a setting blocks access patterns that look public (anonymous or broad-principal)
• Object Ownership / ACL state: ACLs are disabled or the object is owned by a different account
• SSE-KMS permissions: the object is encrypted with a KMS key and the caller lacks kms:Decrypt or kms:GenerateDataKey
• VPC endpoint policy: a Gateway or Interface endpoint policy restricts which buckets or actions are allowed
• SCP / RCP: AWS Organizations controls restrict the action at the account level
• Access point policy: an access point is in the request path and its policy does not cover the action
• Presigned URL: the URL has expired or the session that created it has ended

Same-account and cross-account requests behave differently. Within the same account, one Allow (either IAM or bucket policy) is usually enough if no Deny exists. Across accounts, both sides must explicitly allow the action.

The fastest debugging path: identity → same account or cross-account → explicit Deny → missing Allow → Block Public Access → object ownership → encryption → network controls.

Check these first:

• Who is making the request? (aws sts get-caller-identity)
• Is the bucket in the same AWS account as the caller?
• Does the bucket policy contain an explicit Deny?
• Does the IAM policy include the right action and the correct ARN format?
• Is Block Public Access enabled at the account or bucket level?
• Who owns the objects: the bucket owner or another account?
• Are objects encrypted with a customer-managed KMS key?
• Is the request going through a VPC endpoint?

What “Access Denied” actually means in S3

Most AWS services return an AccessDenied error that names the missing permission. S3 is different. S3 returns a flat Access Denied with no explanation, by design, so that private bucket existence is not leaked to unauthorized callers.

This makes debugging harder than a typical IAM AccessDenied error, where the error message usually names the specific action and resource.

Think of S3 access like getting into a secure building that has multiple checkpoints. Each checkpoint operates independently. Passing the front desk (IAM policy) does not guarantee you pass the floor scanner (bucket policy). Getting through both doesn’t help if the elevator requires a separate key card (KMS permissions). You need to clear every relevant checkpoint, and any single one can send you back.

S3 has its own authorization layer that evaluates several policies simultaneously:

• Your IAM policy must allow the action
• The bucket policy may allow or deny the action independently
• Block Public Access filters certain request patterns before policy evaluation even begins
• KMS permissions apply on top of S3 permissions if the object is encrypted with a customer-managed key
• VPC endpoint policies restrict what S3 actions are allowed through the endpoint

Whether one Allow is enough depends on the account relationship.

Same-account access is more permissive. If you own the bucket and the IAM principal, one Allow (either IAM policy or bucket policy) is usually sufficient, as long as no explicit Deny exists anywhere.

Cross-account access is stricter. If Account B wants to access a bucket in Account A, both the IAM policy in Account B and the bucket policy in Account A must allow the action. Without both, the request is denied by default.

Understanding same-account vs cross-account resolves the majority of S3 403 errors.

How S3 access control actually works

S3 evaluates several policy layers in every request. Here is what each one controls and when it causes a 403.

Same-account vs cross-account S3 access#

S3 now returns enhanced access denied messages for same-account and same-organization requests that indicate which policy type caused the denial. Check CloudTrail for these.

Fast diagnosis checklist

Work through these steps in order. Most S3 Access Denied errors are found by step 6.

Step 1: Confirm caller identity.

aws sts get-caller-identity

Verify the account ID, user ID, and ARN. A frequent trap: your CLI profile uses a different role than your application does. Make sure these match.

Step 2: Confirm whether the bucket is in the same account.

aws s3api get-bucket-location --bucket my-bucket

If this returns Access Denied, you may lack s3:GetBucketLocation, or the bucket belongs to a different account.

Step 3: Check CloudTrail for the exact denial.

CloudTrail logs S3 data events with errorCode=AccessDenied. Same-account denials now include enhanced messages indicating which policy type caused them.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=my-bucket \
  --query 'Events[?contains(CloudTrailEvent, `AccessDenied`)]'

Step 4: Check the IAM policy.

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/my-role \
  --action-names s3:GetObject \
  --resource-arns "arn:aws:s3:::my-bucket/path/to/object"

Run separate simulations for s3:ListBucket with the bucket ARN (arn:aws:s3:::my-bucket) and for object actions with the object ARN (arn:aws:s3:::my-bucket/*).

Step 5: Check the bucket policy.

aws s3api get-bucket-policy --bucket my-bucket

Look for any "Effect": "Deny" statements. Check whether Principal and Resource in Allow statements actually match your caller ARN and the object path you are requesting.

Step 6: Check Block Public Access settings.

# Account-level settings
aws s3control get-public-access-block --account-id 111122223333

# Bucket-level settings
aws s3api get-public-access-block --bucket my-bucket

If BlockPublicPolicy or RestrictPublicBuckets is true and your bucket policy uses "Principal": "*", the policy is silently blocked.

Step 7: Check object ownership and ACL state.

aws s3api get-bucket-ownership-controls --bucket my-bucket

If ObjectOwnership is BucketOwnerEnforced, all ACLs are disabled and the bucket owner owns all objects. If objects were uploaded by a different account without bucket-owner-full-control, the bucket owner cannot read them.

Step 8: Check whether SSE-KMS is involved.

aws s3api head-object --bucket my-bucket --key path/to/object \
  --query '[ServerSideEncryption, SSEKMSKeyId]'

If SSEKMSKeyId is present, the object is encrypted with a KMS key. Confirm your principal has kms:Decrypt for reads or kms:GenerateDataKey for writes. See Customer Managed Keys for how to update KMS key policies.

Step 9: Check the VPC endpoint policy if traffic goes through a VPC.

aws ec2 describe-vpc-endpoints \
  --filters Name=service-name,Values=com.amazonaws.us-east-1.s3

A restrictive VPC endpoint policy can block access to specific buckets or actions even when both IAM and bucket policies allow them.

Step 10: Check Organizations controls.

If the account is under AWS Organizations, check whether any Service Control Policy (SCP) or Resource Control Policy (RCP) restricts S3 access for the account or OU. SCPs require management account access to review.

Step 11: Check presigned URL validity.

If you are using a presigned URL:

• Check whether the URL has passed its expiry (default: 1 hour)
• Check whether the role session that signed the URL has expired
• Check whether a bucket policy Deny was added after the URL was created
• Verify the client clock is within 15 minutes of AWS time

See S3 Signed URLs for how presigned URL signing and expiry works.

Step 12: Check access point, CloudFront, or website endpoint path.

If your request goes through an S3 access point, a CloudFront distribution, or an S3 static website endpoint, the authorization path differs from a direct bucket request. A CloudFront Origin Access Control (OAC) requires the bucket policy to allow the specific CloudFront distribution ARN as the principal. If the bucket policy still references an old OAI, access fails.

Common root causes of S3 Access Denied

How to fix same-account S3 Access Denied

Within the same account, S3 access usually requires one Allow: either in the IAM policy or the bucket policy, as long as no explicit Deny exists. The most common cause is a missing IAM permission or a wrong ARN format in the policy.

The most common fix: add the missing action with the correct ARN format.

Bucket-level actions (s3:ListBucket, s3:GetBucketLocation) need the bucket ARN. Object-level actions (s3:GetObject, s3:PutObject, s3:DeleteObject) need the object ARN with /*. Use two separate statements:

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

A policy with only "Resource": "arn:aws:s3:::my-bucket/*" will fail on ListBucket. A policy with only "Resource": "arn:aws:s3:::my-bucket" will fail on GetObject and PutObject.

If objects are encrypted with a customer-managed KMS key, the IAM policy alone is not enough. The role also needs kms:Decrypt in the KMS key policy. Run head-object to confirm the key ID, then review the key policy via aws kms get-key-policy.

See S3 IAM vs Bucket Policies for a detailed comparison of when to use each policy type.

How to fix cross-account S3 Access Denied

Cross-account S3 access requires explicit allows on both sides. Neither the bucket policy alone nor the IAM policy alone is sufficient.

Think of it like two locked doors. The bucket owner holds the key to the first door (bucket policy) and Account B holds the key to the second door (IAM policy). You need both keys to get through. Having only one key gets you nowhere.

Scenario: Account A owns the bucket. Account B has the role that needs access.

Bucket policy in Account A:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::222233334444:role/reader-role"
    },
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-shared-bucket",
      "arn:aws:s3:::my-shared-bucket/*"
    ]
  }]
}

IAM policy on reader-role in Account B:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-shared-bucket",
      "arn:aws:s3:::my-shared-bucket/*"
    ]
  }]
}

Both must be present. If Account A’s bucket policy grants access but Account B’s role has no S3 IAM policy, the request is denied. If Account B has an IAM policy but Account A has no bucket policy, S3’s default denies the cross-account request regardless.

For understanding how role assumption works in cross-account scenarios, see AWS STS and Temporary Credentials.

S3 Access Denied vs IAM AccessDenied

These are two different errors from two different authorization layers. Distinguishing them speeds up debugging significantly.

For guidance on IAM-layer permission errors that also affect S3, see Fixing IAM AccessDenied Errors. For how to read authorization failures in audit logs, see CloudTrail Log Types.

When to use this page

This page covers:

• AWS CLI, SDK, or application requests returning S3 Access Denied or HTTP 403
• Cross-account bucket access failures: works in one account but not another
• Public bucket or static website returning 403
• Presigned URL failures, including URLs that expire unexpectedly early
• CI/CD pipelines that can read from S3 but fail on writes
• CloudFront or application paths where S3 is the backing store
• VPC-internal workloads that cannot reach S3 despite having IAM permissions

If your error involves credential authentication failing (signature mismatch, token expired, bad access key), see Troubleshooting Authentication Errors.

Real scenario: CI/CD pipeline can read S3 but can’t write

A CI/CD pipeline reads build artifacts from S3 successfully but fails when uploading new artifacts:

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

The pipeline uses an IAM role cicd-pipeline-role.

Investigation:

Check the IAM policies on the role:

aws iam list-attached-role-policies --role-name cicd-pipeline-role
aws iam get-policy-version \
  --policy-arn arn:aws:iam::111122223333:policy/cicd-s3-policy \
  --version-id v1 \
  --query 'PolicyVersion.Document'

The policy returned:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation"],
  "Resource": [
    "arn:aws:s3:::artifacts-bucket",
    "arn:aws:s3:::artifacts-bucket/*"
  ]
}

s3:PutObject is missing. The pipeline was originally built for read-only access and was later given write responsibility without the policy being updated.

Check the bucket policy for explicit denies:

aws s3api get-bucket-policy --bucket artifacts-bucket

No bucket policy exists (NoSuchBucketPolicy). This is a same-account bucket, so the IAM policy alone controls access.

Fix:

Update the IAM policy with two separate statements — bucket-level and object-level actions need different ARN forms:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::artifacts-bucket"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::artifacts-bucket/*"
    }
  ]
}

s3:ListBucket applies to the bucket ARN. s3:GetObject and s3:PutObject apply to the object ARN with /*.

Presigned URL Access Denied

Presigned URLs give time-limited access to S3 objects without requiring the requester to have AWS credentials. A 403 from a presigned URL usually has one of these causes.

Think of a presigned URL like a valet ticket. It’s only valid as long as the valet (the role session that signed the URL) is still on duty. If the valet clocks out early, the ticket becomes worthless even if it says it’s valid until midnight.

The URL has expired. Default expiry is 1 hour. Generate a new URL with a longer --expires-in value:

aws s3 presign s3://my-bucket/my-object --expires-in 86400

The signing session expired before the URL expiry. If the URL was generated by an IAM role, the URL cannot outlive the role’s session token. IAM role sessions have a maximum duration of 12 hours. An --expires-in of 24 hours does not override a session that expires in 1 hour.

The signing credentials were revoked. If the IAM user or role that created the URL was deleted or had credentials rotated, the URL immediately returns 403 regardless of its stated expiry. See AWS STS and Temporary Credentials for session lifecycle details.

A bucket policy Deny was added after URL creation. An explicit Deny in the bucket policy overrides the presigned URL’s authorization.

Clock skew. AWS allows up to 15 minutes of clock skew between client and AWS. Beyond that, signature validation fails.