Cloud Shell in a private VNet: deploy it, tear it down, free a stuck subnet

Putting Azure Cloud Shell in a private virtual network takes two templates and half an hour. Taking it out can take a day, and in the wrong order it leaves a VNet in Failed state that refuses every delete and every update.

I hit this while answering a Microsoft Q&A question from someone whose Cloud Shell VNet could not be deleted. Instead of guessing, I built the setup in a clean subscription, broke it on purpose, and logged every step.

In short: when Cloud Shell runs in your VNet, Azure Container Instances puts a service association link called acisal on the container subnet. It points to a container group in a Microsoft-owned subscription that you cannot see or delete. Closing the session and resetting Cloud Shell does not release it at once. In the lab it was released within about 27 hours, and after that the subnet and the resource group deleted cleanly.

Why

Cloud Shell in your VNet reaches what the normal Cloud Shell cannot: VMs without public IPs, storage and databases behind private endpoints, anything that only answers on a private address. You get it without a jump box.

What the documentation leaves out is the way back. The subnet keeps a link to a resource you do not own, and until Cloud Shell lets go of it, nothing on your side can remove the subnet. Knowing that before you start saves a stuck VNet and a support ticket.

Before you start

• Owner on a subscription, and the Azure CLI signed in to it (GOV-02).
• An empty VNet in the same region and resource group as everything else. The templates create the subnets.
• The helper scripts are in cloudtales-gr/azure-recipes: prepare.ps1, sal.ps1, remove-sal.ps1 and cleanup.ps1. The deploy itself is Microsoft’s two quickstart templates, in the portal.

What ends up where:

The container group that actually runs your shell is in a Microsoft-managed subscription. The only trace of it on your side is the acisal link on the subnet.

Steps

az provider register -n Microsoft.CloudShell
az provider register -n Microsoft.ContainerInstance
az provider register -n Microsoft.Relay

az group create -n rg-cs-vnet-lab -l northeurope
az network vnet create -g rg-cs-vnet-lab -n vnet-cs-lab -l northeurope --address-prefixes 10.0.0.0/16

az ad sp list --display-name "Azure Container Instance" --query "[].id" -o tsv

az network vnet subnet list -g rg-cs-vnet-lab --vnet-name vnet-cs-lab `
  --query "[].{name:name, state:provisioningState, delegation:delegations[0].serviceName, sal:serviceAssociationLinks[].name}" -o json

{ "name": "cloudshellsubnet", "state": "Succeeded",
  "delegation": "Microsoft.ContainerInstance/containerGroups", "sal": null }

az rest --method get --url "https://management.azure.com/subscriptions/<sub>/resourceGroups/rg-cs-vnet-lab/providers/Microsoft.Network/virtualNetworks/vnet-cs-lab/subnets/cloudshellsubnet/serviceAssociationLinks/acisal?api-version=2024-05-01"

{
  "name": "acisal",
  "properties": {
    "allowDelete": true,
    "linkedResourceType": "Microsoft.ContainerInstance/containerGroups",
    "locations": [ "northeurope" ],
    "provisioningState": "Succeeded"
  }
}

12:44:46  acisal present: True
12:49:49  acisal present: True
...
13:20:06  acisal present: True

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

Conflict  SubnetInUse
The subnet '.../SUBNETS/CLOUDSHELLSUBNET' 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-...'

13:41:11  after-reset  acisal present: True
...
14:06:26  after-reset  acisal present: True

{ "sal": null, "state": "Succeeded" }

az group delete -n rg-cs-vnet-lab --yes
az group exists -n rg-cs-vnet-lab   # false

Verify

The whole run, in one table:

The Microsoft-side container group was released somewhere between half an hour and 27 hours after the reset. I did not test whether it is released without the reset, so I would still do it.

Clean up

In this order, and never the last step first:

1. Every user who connected Cloud Shell to the VNet: Cloud Shell > Reset user settings.
2. No Cloud Shell sessions open on the VNet.
3. pwsh ./remove-sal.ps1 reports released, and serviceAssociationLinks on the container subnet is empty.
4. Delete the VNet or the resource group.

The cost while you wait is small: the private endpoint, the storage account and the private DNS zone, well under €1 a day.

Troubleshooting

• Already stuck: VNet and subnets in Failed, SubnetInUse pointing to a cag-… container group in another subscription, and subnet updates failing with SubnetCannotGetUpdatedWhenParentVnetDeletionWasAttemptedEarlier. Reset Cloud Shell user settings for every user who used that VNet. Retry the ACI link delete once a day. When it succeeds, delete the VNet again; that clears the Failed state. A VNet and an NSG cost nothing, so there is no cost pressure while you wait.
• Still SubnetInUse after about 48 hours. The container group is not being cleaned up, and only Microsoft can remove it. On a Basic support plan, ask a Microsoft moderator on Q&A for one-time free technical support, and include the subnet resource ID, the full SubnetInUse message and the correlation ID.
• RequestDisallowedByAzure: The selected region is currently not accepting new customers. A capacity limit for your subscription in that region, not a Cloud Shell problem. Use another supported region.
• state_mismatch on Deploy to Azure. Several tenants signed in. Use a private window with one account.
• The session says it is ephemeral. Cloud Shell kept your old settings. Reset user settings and set up the VNet again.

Going further

NET-03 puts a storage account behind a private endpoint, the kind of resource this Cloud Shell can reach and the normal one cannot. NET-04 does the same job for VMs with Azure Bastion. Microsoft’s own pages: Deploy Cloud Shell in a virtual network with quickstart templates and Cloud Shell in a virtual network.