Cannot delete VNets from my resource groups

Question

I have 3 resource groups that each contain only a VNet and NSGs. All other resources were already deleted. I cannot delete the VNets, subnets, or resource groups because of orphaned serviceAssociationLinks (legionservicelink).

Each VNet has a subnet with delegation Microsoft.App/environments and an orphaned legionservicelink that blocks deletion.

Please help to delete the vnets or to delete my resource groups.

Answer 1

Hi @Busra Basbahcivan

Thank you for sharing the requested details via the Teams message. This required intervention from the development team, following which the orphaned Service Area Link (SAL) was removed from the system. As discussed offline and confirmed, the issue has been successfully resolved by removing the SAL link and deleting the three resource groups, which was validated by the customer.

If the answer is helpful,  Please do click "Accept the answer” and Yes, this can be beneficial to other community members.

If you have any other questions, let me know in the "comments" and I would be happy to help you

Answer 2

Resource groups cannot be deleted directly here. However, the blocking orphaned serviceAssociationLinks can be diagnosed and remediated so that deletion succeeds in the portal, CLI, or ARM.

For VNets and subnets blocked by an orphaned legionservicelink with delegation Microsoft.App/environments, use this approach:

1. Identify all blocking configurations on the subnet
   • Run the diagnostic az network vnet subnet show command (from the article) against each delegated subnet to see delegations, service association links, and IP configurations:

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

   • In the output, review:
     • delegations (should show Microsoft.App/environments)
     • serviceAssociationLinks (will show the legionservicelink that is blocking deletion)
     • ipConfigurations and privateEndpoints (must be empty before deletion)
2. Ensure no active resources still use the delegated subnet
   • A subnet delegated to Microsoft.App/environments cannot be deleted until all resources that use that delegation are removed.
   • Follow the documented pattern for delegated subnets:
     • Delete all Azure service resources that were deployed into this subnet (for Microsoft.App/environments, remove the corresponding Azure Container Apps / App Service Environment–style resources that used this subnet).
   • After all such resources are removed, the subnet should only have the delegation and the serviceAssociationLink remaining.
3. Remove the subnet delegation
   • Once the service resources are gone, remove the delegation from the subnet using the documented CLI pattern:

          az network vnet subnet update \
              --resource-group <resource-group> \
              --vnet-name <vnet-name> \
              --name <subnet-name> \
              --remove delegations
     

   • Verify that delegations is now empty:

          az network vnet subnet show \
              --resource-group <resource-group> \
              --vnet-name <vnet-name> \
              --name <subnet-name> \
              --query delegations
     

     Expected output:

          []
     

4. Handle the orphaned serviceAssociationLink (legionservicelink)
   • serviceAssociationLinks are created by Azure services (for example, App Service, Container Apps, SQL Managed Instance) when they deploy into a subnet and can remain after resources are deleted.
   • If the legionservicelink persists after the backing service resources and delegation are removed, this is the same class of problem as other orphaned serviceAssociationLinks (for example, the App Service case in the context). The documented remediation pattern is:
     1. Attempt to purge the unused virtual network integration / association for that service using the service’s purge/cleanup CLI or API (for App Service this is a purge command; for Microsoft.App/environments the equivalent purge/cleanup operation must be used).
     2. If purge is not available or does not clear the serviceAssociationLink, re-create the service resource that owns the link (for example, re-create the environment or integration using the same name and subnet), then cleanly disconnect/remove the VNet integration from that service, and finally delete the service resource again.
   • If the serviceAssociationLink still cannot be removed and continues to block subnet deletion, open an Azure support request and reference the linkedResourceType from the serviceAssociationLinks output so support can remove the orphaned link from the backend.
5. Confirm no other blockers exist on the subnet
   • Use the same az network vnet subnet show diagnostic to ensure:
     • ipConfigurations is empty (no NICs, load balancers, or other IP configs in the subnet).
     • privateEndpoints is empty.
     • serviceEndpoints and delegations are either removed or no longer associated with active resources.
   • If orphaned NICs are present, delete them using:

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

6. Delete the subnet, VNet, and resource group
   • After delegations, serviceAssociationLinks, NICs, private endpoints, and other dependencies are cleared:
     1. Delete the subnet(s).
     2. Delete the VNet.
     3. Delete the resource group.

If the legionservicelink remains even after following the above steps, support intervention is required. In that case, open an Azure support request and provide:

• Resource group name
• VNet name
• Subnet name
• The serviceAssociationLinks output (including linkedResourceType and link values) so that the backend orphaned link can be removed.

---

References:

• Troubleshoot failure to delete or modify a virtual network or subnet in Azure
• Troubleshoot subnet deletion and modification failures in Azure Virtual Network
• Add or remove subnet delegation in Azure virtual network
• Subnet deletion blocked by orphaned App Service serviceAssociationLink - Microsoft Q&A