Unable to remove vnet with serviceAssociationLinks

Patrick Nick 0 Reputation points
2025-05-19T06:42:11.3133333+00:00

I've deployed a VNET with multiple subnets through Terraform alongside a GitHub.Network/networkSettings resource. One of the subnets is delegated to this resource. (I followed https://docs.github.com/en/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization for all this.)

However, upon destroying these resources, Azure blocks the deletion of the VNET because the delegated subnet is still assigned with the serviceAssociationLink (error InUseSubnetCannotBeDeleted). The GitHub.Network/networkSettings resource was successfully removed, leaving the subnet in a bad state. I tried a few things already (unsuccessfully):

  • deleting the resource group
  • removing the subnet delegation via CLI -> (error: SubnetMissingRequiredDelegation)
  • removing the subnet SAL via CLI -> no effect, as expected
  • re-adding the GH resource -> (error: SubnetInUse)

I found this question, but there is no helpful answer. I don't have a support subscription at the moment.

Is there a way to get out of this situation? Also, how can I avoid it in future?

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,775 questions
{count} votes

1 answer

Sort by: Most helpful
  1. G Sree Vidya 2,360 Reputation points Microsoft External Staff Moderator
    2025-05-19T07:41:19.92+00:00

    Hi Patrick Nick

    Thank you for sharing the details of the issue you're facing with the VNET deletion and the lingering Service Association Link (SAL).

    It seems you've already tried several approaches without success. Based on similar cases, here are a few additional workarounds that may help resolve the issue:

    1.Recreate the GitHub Resource in a New Subnet:

    • Create a new subnet in the same VNET.
    • Recreate the GitHub.Network/networkSettings resource and delegate it to the new subnet.
    • Once it's active, try to reassign the original subnet to it, then disconnect it properly.

    2. To delete this SAL from your end,

    • Create App Service Plan with the same name as the deleted one
    • Create App Service with the same name as the deleted one
    • Link App Service with the VNET subnet
    • Disconnect VNet from App Service -> Networking -> VNet integration -> Disconnect
    • Delete subnet
    • Then delete the App Service.
    1. Delete network profiles: if there are any lingering network profiles tied to your subnet, you need to delete them. Use the Azure CLI with the command:
    2.    az network profile delete --resource-group <resource-group-name> --name <network-profile-name>
      
      Replace <resource-group-name> and <network-profile-name> with your actual resource group and network profile names.
    3. Delete the Service Association Link: If the previous steps don’t work, you can attempt to delete the Service Association Link using the Azure CLI. Here's the command:
    az resource delete --ids /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default --api-version 2018-10-01
    

    Make sure to replace the placeholders with your actual subscription ID, resource group, VNET name, and subnet name.

    Reason for this Error: The VNET integration feature must set locks on subnets in the Network Resource Provider, we set these locks by putting a structure called a Service Association Link(SAL) onto the Subnet,

    Is there a way to get out of this situation? Also, how can I avoid it in future?

    In your Terraform configuration, ensure the subnet delegation is removed before destroying the subnet.- Always disconnect the subnet from the service before deleting the service.


    I hope the above steps help, if you need any suggestions from GitHub try to contact the GitHub support team for the assistance.


Your answer

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