AWS Lambda Support
Fixing Lambda AccessDenied and execution role errors.
Lambda access errors come from several places: the execution role, a resource-based policy, a KMS key, a permissions boundary or an organization policy. The error text names an action but not always the real blocker. We trace the exact denied call and fix the right policy, not the nearest one.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Logs show AccessDeniedException or 'is not authorized to perform' for an action
- A function cannot read S3, DynamoDB, SQS, Secrets Manager or KMS
- Another service or account cannot invoke your function
- A deployment fails with 'role cannot be assumed by Lambda'
- A fix worked in one environment and fails in another
What you get
- The exact cause, with the CloudTrail event that proves it
- A least-privilege policy change in infrastructure as code
- A short note on which policy layer controls each access path
- A repeatable test to confirm permissions after deployments
How we do it
A clear, safe process you can follow along with.
1. Read the exact error
AWS errors name the principal, the action and often the resource, for example 'User: arn:aws:sts::ACCOUNT:assumed-role/ROLE/FUNCTION is not authorized to perform: dynamodb:PutItem on resource: TABLE'. We copy these three values first.
2. Decide which direction is failing
Is the function calling something (execution role needs permission) or being called (the function's resource-based policy must allow the caller)? Mixing these up is the most common reason fixes do not work.
3. Check the execution role
We confirm the role's trust policy allows lambda.amazonaws.com to assume it, that logging permissions are present, and that the policy includes the exact action and resource ARN, including table indexes or object key paths.
4. Look for other layers
An explicit deny in a permissions boundary, a service control policy, a bucket or key policy, or a VPC endpoint policy overrides an allow. KMS needs both IAM permission and the key policy to permit the role.
5. Confirm in CloudTrail
We find the event by error code in CloudTrail, which shows the real principal, API call and, for many services, the denial reason. This avoids guessing.
6. Fix with least privilege and re-test
We add only the required actions and resources, test with the IAM policy simulator, invoke the function again and check that the error is gone and nothing broader was opened.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Attaching AdministratorAccess to make it work
It hides the real gap and leaves a function that can do anything. We scope to the needed actions.
Editing the wrong role
Stale role names from copied templates are common. We check the role actually shown on the function.
Forgetting the key policy
An encrypted queue, secret or bucket can still deny the function even with IAM allow in place.
Wildcard resource ARNs that skip sub-resources
A table ARN does not cover its indexes, and a bucket ARN does not cover objects. Both need explicit entries.
Frequently Asked Questions
What is the difference between an execution role and a resource policy?
The execution role is what the function is allowed to do to other services. The resource-based policy on the function controls who may invoke it.
Why does Lambda say the role cannot be assumed?
The role's trust policy must name lambda.amazonaws.com as a trusted service. Roles created for other services or accounts fail that check.
How long do IAM changes take to apply?
IAM is eventually consistent and changes usually apply quickly, but short delays are possible. If a fix does not work immediately, we still verify there is no explicit deny.
Want Help With Fixing Lambda AccessDenied and execution role errors?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required