When a Lambda function is configured to run inside a VPC, it receives ENIs in the selected subnets and uses those subnets’ routing to reach other networks. If the function is placed in private subnets (common when it needs to access an RDS database in private subnets), it typically does not have a direct route to the internet. As a result, outbound calls to public external APIs will fail unless the VPC provides a controlled egress path.

The standard AWS networking pattern for private-subnet internet access is a NAT gateway (or NAT instance) deployed in a public subnet, with a route from the private subnet(s) to the NAT gateway (0.0.0.0/0 → NAT). The NAT gateway then uses an internet gateway attached to the VPC to reach the public internet while keeping the Lambda function (and the RDS database) in private address space. This resolves the connectivity issue while maintaining the security posture of private subnets.

Option A is not the solution: Lambda automatically provisions ENIs for VPC-enabled functions; manually provisioning an ENI does not provide internet access. Option C (security group outbound rules) is necessary but not sufficient—security groups control allowed traffic, but without a proper route to the internet (via NAT), the packets still cannot reach external endpoints. Option D (gateway VPC endpoint) is for AWS services like S3 and DynamoDB (gateway endpoints), not for arbitrary public internet APIs, and “in a public subnet” is not how gateway endpoints are used; they are associated with route tables.

Therefore, the correct solution is B: add a NAT gateway in a public subnet and update private subnet route tables so the new Lambda function can reach external public APIs while still accessing the private RDS database.