AWS S3 Access Denied (403): Comprehensive Troubleshooting Guide

Understanding the Error

The Access Denied error in AWS S3 is an HTTP 403 Forbidden response. It occurs when AWS evaluates your request and determines that the calling principal (IAM user, role, or anonymous user) does not have the necessary permissions to perform the requested operation on the specified S3 resource (bucket or object).

You might see this error in various forms depending on the tool or SDK you are using:

• fatal error: An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied (often seen with aws s3 ls or aws s3 sync).
• An error occurred (AccessDenied) when calling the PutObject operation: Access Denied (seen with aws s3 cp or file uploads).
• <Code>AccessDenied</Code><Message>Access Denied</Message> (raw XML response in a browser or API client).
• HTTP/1.1 403 Forbidden (in HTTP response headers).

Because AWS IAM evaluates multiple policy types (Identity-based, Resource-based, Permissions Boundaries, SCPs, and Session Policies) alongside S3-specific features (Block Public Access, ACLs, Object Ownership), pinpointing the root cause requires a systematic approach.

Step 1: Verify IAM Identity-Based Policies

The first and most common cause of an S3 Access Denied error is that the IAM user or role executing the command lacks the required permissions.

For example, if you run aws s3 ls s3://my-bucket, the principal needs the s3:ListBucket permission. If you run aws s3 cp file.txt s3://my-bucket/, the principal needs s3:PutObject.

Diagnosis:

1. Identify the exact IAM role or user making the request. If you are using the AWS CLI, run aws sts get-caller-identity to see who you are authenticated as.
2. Review the IAM policies attached to this principal.
3. Ensure the policy explicitly grants the required action and that the Resource ARN is correct.

Common Mistake: Confusing bucket-level permissions with object-level permissions. s3:ListBucket applies to the bucket (arn:aws:s3:::my-bucket), while s3:GetObject and s3:PutObject apply to the objects within the bucket (arn:aws:s3:::my-bucket/*).

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

Step 2: Check S3 Bucket Policies

Bucket policies are resource-based policies attached directly to the S3 bucket. They can grant or deny permissions across the entire bucket or specific prefixes.

Crucially, in AWS, an explicit Deny always overrides an explicit Allow. If an IAM policy grants access but the bucket policy denies it, the result is Access Denied.

Diagnosis:

1. Navigate to the S3 console, select your bucket, and go to the Permissions tab.
2. Review the Bucket policy.
3. Look for statements with "Effect": "Deny" that might inadvertently match your IAM principal, IP address, or VPC endpoint.
4. If you are attempting cross-account access, the bucket policy must explicitly grant access to the external account's principal, AND the external account's IAM policy must also grant access (two-way handshake).

Step 3: S3 Block Public Access (BPA)

AWS S3 Block Public Access is a security feature that can be applied at the account level or the bucket level. It is designed to prevent accidental public exposure of S3 data.

If you are trying to make objects public (e.g., for a static website or public downloads) and you are getting Access Denied, BPA is the likely culprit.

Diagnosis:

1. In the S3 console, check the Block public access (bucket settings) under the Permissions tab.
2. Also check the account-level settings in the S3 console side navigation (Block Public Access settings for this account).
3. If BlockAllPublicAccess is enabled, any bucket policy or ACL that attempts to grant public access (e.g., "Principal": "*") will be ignored, resulting in a 403 error for unauthenticated requests.

Fix: If the bucket must be public, you need to turn off the specific BPA settings (typically "Block public access to buckets and objects granted through new public bucket or access point policies" and "Block public and cross-account access to buckets and objects through any public bucket or access point policies").

Step 4: Investigate AWS KMS Encryption

If your S3 bucket uses AWS Key Management Service (SSE-KMS) to encrypt objects, having S3 permissions is not enough. The IAM principal must also have permissions to use the KMS key.

• To upload an object (PutObject), you need kms:GenerateDataKey.
• To download an object (GetObject), you need kms:Decrypt.

Diagnosis: If you can run aws s3 ls successfully but aws s3 cp (download) fails with an Access Denied error, KMS is a prime suspect.

Fix: Update the IAM policy or the KMS Key policy to allow the principal to use the key.

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "arn:aws:kms:region:account-id:key/key-id"
}

Step 5: Object Ownership and ACLs

Historically, S3 used Access Control Lists (ACLs) to manage permissions. If an object is uploaded by a different AWS account (cross-account upload), the uploading account owns the object by default, not the bucket owner. The bucket owner might get an Access Denied error when trying to read the object.

Fix: AWS recommends disabling ACLs entirely. Go to the bucket's Permissions tab, edit Object Ownership, and set it to Bucket owner enforced. This disables all ACLs, and access is purely governed by IAM and Bucket policies. If you must use ACLs, ensure the uploader includes the bucket-owner-full-control canned ACL during the PutObject request.

Step 6: CloudFront OAI/OAC for S3 Static Websites

When serving a static website from S3 via CloudFront, you should restrict direct access to the S3 bucket and only allow CloudFront to fetch objects. This is done using Origin Access Identity (OAI) or the newer Origin Access Control (OAC).

If you see Access Denied when accessing your CloudFront distribution:

1. Ensure the S3 bucket policy allows s3:GetObject for the CloudFront OAC/OAI.
2. Ensure the requested object actually exists. In S3, if an object doesn't exist (404 Not Found) AND the requester doesn't have s3:ListBucket permissions, S3 returns a 403 Access Denied to prevent revealing whether the object exists.
3. Ensure your CloudFront distribution has a Default Root Object (e.g., index.html) configured.

Step 7: Presigned URLs

Presigned URLs allow temporary access to S3 objects. If a presigned URL returns Access Denied:

1. Expiration: The URL has passed its expiration time.
2. Permissions: The IAM principal that generated the presigned URL must have the necessary permissions (e.g., s3:GetObject) at the time the URL is used. If the principal's permissions are revoked after generating the URL, the URL will fail.
3. Signature Mismatch: The HTTP method used (GET vs PUT) or the headers must match exactly what was signed.