[aws-lambda] Allow placing Lambda Functions in a Public subnet

[richardhboyd]

This restriction is arbitrary and a huge pain to work around. When I deploy a Neptune Instance with default values, the instance is placed in a 'Public' subnet. I want a Lambda that can speak to that instance (I could not possibly care less about it accessing the internet). Because of this issue, I had to go back and move my Neptune instance into a private subnet but then I hit this issue because I don't need (nor want) NAT Gateways. I tried to use the ISOLATED subnets but I get an error saying that the VPCEndpoint for S3 that Neptune needs isn't compatible with ISOLATED subnets.

I can deploy the Neptune instance with only default values and add a Lambda (without a VPC) then go into the console and add the Lambda to the VPC in the appropriate subnets in just a few clicks. This feels like the CDK opinionated design is (a) getting in the way and (b) refusing to get out of the way by refusing to let me add a Lambda to a public subnet.

Reproduction Steps

Error Log

Environment

• CLI Version :
• Framework Version:
• Node.js Version:
• OS :
• Language (Version):

Other

---

This is 🐛 Bug Report

[briancaffey]

I recently had a similar issue where I wanted to place a Lambda function in a PUBLIC subnet but CDK wouldn't let me. I was able to use add_override to change my Lambda function's VPC subnets from ISOLATED to PUBLIC:

        self.my_lambda = _lambda.Function(
            self,
            "MyLambda",
            runtime=_lambda.Runtime.PYTHON_3_8,
            code=_lambda.AssetCode('./my_app'),
            function_name=f"my-lambda",
            handler="handler.handler",
            layers=[self.my_lambda_layer],
            timeout=core.Duration.seconds(15),
            vpc=scope.vpc,
            vpc_subnets=ec2.SubnetSelection(
                subnets=scope.vpc.isolated_subnets
            ),
        )

        # override the lambda's `VpcConfig.SubnetIds` property
        self.my_lambda.node.default_child.add_override(
            "Properties.VpcConfig.SubnetIds",
            [subnet.subnet_id for subnet in scope.vpc.public_subnets],
        )

[richardhboyd]

You shouldn't have to do that. CFN supports it, the Console supports it, the SDKs support it, there's no reason CDK should be forcing customers to not do it.

[briancaffey]

@richardhboyd Yeah, I agree. Maybe it is slightly misleading for CDK to report that it is Not possible to place Lambda Functions in a Public subnet because as you said it is possible to do this in the Console/CloudFormation/SDK. It is possible, but unlike placing a Fargate task in a public, the Lambda won't have internet access because

   // ... Routing through an IGW
   // won't work because the ENIs don't get a Public IP.

My reason for placing a Lambda function in a PUBLIC subnet is also related to avoiding NAT costs. I would be placing the Lambda function in a PRIVATE subnet, but the Vpc construct doesn't allow you to set nat_gateways=0 and have any private subnets in your subnet_configurations:

If you do not want NAT gateways (natGateways=0), make sure you don't configure any PRIVATE subnets in 'subnetConfiguration' (make them PUBLIC or ISOLATED instead)

[nija-at]

It's not clear why this restriction was originally put in place. However, it seems on initial assessment this can be adjusted now.