Share via

Cross-Subscription Zombie References Preventing Resource Deletion - Infrastructure Cleanup Required

Petro Kashpurenko 5 Reputation points
2025-08-26T13:59:26.42+00:00

I am experiencing a critical Azure infrastructure issue where orphaned resources with cross-subscription references are preventing normal resource deletion operations. This is causing unnecessary costs and subscription clutter.

Error Details:

  • Error Code: InUseSubnetCannotBeDeleted
  • Error Message: "Subnet pixqo-aca-subnet is in use by /subscriptions/26feb678-d458-4c50-80a5-19592eeada53/resourceGroups/MC_CALMBAY-2AEAA3CC-RG_CALMBAY-2AEAA3CC_WESTEUROPE/providers/Microsoft.Network/networkInterfaces/|PROVIDERS|MICROSOFT.COMPUTE|VIRTUALMACHINESCALESETS|AKS-SYSTEMPOOL-46606260-VMSS|VIRTUALMACHINES|0|NETWORKINTERFACES|AKS-SYSTEMPOOL-46606260-VMSS/ipConfigurations/IPCONFIG1 and cannot be deleted."

Affected Resources:

  1. Virtual Network: pixqo-vnetba8b1520 (Resource Group: pixqo-rgf7b1e3c0)
  2. Load Balancer: kubernetes (Resource Group: MC_calmbay-2aeaa3cc-rg_calmbay-2aeaa3cc_westeurope)
  3. Public IP Address: calmbay-2aeaa3cc-public-ip-addr (Resource Group: MC_calmbay-2aeaa3cc-rg_calmbay-2aeaa3cc_westeurope)
  4. Network Security Group: aks-agentpool-30894442-nsg (Resource Group: mc_calmbay-2aeaa3cc-rg_calmbay-2aeaa3cc_westeurope)

Current Subscription: 31d2dbe7-1888-40a5-a5e4-8dce676b36ec

Problem Analysis:

  • The error references subscription 26feb678-d458-4c50-80a5-19592eeada53, which does not exist in my Azure tenant
  • These appear to be zombie references from a previously deleted AKS (Azure Kubernetes Service) cluster
  • Standard Azure CLI deletion commands fail due to these cross-subscription dependencies
  • The referenced VMSS (Virtual Machine Scale Set) aks-systempool-46606260-vmss does not exist

Attempted Solutions:

  • Standard resource group deletion with --no-wait
  • Individual resource deletion via Azure CLI
  • REST API deletion attempts
  • Azure Resource Graph queries confirm resources exist in current subscriptionI am experiencing a critical Azure infrastructure issue where orphaned resources with cross-subscription references are preventing normal resource deletion operations. This is causing unnecessary costs and subscription clutter. Error Details:
    • Error Code: InUseSubnetCannotBeDeleted
    • Error Message: "Subnet pixqo-aca-subnet is in use by /subscriptions/26feb678-d458-4c50-80a5-19592eeada53/resourceGroups/MC_CALMBAY-2AEAA3CC-RG_CALMBAY-2AEAA3CC_WESTEUROPE/providers/Microsoft.Network/networkInterfaces/|PROVIDERS|MICROSOFT.COMPUTE|VIRTUALMACHINESCALESETS|AKS-SYSTEMPOOL-46606260-VMSS|VIRTUALMACHINES|0|NETWORKINTERFACES|AKS-SYSTEMPOOL-46606260-VMSS/ipConfigurations/IPCONFIG1 and cannot be deleted."
    Affected Resources:
    1. Virtual Network: pixqo-vnetba8b1520 (Resource Group: pixqo-rgf7b1e3c0)
    2. Load Balancer: kubernetes (Resource Group: MC_calmbay-2aeaa3cc-rg_calmbay-2aeaa3cc_westeurope)
    3. Public IP Address: calmbay-2aeaa3cc-public-ip-addr (Resource Group: MC_calmbay-2aeaa3cc-rg_calmbay-2aeaa3cc_westeurope)
    4. Network Security Group: aks-agentpool-30894442-nsg (Resource Group: mc_calmbay-2aeaa3cc-rg_calmbay-2aeaa3cc_westeurope)
    Current Subscription: 31d2dbe7-1888-40a5-a5e4-8dce676b36ec Problem Analysis:
    • The error references subscription 26feb678-d458-4c50-80a5-19592eeada53, which does not exist in my Azure tenant
    • These appear to be zombie references from a previously deleted AKS (Azure Kubernetes Service) cluster
    • Standard Azure CLI deletion commands fail due to these cross-subscription dependencies
    • The referenced VMSS (Virtual Machine Scale Set) aks-systempool-46606260-vmss does not exist
    Attempted Solutions:
    • Standard resource group deletion with --no-wait
    • Individual resource deletion via Azure CLI
    • REST API deletion attempts
    • Azure Resource Graph queries confirm resources exist in current subscription
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.
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Petro Kashpurenko 5 Reputation points
    2025-08-27T05:52:04.0833333+00:00

    I have tried all of above except escalation, yet I have solved the issue by removing the subscription.

    While subscription becomes unavailable I could easily remove the subscription”zombies” via REST and restore the subscription.

    1 person found this answer helpful.
    0 comments
  2. Thanmayi Godithi 555 Reputation points Microsoft External Staff Moderator
    2025-08-27T00:00:58.53+00:00

    Hello @Petro Kashpurenko ,

    Thank you for reaching out on Microsoft Q&A forum.

    I understand that you are trying to clean up your Azure infrastructure, but you are blocked from deleting some resources. Specifically, when deleting a subnet (pixqo-aca-subnet), Azure throws the error InUseSubnetCannotBeDeleted, claiming the subnet is still attached to a VMSS NIC that belongs to a subscription ID that no longer exists in your tenant.

    This looks like a “zombie reference” — a leftover dependency from a previously deleted AKS cluster that is not visible anymore, but Azure still thinks exists. Because of this broken reference, the subnet, and by extension, the VNet and related resources, cannot be deleted, causing clutter and costs.

    The reference path in the error:

    /subscriptions/26feb678-d458-4c50-80a5-19592eeada53/.../aks-systempool-46606260-vmss/networkInterfaces/...

    is pointing to a subscription that does not exist in your tenant, confirming this is an orphaned dependency. This can happen when AKS clusters or VMSS resources are deleted before their network bindings are fully cleaned up, leaving behind dangling records in the control plane.

    Since you have already attempted CLI, REST API, and Resource Graph approaches without success, the issue cannot be resolved with normal deletion commands. These references exist in the Azure Resource Provider metadata, and manual intervention is required to detach them.

    Next Steps / Workarounds

    1. Force Delete Subnet via Orphaned Reference Cleanup: You can try to explicitly break the subnet reference using: 
         az network vnet subnet update \
     --name pixqo-aca-subnet \
     --resource-group pixqo-rgf7b1e3c0 \
     --vnet-name pixqo-vnetba8b1520 \
     --remove delegations
      and also attempt removing service association links (SALs) if any exist. Reference: Azure CLI - az network vnet subnet update
    2. Check for Stale NIC Associations Run: 
         az network nic list --query "[?ipConfigurations[?subnet.id=='/subscriptions/<your-sub>/resourceGroups/pixqo-rgf7b1e3c0/providers/Microsoft.Network/virtualNetworks/pixqo-vnetba8b1520/subnets/pixqo-aca-subnet']]" -o table
      This ensures no active NICs in your subscription are still mapped. If none are found, it’s indeed a ghost reference.
    3. Escalation Path (Microsoft Backend Cleanup): If the stale reference is outside your tenant or tied to a non-existent subscription, there is no way for you as a customer to break it directly. In this case, you will need to open a support request with Microsoft asking for a “backend orphaned NIC/subnet reference cleanup”. Reference: Create an Azure Support Request Microsoft support engineers have backend tools to remove these phantom references from the networking RP, after which you will be able to delete the subnet and the VNet normally.

    Summary

    • Your subnet deletion is blocked because of a stale (zombie) reference to a VMSS NIC in a non-existent subscription.
    • You’ve already tried the right CLI/API methods — this confirms the issue is at the control plane metadata level.
    • Workaround attempts: force update subnet, check NIC associations.
    • If unresolved, the only solution is to raise a Microsoft Support request to have the orphaned references cleaned up at the backend.
    • Refer: A public IP address/subnet/network security group in use cannot be deleted

    Kindly let us know if the above helps or you need further assistance on this issue.

    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

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.