Lambda in VPC: Network Configuration

By default, AWS Lambda functions run in a secure, AWS-managed VPC that has full internet access. This means they can reach any public endpoint—AWS service endpoints, external APIs, etc.—without any additional configuration. However, many workloads require Lambda to access resources that reside inside a customer-controlled VPC, such as:

To enable this, you must configure the Lambda function to run inside your VPC. When you do, Lambda creates an Elastic Network Interface (ENI) for each combination of function version, subnet, and security group. This ENI gives the function a private IP address from your VPC subnet, allowing it to communicate with other resources in the VPC as if it were an EC2 instance. However, this also removes the function's default internet access—a common source of confusion and exam traps.

When you configure a Lambda function with VPC settings (subnet IDs and security group IDs), AWS Lambda uses the Hyperplane ENI service to manage network connectivity. Here is the step-by-step mechanism:

- Place the function in a private subnet. - Attach a NAT Gateway (or NAT instance) to a public subnet. - Add a route in the private subnet's route table pointing 0.0.0.0/0 to the NAT Gateway. - AWS Service Access: To access AWS services (e.g., S3, DynamoDB) without internet, use VPC Endpoints (Gateway or Interface endpoints). This keeps traffic within the AWS network and avoids NAT costs. - Execution Role: The Lambda function's execution role must have permissions to create, describe, and delete ENIs. The required actions are: - ec2:CreateNetworkInterface - ec2:DescribeNetworkInterfaces - ec2:DeleteNetworkInterface - ec2:AssignPrivateIpAddresses These are automatically added if you use the AWS managed policy AWSLambdaVPCAccessExecutionRole.

To configure a Lambda function in a VPC using the AWS CLI:

aws lambda update-function-configuration \
    --function-name my-function \
    --vpc-config SubnetIds=subnet-12345678,subnet-87654321,SecurityGroupIds=sg-12345678

To remove VPC configuration:

aws lambda update-function-configuration \
    --function-name my-function \
    --vpc-config {}

To verify the ENI creation:

aws ec2 describe-network-interfaces \
    --filters Name=description,Values="*Lambda*" Name=vpc-id,Values=vpc-12345678

You can also check the function's VPC config:

aws lambda get-function-configuration --function-name my-function

Look for the VpcConfig field.

A financial services company runs a microservices architecture where Lambda functions process transactions and write to an Amazon RDS MySQL instance. The RDS is in a private subnet for security. The Lambda function must be in the same VPC to connect. The team configures the Lambda with two private subnets in different Availability Zones for high availability. They also create a security group for the Lambda that allows outbound TCP 3306 to the RDS security group. The RDS security group allows inbound TCP 3306 from the Lambda security group. This works well, but the team notices that cold starts are slow (8-10 seconds). They implement Provisioned Concurrency to keep 10 environments warm, reducing latency to under 1 second. They also set up RDS Proxy to manage database connections efficiently, as Lambda's short-lived nature can exhaust RDS connections. Common misconfiguration: forgetting to add the Lambda security group to the RDS security group's inbound rule, causing connection timeouts.

A retail company uses Lambda to process orders and send confirmation emails via a third-party email API (e.g., SendGrid). The Lambda function also needs to read from a DynamoDB table. The function is placed in a VPC to access a legacy on-premises database via Direct Connect. To reach the email API and DynamoDB, the team must provide internet access. They create a public subnet with a NAT Gateway (Elastic IP attached) and add a route in the private subnet's route table pointing 0.0.0.0/0 to the NAT Gateway. For DynamoDB, they also create a Gateway VPC Endpoint to avoid NAT costs and improve security. The cost of the NAT Gateway is significant ($0.045/hour + data processing). The team monitors CloudWatch metrics for NAT Gateway bytes and decides to use VPC endpoints for all supported services. Common pitfall: forgetting to update the route table after creating the NAT Gateway, causing the Lambda to time out when calling external APIs.

A healthcare startup processes patient data and stores it in S3. Lambda functions, which must be in a VPC to access a private Elasticsearch cluster, also need to read/write to S3. To avoid internet exposure and NAT costs, the team creates a Gateway VPC Endpoint for S3 in the same region. They add a route in the private subnet's route table for the S3 prefix list (e.g., com.amazonaws.us-east-1.s3) pointing to the endpoint. The Lambda function's IAM role grants S3 access. The team tests and finds that S3 operations work without internet. They also set up an Interface VPC Endpoint for CloudWatch Logs to send logs without internet. Common misconfiguration: using a Gateway Endpoint for a service that requires an Interface Endpoint (e.g., Kinesis, SQS). Gateway Endpoints only work for S3 and DynamoDB. For other services, you must use Interface Endpoints (powered by PrivateLink), which incur hourly charges.