How to delete an orphaned service association link

Hi @Chris Jarrett

Thank you for sharing the requested details by private message. This requires intervention from the development team, and we have already removed the orphaned service area link from the system. You can now proceed with the deletion.

Don't forget to click "Accept Answer". This can be helpful for other members of the community.

If you have any other questions, please let me know in the comments and I will gladly help you.

The subnet is blocked by a lingering service association link (SAL) from the deleted Managed DevOps Pool. The SAL must be removed before the subnet can be deleted.

Use these steps:

1. Identify the blocking service association link
   • Run the diagnostic subnet show to list service association links:

      az network vnet subnet show \
          --resource-group <resource-group> \
          --vnet-name <vnet-name> \
          --name <subnet-name> \
          --query "serviceAssociationLinks[].{link:link, linkedResourceType:linkedResourceType}" \
          --output table
   

   • Confirm that the linkedResourceType corresponds to the Managed DevOps Pools integration (a service that injected agents into the subnet).
2. Ensure no resource locks are blocking cleanup
   • If a Delete lock exists on the virtual network or subnet, remove it temporarily. A Delete lock prevents the platform (and Managed DevOps Pools) from cleaning up the SAL and can lead to InUseSubnetCannotBeDeleted and a “subnet in locked state” scenario.
   • After removing the lock, retry any pending pool update/cleanup if applicable. If the pool is already deleted, proceed to step 3.
3. Explicitly delete the service association link resource
   • SALs are exposed as child resources of the subnet. Use az resource delete with the SAL resource ID. The pattern (from similar ACI/App Service scenarios) is:

      az resource delete --ids \
        /subscriptions/<subscription-id>/resourceGroups/<resource-group>\
        /providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>\
        /providers/Microsoft.ContainerInstance/serviceAssociationLinks/default \
        --api-version 2018-10-01
   

   • For Managed DevOps Pools, adjust the provider segment to match the linkedResourceType returned in step 1 (for example, replace Microsoft.ContainerInstance with the provider used by Managed DevOps Pools). The key is to delete the SAL resource whose link and linkedResourceType you discovered.
4. Verify that all other blockers are removed Before deleting the subnet, confirm there are no other blockers:
   • Private endpoints:

          az network vnet subnet show \
              --resource-group <resource-group> \
              --vnet-name <vnet-name> \
              --name <subnet-name> \
              --query "privateEndpoints[].id" \
              --output tsv
     

     Delete any listed private endpoints.
   • Orphaned NICs:

          az network vnet subnet show \
              --resource-group <resource-group> \
              --vnet-name <vnet-name> \
              --name <subnet-name> \
              --query "ipConfigurations[].id" \
              --output tsv
     

     Extract NIC names from the IDs and delete them:

          az network nic delete \
              --resource-group <resource-group> \
              --name <nic-name>
     

   • Delegations and service endpoints, if present, can be removed with az network vnet subnet update after dependent resources are cleaned up.
5. Delete the subnet
   • Once the SAL and other blockers are removed, delete the subnet from the portal or via CLI:

      az network vnet subnet delete \
          --resource-group <resource-group> \
          --vnet-name <vnet-name> \
          --name <subnet-name>
   

If the SAL still persists after these steps and no locks remain, the remaining option is to open an Azure support request (even for technical issues tied to platform cleanup) and reference the linkedResourceType and SAL link values from step 1.

References:

• Troubleshoot failure to delete or modify a virtual network or subnet in Azure
• Failed to delete a virtual network or subnet used by Azure Container Instances
• Configure Managed DevOps Pools networking
• Subnet deletion blocked by orphaned App Service serviceAssociationLink - Microsoft Q&A