AWS DependencyViolation Explained: "Network Interface Is Currently in Use and Is of Type lambda," "Has a Dependent Object," and "Has Dependencies and Cannot Be Deleted" (Find the Owner, Then Delete the VPC, Security Group or Subnet)

DependencyViolation is the error AWS gives when you try to delete something that another thing still holds on to. It wears three disguises: "Network interface is currently in use and is of type 'lambda'" (or interface, vpc_endpoint, api_gateway_managed, branch), "resource sg-… has a dependent object" when a security group will not delete, and "The vpc 'vpc-…' has dependencies and cannot be deleted" (the subnet version says the same). All three come from the same place, and the fix is the same four-step loop: find the network interface that is still alive, read its Description and Interface type to learn which AWS service created it, delete or detach that service's resource (not the interface), then retry. Here is the part that costs people an afternoon: the interface that blocks you is almost never one you made. It belongs to a Lambda function, a load balancer, a VPC endpoint, an RDS database, a NAT gateway or an EFS mount target, AWS will not let you detach it by hand, and in the Lambda case it can take up to 20 minutes to disappear after you have done everything right.

Jake runs a phone repair shop. In August he followed a tutorial and built a small AWS setup for a booking form: a VPC, two subnets, a security group, a Lambda function that wrote bookings to a database. The project is over, and he wants it gone so nothing can quietly bill him. The VPC's Delete button says it "has dependencies." The security group says "has a dependent object." The one network interface left in the list says it is "currently in use and is of type 'lambda'", and the Delete action on it is grayed out. His friend Ethan, a developer, came over with a laptop. This page is what they did: what the error really means, how to find the owner of any network interface in one command, what each AWS service does with its interfaces when you delete things, the right order to delete a VPC, what to do when Terraform or CloudFormation hits the same wall, and the one case where you are allowed to force it.

New to AWS networking? Our plain-English guide to Amazon VPC explains VPCs, subnets and network interfaces in about ten minutes. You can follow this page without it; every step starts from zero.

What DependencyViolation means, in plain English

Think of your VPC as the building Jake rents for the shop. Subnets are rooms, security groups are the lock rules on each door, and a network interface is a wall socket: the thing a device plugs into to get a private address inside the building. Every server, database, load balancer and function that lives in the VPC does its networking through one or more of these sockets. AWS calls them elastic network interfaces, ENIs, and shows them under Network Interfaces in the EC2 console.

AWS will not let you demolish a room while a device is still plugged into a socket in it, will not let you remove a lock rule that a socket still uses, and will not let you tear down the building while any room is still in use. When you try, the EC2 service answers with the error code DependencyViolation. AWS's own definition: "The specified object has dependent resources. A number of resources in a VPC may have dependent resources, which prevent you from deleting or detaching them. Remove the dependencies first, then retry your request."

The message changes with what you were deleting, which is why people search for three different sentences:

Every row leads to the same object: a network interface that is still alive. So the whole job is finding that interface, learning who owns it, and removing the owner.

Jake: "But I deleted the function last week. Why is its socket still in the wall?"

Ethan: "Because Lambda does not give each function its own socket. It shares one between every function that uses the same room and the same lock. Yours is gone; something else is still plugged in, or Lambda just has not come back to unplug it yet."

Find who owns the network interface in one command

Open the EC2 console, choose Network Interfaces, and filter by the VPC or subnet you are trying to delete. Each interface has three fields that tell you its owner:

• Description: text written by the service that created it. A typical example is "VPC Endpoint Interface vpce-…". Load balancers, Lambda, WorkSpaces and NAT gateways all write theirs.
• Interface type: a fixed list of values set by EC2. This is the most reliable field, because a service cannot leave it blank.
• Requester-managed and Requester ID: whether AWS manages the interface on your behalf, and the account or service alias that created it. If you created it, the Requester ID is your own account number.

From the command line, this lists every interface in the VPC with those fields in one table:

aws ec2 describe-network-interfaces \
    --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
    --query "NetworkInterfaces[*].[NetworkInterfaceId,SubnetId,Status,InterfaceType,RequesterManaged,RequesterId,Description]" \
    --output table

Swap the filter for Name=subnet-id,Values=subnet-… when a subnet will not delete, or Name=group-id,Values=sg-… when a security group will not. AWS's documented shortcut for only the service-owned ones is --filters Name=requester-managed,Values=true.

Now read the Interface type column against this list. These are the values EC2 can return, with what each one means for your deletion:

The rule under all of it: when you delete the resource that a requester-managed interface belongs to, the AWS service detaches the network interface and deletes it. You do not delete the socket. You unplug the device, and the socket vanishes. If a service detached an interface but somehow did not delete it, its status shows as available instead of in-use, and that is the one case where you may delete it yourself.

Status is the other column worth reading. The values are available, associated, attaching, in-use and detaching. An in-use interface has an owner; an available one is an orphan you can delete.

Jake: "So the grayed-out Delete button was AWS protecting me from myself?"

Ethan: "From yourself and from a half-deleted Lambda. If it let you rip the socket out while Lambda still thought it had a function wired to it, the next invoke would fail in a far more confusing way than this."

"Network interface is currently in use and is of type 'lambda'": the full fix

This is the most searched variant, and the one with the most invisible moving parts, so here is exactly what Lambda does.

When you attach a function to a VPC, Lambda creates what it calls a Hyperplane ENI for each combination of subnet and security group the function uses. It does not create one per function. Any other function in your account that uses the same subnet and security group combination shares that interface; so can event source mappings. Lambda's own documentation puts it plainly: "Hyperplane ENIs are not directly visible to you, and you don't need to configure or manage them." In the EC2 console they appear with interface type lambda, and if you try to change their security group you get Client.OperationNotPermitted: "The security group can not be modified for this type of interface."

Three rules govern when the interface disappears:

1. Lambda deletes it only when no function or published function version uses it. This is the trap. You deleted the function you remember, but a second function, or an old published version of the first one, still lists the same subnet and security group. Versions are easy to forget: a function with versions 1 through 6 keeps its VPC configuration in every version.
2. It takes time. "When you update a function to remove its VPC configuration, Lambda requires up to 20 minutes to delete the attached Hyperplane ENI." Deleting the function counts as removing the configuration. The interface can sit there, in use, for twenty minutes after the last function is gone.
3. Lambda needs the function's execution role to do the cleanup. It uses the role's ec2:DeleteNetworkInterface permission. "If you delete the execution role before Lambda deletes the Hyperplane ENI, Lambda won't be able to delete the Hyperplane ENI. You can manually perform the deletion." That is the second trap: people delete the role first, then the function, and the interface is orphaned forever with no one holding permission to remove it.

So the procedure:

Step 1: find every function that uses the subnet and security group

The interface's Description names the function that created it, but that function may be long gone; what matters is every function that shares the combination. List functions with a VPC configuration in the Region and filter on the subnet or group:

aws lambda list-functions --region us-east-1 \
    --query "Functions[?VpcConfig.SubnetIds != null && contains(VpcConfig.SubnetIds, 'subnet-0123456789abcdef0')].[FunctionName, VpcConfig.SecurityGroupIds]" \
    --output table

Then check published versions of each function, because list-functions shows only the latest version:

aws lambda list-versions-by-function --function-name booking-writer \
    --query "Versions[*].[Version, VpcConfig.SubnetIds]" --output table

Step 2: remove the VPC configuration, or delete the functions and versions

To keep a function but take it out of the VPC, send an empty configuration:

aws lambda update-function-configuration --function-name booking-writer \
    --vpc-config SubnetIds=[],SecurityGroupIds=[]

To delete old versions that still carry the configuration: aws lambda delete-function --function-name booking-writer --qualifier 3, once per version. Deleting the whole function removes all its versions at once.

Step 3: wait, then check

Give it up to 20 minutes. Re-run the describe-network-interfaces command. When the interface is gone, or its status has changed to available, continue deleting the subnet, security group or VPC.

Step 4: the orphan case

If the function and its execution role are both already deleted and the interface is still in-use after an hour, Lambda cannot clean up and will not. Recreate a role with the AWS managed policy AWSLambdaVPCAccessExecutionRole, create a throwaway function that uses that role and the same subnet and security group (so it attaches to the existing interface), then remove that function's VPC configuration. Lambda now has a role with permission and no remaining users, and it deletes the interface within the usual window. If the interface shows available, delete it directly with aws ec2 delete-network-interface --network-interface-id eni-….

Two related limits, for the person who hits them next: Lambda's default quota is 3,000 interfaces per VPC (ENILimitReachedException), and a function left idle for 14 days has its interfaces reclaimed, which is why an old function sometimes shows as Inactive and takes minutes to wake. Our guide to Lambda in a VPC explains the networking side, including why attaching a function to a VPC takes its internet away.

Security group "has a dependent object": the two commands

There are exactly three reasons a DeleteSecurityGroup call fails with DependencyViolation: the group "is associated with an instance or network interface, is referenced by another security group in the same VPC, or has a VPC association." The console's version of the requirements says the same thing in three bullets. The message you see is "resource sg-… has a dependent object," which annoyingly does not say which of the three it is. Two commands do.

Which interfaces still wear this group:

aws ec2 describe-network-interfaces \
    --filters Name=group-id,Values=sg-0123456789abcdef0 \
    --query "NetworkInterfaces[*].[NetworkInterfaceId,Status,InterfaceType,Description]" --output table

Anything listed is an owner. Use the type table to remove it. Note that a security group can be attached to an interface without the interface being in use; a stopped instance still holds its group.

Which other groups reference this one in a rule:

# inbound rules that name the group as their source
aws ec2 describe-security-groups --filters Name=ip-permission.group-id,Values=sg-0123456789abcdef0 \
    --query "SecurityGroups[*].[GroupId,GroupName]" --output table

# outbound rules that name the group as their destination
aws ec2 describe-security-groups --filters Name=egress.ip-permission.group-id,Values=sg-0123456789abcdef0 \
    --query "SecurityGroups[*].[GroupId,GroupName]" --output table

A security group that references itself ("allow traffic from members of this group") shows up in its own result; that self-reference does not block deletion, but a rule in a different group does. Edit that other group and remove the rule, or delete the other group first. This is the classic circular pair: the database group allows the app group, the app group allows the database group, and neither will delete until one rule goes. (Terraform has a setting for exactly this; see below.)

Two special cases. The VPC's default security group cannot be deleted at all (CannotDelete); it disappears with the VPC. And a security group attached to an interface VPC endpoint gives the dependent-object error until you change the endpoint's security groups in the VPC console, or delete the endpoint. If security groups are new to you, our security groups explainer covers what rules and references mean.

Subnet "has dependencies and cannot be deleted"

A subnet is just a room; it will not delete while any socket exists in it. Run the interface command with Name=subnet-id,Values=subnet-…, remove every owner, and the subnet deletes. Three owners hide particularly well in subnets:

• NAT gateways. A NAT gateway's interface lives in a public subnet and stays for a few minutes after you delete the gateway, while its state reads "deleting." Release the Elastic IP afterward or it keeps billing. Our NAT gateway guide explains what it was doing there.
• Load balancers created by Kubernetes. On EKS, a Service of type LoadBalancer or an Ingress creates an AWS load balancer with interfaces in your subnets. Delete the Service or Ingress in Kubernetes first; EKS's own deletion guide warns that otherwise "the application load balancer remains even if you deleted the cluster."
• EFS mount targets. One interface per mount target, per subnet, with the mount target and file system named in the Description. Delete the mount target in the EFS console. If you set EFS up for Lambda, our Lambda and EFS guide shows the pairing that created it.

Subnets also fail to delete while a route table association or network ACL association points at them only in unusual cases; the console handles those. If you are unsure which subnets are public and which are private, and therefore which ones hold NAT gateways and load balancers, our public vs private subnet guide is the map.

How to delete a VPC that "has dependencies": the order that works

AWS's requirement for deleting a VPC is one sentence: "you must first terminate or delete any resources that created a requester-managed network interface in the VPC. For example, you must terminate your EC2 instances and delete your load balancers, NAT gateways, transit gateway VPC attachments, and interface VPC endpoints." Everything else, the console cleans up for you.

In the console

1. Terminate every EC2 instance in the VPC (EC2 console, Instances, filter by VPC).
2. Run the owner-finder command for the VPC and remove every remaining owner: Lambda VPC configurations, load balancers (and the Kubernetes objects behind them), NAT gateways, interface endpoints, RDS and ElastiCache instances, EFS mount targets, transit gateway attachments, Directory Service directories, WorkSpaces, Client VPN endpoints, Route 53 Resolver endpoints. Wait for the Lambda ones.
3. Delete VPC peering connections that involve this VPC.
4. In the VPC console, choose Your VPCs, select the VPC, Actions, Delete VPC. If anything still blocks it, the dialog lists it. Otherwise it shows what it will delete for you: DHCP options, egress-only internet gateways, gateway endpoints, internet gateways, network ACLs, route tables, security groups and subnets. Review, type delete, confirm.
5. If a Site-to-Site VPN connection exists, the dialog offers to delete it; keep it if another VPC will reuse the customer gateway.

Afterward: release Elastic IPs that belonged to NAT gateways and instances, delete the VPC's flow logs if you want them gone now (AWS removes them eventually), and check CloudWatch log groups and S3 buckets the project created, which are outside the VPC and survive it. Our page on why free-tier accounts still get charged lists the leftovers that keep billing after a VPC is gone.

From the command line

The CLI does none of the automatic cleanup, so you delete the pieces in order. AWS's documented sequence, which you must follow in this order after every owner above is gone:

VPC=vpc-0123456789abcdef0

# 0. nothing left that owns an interface?
aws ec2 describe-network-interfaces --filters Name=vpc-id,Values=$VPC --query "length(NetworkInterfaces)"

# 1. security groups you created (the default one stays)
aws ec2 delete-security-group --group-id sg-…

# 2. custom network ACLs (the default one stays)
aws ec2 delete-network-acl --network-acl-id acl-…

# 3. subnets
aws ec2 delete-subnet --subnet-id subnet-…

# 4. custom route tables (the main one stays)
aws ec2 delete-route-table --route-table-id rtb-…

# 5. detach, then delete, the internet gateway
aws ec2 detach-internet-gateway --internet-gateway-id igw-… --vpc-id $VPC
aws ec2 delete-internet-gateway --internet-gateway-id igw-…

# 6. dual-stack only: the egress-only internet gateway
aws ec2 delete-egress-only-internet-gateway --egress-only-internet-gateway-id eigw-…

# 7. the VPC
aws ec2 delete-vpc --vpc-id $VPC

If step 0 returns anything other than 0, stop and go back to the owner table; nothing below it will work. If step 1 fails with the dependent-object error, you have a circular reference between two groups: remove the rule in one, then delete both.

Jake: "That is seven commands to delete one thing."

Ethan: "The console does six of them for you. The command line assumes you want to see every brick come out, which on a real system is the safer way to feel."

Force detach: when it is allowed and when it does nothing

The console offers "Force detachment" on an interface, and a certain kind of afternoon makes it tempting. Here is what it is for. EC2's documentation describes force detachment as a last resort for a secondary interface attached to your own instance that will not detach normally, and warns that forcing it "can prevent you from attaching a different network interface on the same index until you restart the instance" and can leave the instance metadata stale until a restart.

For a service-owned interface it does not apply. If you try to detach a network interface that is attached to a resource from another service, such as an Elastic Load Balancing load balancer, a Lambda function, a WorkSpace, or a NAT gateway, you get an error that you do not have permission to access the resource. The requester-managed rules forbid attaching, detaching and modifying those interfaces entirely. So the force option is not a workaround for the "type 'lambda'" error; it returns a permissions error and changes nothing. The only honest path is the one above: remove the owner.

The one case where you delete an interface by hand: its status is available. Then aws ec2 delete-network-interface --network-interface-id eni-… works, and if it reports InvalidNetworkInterface.InUse instead, the status changed under you and something attached to it again.

DependencyViolation in Terraform, CloudFormation and CDK

Infrastructure tools hit the same wall, and each handles it its own way.

Terraform

The AWS provider retries a security group deletion for its delete timeout, 15 minutes by default (create is 10), which is why terraform destroy sometimes appears to hang on a security group before failing with DependencyViolation. For groups used by Lambda functions, deletion can take up to 45 minutes, and provider versions 2.31.0 and later handle this automatically; older versions need timeouts { delete = "45m" }. Three settings worth knowing:

• revoke_rules_on_delete = true on aws_security_group makes Terraform remove the group's rules before deleting it, which breaks the circular-reference deadlock. It exists for services such as EMR that add such rules on their own.
• lifecycle { create_before_destroy = true } when replacing a group, so the new group exists before the old one must be deleted.
• A shorter timeout (for example delete = "2m") when you would rather see the failure quickly and fix the real owner than wait a quarter of an hour.

When destroy fails on a subnet or VPC, the dependency is almost always something Terraform did not create: a Lambda interface, a load balancer from Kubernetes, a console-made endpoint. Run the owner-finder command, remove it, run destroy again. If the state lock itself is the thing failing, our state lock guide is the other page for a bad destroy day.

CloudFormation

A stack whose security group, subnet or VPC cannot be deleted ends in DELETE_FAILED, with the DependencyViolation text in the resource's status reason. CloudFormation's troubleshooting guide gives the way out: fix the dependency and delete again, or re-run the deletion with RetainResources naming the stuck resources, which deletes the stack and leaves those resources behind for you to delete by hand once the owner is gone. The console's newer FORCE_DELETE_STACK deletion mode does the same for all failed resources at once. A stack with termination protection on will not delete at all until you turn it off.

aws cloudformation delete-stack --stack-name booking-app \
    --retain-resources AppSecurityGroup PrivateSubnetA

The logical IDs come from the Resources tab of the stack. Retain only what failed; everything else is deleted normally.

CDK and SAM

Both deploy through CloudFormation, so the same rules apply, and a CDK destroy that fails on a VPC usually means a Lambda function in the same stack has not released its interface yet. Wait the 20 minutes and run destroy again before reaching for retain.

EKS, ECS and the interfaces containers leave behind

Clusters are the most common source of "I deleted everything and the VPC still has dependencies," because the cluster creates things you never saw.

EKS. The deletion guide's prerequisite steps are the whole answer: list Services with kubectl get svc --all-namespaces, delete every one that has an EXTERNAL-IP (those are AWS load balancers), delete every Ingress (kubectl get ingress --all-namespaces), then delete node groups, Fargate profiles and capabilities, then the cluster, and only then the VPC stack. Do it in the other order and you own a load balancer with no cluster, which still holds interfaces and still bills. Pods on EC2 nodes get their addresses from interfaces the VPC CNI attaches to the nodes; those disappear when the nodes terminate. If teardown itself times out, our EKS "context deadline exceeded" guide places where it stalled.

ECS. Every task in awsvpc mode gets its own interface, "a fully managed feature of Amazon ECS," which "your account can't detach or modify." It is deleted when the task stops or the service scales down. With ENI trunking, a trunk interface stays on the container instance until you deregister or terminate it. So: scale services to zero or delete them, stop remaining tasks, deregister or terminate instances, then delete the cluster, then the VPC.

Leftovers in other Regions: the loop that finds them all

A VPC you cannot see is one you forgot the Region of. The console shows one Region at a time, and a tutorial that switched you to Ohio for a step leaves a NAT gateway there that bills from Ohio. This loop prints every network interface you own in every Region, with its owner fields, so the hunt takes one run instead of fifteen clicks:

for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  echo "== $r"
  aws ec2 describe-network-interfaces --region "$r" \
      --query "NetworkInterfaces[*].[NetworkInterfaceId,VpcId,Status,InterfaceType,Description]" --output table
done

Regions that are not enabled for your account return an authentication error and move on. Anything the loop prints is a resource that still exists somewhere, and each line names what to delete.

Avoiding the afternoon next time

• Delete in reverse order of creation, and delete the things that create interfaces first: functions out of the VPC, load balancers, endpoints, NAT gateways, databases, then network.
• Never delete an execution role before its function (or its function's interfaces). Delete the function, wait, then the role.
• Give each project its own security group rather than sharing one across projects, so a group's owners are all yours to remove.
• Tag everything with the project name. The owner-finder command can then filter on Name=tag:Project,Values=booking and show you only your own leftovers.
• Keep one tool in charge. A VPC built by Terraform and decorated by hand in the console will always leave something for the other to trip over.

Still stuck? Troubleshooting by symptom

The interface shows "in-use", type "lambda", and I have no functions left

Check published versions and functions in other accounts sharing the VPC, then wait the full 20 minutes from the last change. If the execution role was deleted first, follow the orphan procedure.

"You do not have permission to access the specified resource" when detaching

That is the service-owned refusal, not an IAM problem. Delete the owning resource instead.

The security group will not delete and no interface lists it

Another group's rule references it. Run the two describe-security-groups filter commands, remove the referencing rule, retry. Also check that it is not the VPC's default group.

The VPC dialog lists nothing but still refuses

Look for a VPC peering connection, a transit gateway attachment, a Client VPN endpoint, a Route 53 Resolver endpoint or a shared-VPC participant's resources. Each creates a dependency that the owner-finder command shows as an interface or that lives under its own console page.

An interface is "available" and delete still fails with InUse

Something re-attached between your listing and your delete, which happens with autoscaling and with Lambda recreating interfaces on invocation. Stop the thing that is scaling, list again, delete again.

Terraform destroy waits 15 minutes then fails

Working as designed. Find the owner during the wait, or set a short delete timeout and fix the real dependency.

I am being billed for a VPC I thought I deleted

VPCs themselves are free; the bill is the NAT gateway, the load balancer, the Elastic IP or the database that survived. The owner-finder command, run across every Region you used, finds them.

AWS DependencyViolation: frequently asked questions

Jake's blocker turned out to be exactly the boring kind: the tutorial had published version 1 of the booking function, and version 1 still carried the VPC configuration after he deleted the one in the editor. Ethan deleted the function entirely, they made tea, and eighteen minutes later the interface was gone, the security group deleted, and the VPC dialog finally listed the things it would remove instead of the things that stopped it. The bill for the dead project next month: zero. The only thing Jake kept was the one-line command that tells you who is plugged into the wall.

Revision note. Written October 10, 2026, after one dead booking project and one cup of tea. "Look before you leap," says the proverb; here it is look before you delete, and the looking takes one command.