AWS IAM AccessDenied Errors: Step-by-Step Troubleshooting Guide

Simple explanation

AWS checks every API call against a set of policies before allowing it through. If no policy grants permission, the request is denied. If any policy explicitly denies it, the request is blocked regardless of what other policies allow.

Two kinds of AccessDenied:

• Implicit deny: no Allow policy covers this action and resource. Nothing said “yes”. Fix: add an Allow.
• Explicit deny: a Deny statement directly blocked the action. Fix: find and remove the Deny, or restructure which principals it applies to.

Both look like AccessDenied or AccessDeniedException in the error. The distinction matters because an explicit deny wins over any Allow, regardless of where that Allow comes from.

When to use this page

Use this guide when:

• Your error message contains a principal ARN (arn:aws:iam::... or arn:aws:sts::...).
• The error text says “is not authorized to perform” or “AccessDeniedException”.
• You are debugging a failed sts:AssumeRole call.
• You are troubleshooting permission boundaries, SCPs, or session policies.

This guide is for IAM authorization failures. If the error comes from SSH, OS-level permissions, or application-layer authentication, see Permission Denied Errors in AWS instead.

For S3-specific 403 errors that do not include a principal ARN, start with S3 Access Denied Errors. S3 has its own evaluation chain involving bucket policies and Block Public Access that this guide does not fully cover.

How AWS authorization works for AccessDenied

AWS evaluates a request through multiple policy layers in a fixed order. Understanding this order is what lets you debug systematically rather than guessing.

Default deny: every request starts as denied. AWS allows it only if a policy explicitly says Allow and nothing else says Deny.

What gets evaluated:

For a request to succeed, the identity-based policy (or a resource-based policy for cross-account access) must Allow the action, and none of the other layers may Deny it.

Read IAM Policy Structure for the full evaluation logic and JSON format.

Fast triage checklist

1. Extract the principal, action, and resource from the error message.
2. Identify the principal type: IAM user, assumed role session, service principal, or federated identity.
3. Check identity-based policies: list all attached managed and inline policies on the role or user.
4. Look for explicit denies: search every attached policy for "Effect": "Deny" statements.
5. Check the permissions boundary: if one is attached, verify it allows the failing action.
6. Check session policies: if the role was assumed via sts:AssumeRole with a policy parameter, check that policy.
7. Check resource-based policies: for S3, KMS, SQS, Lambda, SNS, and other services that support resource policies.
8. Check SCPs: if the account is in an AWS Organization, an SCP may be blocking the action at the org level.
9. Check the trust policy: only relevant if the error action is sts:AssumeRole itself, not a downstream action.
10. Re-test with the Policy Simulator: use aws iam simulate-principal-policy to confirm the fix before deploying.

Reading the error message

IAM AccessDenied errors follow a consistent format. Parse these three fields every time:

An error occurred (AccessDeniedException) when calling the PutObject operation:
User: arn:aws:sts::111122223333:assumed-role/my-lambda-role/my-function
is not authorized to perform: s3:PutObject
on resource: "arn:aws:s3:::my-data-bucket/uploads/file.csv"

Reading the principal ARN:

• arn:aws:sts::...:assumed-role/ROLE-NAME/SESSION-NAME: an assumed role session. Check policies on ROLE-NAME, not on the user or service that assumed it. The role name is the segment between assumed-role/ and the final slash.
• arn:aws:iam::...:user/USER-NAME: a direct IAM user. Check policies attached to the user and their IAM groups.
• arn:aws:iam::...:role/ROLE-NAME: the role itself is the actor (rare in action errors; more common in service-to-service calls).
• The denied action is sts:AssumeRole: the denial is on the assumption itself, before credentials were issued. Check the target role’s trust policy.

Common root causes of IAM AccessDenied

Missing allow in identity-based policy

The most common cause. The role or user has no policy that explicitly allows the action on the target resource. This produces an implicit deny.

aws iam list-attached-role-policies --role-name my-role
aws iam list-role-policies --role-name my-role  # inline policies listed separately

Run both commands. list-attached-role-policies only returns managed policies. Inline policies are stored separately and are easy to miss.

Explicit deny in identity-based policy

A Deny statement in one of the principal’s attached policies is directly blocking the action. This produces an explicit deny that cannot be overridden by any Allow.

Look for "Effect": "Deny" in every policy attached to the principal. The deny may be scoped to a specific action, a wildcard, or a condition key that matches the current request context.

Permissions boundary blocking access

A permissions boundary sets the maximum permissions a role can have. Even if the identity policy says Allow, the boundary must also cover the action. If it does not, the request is denied silently from the role policy’s perspective.

Boundaries are common in delegated-access environments where administrators allow developers to create roles but cap what those roles can do.

aws iam get-role --role-name my-role --query 'Role.PermissionsBoundary'

If a boundary is attached, retrieve and review its policy document and verify it includes the failing action and resource pattern. IAM Policy Conditions explains how condition keys interact with boundaries when the boundary uses conditional allows.

Session policy blocking access

When code calls sts:AssumeRole and passes a Policy parameter, that inline session policy further restricts what the resulting credentials can do. The session can never exceed the role’s own permissions, and the session policy can narrow them further.

This is common in broker architectures, CI/CD pipelines, and multi-tenant systems where each session is scoped to a specific customer or resource set. See AWS STS and Temporary Credentials for how session policies are evaluated alongside role policies.

SCP blocking access

Service Control Policies (SCPs) from AWS Organizations apply to all principals in a member account, including the account root. If an SCP denies an action or does not include an Allow for it, no principal in that account can perform it, not even an administrator.

SCPs are not visible from inside the member account. To check them, you need access to the management account or a delegated admin account:

aws organizations list-policies-for-target \
  --target-id ACCOUNT_ID \
  --filter SERVICE_CONTROL_POLICY

Resource-based policy blocking access

Services like S3, KMS, SQS, Lambda, and SNS have resource-based policies evaluated alongside identity-based policies. A Deny in a resource policy blocks the request regardless of what the identity policy says.

For cross-account access, a resource-based policy must explicitly Allow the source account’s principal. The identity policy alone is not sufficient.

For S3 specifically, see S3 IAM vs Bucket Policies for how identity and bucket policies are evaluated together and where each one must allow the action.

VPC endpoint policy blocking access

If the request originates from a VPC using a gateway or interface endpoint, the request also passes through the endpoint’s policy. If the endpoint policy does not allow the action, the request is denied, even if the identity policy does allow it.

Check for VPC endpoint policies when:

• The service call originates from an EC2 instance, Lambda in a VPC, or an EKS pod.
• The failing service is S3, DynamoDB, or another service with a gateway endpoint in that VPC.

See VPC Endpoint Policies for how endpoint conditions restrict traffic.

Trust policy blocking sts:AssumeRole

If the denied action is sts:AssumeRole, the cause is in the trust policy of the target role, not in any identity policy on the calling principal. The trust policy must explicitly trust the source principal.

The source principal also needs an identity policy that allows sts:AssumeRole on the target role ARN. Both sides must be in place for cross-account assumptions. See Role Assumption in AWS for the full dual-side setup.

Service-specific authorization edge cases

Some services have additional authorization requirements beyond standard IAM:

• KMS: the key policy is required even for same-account access. If the KMS key policy does not grant the caller access, IAM alone cannot override it.
• Secrets Manager: resource-based policies on the secret can restrict access independently of IAM role policies.
• S3 Object Lock / Block Public Access: these produce 403 errors that look like IAM failures but are enforced at the bucket or object level.
• STS condition keys: sts:AssumeRole can be restricted with conditions like sts:ExternalId, aws:SourceAccount, or OIDC claim values. A mismatch silently fails the assumption.

Using the IAM Policy Simulator correctly

The IAM Policy Simulator tests identity-based policies and permissions boundaries against a simulated request. It is useful for confirming that a role’s policies permit an action before deploying a fix, but it has real limits.

# Test whether a role can perform a specific action on a specific resource
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/my-lambda-role \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::my-data-bucket/uploads/file.csv

# Test multiple actions at once
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/my-lambda-role \
  --action-names s3:PutObject s3:GetObject s3:DeleteObject \
  --resource-arns "arn:aws:s3:::my-data-bucket/*"

The output shows "EvalDecision": "allowed" or "EvalDecision": "implicitDeny", plus which policy statement made the decision.

What the simulator evaluates:

• Identity-based policies attached to the principal (managed and inline)
• Permissions boundaries on the principal

What the simulator does not evaluate:

• SCPs from AWS Organizations
• VPC endpoint policies
• Resource-based policies on the target resource (for roles; there are limited same-account scenarios for users)
• Live policy propagation edge cases

For CLI-based IAM investigation beyond simulation, see Managing IAM with AWS CLI.

Step-by-step worked examples

Example 1: Lambda role cannot write to S3

Error (from CloudWatch Logs):

[ERROR] ClientError: An error occurred (AccessDeniedException) when calling the
PutObject operation: User: arn:aws:sts::111122223333:assumed-role/process-role/process-function
is not authorized to perform: s3:PutObject on resource:
"arn:aws:s3:::results-bucket/2026/03/19/output.json"

Principal / action / resource: process-role / s3:PutObject / results-bucket

Inspect:

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

The policy document shows:

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

Root cause: s3:PutObject is missing. The function was originally read-only and was later repurposed to write output files without updating the policy.

Fix: Add s3:PutObject to the Action list and create a new policy version:

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

aws iam create-policy-version \
  --policy-arn arn:aws:iam::111122223333:policy/process-s3-policy \
  --policy-document file://updated-policy.json \
  --set-as-default

Verify:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/process-role \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::results-bucket/2026/03/19/output.json

Expected: "EvalDecision": "allowed". Then trigger the Lambda to confirm the real request succeeds.

Example 2: Cross-account AssumeRole is denied

Error:

An error occurred (AccessDenied) when calling the AssumeRole operation:
User: arn:aws:iam::111122223333:user/deploy-bot
is not authorized to perform: sts:AssumeRole
on resource: arn:aws:iam::444455556666:role/deploy-role

Principal / action / resource: deploy-bot (account 111122223333) / sts:AssumeRole / deploy-role (account 444455556666)

Inspect both sides:

Side A: does deploy-bot have an identity policy that allows sts:AssumeRole on the target ARN?

aws iam list-attached-user-policies --user-name deploy-bot

The policy must include:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::444455556666:role/deploy-role"
}

Side B: does the target role’s trust policy trust this specific principal?

# Run this in account 444455556666
aws iam get-role --role-name deploy-role \
  --query 'Role.AssumeRolePolicyDocument'

The trust policy must include:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:user/deploy-bot"},
  "Action": "sts:AssumeRole"
}

Root cause: The trust policy listed arn:aws:iam::111122223333:root as the principal. This grants the account the ability to delegate the role, but deploy-bot still needs an explicit identity policy, which was missing.

Fix: Add the sts:AssumeRole Allow to deploy-bot’s identity policy, or update the trust policy to reference the user ARN directly. Both sides must allow the assumption.

See Role Assumption in AWS for the complete trust policy and identity policy setup.

Example 3: EKS pod / IRSA role gets AccessDenied

Error (from pod logs):

botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the
GetSecretValue operation: User:
arn:aws:sts::111122223333:assumed-role/my-app-irsa-role/botocore-session-1234567890
is not authorized to perform: secretsmanager:GetSecretValue
on resource: arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app-secret

Principal / action / resource: my-app-irsa-role / secretsmanager:GetSecretValue / my-app-secret

Inspect:

First, confirm the pod is actually using the IRSA role and not falling back to the node’s instance profile:

kubectl get serviceaccount my-app-sa -n my-namespace -o yaml
# Look for: eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-app-irsa-role

Check the IRSA role’s trust policy. It must trust the cluster’s OIDC provider and match the exact namespace and service account name:

aws iam get-role --role-name my-app-irsa-role \
  --query 'Role.AssumeRolePolicyDocument'

The condition block in the trust policy must match:

"Condition": {
  "StringEquals": {
    "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLE123:sub":
      "system:serviceaccount:my-namespace:my-app-sa"
  }
}

Then check the role’s identity policies for secretsmanager:GetSecretValue.

Root cause: The trust policy condition had a typo: my-app instead of my-app-sa in the service account subject claim. The pod could not assume the IRSA role and fell back to the node’s instance profile, which had no Secrets Manager access.

Fix: Update the trust policy condition to use the exact service account name. Restart the pod to pick up fresh credentials via the corrected OIDC flow.

See IAM Roles for Service Accounts (IRSA) for the full IRSA setup, OIDC provider configuration, and trust policy format.

IAM AccessDenied vs S3 Access Denied

S3 403 errors and IAM AccessDenied errors look similar but come from different evaluation chains. Mixing them up wastes debugging time.

IAM AccessDenied: the IAM evaluation engine blocked the request before S3 processed it. The error message includes the principal ARN and the denied action name.

S3 403 Access Denied: S3 evaluated its own authorization chain and returned a 403. The response body says “Access Denied” but typically does not include the principal ARN. S3 can return 403 for reasons that have nothing to do with IAM role policies:

• A bucket policy with an explicit Deny (or no Allow for cross-account access)
• Block Public Access settings blocking a public GET request
• An S3 Object Lock rule preventing deletion or overwrite of a locked object
• A VPC endpoint policy that does not allow the S3 action for that endpoint

For same-account access, IAM and the bucket policy are evaluated together. Either one allowing the action is sufficient, unless there is an explicit deny somewhere. For cross-account access, both the IAM policy and the bucket policy must explicitly Allow the request.

If you cannot find the cause in IAM policies and the service is S3, switch to S3 Access Denied Errors. For the complete breakdown of how IAM and bucket policies interact, see S3 IAM vs Bucket Policies.