Lambda ENI Stuck Pending in VPC: Fix for AWS

You're setting up an AWS Lambda function inside a VPC, and you see it in the Pending state for way too long — like 5, 10, even 20 minutes. The exact trigger is usually right after you attach a Lambda function to a private subnet inside a VPC that doesn't have a NAT gateway or VPC endpoints for AWS services. The function never starts, and CloudWatch logs show nothing useful. I've seen this with Python 3.9 and Node.js 18 runtimes, but it happens with any runtime.

What's Actually Happening

Lambda creates a special network interface (ENI) in your VPC to let the function talk to resources there. This ENI needs an available IP from the subnet's CIDR range. If that subnet has no free IPs, or if the DHCP options don't match what Lambda expects, the ENI gets stuck in Pending. The real culprit is almost always the subnet running out of IPs, or the Lambda service can't reach the EC2 API to finish the ENI creation because there's no route to the internet or a VPC endpoint.

Lambda uses the EC2 API behind the scenes to create these ENIs. If your subnet is private and you haven't set up a VPC gateway endpoint for EC2, or a NAT gateway, the API call times out. Lambda doesn't tell you this nicely — it just sits in Pending.

How to Fix It

I've fixed this for dozens of teams. The steps below are tested on AWS accounts in us-east-1 and eu-west-2. They work the same everywhere.

1. Check the subnet IP count. Go to the VPC console, select your subnet, and look at the 'Available IPs' field. If it's less than 2, that's your problem. Lambda needs at least one free IP per ENI, and it won't work if the pool is empty. Create a new subnet with a larger CIDR (like /24 instead of /28) and attach that to the function.
2. Make sure the subnet has a route to AWS services. For a private subnet, you need either a VPC gateway endpoint for EC2 and S3, or a NAT gateway in a public subnet with a route in the private subnet's route table pointing to that NAT. Without this, Lambda can't call the EC2 API to create the ENI. After step 1, this is the second most common cause.
3. Check the security group rules. Lambda creates the ENI in the security group you specify. If that security group has inbound rules that block traffic from the Lambda service (which uses IPs in the 10.0.0.0/8 range for ENI creation), the process hangs. Temporarily add an inbound rule allowing all traffic from within the VPC CIDR. If that fixes the issue, tighten it down later.
4. Verify the Lambda function's execution role. It needs the ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces, and ec2:DeleteNetworkInterface permissions. I've seen roles that had these but the policy was attached to the wrong place. Use the IAM policy simulator to test the role with these actions. The role also needs ec2:AssignPrivateIpAddresses if you're using custom IP assignments.
5. Wait and then delete the stuck ENI. If the above don't work, go to the EC2 console, find the ENI with description 'AWS Lambda VPC ENI' and status 'pending'. Delete it. Then update the Lambda function's VPC configuration to a different subnet (same VPC, different subnet) and save. This forces Lambda to recreate the ENI from scratch. Wait 2 minutes — it usually attaches cleanly now.

What to Check If It Still Fails

If the function stays in Pending after all that, check the VPC flow logs for the subnet. Look for outbound traffic to the EC2 endpoint (ec2..amazonaws.com) being denied. If it's denied, your route table or NACL is blocking it. Also check if you're hitting the Lambda ENI limit per region — it's 250 per region by default. You can request a limit increase from AWS Support. Finally, try a different AWS region. I've seen rare cases where the EC2 API had a hiccup in one region but worked fine in another.