AWS Lambda VPC Change: Function Stuck in Pending

You just attached a VPC to your Lambda function or changed its subnets or security groups, and now it's stuck in Pending. The dashboard shows a spinning icon that never goes away. You're not alone — this happens a lot, especially when the function has no traffic or after a config update.

The root cause is almost always an Elastic Network Interface (ENI) problem. Lambda creates an ENI for each combination of subnet and security group. If those ENIs can't be provisioned, the function stays Pending indefinitely. Below is a troubleshooting flow, from the 30-second check to the 15-minute deep dive. Stop when the function flips to Active.

Step 1: The 30-Second Fix — Just Wait (No, Really)

Before you change anything, wait. ENI creation can take 1 to 5 minutes, sometimes longer if your AWS account is busy or you're in a region with high demand. I've seen functions sit in Pending for up to 10 minutes after a VPC change.

Here's what to do:

1. Open the Lambda console.
2. Select your function.
3. Refresh the page every 30 seconds.

After a few minutes, you should see the status change from Pending to Active. If it doesn't, move on to the next step.

One real-world trigger: I once changed a security group on a function that hadn't been invoked in weeks. It stayed Pending for 8 minutes. I almost rebuilt the whole function, but patience saved me.

Step 2: The 5-Minute Fix — Check Subnets and Security Groups

If waiting didn't work, the most common cause is a subnet or security group misconfiguration. Lambda can't create the ENI because the network settings are wrong.

Here's what to check:

Subnets

• Make sure you're using private subnets, not public ones. Public subnets with an Internet Gateway won't help — Lambda doesn't need a public IP for VPC access.
• Each subnet must have at least 4 available IP addresses. Lambda needs an ENI per subnet, and if the subnet is full (CIDR exhausted), ENI creation fails.
• Subnets must be in the same region as your Lambda function. Sounds obvious, but I've seen people copy a config from another region.

Security Groups

• Your security group must allow outbound traffic for Lambda to communicate. By default, a security group allows all outbound, but if you've locked it down, that's a problem.
• Inbound rules don't matter much for Lambda, but if your function needs to respond to something, make sure the appropriate inbound ports are open.

Here's the concrete fix:

1. Go to the VPC console.
2. Select Subnets and verify the subnets you're using have available IPs (check the Available IPv4 column).
3. Select Security Groups and verify the group ID you attached to Lambda exists and is in the same VPC as the subnets.
4. Edit your Lambda function's VPC configuration and reselect the subnets and security group, then hit Save.

After saving, Lambda will try to create new ENIs. Wait a few minutes and refresh. If it's still Pending, there's a deeper issue.

Step 3: The 15-Minute Fix — IAM Role and CloudWatch Logs (The Advanced Route)

If your subnets and security groups are correct, the problem is likely your execution role. Lambda needs specific IAM permissions to create and describe ENIs. If those permissions are missing, ENI creation fails silently and the function stays Pending.

Here's the fix:

Verify IAM Permissions

Your function's execution role must include the following AWS managed policy (or equivalent permissions):

arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole

If you already have a custom policy, make sure it includes these actions:

ec2:CreateNetworkInterface
 ec2:DeleteNetworkInterface
 ec2:DescribeNetworkInterfaces
 ec2:DescribeSubnets
 ec2:DescribeSecurityGroups
 ec2:ModifyNetworkInterfaceAttribute

Here's how to check and fix it:

1. Open the IAM console.
2. Find the execution role used by your Lambda function (check the Configuration tab of your function, then Permissions).
3. Click on the role, then Permissions.
4. Look for the AWSLambdaVPCAccessExecutionRole policy. If it's not there, click Add permissions → Attach policies and attach it.
5. If you're using a custom policy, add the missing actions above.

After updating the role, give it a minute or two, then refresh your Lambda function's status. IAM changes propagate quickly, but not instantaneously.

Check CloudWatch Logs

If you're still stuck, CloudWatch Logs will tell you what's failing. Lambda writes errors to CloudWatch Logs when ENI creation fails, even if the function isn't invoked.

Here's what to do:

1. Go to the CloudWatch Logs console.
2. Find the log group named /aws/lambda/your-function-name.
3. Look for error messages like EC2 error: UnauthorizedOperation or Network interface creation failed.

If you see UnauthorizedOperation, your IAM role is missing permissions — go back and double-check the policy.

If you see something like No subnet with ID found, then you've referenced a subnet that doesn't exist in your function's config. That can happen if you deleted a subnet after attaching it. Fix that by re-selecting valid subnets.

If you see Subnet has insufficient IP addresses, then you're out of IPs. Create a new subnet with a larger CIDR or use a different one.

What If It's Still Pending?

If you've gone through all three steps and the function is still Pending, here's the nuclear option: delete the function and recreate it. Yes, it's drastic, but if the underlying ENI state is corrupted, that's the fastest way out. I've done it twice, and both times it worked.

Before you delete, export your function's code and environment variables. Then create a new function with the same configuration, including the VPC settings. In most cases, the new function will go to Active immediately.

One last thing — if you're using a NAT gateway or VPC endpoints, make sure they're healthy. A misconfigured NAT can cause Lambda to hang during ENI creation, though that's rare. But if you're desperate, checking route tables might just save you.

That's the full troubleshooting flow. Start with waiting, then fix subnets and security groups, then check IAM and logs. You'll almost always find the culprit by step 2.