The provided execution role does not have permissions to call CreateNetworkInterface on EC2

What it means

There are two kinds of permission a Lambda function needs, and conflating them is what produces this error. The first is obvious: whatever your code calls — DynamoDB, S3, SQS — has to be permitted. The second is easy to miss entirely, because it covers calls your code never makes.

When a function is attached to a VPC, Lambda has to create an elastic network interface in your subnets to give the execution environment a path into your network. It makes that EC2 call using your function's execution role, not as a service principal with its own permissions. So the role needs ec2:CreateNetworkInterface even though there is no EC2 code anywhere in your project, and the absence of it stops the function before it exists.

The most common way in is adding a VPC configuration to a function that already worked. Attaching the VPC does not update the role, so a function that ran happily for months starts failing every invocation immediately after a change that looks like it only touched networking. Nothing about the code changed and nothing about the permissions your code needs changed — the role simply now needs permissions for something Lambda does on its behalf.

Three EC2 actions are involved and all three are needed, which matters because granting only the first appears to work. Lambda creates the interface when it scales up, describes it while managing it, and deletes it when the function is removed or its VPC configuration changes. A role with only CreateNetworkInterface succeeds at the thing you tested and leaves orphaned interfaces behind later, at a moment far removed from the deploy that caused it. AWSLambdaVPCAccessExecutionRole is the managed policy that contains the correct set, and using it is safer than assembling the list by hand.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

The message names the exact EC2 action that was refused, and there are three that matter: CreateNetworkInterface, DescribeNetworkInterfaces and DeleteNetworkInterface. All three are needed, and a role granted only the first will work until Lambda tries to clean up.

This appears before any of your own output, because it happens while the execution environment is being built. It also appears at deploy time in CloudFormation and CLI output, so seeing it in both places is expected rather than two separate problems.

Causes, most likely first

Fixes

yamlResources:
  FunctionRole:
    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/AWSLambdaVPCAccessExecutionRole

json{
  "Effect": "Allow",
  "Action": [
    "ec2:CreateNetworkInterface",
    "ec2:DescribeNetworkInterfaces",
    "ec2:DeleteNetworkInterface",
    "ec2:AssignPrivateIpAddresses",
    "ec2:UnassignPrivateIpAddresses"
  ],
  "Resource": "*"
}

bashaws iam list-attached-role-policies --role-name orders-fn-role
aws iam get-role --role-name orders-fn-role \
  --query 'Role.PermissionsBoundary'

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Connecting outbound networking to resources in a VPC
• AWS Lambda Developer Guide — Lambda execution role