Serverless-application-model: VPCAccessPolicy does not take effect.

[vinkris]

AdminReturn:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub ${AWS::StackName}-${EnvName}-adminreturn
      CodeUri: ../build
      Handler: handler.adminReturn
      Policies:
        - VPCAccessPolicy: {}
        - DynamoDBCrudPolicy:
            TableName: !Ref TenantsTable
      VpcConfig:
        SubnetIds: !Split [ ',', 'Fn::ImportValue': !Sub "${BaseVPCStackName}-${EnvName}-SubnetsPrivateAppIds" ]
        SecurityGroupIds: ['Fn::ImportValue': !Sub "${BaseVPCStackName}-${EnvName}-AzureAdSG" ]
      Environment:
        Variables:
          TENANTSTATE_TABLE: !Ref TenantsTable
          DEP_ENVIRONMENT: !Ref EnvName
          DEV_PROFILE: !Ref AzureADDepProfile
      Events:
        Consent:
          Type: Api
          Properties:
            Path: /adminreturn
            Method: get
            RestApiId:
              !Ref AzureADSyncAPI

I have a serverless function as above, and I keep getting the following error in Cloudformation:

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

Everything works fine if I use the AWS managed policy AWSLambdaENIManagementAccess, but I really want the policy to be specific to the resources being used by Lambda. Of course, we could write up a policy by hand which is specific to our needs, I am still wondering why this VPCAccessPolicy: {} wouldn't work as an inline policy.

Also, I observed that VPCAccessPolicy does work sometimes, although its not clear when.

[winsome]

Also having the same issue as @vinkris. AWSLambdaENIManagementAccess is a reasonable workaround, but it would be best if the VPCAccessPolicy works as expected

[tp6m4fu6250071]

found the managed policy "AWSLambdaVPCAccessExecutionRole" works fine, too. For example:
...
Policies:
- AWSLambdaVPCAccessExecutionRole
...

[keetonian]

Our best guess is that this is an eventual consistency issue in IAM. The permissions in each of these policies are essentially the same, it just seems like the AWS managed policies are more readily available from IAM than custom policies (like a policy template).

I'd recommend using the AWS managed policy for this issue, as you haven't seen an error with it and it is the same policy. These policy actions cannot be scoped to specific resources, so this is fine.

VPCAccessPolicy:

    "VPCAccessPolicy": {
      "Description": "Gives access to create, delete, describe and detach ENIs",
      "Parameters": {

      },
      "Definition": {
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "ec2:CreateNetworkInterface",
              "ec2:DeleteNetworkInterface",
              "ec2:DescribeNetworkInterfaces",
              "ec2:DetachNetworkInterface"
            ],
            "Resource": "*"
          }
        ]
      }
    },

AWSLambdaVPCAccessExecutionRole:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "ec2:CreateNetworkInterface",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DeleteNetworkInterface"
            ],
            "Resource": "*"
        }
    ]
}

AWSLambdaENIManagementAccess:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DeleteNetworkInterface"
            ],
            "Resource": "*"
        }
    ]
}