AccessDenied call_aws

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

For "Error: Failed to get existing workspaces: AccessDenied: Access Denied": check the bucket policy and IAM policy for the four operations state needs: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on the state bucket and key prefix. If locking uses DynamoDB, the identity also needs dynamodb:GetItem/PutItem/DeleteItem on the lock table. A 403 that only appears during apply (not plan) often means the lock table permissions are missing. The S3 403 that survives an IAM fix is usually KMS.

Error: Failed to get existing workspaces: AccessDenied: Access Denied
  status code: 403 ...

When to use

You are seeing this: ` Error: Failed to get existing workspaces: AccessDenied: Access Denied status code: 403... ` or on the S3 backend, 403s during init, plan, or state operations. Use this skill when you run into "Terraform: 403/AccessDenied on the backend is an IAM problem, not a Terraform problem".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

What you are seeing

Error: Failed to get existing workspaces: AccessDenied: Access Denied
  status code: 403 ...

or on the S3 backend, 403s during init, plan, or state operations. Terraform is telling you the credentials it has cannot read or write the state location. The config is almost certainly fine.

First response

1. Confirm which credentials Terraform is using. For AWS: check env vars, shared config, instance profile, in that precedence order. aws sts get-caller-identity tells you who you actually are.
2. Check the bucket policy and IAM policy for the four operations state needs: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on the state bucket and key prefix. Missing any one of them produces a different confusing failure.
3. If locking uses DynamoDB, the identity also needs dynamodb:GetItem/PutItem/DeleteItem on the lock table. A 403 that only appears during apply (not plan) often means the lock table permissions are missing.
4. KMS-encrypted buckets need kms:Decrypt/kms:GenerateDataKey too. The S3 403 that survives an IAM fix is usually KMS.

Rules for agents

1. Do not "fix" a 403 by making the bucket public or widening the policy to s3:*. Scope the fix to the state prefix.
2. Never paste long-lived keys into backend config to dodge the issue. Fix the identity, not the config.
3. If it worked yesterday and 403s today, check for expired credentials, rotated keys, or a changed bucket policy before anything else.
4. Reproduce outside Terraform first: aws s3 ls on the bucket path. If the CLI 403s, Terraform will too, and you have eliminated Terraform from the suspect list.

S3 backend requires bucket/key/region config plus IAM permissions on the bucket and (for locking) DynamoDB table; KMS-encrypted buckets need key permissions. Verified against live S3 backend docs 2026-09-26. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR: Attach an IAM policy allowing the Cost Explorer read actions, then flip the account-level switch that lets IAM identities access billing at all: in the Billing console, under IAM user and role access to billing information, activate it as the root user. The policy alone is not enough, and this second step is the one most troubleshooting guides miss. Re-run the call and expect cost data back.

The exact error:

AccessDeniedException: User: [FINOPS-READER-USER-ARN] is not authorized to perform: ce:GetCostAndUsage on resource: *

1. Confirm who is calling: aws sts get-caller-identity Expected: the ARN matches the user or role in the error, so you are fixing the right identity.

2. Check whether this is a member account in an Organization: only the payer account holds the consolidated billing data, so member-account callers need the payer's data shared or must call from the payer. Expected: you know whether the data even exists in this account.

3. Attach a policy granting the Cost Explorer read actions to the identity:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ce:GetCostAndUsage",
           "ce:GetCostForecast",
           "ce:GetDimensionValues",
           "ce:GetTags"
         ],
         "Resource": "*"
       }
     ]
   }

   Expected: the policy attaches with no syntax errors.

4. As the root user, open the Billing console, find the setting for IAM user and role access to billing information, and activate it. This is account-level and defaults to off. Expected: the console confirms IAM access to billing is activated.

5. Re-run the failing call: aws ce get-cost-and-usage --time-period Start=2026-09-01,End=2026-10-01 --granularity MONTHLY --metrics BlendedCost Expected: a JSON cost-and-usage response instead of AccessDeniedException.

Use this when

• The error names ce:GetCostAndUsage, ce:GetCostForecast, or other ce: read actions
• An IAM user or assumed role gets AccessDeniedException on Cost Explorer APIs
• The policy looks correct but the denial persists, which points at the account-level switch
• A FinOps tool or agent fails its first billing API call in a new account

Not for this skill when

• The error is about the CUR S3 bucket or a KMS key, which are storage and encryption permissions, not Cost Explorer API permissions
• You are in a member account expecting payer-level consolidated data without cross-account setup
• The call throttles with Rate exceeded instead of denying, which is a backoff problem

Variant phrasings

• user is not authorized to perform ce:GetCostAndUsage
• cost explorer access denied IAM role
• enable IAM access to billing information
• ce:GetCostAndUsage forbidden

Why it happens

AWS locks billing data behind two gates. The IAM policy is the identity gate, and the account setting is the account gate: even a perfect policy fails while the account still reserves billing for the root user. New accounts and Organization member accounts hit this constantly because the setting is buried in the Billing console and defaults to off.

Edge cases

• Only the root user can flip the account-level switch, so an admin without root credentials has to escalate
• In Organizations, the payer account sees everything while member accounts see only their own usage unless consolidated data sharing is configured
• The setting can take a few minutes to propagate; a retry loop that gives up after one attempt will report a false failure
• Service control policies on the OU can deny ce: actions above the identity policy, so check effective permissions if both gates look open

Provenance

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

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

Thread query: "AccessDeniedException: User is not authorized to perform: ce:GetCostAndUsage" - how to fix

TL;DR: