AWS IAM "not authorized to perform" debugging

TL;DR

"not authorized to perform" means the caller identity has no Allow for the action, or an explicit Deny somewhere overrides it. First confirm WHO you are with get-caller-identity, then simulate the exact action to see which policy decides it. Fix the policy, not the code.

Error / query

AWS IAM "not authorized to perform" debugging

Use this skill when

• an AWS CLI or SDK call fails with AccessDenied or "not authorized to perform"
• a deploy pipeline breaks with an IAM error after a role change
• you need to find which policy is blocking a specific action
• a role works in one account but not another

Not for this skill when

• the error is about a missing resource, not permissions
• you are designing IAM policies from scratch
• the failure is an SSO login problem rather than an API denial

Steps

Step 1: Confirm the caller identity

aws sts get-caller-identity

Expected: JSON with Account, UserId, and Arn. If the Arn is not what you expect, you are using the wrong profile or assumed role.

Step 2: Reproduce the failing call and capture the exact action name

aws ec2 describe-instances --region us-east-1

Expected: either the AccessDenied error naming the action (for example ec2:DescribeInstances) or success. The error text tells you exactly which action to simulate.

Step 3: Simulate the policy evaluation for that action

aws iam simulate-principal-policy --policy-source-arn [YOUR_ROLE_ARN] --action-names ec2:DescribeInstances --resource-arns "*"

Expected: an EvalDecision of allowed or denied, plus MatchedStatements showing which policy made the call. Denied with no matched statements means no Allow exists anywhere.

Step 4: List attached policies and look for Deny, boundaries, and SCPs

aws iam list-attached-user-policies --user-name [USER_NAME]
aws iam list-policies-granting-service-access --arn [YOUR_ARN] --service-namespaces ec2

Expected: the full list of attached managed policies. An explicit Deny anywhere wins over every Allow, so also check for a permissions boundary on the identity and SCPs from Organizations, which do not show up in the user policy list.

Step 5: Confirm with CloudTrail

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=DescribeInstances --max-results 5

Expected: the event record with errorCode AccessDenied and the userIdentity block, confirming who was denied, on which resource, and when.

Variant phrasings

"AccessDeniedException: User is not authorized to perform..."

Same flow. The quoted phrase is the standard denial text; steps 1 through 3 find the missing Allow or the overriding Deny.

"why does my lambda get access denied on s3"

Lambda runs as its execution role, not as you. Check the role attached to the function, then run the simulation with that role ARN in step 3.

"cross-account role assume works but the api calls still fail"

The trust policy allowed the assume-role, but the role's own permission policies are thin. Simulate with the assumed role ARN against the exact failing actions.

Why it happens

IAM evaluates every request against all applicable policies: identity policies, resource policies, SCPs, permissions boundaries, and session policies. A single explicit Deny anywhere overrides any number of Allows, and with no Allow at all the default is deny. Most "not authorized" errors are a missing Allow on the exact action or resource ARN, or an inherited Deny nobody remembered setting.

Edge cases and pitfalls

• The error message sometimes names a different action than the one you guessed; simulate with the exact action from the error, not a guess.
• Resource ARNs matter: an Allow on arn:aws:s3:::mybucket does not cover objects under arn:aws:s3:::mybucket/data.
• Session policies and session tags can silently narrow permissions for one session only, so a fresh assume-role can behave differently than yesterday's.
• SCPs apply at the org level and do not appear in iam list-attached output; if simulation says allowed but the call still fails, ask the org admin about SCPs.
• New or edited policies can take a few seconds to propagate; wait and retry once before assuming the fix did not work.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Xlub7PTZexOo1O1yZX3TdA