Lambda Stuck on Cold Start? Fix VPC ENI Internet Access

You deploy a Lambda into a private subnet. First invocation after a deploy takes 12 seconds. Then it works fine. Then next deploy, same thing. Or worse — it times out completely with a generic Task timed out after 3.00 seconds and you're staring at CloudWatch wondering what the hell happened.

The culprit is almost always the same: your function sits in a VPC with no route to the internet, and the Lambda service can't reach its own control plane endpoints to attach the elastic network interface that gives your function a network identity. No ENI, no invocation.

Cause 1: Private subnet with no NAT gateway (the big one)

This is the most common setup I see. Someone drops a Lambda into a private subnet because it needs to reach an RDS instance, and they forget that "private subnet" means exactly what it says — no route to 0.0.0.0/0 via an internet gateway or NAT.

When the function cold starts, AWS has to create a Hyperplane ENI inside your subnet. That process needs to talk back to Lambda's control plane, which lives on the public AWS network. Without a NAT gateway (or NAT instance), those calls go nowhere. You get a hang, then a timeout.

The real fix: put a NAT gateway in a public subnet and add a route in your private subnet's route table:

aws ec2 create-route \
  --route-table-id rtb-0abc123 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0def456

Yes, NAT gateways cost money — around $32/month plus data processing. If that stings, consider whether the Lambda actually needs VPC access at all. A lot of functions get thrown into a VPC for no good reason. If it's just calling DynamoDB or S3, take it out of the VPC and use IAM policies. Cold starts drop to under a second.

Watch out: NAT gateway route alone isn't enough if your security group blocks outbound traffic. The default SG allows all outbound, but if someone tightened it, you'll still hang. Check the outbound rules on the SG attached to the Lambda.

Cause 2: Missing VPC endpoints for the services you actually call

You added a NAT gateway. Cold starts are better but you're still seeing 4-6 second delays, and your NAT data processing bill is climbing. You're routing S3, DynamoDB, and Secrets Manager traffic through the NAT when you don't have to.

Gateway endpoints for S3 and DynamoDB are free. Interface endpoints (PrivateLink) for Secrets Manager, KMS, SQS, etc. cost about $7/month per AZ but skip the NAT hops entirely.

Create a gateway endpoint for S3:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0abc123 \
  --vpc-endpoint-type Gateway

Then add the endpoint ID to your route table. Do the same for DynamoDB. For interface endpoints, set Enable DNS name to true and make sure Private DNS is enabled — otherwise your SDK calls go to the public endpoint and back through the NAT.

I had a client last year burning $400/month in NAT data processing because every Lambda invocation was pulling secrets from Secrets Manager over the NAT. Two interface endpoints later, that bill dropped to $28.

Cause 3: ENI subnet exhaustion (the sneaky one)

Lambda creates one ENI per subnet per security group combination, not per function. But if you've got dozens of functions across many subnets and SG combos, those ENIs add up. A /28 subnet only has 16 addresses — usable ones after AWS reserves the first four and last one. That's 11 addresses. Hit the limit and new ENIs can't be created.

Symptom looks identical to the NAT problem: function hangs, times out, works after some other function scales down. Check subnet free IPs:

aws ec2 describe-subnets \
  --subnet-ids subnet-0abc123 \
  --query 'Subnets[].AvailableIpAddressCount'

If you're under 10 free IPs, expand the subnet or spread your functions across more subnets. Lambda will reuse ENIs aggressively, but you still need headroom.

Another gotcha: if you delete and recreate the execution role, or change the security groups attached to a function that's already deployed, Lambda rebuilds the ENI from scratch. First invocation after that change will be slow, even with a NAT in place. That's normal — give it 30 seconds and move on.

Quick reference

Don't waste time tweaking memory or timeout values. Those don't fix ENI creation. The problem is networking, not compute.