Resolve “Access Denied” errors encountered when accessing Amazon S3 objects

As a user of Amazon S3, you may encounter “Access Denied” errors when trying to access objects in your S3 bucket. These errors indicate that the request lacks valid credentials or permissions policies to perform the requested operation.

In this blog post, I will cover various troubleshooting steps and configuration checks to resolve “Access Denied” errors encountered when accessing S3 objects.

Automate documentation using AWS Systems Manager

AWS provides two Systems Manager automation documents that can help diagnose access issues with your S3 buckets:

AWSSupport-TroubleshootS3PublicRead – Use this document to check for public read access issues with your S3 bucket.

AWSSupport-TroubleshootS3AccessSameAccount – Use this document to diagnose access denied errors from your own S3 bucket.

These documents automatically run diagnostics and provide recommended solutions based on your bucket configuration. I highly recommend using them as first troubleshooting steps.

To run these documents:

Open the AWS Systems Manager console and go to the Automation section.
Search document name.
Click “Execute Automation”.
Specify the required parameters such as S3 bucket name.
Review results and implement recommendations.

Automated documentation will examine bucket policies, object ownership, user credentials, and more to identify the root cause. This can save you hours of manual troubleshooting.

Check bucket and object ownership

If the object being accessed has a different owner than the bucket, an “Access Denied” error may occur. By default, the uploader owns the object even if it is uploaded to your bucket.

Follow these steps to check object ownership:

Use the AWS CLI to get your account’s canonical ID:

aws s3api list-buckets --query "Owner.ID"

Get the canonical ID of the object owner:

aws s3api list-objects --bucket mybucket --prefix myobject

If the IDs do not match, the object owner must grant you a Full Control ACL:

aws s3api put-object-acl --bucket mybucket --key myobject --acl bucket-owner-full-control

Update object ownership by copying the object to yourself:

aws s3 cp s3://mybucket/myobject s3://mybucket/myobject

To prevent this issue from occurring in the future, it is required to set the bucket-owner-full-control ACL on object uploads and enable S3 object ownership.

Check bucket policy and IAM policy

Double-check the bucket policy and IAM user policy for statements that might inadvertently deny access.

pay attention:

Deny statements containing conditions such as multi-factor authentication, IP address, VPC, etc.
Missing operations like s3:GetObject or s3:PutObjectAcl
Extra spaces or typos in ARN
Overly restrictive body elements

For example, this bucket policy denies access based on VPC:

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws-cn:s3:::DOC-EXAMPLE-BUCKET/*",
      "Principal": "*"
    },
    {
      "Sid": "Statement2",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws-cn:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-1a2b3c4d"
        }
      },
      "Principal": "*"
    }
  ]
}

In the above strategy, Statement1 is allowed to obtain the object. But if the request does not come from the VPC endpoint vpce-1a2b3c4d, Statement2 denies the same GET access. Therefore, users outside that VPC endpoint will receive an “Access Denied” error.

And this strategy lacks the key s3:PutObjectAcl operation:

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1234567890123",
      "Action": [
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws-cn:s3:::DOC-EXAMPLE-BUCKET/*",
      "Principal": {
        "AWS": [
          "arn:aws-cn:iam::111122223333:user/Dave"
        ]
      }
    }
  ]
}

The above policy only allows s3:PutObject operations. If a user attempts to modify an object’s ACL using s3:PutObjectAcl, they will receive an “Access Denied” error since the operation is not permitted.

Ideally, there would be no problem running the AWS Policy Builder tool to verify the policy.

If IAM permission boundaries are set on the identity, check them as well.

Check S3 public access blocking settings

If you are getting access denied on a public object request, check the S3 public access blocking settings at the account and bucket levels. These settings can override permissions that allow public access.

Use the S3 console to check these settings on your account and bucket.

Review user credentials

Make sure the IAM user or role accessing the bucket has the appropriate credentials configured:

For the CLI, check the configured credentials:

aws configure list

For EC2, check the roles attached to the instance:

aws sts get-caller-identity

For temporary credentials obtained through STS, check the S3 permissions in the session policy associated with the assumed role.

Check VPC endpoint policy

If accessing S3 via a VPC endpoint, make sure the endpoint policy grants the required permissions. This policy controls which buckets/objects can be accessed through this endpoint.

For example:

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1234567890123",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:s3:::DOC-EXAMPLE-BUCKET",
        "arn:aws-cn:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Principal": "*"
    }
  ]
}

The above VPC endpoint policy:

Allows getting, putting, and listing objects in the DOC-EXAMPLE-BUCKET bucket
Use wildcards to allow access to any object in the bucket
Applies to all principals accessed through the VPC endpoint
But only allow access to DOC-EXAMPLE-BUCKET bucket

Check S3 access point policy

If using an S3 access point, the access point policy must allow access to the underlying bucket. So check the access point policy and bucket policy.

Check for missing objects

If the object being accessed does not exist in the bucket, S3 returns an “Access Denied” error instead of a 404. Check if the object actually exists:

aws s3api head-object --bucket mybucket --key myobject

If it doesn’t exist, troubleshoot the actual object.

Confirm KMS encryption key access

If S3 objects encrypted using AWS KMS (SSE-KMS) cannot be accessed by users with valid permissions, make sure that:

KMS key policy grant required permissions (e.g. kms:Decrypt)
If the IAM user and KMS key are not in the same account, the IAM policy also contains KMS permissions

Specify requester payment parameters

If requester payer is enabled for the bucket, cross-account users must pass the --request-payer parameter:

aws s3 cp s3://mybucket/myobject . --request-payer requester

Check AWS Organizations policy

Verify that the AWS Organizations service control policy allows your account to access S3. An explicit deny policy will override any allow policy.

This covers the main areas you need to check when troubleshooting “Access Denied” errors on S3 objects. Some key points:

Automated diagnostics using Systems Manager Automation Documentation
Review bucket policies, object ownership, and access point policies
Check IAM permissions and resource policies such as VPC endpoint policies
If using temporary tokens, verify credentials and session policy
Check if object exists and special characters

Fix these issues for your configuration and you will be able to access S3 objects without encountering any “Access Denied” errors. If you have any other troubleshooting tips, please let me know in the comments!

References

[1] Troubleshooting Amazon S3 Access Denied Errors

[2] Amazon S3 Requester Pays

[3] Amazon S3 Object Ownership

[4] Use bucket policies and user policies

[5] AWS KMS Key Policy