🚨 Azure Error Guide: 'InUseSubnetCannotBeDeleted' — Remove Subnet Dependencies First

Overview

Azure blocks deletion (or address-range changes) of a subnet that still has resources connected to it. The control plane returns InUseSubnetCannotBeDeleted, usually listing the IP configurations still attached:

{
  "error": {
    "code": "InUseSubnetCannotBeDeleted",
    "message": "Subnet app-subnet is in use by /subscriptions/xxxx/resourceGroups/rg-app/providers/Microsoft.Network/networkInterfaces/nic-01/ipConfigurations/ipconfig1 and cannot be deleted. In order to delete the subnet, remove all the resources within the subnet. Please refer to https://aka.ms/deletesubnet."
  }
}

A related delegation/association variant appears when the subnet is delegated to a service or bound to a service association link:

{
  "error": {
    "code": "InUseSubnetCannotBeDeleted",
    "message": "Subnet <name> cannot be deleted because it is in use by resource(s): [Microsoft.Web/serverFarms]. Please remove the delegation/service association before deleting the subnet."
  }
}

Symptoms

• az network vnet subnet delete fails with InUseSubnetCannotBeDeleted naming one or more IP configurations.
• Changing a subnet’s address prefix fails because resources are still bound to the current range.
• Terraform/Bicep tries to replace (force-new) a subnet and fails on the destroy step.
• Deleting the parent VNet fails because a subnet within it is still in use.
• The error references a service like Microsoft.Web/serverFarms, Microsoft.Sql/managedInstances, or a private endpoint rather than a NIC.

Common Root Causes

• Attached NICs / VMs. Any NIC (and thus VM) with an IP configuration in the subnet keeps it in use.
• Private endpoints / private link service. A private endpoint’s NIC lives in the subnet and blocks deletion until removed.
• Subnet delegation. The subnet is delegated to a service (App Service/Web, SQL Managed Instance, container instances) and must be un-delegated first.
• Service association links (SAL). Some integrations create a hidden service association link that must be removed by deleting the associated service.
• Application Gateway / Azure Firewall / Bastion. These deploy into dedicated subnets and hold them until the appliance is deleted.
• Stale/hidden connections. A recently deleted resource whose NIC has not fully finished removing, or an orphaned IP configuration.

Diagnostic Workflow

All commands below are read-only. First list exactly what the subnet still contains:

# Show the subnet and its ipConfigurations, delegations, and service links.
az network vnet subnet show --resource-group <rg> --vnet-name <vnet> --name <subnet> \
  --query "{ipConfigs:ipConfigurations[].id, delegations:delegations[].serviceName, sal:serviceAssociationLinks}" --output json

Find every NIC using the subnet across the subscription:

# List NICs whose ipConfigurations reference this subnet.
az network nic list --query "[?ipConfigurations[?subnet.id=='<subnet-id>']].{name:name, rg:resourceGroup}" --output table

Check for private endpoints in the subnet:

# Private endpoints place a NIC in the subnet.
az network private-endpoint list --query "[?subnet.id=='<subnet-id>'].{name:name, rg:resourceGroup}" --output table

Confirm the subnet ID you are matching against:

az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query id --output tsv

Example Root Cause Analysis

An engineer tried to delete app-subnet after decommissioning its VMs and got InUseSubnetCannotBeDeleted, but the message referenced Microsoft.Web/serverFarms, not a NIC — surprising, since no web app was obviously deployed there.

az network vnet subnet show revealed a delegations entry for Microsoft.Web/serverFarms and a service association link. The subnet had been used for App Service regional VNet integration months earlier; the app’s VNet integration was still bound to it even though the VMs were gone.

The fix was to disconnect the App Service plan’s VNet integration (which removed the service association link and delegation) before deleting the subnet. Listing NICs and private endpoints confirmed nothing else remained. After removing the integration, az network vnet subnet delete succeeded. Root cause: a lingering subnet delegation/service association link from App Service VNet integration, not an attached NIC.

Prevention Best Practices

• Enumerate dependencies before deleting. Always list ipConfigurations, delegations, and service association links on a subnet before attempting deletion.
• Delete or move dependents first — NICs/VMs, private endpoints, and appliance resources (App Gateway, Firewall, Bastion) — then delete the subnet.
• Remove delegations and VNet integrations (App Service, SQL MI) explicitly; they are not removed by deleting unrelated resources.
• Use dedicated subnets for appliances so their lifecycle is clear and teardown order is obvious.
• Model teardown order in IaC with correct dependencies so destroy operations remove dependents before the subnet.
• Wait for asynchronous deletes to finish; a NIC mid-deletion can still hold the subnet briefly.

Quick Command Reference

# Show what the subnet still contains.
az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --output json

# Find NICs using the subnet.
az network nic list --query "[?ipConfigurations[?subnet.id=='<subnet-id>']].name" -o table

# Find private endpoints in the subnet.
az network private-endpoint list --query "[?subnet.id=='<subnet-id>'].name" -o table

# Get the subnet's resource ID for matching.
az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query id -o tsv

# Delete only after all dependents are removed.
az network vnet subnet delete -g <rg> --vnet-name <vnet> -n <subnet>

Conclusion

InUseSubnetCannotBeDeleted is Azure protecting connected resources: something still lives in the subnet. Enumerate its IP configurations, delegations, and service association links, remove the NICs, private endpoints, appliances, and VNet integrations that hold it, then delete. Modeling correct teardown order in IaC and using dedicated appliance subnets makes these deletions predictable instead of a surprise mid-decommission.