AWS Lambda VPC timeout: fix network latency in seconds

Quick answer

Add a NAT gateway to your public subnet, or create a VPC endpoint for the AWS service you're calling (like S3 or DynamoDB). That gets your Lambda outbound traffic moving.

Why this happens

Lambda functions placed inside a VPC lose their default internet access. They only have an ENI (elastic network interface) in your VPC, with no route to the public internet unless you explicitly set one up. The culprit here is almost always a missing NAT gateway or VPC endpoint. The function spins up, tries to call S3 or DynamoDB or some other AWS service, and sits there waiting for a route that doesn't exist. After 3 seconds, Lambda kills it. The error in CloudWatch looks like Task timed out after 3.00 seconds — no other details, just dead silence.

I've seen this exact pattern in dozens of teams: they add a VPC to their Lambda for RDS access, then wonder why external calls fail. The fix is straightforward, but you need to know which path your traffic takes.

Step-by-step fix

1. Check your subnet routing — In the VPC console, look at your Lambda's subnets. If they're private (no route to an internet gateway), you need either a NAT gateway or VPC endpoints. Public subnets with an internet gateway route won't help here because Lambda ENIs don't get public IPs.
2. Add a NAT gateway — Create a NAT gateway in a public subnet (one with a route to an internet gateway). Then add a route in your private subnet's route table that points 0.0.0.0/0 to the NAT gateway. This costs about $0.045/hour plus data transfer. Skip this if you're only calling AWS services — use a VPC endpoint instead.
3. Add VPC endpoints — For services like S3, DynamoDB, or SQS, create a gateway endpoint (for S3/DynamoDB) or interface endpoint (for everything else). Gateway endpoints are free. Interface endpoints cost per hour. Add the endpoint to the same subnets your Lambda uses, and update the route tables accordingly.

Alternative fixes if the main one fails

• Increase the timeout temporarily — Bump it to 10 seconds in the Lambda configuration. This isn't a real fix, but it buys you time to debug. Watch CloudWatch logs for connect() timed out — that confirms a routing problem.
• Check security group rules — Make sure the Lambda's security group allows outbound traffic (all traffic to 0.0.0.0/0 for testing, then tighten it later). A restrictive SG can block the NAT gateway or VPC endpoint traffic.
• Use a VPC interface endpoint for other services — If calling SQS or SNS, gateway endpoints won't work. You need an interface endpoint (they use AWS PrivateLink). Check the endpoint type — gateway only works for S3 and DynamoDB.

Prevention tip

Don't put Lambda in a VPC unless you absolutely need RDS or ElastiCache access. For everything else — like calling S3, DynamoDB, or external APIs — keep the function outside the VPC. It's simpler, faster, and cheaper. If you do need VPC access, always add VPC endpoints for every AWS service you call before you deploy. Strip the Lambda of all outbound internet routing and use endpoints exclusively — no NAT gateway, no headaches. You'll avoid the timeout entirely.