**Title:** Orphaned AzureKubernetesService serviceAssociationLink blocking subnet and VNet deletion after AKS cluster is gone

Abdul Hameed A 0 Reputation points
2026-04-05T07:10:16.1966667+00:00

@AzureSupport Hi, I have an orphaned serviceAssociationLink on a subnet that is blocking deletion of the subnet, VNet, and resource group. The AKS cluster no longer exists but the SAL remains with "allowDelete": false — making it impossible to remove through any client-side tooling.

Subscription: ********

Resource Group: rg-test-dev-networking

VNet: vnet-test-dev

Subnet: snet-aks-pods

SAL: .../serviceAssociationLinks/AzureKubernetesService

What I have tried:

❌ az network vnet subnet delete → InUseSubnetCannotBeDeleted

❌ az rest DELETE on the SAL → UnauthorizedClientApplication

❌ PowerShell ServiceAssociationLinks.Clear() → SubnetMissingRequiredDelegation

❌ az group delete → same block

❌ --force-deletion-types → did not help

❌ az resource delete --ids on SAL → failed

SAL JSON confirms: "allowDelete": false with no backing resource — classic orphaned platform state. Need backend cleanup. Can you please help?

Azure Kubernetes Service
Azure Kubernetes Service

An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.


2 answers

Sort by: Newest
  1. Nikhil Duserla 9,950 Reputation points Microsoft External Staff Moderator
    2026-04-23T16:25:36.2166667+00:00

    Hello @Abdul Hameed A, sorry you’re stuck with that orphaned AKS serviceAssociationLink (SAL) blocking your subnet/VNet deletion. This is a known platform-state issue where the SAL’s "allowDelete": false prevents any client-side removal. Here’s what you can try next:

    1. Purge the orphaned SAL via Azure CLI Run the following (make sure you’re Owner on the subscription and no resource lock exists):
      
         az resource delete \
      
           --ids /subscriptions/<subID>/resourceGroups/rg-test-dev-networking/providers/Microsoft.Network/virtualNetworks/vnet-test-dev/subnets/snet-aks-pods/providers/Microsoft.Network/serviceAssociationLinks/AzureKubernetesService \
      
           --api-version 2020-11-01
      
      
      • If it succeeds, wait 10–15 minutes for the platform to finish cleanup, then retry deleting the subnet/VNet. • If you still get “UnauthorizedClientApplication”, double-check your login context (e.g. run az account show) and that you’re using the Microsoft.Network provider.
    2. Workaround: Re-create + delete an AKS cluster Sometimes you can “attach” a fresh AKS cluster to the same vnet/subnet and then delete it normally, which cleans up the SAL: a. az aks create --name tempCluster --resource-group rg-test-dev-networking --vnet-subnet-id /subscriptions/<sub>/…/snet-aks-pods --disable-rbac --generate-ssh-keys b. az aks delete --name tempCluster --resource-group rg-test-dev-networking --yes --no-wait Then retry deleting the subnet/VNet.
    3. Last resort: Backend support removal Because allowDelete=false is controlled server-side, if the CLI purge doesn’t work and you can’t re-create an AKS cluster, you’ll need to file a free support request so the SAL can be manually purged on the backend.

    — Reference Documentation —

    • Troubleshoot orphaned SALs (including sample az resource delete):

    https://learn.microsoft.com/troubleshoot/azure/virtual-network/virtual-network-troubleshoot-cannot-delete-modify-subnet

    • Subnet deletion blocked by orphaned App Service SAL (similar cleanup steps):

    https://learn.microsoft.com/answers/a/12572408

    Let me know:

    • Did the az resource delete … --api-version 2020-11-01 call work or still error?

    • Are there any resource locks on your subnet/VNet?

    • Do you have Owner rights in that subscription?

    With that info we can decide if a backend purge request is needed.

    Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-04-05T07:10:29.5566667+00:00

    The subnet and VNet are blocked because the AzureKubernetesService serviceAssociationLink (SAL) is still present and marked with allowDelete: false. This is an orphaned platform-side link similar to the App Service and ACI cases and cannot be removed purely from the client side once it is in this state.

    From the available guidance, the only supported resolutions for orphaned SALs are:

    1. Identify the blocking serviceAssociationLink
      • Use Azure CLI to confirm the SAL on the subnet:
             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
        
      • This will show the AzureKubernetesService SAL that is blocking deletion.
    2. Confirm there are no remaining resources using the subnet
      • Run the diagnostic-style query to ensure no NICs, private endpoints, or delegations are still present:
             az network vnet subnet show \
               --resource-group rg-test-dev-networking \
               --vnet-name vnet-test-dev \
               --name snet-aks-pods \
               --query "{delegations:delegations, serviceEndpoints:serviceEndpoints, ipConfigurations:ipConfigurations, privateEndpoints:privateEndpoints, serviceAssociationLinks:serviceAssociationLinks}"
        
      • If ipConfigurations or privateEndpoints contain values, those resources must be removed first. If only the SAL remains, the issue is an orphaned SAL.
    3. Handle orphaned SALs
      • For ACI and App Service, the documented pattern is to:
        • Explicitly delete the subnet first to avoid cascading delete confusion.
        • Then delete the SAL object directly with az resource delete or az rest using the SAL resource ID.
      • In the AKS scenario described in the context, when the error message references serviceAssociationLinks/AppServiceLink or similar, the guidance is to remove the external service resources and then delete the subnet. However, when the SAL is orphaned and allowDelete is false, platform-side cleanup is required.
    4. When client-side deletion of the SAL fails
      • The behavior described (UnauthorizedClientApplication, SubnetMissingRequiredDelegation, allowDelete: false) matches an orphaned platform state that cannot be fixed from the subscription using normal tools.
      • In this state, the only path forward is a backend purge of the orphaned SAL by Microsoft Support. This is consistent with the guidance for similar orphaned SAL issues (for example, App Service VNet integration and ACI network profiles) where a backend cleanup is required when direct deletion is blocked.
    5. Recommended next step
      • Open an Azure support request for the subscription and reference:
        • The full resource ID of the SAL: .../virtualNetworks/vnet-test-dev/subnets/snet-aks-pods/providers/Microsoft.ContainerService/serviceAssociationLinks/AzureKubernetesService (or the exact ID from the CLI output).
        • The error codes seen when attempting deletion: InUseSubnetCannotBeDeleted, UnauthorizedClientApplication, SubnetMissingRequiredDelegation.
        • That allowDelete is false and the AKS cluster and any associated resources are already deleted.
      • Ask support to perform a backend purge of the orphaned AzureKubernetesService serviceAssociationLink so that the subnet, VNet, and resource group can be deleted.

    Once the SAL is removed by support and any remaining NICs or private endpoints are confirmed deleted, subnet and VNet deletion should succeed.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.