Azure Cloud Shell Private VNet cannot be deleted — orphaned acisal references Microsoft-managed ACI

Question

Azure Cloud Shell Private VNet cannot be deleted — orphaned acisal references Microsoft-managed ACI

Gustavo 0

I am trying to decommission an Azure Cloud Shell private networking environment.

All resources have been deleted except the Virtual Network and Network Security Group.

The VNet and its subnets are in Failed provisioning state. The cloudshell-containers subnet still has a Service Association Link named acisal.

Attempting to delete the link through the Microsoft.ContainerInstance API returns SubnetInUse, referencing a container group in a different subscription (cag-westeurope-1), apparently managed by the Cloud Shell service.

No container groups remain in my subscription. Subnet updates also fail with SubnetCannotGetUpdatedWhenParentVnetDeletionWasAttemptedEarlier.

I have a Basic Azure support plan and cannot open a technical support ticket.

Could a Microsoft engineer help escalate this orphaned ACI dependency for backend cleanup, or identify a supported recovery procedure?

I can provide the resource IDs and correlation ID privately if required.

Gustavo 0 Reputation points

2026-11-05T03:03:14.21+00:00

I have confirmed that ipConfigurationProfiles is null, so there are no legacy network profiles associated with the subnet.

The ACI Service Association Link removal was already attempted using the documented extension resource path with API versions 2018-10-01 and 2026-07-01.

The latter returned SubnetInUse, referencing a container group in another Azure subscription, outside my administrative control.

The subnet remains in Failed state with the acisal association present.

Since there are no remaining container groups in my subscription, could this issue be escalated to the Azure Container Instances / Cloud Shell engineering team for backend dependency cleanup?

My Azure Basic support plan does not permit technical support requests.

1 answer

Your answer

Gustavo 0 Reputation points

2026-11-05T03:03:14.21+00:00

I have confirmed that ipConfigurationProfiles is null, so there are no legacy network profiles associated with the subnet.

The ACI Service Association Link removal was already attempted using the documented extension resource path with API versions 2018-10-01 and 2026-07-01.

The latter returned SubnetInUse, referencing a container group in another Azure subscription, outside my administrative control.

The subnet remains in Failed state with the acisal association present.

Since there are no remaining container groups in my subscription, could this issue be escalated to the Azure Container Instances / Cloud Shell engineering team for backend dependency cleanup?

My Azure Basic support plan does not permit technical support requests.

Answer 1

I reproduced this end to end in a clean lab. The link does get released, but not immediately, and not by anything you do in your subscription.

Repro (fresh subscription, North Europe, official quickstart templates)

Deployed Azure Cloud Shell – VNet and Azure Cloud Shell – VNet storage. Before connecting Cloud Shell: cloudshellsubnet delegated to Microsoft.ContainerInstance/containerGroups, no service association link.
Connected Cloud Shell to the VNet (session IP 10.0.1.x). The subnet now has acisal:

linkedResourceType : Microsoft.ContainerInstance/containerGroups
allowDelete        : true

Ran exit and closed Cloud Shell (Day 1, 12:44). Polled every 5 minutes: acisal was still present after 35 minutes.
The ACI SAL removal returned exactly your error:

DELETE .../subnets/cloudshellsubnet/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default?api-version=2018-10-01

Conflict  SubnetInUse
"...is still in use. Please delete all container groups in the subnet and try again.
One sample container group in use is
/subscriptions/<Microsoft subscription>/resourceGroups/cag-westeurope-1/providers/Microsoft.ContainerInstance/containerGroups/ae2prodamcag-1-..."

The resource group is named cag-westeurope-1 even though my VNet is in North Europe, so the name is internal to Cloud Shell and doesn't refer to your region.

Cloud Shell → Settings → Reset user settings (Day 1, 13:40). Still present after 26 more minutes. The same DELETE still returned SubnetInUse at 14:14.
Left everything untouched (Relay, storage, VNet all in place, no Cloud Shell sessions). Day 2, 16:37: the same DELETE succeeded (no error), the subnet showed serviceAssociationLinks: null and provisioningState: Succeeded, and az group delete removed the whole resource group cleanly.

So the Microsoft-side container group was cleaned up somewhere between ~30 minutes and ~27 hours after the Cloud Shell user settings were reset. I couldn't pin it down more precisely.

What to do in your case

Make sure no Cloud Shell session or user setting still points at the VNet. Open Cloud Shell → Settings → Reset user settings, then close it. Do this for every user who configured Cloud Shell on this VNet.
Retry the SAL removal now, and then once a day:

az rest --method delete --url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>/subnets/<container-subnet>/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default?api-version=2018-10-01"

No output means success. Then confirm serviceAssociationLinks is null and delete the VNet. That also clears the Failed state and SubnetCannotGetUpdatedWhenParentVnetDeletionWasAttemptedEarlier.

If it still returns SubnetInUse after ~48 hours, the container group isn't being garbage-collected. You can't delete it yourself because it lives in a Microsoft subscription. On a Basic plan, ask a Microsoft moderator in this thread for one-time free technical support, and include the subnet resource ID, the full SubnetInUse message with the container group ID, and the correlation ID.

An orphaned VNet/NSG costs nothing, so there's no cost pressure while you wait.

Recommended teardown order for anyone removing Cloud Shell VNet isolation: reset Cloud Shell user settings for all users → wait until the ACI SAL DELETE succeeds → then delete the VNet / resource group. Deleting the VNet first is what leaves it in the Failed state you're seeing.

References: Deploy Cloud Shell in a virtual network · Cloud Shell virtual network overview