AWS Lambda Error - AccessDeniedException: User is not authorized to perform lambda:InvokeFunction

#aws #lambda #devops #cloud

This error is Lambda’s way of telling you the caller isn’t allowed through the front door.

Problem

Your Lambda function (or another AWS service) fails with the error:

AccessDeniedException: User is not authorized to perform lambda:InvokeFunction

This appears when something — a user, another Lambda, API Gateway, EventBridge, Step Functions, or an IAM principal — tries to invoke your function without the correct IAM permissions.

Clarifying the Issue

This error does not indicate a problem inside your Lambda code. It means the caller itself does not have permission to invoke the function. Lambda protects the InvokeFunction API call the same way it protects all its APIs — through IAM. If the caller lacks the right action on the right resource, Lambda blocks the request before it ever reaches your function.

Why It Matters

This is one of the most common IAM blockers in serverless architectures. Event-driven systems depend on services invoking each other. If InvokeFunction permission is missing, your workflows stall, events fail silently, and API Gateway can return 500 errors even though your Lambda runs perfectly. Fixing this ensures your system behaves predictably across environments.

Key Terms

Lambda InvokeFunction: The API call that triggers a Lambda function.
IAM Principal: The identity making the call (user, role, service).
Resource Policy: A policy attached directly to a Lambda function defining who can invoke it.
Execution Role: The role the Lambda function itself uses while running.

Invocation Flow Diagram

This visual shows the entire chain: a principal makes a request, the Lambda service processes the InvokeFunction call, and the function runs only if the correct permissions exist. This is the model we’ll be fixing in the steps below.

 IAM Principal
 (API Gateway, Role, User)
          |
          |  lambda:InvokeFunction
          v
   Lambda Service
          |
          v
   Lambda Function

Permissions needed:
- Principal -> Function: lambda:InvokeFunction
- Optional: Function resource policy allowing the Principal

Steps at a Glance

Identify the caller attempting to invoke the function.
Check CloudWatch or error output to confirm the missing permission.
Add lambda:InvokeFunction permission to the caller’s IAM role.
(Optional) Add a Lambda resource policy for cross-account or cross-service access.
Redeploy or reattach the corrected policy.
Test again and confirm the invocation succeeds.

Step 1: Identify the caller attempting to invoke the function

Before fixing anything, determine who is making the InvokeFunction call. This could be:

API Gateway
EventBridge
Step Functions
A different Lambda
An IAM user
A cross-account role

Check the error context or logs. A typical CloudWatch entry might show:

User: arn:aws:iam::111111111111:role/MyApiGatewayRole is not authorized to perform: lambda:InvokeFunction

This tells you exactly which IAM entity lacks permission.

Step 2: Check CloudWatch or error output to confirm the missing permission

Pull up the error in CloudWatch or the service’s error logs. API Gateway, for instance, reports:

Execution failed due to configuration error: Invalid permissions on Lambda function

Step Functions reports:

Task failed: AccessDeniedException: User is not authorized to perform lambda:InvokeFunction

This confirms you’re dealing with an IAM permissions issue rather than a Lambda runtime problem.

Step 3: Add lambda:InvokeFunction permission to the caller’s IAM role

Once you know the caller, add the necessary permission. Here’s the IAM policy:

{
  "Effect": "Allow",
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:111111111111:function:MyFunction"
}

The resource ARN should include the full region, account ID, and function name. You may also grant permission to a specific alias or version, for example:

arn:aws:lambda:us-east-1:111111111111:function:MyFunction:ProdAlias

Attach this policy to the role that CloudWatch identified earlier. If you are using API Gateway or Step Functions, this must be added to their execution role.

Step 4: (Optional) Add a Lambda resource policy for cross-account or cross-service access

For cross-account access or certain AWS services, you may need a Lambda resource policy. Some services such as API Gateway and EventBridge often require the function to explicitly allow them to invoke it, even within the same account.

Example:

aws lambda add-permission \
  --function-name MyFunction \
  --statement-id AllowAccount222222222222 \
  --action lambda:InvokeFunction \
  --principal 222222222222 \
  --source-account 222222222222

The resource policy lives on the Lambda itself and works alongside the caller’s IAM role.

Step 5: Redeploy or reattach the corrected policy

Update the role or reapply the policy. If using IaC tools (CloudFormation, Terraform, CDK), redeploy the stack so the changes are version controlled.

For a quick verification in the AWS Console, navigate to the IAM role identified in Step One, open the Permissions tab, and confirm the new policy is visible and active.

Step 6: Test again and confirm the invocation succeeds

Invoke the function using the corrected caller:

aws lambda invoke \
  --function-name MyFunction \
  --payload '{}' \
  response.json
cat response.json

Expected output:

{"statusCode": 200, "body": "Invocation succeeded"}

CloudWatch should no longer show an AccessDeniedException. If errors persist, verify that:

The Resource ARN matches the actual Lambda name and region.
You allowed the correct principal.
You redeployed the IaC stack properly.

Pro Tips

When using API Gateway as a trigger, always verify that the execution role ARN is real, active, and attached.
Step Functions run tasks under the state machine’s IAM role, not your user account; permissions must be applied there.
Use add-permission only for resource policies; avoid mixing caller-role privileges with function-level allow statements unless needed.
Avoid wildcards like Resource: * in production environments.

Conclusion

This error is Lambda’s way of telling you the caller isn’t allowed through the front door. The fix is always the same: identify the caller, grant lambda:InvokeFunction on the correct resource, and test again. Once permissions are aligned, the entire event-driven chain runs smoothly and predictably.

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.

Search This Blog

Tech-Reader.blog