Lambda "The Role Defined for the Function Cannot Be Assumed by Lambda": The Trust Policy, the 10-Second Timing Trap, and the Fix in the CLI, CloudFormation, Terraform, CDK and SAM

The role defined for the function cannot be assumed by Lambda. comes back from CreateFunction or UpdateFunctionConfiguration as an InvalidParameterValueException, and it means one of two things. Either the role's trust policy doesn't name lambda.amazonaws.com as a principal that may assume it, or the role is fine and you created it a few seconds ago: IAM is eventually consistent, and a role that exists in one API call can still be invisible to Lambda in the next. The second cause is the one that fools people, because the same script works on the second run. This page shows you how to tell the two apart in one command, the exact trust policy, the wait-and-retry that fixes the timing case, and the right fix in CloudFormation, Terraform, CDK and SAM, plus how this error differs from the iam:PassRole denial that lands on the same command.

Ethan, a developer, deploys the booking function for his friend Jake's phone repair shop with a script: create the role, attach the logging policy, create the function. On Tuesday it failed with this error. He ran it again, it worked, and he deleted the function to see if he'd imagined it. It failed again. Jake asked whether AWS was "flaky." Ethan had a better word by the end of the afternoon: eventual.

What the error means, in plain English

Every Lambda function has an execution role: the identity it wears while it runs. When Lambda runs your function, it assumes that role, which means it calls sts:AssumeRole on your behalf. A role will only let a principal assume it if the role's trust policy says so. So when you create a function and hand it a role ARN, Lambda immediately checks: can the Lambda service assume this role? If the answer is no, the function is not created, and you get:

An error occurred (InvalidParameterValueException) when calling the CreateFunction operation:
The role defined for the function cannot be assumed by Lambda.

In CloudFormation the same text arrives wrapped: Resource handler returned message: "The role defined for the function cannot be assumed by Lambda.", and the stack rolls back. In Terraform it's creating Lambda Function (...): operation error Lambda: CreateFunction, ... InvalidParameterValueException: The role defined for the function cannot be assumed by Lambda. Same check, same two causes.

The check can fail for exactly two reasons. The trust policy on the role really doesn't allow Lambda, or the trust policy does allow Lambda but IAM hasn't finished propagating the role (or a change to it) to every service yet. There is no third reason, which is good news: one command below tells you which one you have.

Jake: "So the role exists, and Lambda still says it can't use it?"

Ethan: "A role is a thing with a lock on it. The trust policy is the list of who holds a key. Either Lambda isn't on the list, or it is and the locksmith hasn't delivered the key yet. The second one takes ten seconds."

One command to tell the two causes apart

Read the trust policy of the role you passed, not the one you think you passed. Use the exact role name from the ARN in the failing command:

aws iam get-role --role-name booking-fn-role \
  --query 'Role.AssumeRolePolicyDocument.Statement[].Principal' --output json

You want to see this, and only this, for a plain Lambda function:

[
    {
        "Service": "lambda.amazonaws.com"
    }
]

If the output names a different service, such as ec2.amazonaws.com because the role was cloned from an instance role, or an account or user ARN, or nothing at all, you have cause one: fix the trust policy. If the output shows lambda.amazonaws.com exactly, you have cause two: timing, and the fix is to retry. Two more things to glance at in the same breath: the account ID inside the role ARN must be the account you're deploying to (aws sts get-caller-identity tells you which one that is), and the ARN must be a role ARN, arn:aws:iam::123456789012:role/name, not a user ARN and not an instance-profile ARN (arn:aws:iam::123456789012:instance-profile/name), which looks similar and is a different object.

Cause one: the trust policy, and the exact JSON that works

A trust policy is a small JSON document attached to the role that says who may assume it. For Lambda, the principal is the service itself. This is the whole file:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Save it as trust.json. To fix an existing role in place, replace its trust policy; nothing else about the role changes, and functions that already use it keep working:

aws iam update-assume-role-policy --role-name booking-fn-role --policy-document file://trust.json
aws iam get-role --role-name booking-fn-role \
  --query 'Role.AssumeRolePolicyDocument.Statement[].Principal.Service' --output text
# lambda.amazonaws.com

To create a role correctly from the start, give the trust policy at creation and attach the basic logging policy, which is what every function needs to write to CloudWatch:

aws iam create-role --role-name booking-fn-role \
  --assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name booking-fn-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

The mistakes that produce a wrong trust policy, in the order we see them: a role copied from an EC2 or ECS example with its principal left as ec2.amazonaws.com or ecs-tasks.amazonaws.com; a trust policy that names an AWS account or a user, which is how roles for people are built, where the service line was never added; a condition block (aws:SourceArn or aws:SourceAccount) copied from another service's example that Lambda's assume call doesn't satisfy; and a Deny statement somewhere in the same document. In the console, this is IAM → Roles → your role → Trust relationships → Edit trust policy; paste the JSON above and save.

One thing the trust policy does not need: your own user or account as a principal. Lambda assumes the role; that is its job, not yours. The execution-role guidance says the same: calling sts:AssumeRole on the execution role from inside your function is unnecessary, and if you truly need the role to assume itself, the role has to trust itself explicitly.

Cause two: the role is correct and seconds old

Here is the part that makes people doubt their own eyes. IAM is a global service that replicates every change across Regions and to every other AWS service. The IAM troubleshooting guidance states it plainly: changes you make are not always immediately visible, because IAM uses eventual consistency, and it tells you to wait for changes to propagate before production workflows depend on them. In practice that window is seconds, usually under ten, occasionally longer. A script that creates a role and creates the function in the next line is racing that window, and sometimes loses.

The symptoms are unmistakable once you know them: the trust policy is perfect, the first attempt fails, the same command succeeds a moment later, and the problem comes and goes between runs. The fix is to retry with a pause. In a shell script:

for i in 1 2 3 4 5 6; do
  aws lambda create-function --function-name booking-fn \
    --runtime nodejs22.x --handler index.handler \
    --role arn:aws:iam::123456789012:role/booking-fn-role \
    --zip-file fileb://fn.zip && break
  echo "attempt $i failed, waiting 10 s"; sleep 10
done

Six attempts ten seconds apart is a minute, which is more than propagation ever needs; if the sixth attempt still fails, you are back in cause one. The same idea in Python with boto3, catching only this error so a real mistake still surfaces:

import time, boto3
from botocore.exceptions import ClientError

lam = boto3.client("lambda")
for attempt in range(6):
    try:
        lam.create_function(FunctionName="booking-fn", Runtime="nodejs22.x",
                            Handler="index.handler",
                            Role="arn:aws:iam::123456789012:role/booking-fn-role",
                            Code={"ZipFile": open("fn.zip", "rb").read()})
        break
    except ClientError as e:
        msg = e.response["Error"]["Message"]
        if "cannot be assumed by Lambda" not in msg or attempt == 5:
            raise
        time.sleep(10)

The same race exists on update-function-configuration --role when you switch a function to a role you just created, and after update-assume-role-policy: the fix you made in the section above also takes a few seconds to be seen. If you fixed the trust policy and the very next command still fails, that is propagation, not a second mistake.

Jake: "Ten seconds. The whole Tuesday was ten seconds?"

Ethan: "Ten seconds and a script that didn't know how to wait. The second run always worked because the role had caught up by then."

The fix in CloudFormation, SAM, Terraform and CDK

Infrastructure tools hit the same race in a more confusing costume, because the tool creates the role and the function for you and decides the order. Each one has its own correct answer.

CloudFormation

CloudFormation already waits for the role to exist before it creates a function that references it with !GetAtt Role.Arn; the reference creates the dependency. What it doesn't wait for is the role's policies when those are separate resources (AWS::IAM::Policy, AWS::IAM::RolePolicy), and a function can be created against a role whose trust is fine but whose attachments are still being written, which some deployments surface as this error or as a function that fails its first invocation. The fix is an explicit DependsOn from the function to the policy resource:

Resources:
  FnRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal: { Service: lambda.amazonaws.com }
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
  FnLogPolicy:
    Type: AWS::IAM::RolePolicy
    Properties:
      RoleName: !Ref FnRole
      PolicyName: booking-extra
      PolicyDocument: { Version: "2012-10-17", Statement: [ ... ] }
  BookingFn:
    Type: AWS::Lambda::Function
    DependsOn: FnLogPolicy
    Properties:
      Role: !GetAtt FnRole.Arn
      Runtime: nodejs22.x
      Handler: index.handler
      Code: { S3Bucket: my-bucket, S3Key: fn.zip }

Two template mistakes produce cause one rather than timing: a Principal written as a string (Principal: lambda.amazonaws.com) instead of a map with the Service key, and an AssumeRolePolicyDocument pasted from an EC2 role. If the template creates the role with a fixed RoleName, the stack also needs CAPABILITY_NAMED_IAM, which is a different error with its own page in the cards below.

SAM

A AWS::Serverless::Function with Policies: gets a role generated by SAM with the correct trust policy and the dependencies in the right order; this error rarely appears on that path. It appears when you pass your own role through the Role: property: then the function depends only on what you reference, so the same DependsOn as CloudFormation applies, and the trust policy of that role is yours to get right.

  BookingFn:
    Type: AWS::Serverless::Function
    DependsOn: FnLogPolicy
    Properties:
      Role: !GetAtt FnRole.Arn
      Runtime: nodejs22.x
      Handler: index.handler
      CodeUri: ./src

Terraform

Terraform's own example for aws_lambda_function shows the pattern: the role from a trust policy document, a policy attachment, and the function with an explicit depends_on on the attachment, so the function isn't created while the role's permissions are still landing. Without it, Terraform knows the function needs the role (it reads aws_iam_role.example.arn) but not that it should wait for the attachment:

data "aws_iam_policy_document" "assume_role" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "lambda" {
  name               = "booking-fn-role"
  assume_role_policy = data.aws_iam_policy_document.assume_role.json
}

resource "aws_iam_role_policy_attachment" "lambda_logs" {
  role       = aws_iam_role.lambda.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_lambda_function" "booking" {
  function_name = "booking-fn"
  role          = aws_iam_role.lambda.arn
  runtime       = "nodejs22.x"
  handler       = "index.handler"
  filename      = "fn.zip"

  depends_on = [aws_iam_role_policy_attachment.lambda_logs]
}

If the error still appears on a fresh apply with that in place, run terraform apply again before changing anything: the provider retries some IAM propagation errors on its own, but not every path, and a second apply after a few seconds is the honest test. A persistent failure means the trust document above is wrong, often because type was set to AWS instead of Service.

CDK

CDK writes the trust policy for you when you let it: new lambda.Function(...) without a role creates a role with lambda.amazonaws.com as the principal and orders the resources correctly. The error shows up when you build the role yourself with the wrong principal:

const role = new iam.Role(this, "BookingFnRole", {
  assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),   // not "ec2.amazonaws.com"
  managedPolicies: [iam.ManagedPolicy.fromAwsManagedPolicyName("service-role/AWSLambdaBasicExecutionRole")],
});
new lambda.Function(this, "BookingFn", {
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: "index.handler",
  code: lambda.Code.fromAsset("src"),
  role,
});

Passing the role object (not its ARN as a string) is what lets CDK add the dependency; a role ARN imported with iam.Role.fromRoleArn from another stack gives CDK nothing to wait for, so make sure that stack deployed first.

Lambda@Edge: two principals, not one

A function you attach to a CloudFront distribution is replicated to edge locations by a different service, and its role must trust both the Lambda service and the Lambda@Edge replicator. A role that works for an ordinary function fails here with the same error until the trust policy lists both:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [ "lambda.amazonaws.com", "edgelambda.amazonaws.com" ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Lambda@Edge also creates a service-linked role, AWSServiceRoleForLambdaReplicator, which trusts replicator.lambda.amazonaws.com; you don't edit that one, and it is not the role this error is about.

Not this error: the PassRole denial on the same command

The other role error that lands on CreateFunction reads User: arn:aws:iam::123456789012:user/ethan is not authorized to perform: iam:PassRole on resource: arn:aws:iam::123456789012:role/booking-fn-role. It looks like a cousin and it is the opposite problem: Lambda could assume the role fine, but you, the identity running the deploy, aren't allowed to hand that role to a service. That is fixed in the deployer's identity policy with an iam:PassRole allow on the role, not in the trust policy. Our PassRole guide covers it; the short version of the difference:

The worked example: Ethan's deploy script

Ethan's script did four things in order: create the role, attach AWSLambdaBasicExecutionRole, zip the code, create the function. The trust policy was right; the diagnosis command printed lambda.amazonaws.com. The failure was the fourth line running about a second after the first. He made two changes. The function creation went inside the six-attempt loop with a ten-second sleep, and the script now checks aws sts get-caller-identity first and refuses to run if the account doesn't match the one in the role ARN, because the second time this error appeared, on Thursday, it was a copy of the script run with Jake's personal profile against Jake's own account, where no such role existed at all. Different cause, same message, same one-command diagnosis.

Jake: "So on Thursday the role really didn't exist, and on Tuesday it existed but wasn't ready?"

Ethan: "Right. And both times the fix started with reading the role back instead of staring at the error."

The checklist, in order

1. Read the trust policy of the exact role in the ARN: aws iam get-role --role-name ROLE --query 'Role.AssumeRolePolicyDocument'.
2. If lambda.amazonaws.com is missing, replace the trust policy with the JSON above; add edgelambda.amazonaws.com for Lambda@Edge.
3. If the trust policy is right and the role or its trust policy changed in the last minute, wait 10 seconds and retry, up to six times.
4. Check the account: the role ARN's account must match aws sts get-caller-identity, and the ARN must be a role, not a user or an instance profile.
5. In CloudFormation and SAM, add DependsOn from the function to the role's policy resources; in Terraform, depends_on on the policy attachment; in CDK, pass the role object.
6. If the message says iam:PassRole, stop: that's your permission, not the trust policy.

Ethan's script has a ten-second patience built in now, and a line that refuses to run against the wrong account. The booking function deploys on the first try every time, which Jake finds less impressive than the Tuesday it didn't. Jake's verdict: "So the role was fine all along; it was just late." Ethan said that was the most accurate bug report the shop had ever filed.

Revision note. Written October 15, 2026, with the Node.js 22 runtime in the examples and the current Terraform and CDK role patterns. "Patience is bitter, but its fruit is sweet," says the old proverb; here the fruit arrives in about ten seconds.