Orphaned Service Association Links in Vnets

Question

Orphaned Service Association Links in Vnets

Kruti Joshi 20 Microsoft Employee

There are some RGs which we are unable to delete due to orphaned service association links in the subnets.

There is a workaround present here - https://learn.microsoft.com/en-us/answers/questions/140197/unable-to-delete-vnet-due-to-serviceassociationlin. However, we are unable to use this because creating a new service plan in the region 'EastUS2EUAP' is throwing an error - "Subscription is not allowed for this region".

Need help to delete the orphaned app service plan link.

0 comments

Answer accepted by question author

TP 163.4K Volunteer Moderator

Hi,

Please run command similar to below in Azure Cloud Shell (Bash mode) to purge unused Service Association Link (SAL). Substitute SubscriptionId, Location, SubnetId. Subnet Id can be found by navigating to your subnet in portal and clicking the Copy icon next to Subnet ID

az rest --method POST \
     --uri "/subscriptions/<SubscriptionId>/providers/Microsoft.Web/locations/<Location>/purgeUnusedVirtualNetworkIntegration?api-version=2024-04-01" \
     --body "{'subnetResourceId': '<SubnetId>'}"

You should see output similar to below:

User's image

Once you have completed the above, try the delete again.

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

0 comments

1 additional answer

Your answer

Answer 1

Hi @Kruti Joshi ,

When subnet deletion fails due to orphaned Service Association Links (SALs), it usually means the SAL still exists in the subnet even though the originally associated service plan/resource is gone. That stale backend association can block deletion/update operations (often with allowDelete: false behavior).

Here’s the supported path you can try to remove the orphaned link.

Identify the SAL(s) blocking the subnet

Since the recreate-ASP workaround is blocked in EastUS2EUAP, First confirm what the SAL actually is (the fix depends on linkedResourceType), run below command to list SALs on the impacted subnet:


az network vnet subnet show \

  --resource-group <resource-group> \

  --vnet-name <vnet-name> \

  --name <subnet-name> \

  --query serviceAssociationLinks[].{link:link, linkedResourceType:linkedResourceType} \

  --output table

If you suspect other orphaned SALs are present, also enumerate them via resource listing:


az resource list --resource-type Microsoft.Network/virtualNetworks/subnets

Delete the orphaned SAL directly (if it’s deletable)

If you find the specific SAL name that’s orphaned, attempt to delete it using Azure CLI:


az resource delete \

  --ids /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>/serviceAssociationLinks/<SAL-name> \

  --api-version 2018-10-01

If linkedResourceType = Microsoft.Web (App Service/Functions), run the purge, then delete:

az rest --method POST \
  --uri "/subscriptions/<sub>/providers/Microsoft.Web/locations/eastus2euap/purgeUnusedVirtualNetworkIntegration?api-version=2024-04-01" \
  --body "{'subnetResourceId': '<subnet-resource-id>'}"
az network vnet subnet delete -g <rg> --vnet-name <vnet> --name <subnet>

Verify the SAL is gone by re-running the show from step 1.

Also clear any Delete lock on the VNet/subnet first a lock can block the platform's own cleanup and reproduce InUseSubnetCannotBeDeleted.

If purge returns "Purged" but the SAL persists (common when the link is not Microsoft.Web), that's expected the purge API only covers App Service. At that point the link has allowDelete:false with no owning resource, provide the requested details and we will try to delete it from backend.

If the SAL represents an active dependency

Sometimes the SAL is not actually orphaned it can still reflect a live dependency (like private endpoints, container instances, etc.). In that case, you need to remove the actual dependency rather than the SAL.

To check what delegations/SALs look like on the subnet:


az network vnet subnet show \

  --resource-group <resource-group> \

  --vnet-name <vnet-name> \

  --name <subnet-name> \

  --query {delegations:delegations[].serviceName, serviceAssociationLinks:serviceAssociationLinks[].linkedResourceType} \

  --output json

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.