เกตเวย์ NAT และการเข้าถึงอินเทอร์เน็ตจาก VPC

A Lambda in a VPC can reach private resources, but it loses default internet access. Calls to public APIs suddenly time out.

VPC Lambdas have no public IP. Without a route to the internet, outbound calls to external endpoints have nowhere to go.

A public subnet routes to an Internet Gateway; a private subnet does not. Always place Lambdas in private subnets for security.

A NAT gateway lives in a public subnet and lets private subnets make outbound internet calls while staying unreachable from the internet.

The private subnet route table sends internet-bound traffic to the NAT gateway, which forwards it through the Internet Gateway.

NAT gateways charge per hour plus per GB processed. For heavy traffic this adds up, so consider whether you truly need public internet access.

To reach AWS services like S3 or DynamoDB, use a VPC endpoint. Traffic stays on the AWS network with no NAT needed and no per-GB internet cost.

S3 and DynamoDB use free gateway endpoints; most other services use interface endpoints (powered by PrivateLink) which are billed hourly.

No code change is needed. With a gateway endpoint and the right route, this S3 call never leaves the AWS backbone.

Need a public third-party API? Use a NAT gateway. Need only AWS services? Use VPC endpoints. Often you use endpoints to avoid NAT entirely.

Deploy a NAT gateway per Availability Zone and put the Lambda in multiple subnets, so one AZ outage does not break connectivity.

Test your VPC networking knowledge.

You learned why VPC Lambdas lose internet access and how NAT gateways restore outbound access, while VPC endpoints reach AWS services privately and cheaply.