Cannot remove serviceAssociationLink from subnet due to orphaned Microsoft.App/environments link

Question

We are unable to remove a serviceAssociationLink from the following subnet:

/subscriptions/34872a55-0fad-4390-a95c-711e453c160f/resourceGroups/rg-devplaton-agent2/providers/Microsoft.Network/virtualNetworks/agents-vnet/subnets/agent-subnet

This link references a Microsoft.App/environments resource that no longer exists. The linked managed environment has already been deleted, but the subnet is still showing a serviceAssociationLink named legionservicelink.

The link has the property "allowDelete": false, and prevents us from updating, deleting, or reusing the subnet. All attempts to delete or remove the link via CLI have failed.

We set up this environment using the following official sample script provided by Azure AI Foundry:

https://github.com/azure-ai-foundry/foundry-samples/tree/main/samples/microsoft/infrastructure-setup/15-private-network-standard-agent-setup

After deleting the environment, the serviceAssociationLink was not automatically cleaned up, resulting in this orphaned state.

We kindly request Microsoft support to manually remove or clean up the orphaned serviceAssociationLink from the subnet so we can reuse or delegate it properly.

Thank you.

Answer 1

Hello !

Thank you for posting on Microsoft Learn !

What I have see so far, this is a common issue in Azure where orphaned serviceAssociationLinkremain on a subnet after a Microsoft.App/environments (Azure Container Apps Environment) is deleted, especially when set up using scripts like the one from Azure AI Foundry. These links can block subnet reuse and can't be deleted due to "allowDelete": false.

The serviceAssociationLink was created by the managed environment, but the automatic cleanup failed during deletion. Azure has no current public method (via CLI/Portal) to force deletion such orphaned links if the parent resource no longer exists.

The only way to resolve the issue currently is to open a support ticket since the link has allowDelete: false, somanual removal by Microsoft backend is required.

Meanwhile as a workaround, while you get the support, ceate a new subnet in the same VNet and update your deployments to use the new subnet as this avoids the blocked subnet but is not ideal if address space is constrained.