🚨 Azure Error Guide: 'NicInUse' Network Interface Cannot Be Deleted While Attached

Exact Error Message

When you try to delete a network interface (NIC) that something else still depends on, Azure Resource Manager rejects the request at the control plane. The most common form looks like this:

(NicInUse) Network Interface /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Network/networkInterfaces/web-01-nic is used by existing resource /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/web-01. In order to delete the network interface, it must be dissociated from the resource. To learn more, see aka.ms/deletenic.
Code: NicInUse
Message: Network Interface ... is used by existing resource ...

You will also see a closely related variant returned by some delete paths and surfaced in ARM/Terraform output:

(InUseNetworkInterfaceCannotBeDeleted) Network Interface /subscriptions/.../networkInterfaces/web-01-nic cannot be deleted because it is currently in use.
Code: InUseNetworkInterfaceCannotBeDeleted

Both error codes describe the same condition: the NIC is still referenced by another resource, and Azure will not orphan that resource by removing its interface.

What the Error Means

A network interface in Azure is a first-class resource, but it rarely exists alone. It is almost always attached to a parent resource — most often a virtual machine — and it carries one or more ipConfiguration objects that can be referenced by load balancers, application gateways, and private endpoints.

NicInUse (and its sibling InUseNetworkInterfaceCannotBeDeleted) is a reference-counting safety check. Azure Resource Manager refuses to delete a resource that another live resource still points at. The deletion never reaches a half-completed state; ARM evaluates the dependency graph and rejects the request up front. The fix is never to “force” the delete — there is no force flag — but to remove every reference to the NIC first, then delete it.

Common Causes

• NIC still attached to a VM. The most frequent cause. A NIC attached to a virtual machine cannot be deleted whether the VM is running or stopped (deallocated). Stopping the VM does not detach the NIC.
• NIC backing a private endpoint. Private endpoints create a managed NIC. You cannot delete that NIC directly; you must delete the private endpoint, which removes its NIC automatically.
• NIC belongs to a VM Scale Set (VMSS) instance. Scale set instances own NICs through the model. Deleting them individually fails — you scale in or update the model instead.
• An ipConfiguration is referenced by a load balancer or application gateway backend pool. Even if the VM is gone, if the NIC’s IP config is still listed in a backend address pool, the NIC is “in use.”
• A public IP is attached to the NIC. A public IP associated with an ipConfiguration can block the NIC delete, and separately the public IP cannot be deleted while still attached.
• IaC ordering bugs. Terraform or ARM/Bicep attempting to delete the NIC before (or concurrently with) the VM that owns it. The dependency exists implicitly, but a removed or reordered resource block breaks the teardown sequence.

How to Reproduce the Error

Create a VM (which provisions a NIC), then try to delete the NIC while the VM still exists:

# Create a VM — this implicitly creates web-01-nic and attaches it
az vm create \
  --resource-group rg-prod \
  --name web-01 \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --generate-ssh-keys

# Attempt to delete the still-attached NIC
az network nic delete --resource-group rg-prod --name web-01VMNic
# => (NicInUse) Network Interface ... is used by existing resource .../virtualMachines/web-01

The same happens if you create a private endpoint and try to delete its underlying NIC, or if you remove a VM but leave the NIC inside a load balancer backend pool.

Diagnostic Commands

Before changing anything, find out what is holding the NIC. These commands are all read-only.

# What VM (if any) is the NIC attached to?
az network nic show \
  --resource-group rg-prod --name web-01-nic \
  --query "virtualMachine" -o json

# List every NIC and which VM it's attached to, across the resource group
az network nic list \
  --resource-group rg-prod \
  --query "[].{name:name, vm:virtualMachine.id, ipconfigs:ipConfigurations[].name}" -o table

# Inspect the NIC's IP configurations (public IPs, subnet, primary flag)
az network nic ip-config list \
  --resource-group rg-prod --nic-name web-01-nic \
  --query "[].{name:name, privateIp:privateIPAddress, publicIp:publicIPAddress.id, subnet:subnet.id}" -o table

# From the VM side: what NICs does the VM reference?
az vm show \
  --resource-group rg-prod --name web-01 \
  --query "networkProfile.networkInterfaces[].id" -o json

# Is the NIC's IP config in a load balancer or app gateway backend pool?
az network nic show \
  --resource-group rg-prod --name web-01-nic \
  --query "ipConfigurations[].loadBalancerBackendAddressPools" -o json

If virtualMachine is non-null, a VM owns the NIC. If loadBalancerBackendAddressPools is non-empty, a load balancer (or app gateway) references it. If the NIC name ends in something like -nic.<guid> and lives in a managed resource group, it likely belongs to a private endpoint or scale set.

Step-by-Step Resolution

1. Identify the attaching resource. Run the diagnostics above. Confirm whether the holder is a VM, a private endpoint, a VMSS, or a backend pool reference. Do not guess — delete the wrong parent and you may take down a service.

2. Dissociate the NIC from the resource.

Detach from a VM. A VM must have at least one NIC, so you either delete the VM (if it’s being decommissioned) or attach a replacement NIC before removing this one:

# Decommissioning the whole VM (this also frees the NIC):
az vm delete --resource-group rg-prod --name web-01 --yes

# OR detach a non-primary NIC while keeping the VM alive:
az vm nic remove --resource-group rg-prod --vm-name web-01 --nics web-01-nic2

Remove from a load balancer / app gateway backend pool. Update the backend address pool so it no longer references the NIC’s ipConfiguration, then re-check loadBalancerBackendAddressPools returns empty.

Delete a private endpoint (never the managed NIC directly):

az network private-endpoint delete --resource-group rg-prod --name pe-sql

For a VMSS, scale in or update the scale set model rather than touching instance NICs.

3. Detach or delete any blocking public IP. If a public IP is associated with the NIC’s IP config, dissociate it first:

az network nic ip-config update \
  --resource-group rg-prod --nic-name web-01-nic \
  --name ipconfig1 --remove publicIPAddress

4. Delete the NIC. Once every reference is gone:

az network nic delete --resource-group rg-prod --name web-01-nic

Order of operations for IaC. In Terraform, the azurerm_network_interface should be created before the VM and destroyed after it — azurerm_linux_virtual_machine already declares a dependency on its network_interface_ids, so let the implicit graph drive teardown. If you previously removed the VM block from state while keeping the NIC, re-add it or terraform state rm the dangling NIC and import/clean up manually. In ARM/Bicep, use dependsOn so the VM is torn down before the NIC, and avoid complete mode deployments that race the two resources.

Prevention and Best Practices

• Delete top-down. Always remove the parent (VM, private endpoint, scale set) before the NIC, and the NIC before the subnet and public IP.
• Let IaC manage the graph. Don’t manually delete child resources of a Terraform/Bicep-managed VM; you’ll create state drift and the NicInUse error on the next apply.
• Tag NICs with their owner so teardown scripts know which VM or service to dissociate first.
• Use resource group deletion for full environments. Deleting the whole resource group resolves dependencies in the correct order automatically.
• Audit orphaned NICs periodically with az network nic list --query "[?virtualMachine==null]" — but confirm they aren’t backend-pool or private-endpoint NICs before removing them.

For broader teardown patterns, see our Azure cleanup guide.

Related Errors

• InUseNetworkInterfaceCannotBeDeleted — the alternate code for the same condition; resolve identically by dissociating the NIC first.
• SubnetInUse / InUseSubnetCannotBeDeleted — a subnet still has NICs, delegations, or service endpoints attached; delete those resources before the subnet.
• PublicIPAddressCannotBeDeleted — a public IP is still associated with a NIC’s IP configuration or a load balancer frontend; dissociate it first.
• NetworkInterfaceAlreadyExists — a NIC with the same name exists in the resource group; rename or import the existing resource instead of recreating it.

Frequently Asked Questions

Is there a force flag to delete a NIC that’s in use? No. Azure has no force-delete for a referenced NIC. The reference check protects the parent resource from being orphaned. You must remove every reference (VM attachment, backend pool, private endpoint) before the delete will succeed.

The VM is stopped (deallocated) — why is the NIC still in use? Deallocating a VM releases compute, but the NIC stays attached to the VM resource. Stopped and running VMs both hold their NICs. You must detach the NIC or delete the VM.

Why can’t I delete the NIC behind my private endpoint? Private endpoints provision a managed NIC that you don’t own directly. Delete the Microsoft.Network/privateEndpoints resource instead, and its NIC is removed automatically.

My VM is already deleted but I still get NicInUse — why? Something else references the NIC’s ipConfiguration — almost always a load balancer or application gateway backend address pool. Check ipConfigurations[].loadBalancerBackendAddressPools and remove the NIC from that pool before deleting it.