Fix Lambda 15-Min Timeout with VPC and NAT Gateway

Yeah, this one bites.

You've got a Lambda function doing real work, and it's dying right at the 15-minute mark. You're in a VPC, you've got a NAT gateway, and you're pulling your hair out. I've been there.

The fix is usually simpler than you think, but it's not what most docs tell you.

The Direct Fix

First, check your function's timeout setting. If it's set to 15 minutes (900 seconds), that's the hard ceiling. You can't go higher — AWS hard-codes it. So the fix isn't raising the timeout.

The real fix is making your function finish faster. And the most common reason it's slow in a VPC is the NAT gateway's bandwidth and connection overhead. Every outbound request from your Lambda goes through the NAT, and if you're doing lots of small requests, the NAT becomes a bottleneck.

Increase memory. Sounds counterintuitive, but memory allocation directly scales CPU. Double the memory and your function often runs 2-3x faster. Try bumping from 128MB to 512MB or 1GB. Costs more, but it eats the latency caused by NAT overhead.
Batch your network calls. If you're making 100 API calls in a loop, that's 100 round-trips through the NAT. Instead, batch them into fewer requests, or use async patterns if the API supports it. This alone cut a client's execution time from 14 minutes to 4.
Check your NAT gateway's bandwidth. If it's small (like 1 Gbps) and you're pushing high throughput, you're throttling. Switch to a larger NAT gateway or, better yet, use a VPC endpoint for the AWS services you're hitting (S3, DynamoDB, etc.) so traffic doesn't go through the NAT at all.

Why This Actually Works

NAT gateways aren't just a simple tunnel. Each connection through them gets tracked, and there's a finite number of concurrent connections. When you hit that limit, packets drop, and TCP retries kick in. Retries are slow — they can double or triple your effective latency.

More memory gives you more CPU, which means your code executes faster and the time spent waiting on the NAT shrinks. Batching reduces the number of NAT connections you need. VPC endpoints bypass the NAT entirely, so you remove that whole hop for AWS service calls.

The combination of these three fixes usually gets you well under the 15-minute cap.

Less Common Variations

Sometimes the timeout isn't about the NAT at all. Here are a few other things I've seen in the wild:

Cold starts eating your budget. If you're using Java or .NET, a cold start can eat 5-10 seconds. But if you have lots of cold starts, they add up. Set a Provisioned Concurrency to keep functions warm.
DNS resolution inside the VPC. The default VPC DNS might be slow. If you're calling services by domain name, each resolution goes through the NAT too. Switch to IP addresses or set up a custom DNS forwarder.
Elastic Network Interface (ENI) exhaustion. Every Lambda in a VPC attaches to an ENI. If your subnets don't have enough IPs, Lambda waits to attach, and that counts toward your timeout. Make sure your subnets are big enough.

Prevention

Don't wait for another timeout. Do these now:

Set CloudWatch alarms on duration. If your function consistently runs over 10 minutes, investigate before it hits the cap.
Use Step Functions for long jobs. If you have a genuinely long task, orchestrate it with Step Functions instead of one giant Lambda. You can split it into chunks or use a loop.
Monitor NAT gateway metrics. Watch ActiveConnections and BytesOutToDestination. If you see sustained high numbers, you know you're pushing it.

Bottom line: the 15-minute limit is fixed, but your workload isn't. Speed it up, or break it apart. Don't fight the platform — it'll win every time.