Introduction

A Lambda function placed in private subnets inside a VPC does not get outbound internet access automatically. If that function needs to reach public internet endpoints, the usual network design is a NAT gateway in a public subnet plus correct route-table wiring from the private subnets. The main confusion is that attaching Lambda to a VPC solves private-network access, not internet egress.

The High-Level Topology

The typical layout looks like this:

• Lambda is attached to private subnets
• the VPC has a public subnet
• the public subnet contains a NAT gateway with an Elastic IP
• the VPC has an internet gateway
• the private subnets route outbound internet traffic to the NAT gateway

That gives the Lambda function outbound access without exposing it directly to inbound public traffic.

Why the NAT Gateway Must Be in a Public Subnet

A NAT gateway itself needs internet reachability through an internet gateway. That is why it belongs in a public subnet with a route to the internet gateway.

The Lambda function, on the other hand, should usually sit in private subnets that route 0.0.0.0/0 to the NAT gateway.

The direction of thinking is:

• Lambda stays private
• NAT performs outbound translation for it

Route Table Setup

The route tables are the crucial part.

Public subnet route table:

• local VPC route
• default route 0.0.0.0/0 to the internet gateway

Private subnet route table:

• local VPC route
• default route 0.0.0.0/0 to the NAT gateway

If the private subnet still routes nowhere for internet-bound traffic, the Lambda function will remain isolated even if the NAT gateway exists.

A Practical Build Sequence

A practical setup order is:

1. create or identify the VPC
2. create at least one public subnet
3. create at least one private subnet for Lambda
4. attach an internet gateway to the VPC
5. allocate an Elastic IP
6. create the NAT gateway in the public subnet
7. update the private subnet route table to send default traffic to the NAT gateway
8. attach the Lambda function to the private subnets and security groups

That order keeps the dependencies straightforward.

Security Groups and NACLs

Security groups still matter, but they are not the main internet-egress switch here. Lambda's security group must allow the needed outbound traffic, and the subnet-level network ACLs must not block it.

If the route tables are correct but outbound requests still fail, the next things to inspect are:

• security group egress rules
• network ACL rules
• DNS resolution settings in the VPC

Do You Really Need NAT

A NAT gateway is the standard answer when the Lambda must access arbitrary public internet destinations.

But if the function only needs certain AWS services, a VPC endpoint may be better.

Examples:

• S3 access can often use an S3 VPC endpoint
• some AWS APIs can use interface endpoints

That can reduce cost and keep traffic private inside AWS instead of routing through NAT.

So the first design question should be:

• does the function need the public internet generally
• or does it only need specific AWS services

Common Pitfalls

• Putting the Lambda function in a private subnet but forgetting the private route-table default route to the NAT gateway.
• Creating the NAT gateway in a private subnet instead of a public one.
• Assuming VPC attachment alone gives internet access.
• Using a NAT gateway when a VPC endpoint would be cheaper and more precise for the actual traffic pattern.
• Debugging Lambda code first when the real problem is VPC routing, security group egress, or subnet design.

Summary

• A Lambda function in private VPC subnets needs extra routing for outbound internet access.
• The standard solution is a NAT gateway in a public subnet plus correct private-subnet route tables.
• The NAT gateway must have internet reachability through an internet gateway.
• Security groups and NACLs still need to allow the desired traffic.
• If the function only needs certain AWS services, consider VPC endpoints instead of NAT.