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

Question

I tried the solutions in this answer but it does not work for me. I am getting the error:

The provided execution role does not have permissions to call CreateNetworkInterface on EC2 (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 4c8d047c-2710-4334-86cd-51b7467c6f08)

Here is the CloudFormation associated with the error:

EventLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: !Sub ${DeveloperPrefix}event-lambda-${Environment}-${DeployPhase}
      Handler: EventHandler
      Runtime: java8
      Code:
        S3Bucket: !Ref SharedBucketName
        S3Key: !Sub ${WorkspacePrefix}/event-subscriber-${AppVersion}.jar
        S3ObjectVersion: !Ref EventLambdaS3Version
      Role: !GetAtt EventLambdaRole.Arn
      Environment:
        Variables:
          retry_event_table_name: !Sub "${DeveloperPrefix}${AppName}-${RetryEventTableName}-${Environment}-${DeployPhase}"
          test_enabled: true # TODO: Remove once endpoint provided.
      VpcConfig:
        SecurityGroupIds:
          - !Ref LambdaSecurityGroup
        SubnetIds:
          - Fn::ImportValue: !Sub ${VPCStackName}-SubnetPrivateL
          - Fn::ImportValue: !Sub ${VPCStackName}-SubnetPrivateR
      Timeout: 28
      MemorySize: 256

  EventLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Sub ${DeveloperPrefix}${AppName}-${Environment}-${DeployPhase}-EventLambdaRole
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: [lambda.amazonaws.com]
            Action: ['sts:AssumeRole']
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: !Sub ${DeveloperPrefix}${AppName}-${Environment}-${DeployPhase}-EventLambdaPolicy
          PolicyDocument:
            Statement:
              - Sid: DynamoDbPermissions
                Effect: Allow
                Action:
                  - dynamodb:PutItem
                Resource: !Sub 'arn:aws:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${DeveloperPrefix}${AppName}-EventRetry-${Environment}-${DeployPhase}'
              - Sid: LambdaVPCPermissions
                Effect: Allow
                Action:
                  - ec2:AttachNetworkInterface
                  - ec2:CreateNetworkInterface
                  - ec2:CreateNetworkInterfacePermission
                  - ec2:DeleteNetworkInterface
                  - ec2:DeleteNetworkInterfacePermission
                  - ec2:DescribeDhcpOptions
                  - ec2:DescribeNetworkInterfaces
                  - ec2:DescribeNetworkInterfacePermissions
                  - ec2:DescribeSubnets
                  - ec2:DescribeVpcs
                  - ec2:DescribeInstances
                Resource: '*'

I have searched for an answer to this and have tried several of the suggestions found but to no avail. I am making any obvious mistakes? I fear I cannot see the forest for the trees right now.

Solution 1

As the lambda is running in VPC, you can use AWSLambdaVPCAccessExecutionRole instead of AWSLambdaBasicExecutionRole. Ideally, it should be the same as what you have. One advantage is less maintenance effort from dev ops view.

! Important The error is not warning us about permissions of the user, but about permissions of the role associated with the lambda function. Make sure that

1. you have a role for the lambda function and
2. this role has AWSLambdaBasicExecutionRole permission policy
3. this role has Trust relationships like the following:

`

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

Solution 2

You must also include the ec2:AssignPrivateIpAddresses and ec2:UnassignPrivateIpAddresses actions in your permissions.

Comments

[ir0h]

i was pinpointing access and thereby avoiding the managed groups. this is a more specific answer because these are the exact actions missing from op's example.