Orphaned AzureKubernetesService serviceAssociationLink on subnet after AKS deletion — cannot delete subnet or VNet

The subnet is blocked by an orphaned serviceAssociationLinks/AzureKubernetesService, which is a known class of issue where a service association link (SAL) remains after the service (here, AKS) is deleted. Client-side tools (Azure CLI, PowerShell, direct az rest DELETE) generally cannot remove such orphaned SALs when the platform marks them as non-deletable (allowDelete=false) or when backend ownership is required.

Supported remediation from the available guidance is:

1. Verify that no AKS or other resources are still using the subnet
   • Use the diagnostic/inspection commands on the subnet to confirm what is present:
     • Check delegations:

              az network vnet subnet show \
                --resource-group rg-test-dev-networking \
                --vnet-name vnet-test-dev \
                --name snet-aks-pods \
                --query "delegations[].{name:name, service:serviceName}" \
                --output table
       

     • Check service association links (this will show the AzureKubernetesService SAL):

              az network vnet subnet show \
                --resource-group rg-test-dev-networking \
                --vnet-name vnet-test-dev \
                --name snet-aks-pods \
                --query "serviceAssociationLinks[].{link:link, linkedResourceType:linkedResourceType}" \
                --output table
       

     • Check for NICs/IP configurations that might also block deletion:

              az network vnet subnet show \
                --resource-group rg-test-dev-networking \
                --vnet-name vnet-test-dev \
                --name snet-aks-pods \
                --query "ipConfigurations[].id" \
                --output tsv
       

   • If any NICs or other resources are listed, delete or detach them first (for NICs: az network nic delete --resource-group <rg> --name <nic-name>), then retry subnet deletion.
2. Follow the documented SAL cleanup pattern
   • For service association links in general, the documented process is:
     1. Ensure all resources from the linked service are deleted.
     2. Wait 10–15 minutes for the platform to clean up the SALs automatically.
     3. Retry subnet deletion.
     4. If the SAL persists, open an Azure support request referencing the linkedResourceType.
   • In this case, the linkedResourceType is AzureKubernetesService (AKS). Since AKS is already deleted and the SAL is still present after client-side attempts, this falls into the “persisting SAL” scenario that requires backend intervention.
3. Engage Azure Support to remove the orphaned SAL
   • The platform documentation explicitly states that if service association links remain after resource deletion and do not clear after waiting, the next step is to open an Azure support request and reference the specific linkedResourceType.
   • Include in the support request:
     • The full SAL resource ID: /subscriptions/6aad4f09-475d-4494-94a4-b31a01f55b5d/resourceGroups/rg-test-dev-networking/providers/Microsoft.Network/virtualNetworks/vnet-test-dev/subnets/snet-aks-pods/serviceAssociationLinks/AzureKubernetesService
     • The error code and message (InUseSubnetCannotBeDeleted and the message showing the SAL).
     • Confirmation that the AKS cluster and related resources are deleted and that client-side deletion attempts for the SAL have failed.
   • Backend engineering/support can then purge the orphaned AzureKubernetesService serviceAssociationLink so that the subnet and VNet can be deleted.

This aligns with the general guidance for orphaned SALs (for example, App Service SALs) where, if purge/cleanup via CLI or re-creation is not possible or fails, the remaining resolution is a platform-side cleanup by Microsoft Support.

References:

• Troubleshoot failure to delete or modify a virtual network or subnet in Azure
• Troubleshoot subnet deletion and modification failures in Azure Virtual Network
• AKS cluster deletion fails because a public IP address, subnet, or network security group is in use
• Subnet deletion blocked by orphaned App Service serviceAssociationLink - Microsoft Q&A