How to Fix AccessDenied (AWS S3)
Quick Answer
The 'AccessDenied' error in AWS S3 indicates that the AWS Identity and Access Management (IAM) principal (user or role) attempting the action lacks the necessary permissions. The fastest fix is to review and update the relevant IAM policy or S3 bucket policy to grant the required S3 actions.
What Causes This Error
- Incorrect or missing IAM user/role permissions for S3 actions.
- S3 bucket policy explicitly denies the action or principal.
- Object ACLs (Access Control Lists) override bucket policy or IAM permissions for specific objects.
- S3 Block Public Access settings are preventing access, even if other policies allow it.
- AWS Organizations Service Control Policies (SCPs) are restricting access at the account level.
- Cross-account access issues where the resource owner has not granted sufficient permissions.
Step-by-Step Fixes
1Verify IAM User/Role Permissions to Resolve AccessDenied
- Navigate to the AWS IAM console.
- In the navigation pane, choose 'Users' or 'Roles' depending on the principal experiencing the error.
- Select the specific user or role. Review the 'Permissions' tab to identify attached policies.
- Examine the policies for explicit 'Deny' statements or missing 'Allow' statements for the S3 actions (e.g., s3:GetObject, s3:PutObject, s3:ListBucket) on the target S3 bucket or objects.
- If permissions are insufficient, attach a new managed policy or create and attach an inline policy that grants the necessary S3 permissions. Ensure the policy specifies the correct S3 resource ARN (Amazon Resource Name).
2Review and Adjust S3 Bucket Policies
- Open the Amazon S3 console and navigate to the affected bucket.
- Select the 'Permissions' tab, then click on 'Bucket Policy'.
- Carefully read the JSON policy document. Look for 'Deny' statements that might be blocking access for your IAM principal or specific IP addresses.
- Verify that 'Allow' statements explicitly grant the required S3 actions to your IAM principal. Ensure the 'Principal' element in the policy correctly identifies the user or role.
- Modify the bucket policy as needed to remove conflicting 'Deny' statements or add 'Allow' statements. Save the changes and re-test access.
3Check S3 Block Public Access Settings
- In the Amazon S3 console, navigate to the affected bucket.
- Select the 'Permissions' tab, then locate the 'Block Public Access' section.
- Review the settings for 'Block public access to buckets and objects granted through new access control lists (ACLs)', 'Block public access to buckets and objects granted through any access control lists (ACLs)', 'Block public access to buckets and objects granted through new public bucket policies', and 'Block public and cross-account access to buckets and objects through any public bucket policies'.
- If any of these settings are enabled and public or cross-account access is intended, consider if these settings are appropriate for your use case. Disabling them should be done with caution, as it can expose your bucket to public access.
- Adjust the Block Public Access settings if they are inadvertently preventing legitimate access. Note that these settings can override other policies.
4Inspect S3 Object ACLs for Specific Objects
- Open the Amazon S3 console and navigate to the affected bucket.
- Locate the specific object that is returning the 'AccessDenied' error.
- Select the object, then click on the 'Permissions' tab.
- Review the 'Access Control List (ACL)' section. ACLs can grant or deny permissions at the object level.
- Ensure that the ACL does not explicitly deny access to your IAM principal or that it grants the necessary 'READ' or 'WRITE' permissions. Modify the ACL if it is conflicting with desired access. Note that ACLs are a legacy access control mechanism and bucket policies are generally preferred.
Advanced Fixes
Evaluate AWS Organizations Service Control Policies (SCPs)
- Access the AWS Organizations console.
- Navigate to 'Policies' and then 'Service control policies'.
- Review the SCPs attached to the Organizational Unit (OU) or directly to the AWS account where the S3 bucket resides.
- Look for any 'Deny' statements that restrict S3 actions (e.g., s3:*) or access to specific S3 resources (e.g., arn:aws:s3:::your-bucket-name/*).
- If an SCP is found to be the cause, coordinate with your AWS Organizations administrator to modify or detach the SCP. SCPs apply to all IAM principals within the affected accounts.
Troubleshoot Cross-Account Access for AccessDenied
- Identify the AWS account that owns the S3 bucket (Resource Owner) and the account attempting to access it (Requester).
- In the Resource Owner account, review the S3 bucket policy. Ensure it explicitly grants permissions to the Requester account's IAM principal (user or role). The 'Principal' element in the bucket policy should specify the ARN of the Requester's IAM user or role.
- In the Requester account, verify that the IAM user or role has an attached policy that allows it to perform the desired S3 actions on the Resource Owner's bucket. This policy should specify the ARN of the Resource Owner's S3 bucket as the resource.
- If the Requester is assuming a role in the Resource Owner account, ensure the Resource Owner's role trust policy allows the Requester's IAM principal to assume the role, and the role's permissions policy grants the necessary S3 actions.
- Check for any S3 Block Public Access settings in the Resource Owner account that might be preventing cross-account access, particularly 'Block public and cross-account access to buckets and objects through any public bucket policies'.
Frequently Asked Questions
What is the difference between an IAM policy and an S3 bucket policy?
An IAM policy is attached to an IAM user, group, or role and defines what that principal can do across AWS services. An S3 bucket policy is attached directly to an S3 bucket and defines who can access the bucket and its objects, and what actions they can perform. Both work together to determine effective permissions.
Can S3 object ACLs cause an AccessDenied error?
Yes, S3 object ACLs (Access Control Lists) can cause an 'AccessDenied' error. While bucket policies are generally preferred, ACLs can grant or deny permissions at the individual object level. If an object's ACL explicitly denies access to a principal, or doesn't grant the necessary permissions, that principal will receive an 'AccessDenied' error for that specific object, even if the bucket policy allows it.
How do I check the effective permissions for an IAM principal on an S3 bucket?
You can use the AWS IAM Policy Simulator. Navigate to the IAM console, select 'Policy Simulator', choose the IAM user or role, select 'S3' as the service, and specify the S3 actions (e.g., GetObject, PutObject) and the S3 bucket/object ARN as the resource. The simulator will show whether the action is allowed or denied and which policy statement is responsible.
Why am I getting AccessDenied even though my policy has 's3:*' permissions?
Even with 's3:*' in an IAM policy, 'AccessDenied' can occur due to several reasons: an explicit 'Deny' statement in an S3 bucket policy, S3 Block Public Access settings overriding permissions, an AWS Organizations Service Control Policy (SCP) at a higher level denying the action, or an object-level ACL explicitly denying access. Always check all layers of permissions.