Troubleshooting Azure: Resolving Virtual Network Deletion Issues with ACI
When managing your network infrastructure in Azure, you may encounter situations where deleting a Virtual Network (VNet) or a specific subnet within it becomes problematic. A common source of such issues arises when the subnet has been delegated for use by Azure Container Instances (ACI). Attempting to remove a subnet that is still linked to ACI resources will typically result in error messages indicating that the subnet is currently in use and cannot be deleted until the dependent resources are removed.
Understanding the Errors¶
When you attempt to delete a subnet that ACI is still utilizing, Azure’s dependency checks will prevent the operation and return informative error messages. Two common error patterns you might see include messages related to delegation requirements and messages indicating the subnet is actively in use by specific network resources.
One frequent error explicitly mentions delegation and a “service association link”:
Failed to delete subnet '<subnet-name>'.
Error: 'Subnet /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name> requires any of the following delegations
[Microsoft.ContainerInstance/containerGroups] to reference service association link /
subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>/serviceAssociationLinks/acisal.'
This message indicates that there’s a dependency linked via the ACI service association link (acisal) within the subnet. While it mentions delegation requirements, the core issue it highlights is the existence of the service association link, which is established when ACI resources are deployed into a delegated subnet. The link signifies an active connection that must be severed before the subnet can be removed.
Another common error message points directly to specific network resources that are using the subnet:
Subnet <subnet-name> is in use by /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/networkProfiles/aci-network-profile-<network-profile-name>/containerNetworkInterfaceConfigurations/eth0/ipConfigurations/ipconfigprofile and cannot be deleted.
In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet.
This error is more explicit, identifying a specific network profile (aci-network-profile-...) and an underlying network interface configuration (containerNetworkInterfaceConfigurations/eth0/ipConfigurations/ipconfigprofile) as the blockers. When ACI deploys container groups into a delegated subnet, it provisions network resources like network profiles behind the scenes to manage the container group’s network connectivity within the VNet. These network profiles maintain a direct reference to the subnet and must be deleted before the subnet is free to be removed.
Both errors essentially mean the same thing: the subnet cannot be deleted because there are still resources (specifically, underlying ACI-related network infrastructure) depending on it.
Why ACI Creates Dependencies¶
Azure Container Instances offers the capability to deploy container groups directly into an Azure Virtual Network. This provides secure network isolation and allows container groups to communicate securely with other resources in the VNet or peered networks. To enable this VNet integration, the subnet intended for ACI deployment must have a delegation configured for Microsoft.ContainerInstance/containerGroups.
Subnet delegation is a feature that allows a specific Azure service to have explicit permissions to create service-specific resources in that subnet. When a subnet is delegated to ACI, ACI gets the necessary permissions to manage the lifecycle of network interfaces and related resources within that subnet for the container groups it deploys.
When you create an ACI container group within a delegated subnet, Azure performs several actions:
1. It reserves IP addresses from the subnet’s address space for the container group’s network interface.
2. It creates a service association link within the subnet, establishing the connection to the ACI service.
3. It provisions underlying network resources, most notably a Network Profile (Microsoft.Network/networkProfiles). This network profile acts as a template or configuration for the network interfaces created for container groups deployed in this subnet. It contains details like the subnet reference.
These underlying network profiles and the associated service association links are persistent resources within your resource group. While deleting the ACI container group itself will release the IP addresses and remove the primary ACI resource, it might not automatically clean up the associated network profile, especially if the deletion process was interrupted or encountered an issue. If the network profile remains, it still holds a reference to the subnet, preventing subnet deletion.
Troubleshooting Steps to Resolve Deletion Issues¶
Resolving this issue requires identifying and deleting the specific Azure resources that are still referencing the subnet. Since the error messages point towards ACI-related network infrastructure (network profiles), the primary steps involve clearing these dependencies.
Here’s a systematic approach to troubleshoot and resolve VNet subnet deletion issues with ACI dependencies:
Step 1: Identify Dependent ACI Container Groups (If Any)¶
Even though the error messages point to network profiles, it’s best practice to ensure no active ACI container groups are still running in the subnet. While deleting container groups should ideally lead to the cleanup of associated network resources, verifying their absence is a crucial first step.
You can list ACI container groups within a specific resource group using the Azure CLI or Azure PowerShell.
Using Azure CLI:
az container list --resource-group <resource-group-name> --output table
Review the output to see if any container groups are listed in the resource group containing the VNet. If you have many resource groups or are unsure, you might need to list across your subscription or target specific resource groups known to host ACI.
If container groups exist, you can inspect their details to find which VNet/subnet they are using:
az container show --resource-group <resource-group-name> --name <container-group-name> --query properties.ipAddress.subnet.id --output tsv
Replace <resource-group-name> and <container-group-name> with your values. This command will output the full resource ID of the subnet used by that container group. Compare this ID to the subnet you are trying to delete.
Using Azure PowerShell:
Get-AzContainerGroup -ResourceGroupName <resource-group-name> | Format-Table Name, ProvisioningState, @{Name="SubnetId";Expression={$_.IpAddress.Subnet.Id}}
Again, replace <resource-group-name>. Check the output for container groups referencing the subnet you want to delete.
Step 2: Delete Dependent ACI Container Groups¶
If you identified any container groups residing in the problematic subnet, the next step is to delete them. Deleting the container group is the standard way to release the IP addresses and initiate the cleanup of associated ACI network resources.
Using Azure CLI:
az container delete --resource-group <resource-group-name> --name <container-group-name> --yes
Repeat this command for every container group found in Step 1 that uses the subnet.
Using Azure PowerShell:
Remove-AzContainerGroup -ResourceGroupName <resource-group-name> -Name <container-group-name> -Force
Repeat for all relevant container groups.
Wait for the deletion operation to complete for all container groups. You can check their status using the list commands from Step 1.
Step 3: Identify and Delete Associated Network Profiles¶
This is often the most critical step, as network profiles created by ACI might persist even after container groups are deleted. The error message specifically mentions Microsoft.Network/networkProfiles, confirming these are likely the blocking resources.
Network profiles are resource type Microsoft.Network/networkProfiles. They reside within a resource group, often the same resource group as the VNet or the container groups.
Using Azure CLI:
To list network profiles in a resource group:
az network profile list --resource-group <resource-group-name> --output table
Examine the output. Look for network profiles whose names might resemble aci-network-profile-.... To confirm if a specific network profile is linked to your VNet/subnet, you can show its details:
az network profile show --resource-group <resource-group-name> --name <network-profile-name> --query properties.containerNetworkInterfaceConfigurations[].properties.ipConfigurations[].properties.subnet.id --output tsv
Replace <resource-group-name> and <network-profile-name>. This command attempts to extract the subnet ID referenced within the network profile’s configuration. If the output matches the ID of the subnet you’re trying to delete, this network profile is a blocker.
Once you have identified the network profile(s) linked to your subnet, delete them:
az network profile delete --resource-group <resource-group-name> --name <network-profile-name> --yes
Repeat for all identified blocking network profiles.
Using Azure PowerShell:
To list network profiles:
Get-AzNetworkProfile -ResourceGroupName <resource-group-name> | Format-Table Name, Location, Id
To inspect a specific network profile for its subnet reference:
Get-AzNetworkProfile -ResourceGroupName <resource-group-name> -Name <network-profile-name> | Select-Object -ExpandProperty ContainerNetworkInterfaceConfigurations | Select-Object -ExpandProperty IpConfigurations | Select-Object -ExpandProperty Subnet | Select-Object Id
If the output matches the subnet ID, delete the network profile:
Remove-AzNetworkProfile -ResourceGroupName <resource-group-name> -Name <network-profile-name> -Force
Repeat for all identified blocking network profiles.
Give Azure some time for the deletion operations to propagate.
Step 4: Verify Subnet Delegation (Optional)¶
After deleting dependent ACI resources and associated network profiles, the service association link and implicitly the need for delegation should be gone. While not always necessary to manually remove the delegation before deleting the subnet (as the dependencies are the primary blocker), you can verify the delegation state.
If you find the subnet still has the Microsoft.ContainerInstance/containerGroups delegation and you’ve confirmed all dependent resources are gone, you can attempt to remove the delegation. However, usually, deleting the dependent resources is sufficient, and the subnet deletion will succeed without needing to remove delegation explicitly first.
To view subnet delegation:
Using Azure CLI:
az network vnet subnet show --resource-group <resource-group-name> --vnet-name <vnet-name> --name <subnet-name> --query properties.delegations
Using Azure PowerShell:
Get-AzVirtualNetwork -ResourceGroupName <resource-group-name> -Name <vnet-name> | Get-AzVirtualNetworkSubnetConfig -Name <subnet-name> | Select-Object Delegations
If you need to remove delegation (only if deletion fails after clearing resources and delegation persists):
Using Azure CLI:
You typically update the subnet configuration to remove the delegation object from the delegations array. This is a bit more complex via CLI and involves getting the current config, modifying it, and updating the subnet. A simpler approach might be the Portal or PowerShell, or ensure all dependencies are gone, which should implicitly remove the need for the service association link tied to delegation.
Using Azure PowerShell:
$vnet = Get-AzVirtualNetwork -ResourceGroupName <resource-group-name> -Name <vnet-name>
$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name <subnet-name>
$subnet.Delegations.Clear() # Or remove specific delegation from the list
Set-AzVirtualNetwork -VirtualNetwork $vnet
Be careful when modifying VNet/Subnet configurations. Ensure you only remove the ACI delegation if others exist that you need to keep.
Step 5: Attempt Subnet Deletion Again¶
Once you are confident that all ACI container groups (if any) and, crucially, the associated network profiles have been deleted, you should be able to delete the subnet successfully.
Using Azure CLI:
az network vnet subnet delete --resource-group <resource-group-name> --vnet-name <vnet-name> --name <subnet-name>
Using Azure PowerShell:
Remove-AzVirtualNetworkSubnetConfig -Name <subnet-name> -VirtualNetwork <virtual-network-object>
Set-AzVirtualNetwork -VirtualNetwork <virtual-network-object>
(Note: Deleting a subnet config via PowerShell requires getting the VNet object first, removing the subnet config from it, and then updating the VNet.)
If the subnet deletion still fails, double-check that all potential network profiles or other dependent resources have been removed. Sometimes, there might be a slight delay in resource cleanup or reporting.
Visualizing Dependencies¶
Understanding the relationship between these resources can be helpful. The dependency chain typically looks like this:
mermaid
graph LR
A[Virtual Network] --> B[Subnet];
B --> C{ACI Delegation};
C --> D[ACI Container Group];
C --> E[Network Profile];
D --> E;
E --> B;
The key dependency blocking subnet deletion is the link from the Network Profile back to the Subnet. Although the ACI Container Group depends on the Network Profile and indirectly the subnet, deleting the container group doesn’t always break the Network Profile -> Subnet link reliably, which is why deleting the network profile is often necessary.
Preventing Future Issues¶
To minimize encountering this issue in the future, consider the following practices:
- Order of Deletion: When decommissioning ACI resources deployed in a VNet, always delete the ACI container groups first. Then, verify and delete any associated network profiles before attempting to delete the subnet or VNet.
- Resource Group Deletion: If the VNet, subnet, ACI container groups, and associated network profiles are all contained within a dedicated resource group, deleting the entire resource group is often the cleanest way to ensure all dependencies are removed together. Azure manages the deletion order internally for resource groups. However, be cautious with this approach, as it permanently deletes all resources within the group.
- Automation: If deploying and tearing down ACI resources and networks frequently, use automation (like ARM templates, Bicep, Terraform, or scripts) that explicitly includes steps to delete container groups and network profiles before deleting the subnet.
Conclusion¶
Troubleshooting VNet subnet deletion errors with Azure Container Instances dependencies primarily involves identifying and removing the underlying network profiles that ACI creates and links to the subnet. By systematically checking for and deleting active container groups and, more importantly, the persistent network profiles (Microsoft.Network/networkProfiles), you can clear the dependencies and successfully delete the subnet. Understanding the role of subnet delegation and the lifecycle of associated network resources is key to resolving these issues efficiently.
Have you encountered similar issues with ACI and VNet deletion? Do you have other troubleshooting tips or experiences to share? Please leave a comment below!
Post a Comment