AWS Access DeniedAWS Identity and Access Management (IAM)

How to Fix AWS Access Denied (AWS Identity and Access Management (IAM))

Quick Answer

The 'AWS Access Denied' error indicates that the AWS Identity and Access Management (IAM) principal (user, role, or group) attempting an action lacks the necessary permissions. The quickest resolution often involves reviewing and updating the IAM policy attached to the principal or resource to grant the required 'service:action' on the specified 'resource'.

What Causes This Error

Missing or incorrect IAM permissions in the user, group, or role policy.
Resource-based policies (e.g., S3 bucket policies, KMS key policies) explicitly deny the action or do not grant access.
Service control policies (SCPs) in AWS Organizations restrict the action.
Session policies or permissions boundaries are limiting effective permissions.
The principal is attempting to access a resource in a different AWS account without proper cross-account access configuration.
Incorrect ARN specified for the resource or principal in the policy statement.

Step-by-Step Fixes

1Verify IAM User/Role Permissions for AWS Access Denied

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. Go to the 'Permissions' tab.
Review the attached policies. Look for policies that should grant the 'service:action' mentioned in the error message. If the required permissions are missing, attach a new policy or edit an existing one to include the necessary 'Allow' statement for the 'service:action' on the 'resource'.
If an explicit 'Deny' statement exists for the action or resource, modify or remove it, as 'Deny' statements always override 'Allow' statements.

2Check Resource-Based Policies

Identify the AWS service and resource type mentioned in the error message (e.g., S3 bucket, KMS key, SQS queue).
Navigate to the console for that specific AWS service.
Locate the resource in question (e.g., the S3 bucket name).
Access the resource's permissions or policy section. For S3, this is under 'Permissions' -> 'Bucket Policy'. For KMS, it's under 'Key policy'.
Review the resource policy for any 'Deny' statements that might be blocking the principal's access or for missing 'Allow' statements that should grant access to the principal's ARN.

3Use IAM Policy Simulator

Go to the AWS IAM console.
In the navigation pane, choose 'Policy Simulator'.
Select the IAM user or role that is encountering the 'Access Denied' error.
Choose the AWS service and specific action (e.g., 's3', 'GetObject') that the principal is attempting to perform. Specify the ARN of the resource.
Click 'Run Simulation' to determine if the selected action is allowed or denied by the attached policies. The simulator will highlight which policy statement is responsible for the outcome, aiding in identifying the missing or conflicting permission.

4Review AWS Organizations Service Control Policies (SCPs)

If your AWS account is part of an AWS Organization, navigate to the AWS Organizations console.
In the navigation pane, choose 'Service control policies'.
Identify any SCPs that are attached to the Organization Root, Organizational Units (OUs), or directly to the AWS account experiencing the issue.
Review the SCPs for any 'Deny' statements that restrict the 'service:action' mentioned in the error. SCPs can explicitly deny access to specific services or actions across accounts within an OU or the entire organization.
If an SCP is found to be denying the required action, consult with your AWS Organization administrator to modify or detach the SCP, if appropriate.

Advanced Fixes

Inspect Permissions Boundaries and Session Policies

Navigate to the AWS IAM console and select the user or role.
On the 'Permissions' tab, check if a 'Permissions boundary' is set. A permissions boundary defines the maximum permissions an IAM entity can have.
If a permissions boundary is present, review its policy to ensure it allows the 'service:action' in question. If the boundary does not permit the action, the principal will be denied, even if their identity-based policies grant it.
If the access is occurring within a specific session (e.g., via `AssumeRole` with session tags or inline session policies), examine the session policy. Session policies are passed during programmatic access and can further restrict permissions for that specific session.

Troubleshoot Cross-Account Access Issues

If the error occurs when accessing a resource in a different AWS account, verify the IAM role's trust policy in the target account.
In the target account, navigate to IAM Roles, select the role designed for cross-account access, and go to the 'Trust relationships' tab.
Ensure the trust policy explicitly allows the principal's ARN (user or role) from the source account to assume this role. The 'Principal' element in the trust policy should specify the full ARN of the calling principal.
In the source account, verify that the calling principal has an 'Allow' policy statement to perform `sts:AssumeRole` on the target account's cross-account role ARN. Both sides of the trust relationship must be correctly configured for cross-account access to succeed.

Frequently Asked Questions

What is the difference between an identity-based policy and a resource-based policy?

An identity-based policy is attached to an IAM identity (user, group, or role) and grants permissions for that identity to access resources. A resource-based policy is attached directly to an AWS resource (like an S3 bucket or KMS key) and specifies which principals are allowed or denied access to that specific resource.

Why would an 'Allow' policy still result in 'Access Denied'?

An 'Allow' policy can be overridden by an explicit 'Deny' statement in any applicable policy (identity-based, resource-based, or Service Control Policy). Additionally, permissions boundaries or session policies might restrict the effective permissions, even if the identity policy grants the action.

How do I find the ARN of the resource mentioned in the error message?

The ARN (Amazon Resource Name) is typically provided in the error message itself, following 'on resource: arn:aws:...'. If it's truncated, you can usually reconstruct it based on the service and resource type, or find it in the details of the specific resource within its AWS service console.

What are Service Control Policies (SCPs) and how do they impact permissions?

Service Control Policies (SCPs) are a feature of AWS Organizations that allow you to centrally manage permissions across multiple AWS accounts. SCPs define the maximum available permissions for accounts within an Organization Unit (OU) or the entire organization. They do not grant permissions but rather filter them; if an action is denied by an SCP, no identity-based or resource-based policy can grant it.