Help deleting orphaned Lambda ENI. It's been orphaned for days.

Hi Igor,

This is expected behavior rather than a true "orphan." A Lambda VPC network interface (shown as a requester-managed lambda-type ENI) can only be created, managed, and deleted by Lambda itself — you can't detach/delete it manually, and aws ec2 delete-network-interface will fail with an "in use" error. Lambda deletes the ENI automatically, but only once nothing still references its specific subnet + security group combination.

The important detail: Lambda shares one ENI across every function, function version, and event source mapping that has the same VPC config. So even though you moved your current functions, the ENI usually persists because something else still points at that subnet+SG. The two most common culprits are:

1. A published function version still configured with the old subnet/SG. You can't edit a published version, so changing the $LATEST VPC config does not update old versions — they keep the ENI alive.
2. An event source mapping (Amazon MSK, self-managed Kafka, Amazon MQ, or DocumentDB) using the same subnet/SG.

Steps to resolve:

1. Find exactly what's using it. Use the AWS Lambda ENI Finder (aws-support-tools/Lambda/FindEniMappings on GitHub - https://github.com/awslabs/aws-support-tools/blob/master/Lambda/FindEniMappings/README.md): ./findEniAssociations --eni eni-0c474a8977416326e --region <your-region>

   This lists every function and version still referencing the ENI.

2. If functions/versions are listed: - For $LATEST: change the VPC config to a different subnet/SG, or disconnect the function from the VPC. - For published versions: since they can't be edited, delete the versions that still reference the old subnet/SG.

3. If no functions are listed, check event source mappings: aws lambda list-event-source-mappings --query 'EventSourceMappings[?State != Disabled]'

   Disable or delete any MSK/Kafka/MQ/DocumentDB mapping whose cluster/broker uses that subnet+SG. (Also check Amazon Managed Service for Prometheus scrapers if you use them.)

4. Wait for Lambda to clean up. Once nothing references the subnet+SG, Lambda deletes the ENI automatically — this typically takes ~20 minutes but can take up to ~45 minutes (longer if many functions shared it). Re-run the ENI Finder to confirm it's gone.

• Note : Don't delete the relevant function's execution role until after the ENI is gone — Lambda uses that role's permissions to delete the ENI.

If the ENI Finder shows zero functions, versions, event source mappings, and scrapers, and the ENI still won't clear after an hour or two, that points to a backend Hyperplane cleanup that's genuinely stuck — at that point open an AWS Support case so we can remove it from the backend.

Hope this helps!

This ENI is not a part of cloud formation stack. It isn't attached to a lambda. It has been stuck in this orphaned state for several days.

I understand you're dealing with an orphaned Lambda ENI that's preventing you from making VPC changes. This is a common issue that can typically be resolved through a few troubleshooting steps.

First, verify that all Lambda functions that were using the VPC have been either deleted or updated to use different subnets. Even if functions appear to be moved, there may be lingering configurations or function versions that still reference the old subnet.

Here are the recommended steps to resolve this:

1. Check for Lambda function versions and aliases: Lambda creates ENIs for each concurrent execution, and older function versions or aliases might still be configured with the original VPC settings. Review all versions and aliases of your Lambda functions to ensure none reference the problematic subnet.

2. Wait for automatic cleanup: Lambda ENIs are typically cleaned up automatically, but this process can take some time - sometimes up to several hours after the last function using them is removed or reconfigured.

3. Verify no active Lambda invocations: Ensure there are no Lambda functions currently executing that might be using the ENI.

4. Check CloudFormation stacks: If your Lambda functions were deployed via CloudFormation, ensure the stacks have been properly updated or deleted.

If you've verified all of the above and the ENI persists, you can reach out to AWS Support through the AWS Support Center at https://console.aws.amazon.com/support/ for assistance with removing the stuck ENI. They can investigate whether there are any backend issues preventing the automatic cleanup and help resolve the situation more quickly.

For future prevention, consider reviewing your AWS Support plan options if you need faster response times for blocking issues like this.