Azure Cloud Shell private VNet: orphaned ACI acisal stuck Deleting / SubnetInUse after session close

福井 健太 Hi & thx for join me at Q&A platform,

I think ur approach is correct here, especially the decision not to force-remove acisal while the referenced ACI container group is outside ur subscription. That ownership boundary is the key detail in this case.

The combination of an empty delegated subnet, no customer-visible container groups, and a service association link stuck in Deleting suggests that the Cloud Shell / ACI cleanup process hasn't fully reconciled its networking state. However, zero IP configurations and an ended Cloud Shell session don't conclusively prove that the Microsoft-managed container group has been released.

The SubnetInUse error is particularly useful because it identifies an ACI container group in a Microsoft-managed subscription. That means normal customer-side resource enumeration won't be enough to establish whether the dependency still exists. I'd expect Microsoft to verify the container group's lifecycle state and its subnet association from the service side.

There isn't a supported customer-facing command I'm aware of that can inspect or release an ACI container group owned by Microsoft's subscription. You can continue collecting read-only subnet and SAL state through Azure Resource Manager, but the authoritative confirmation needs to come from the service that owns the container group.

I'd open a technical support case involving Azure Cloud Shell, Azure Container Instances, and Azure Networking. Ask the engineer to identify the service-managed container group referenced by SubnetInUse, confirm whether its deletion has completed, and investigate why the associated acisal remains in Deleting.

If the container group is already gone, Microsoft should determine whether the remaining SAL is an orphaned networking reference that can be safely reconciled. If the container group still exists, the owning service team should complete its cleanup first. Either way, I'd want explicit confirmation before anyone removes the association or changes the subnet delegation.

It's also important to keep the recovery scope limited to the temporary Cloud Shell subnet and its service-managed dependency. There's no reason to delete or recreate the parent VNet, modify unrelated subnets, or disrupt the production workloads attached to it.

Regarding support, an Azure Developer support plan can generally be used to open technical cases, subject to the subscription's support entitlement. A community forum post alone doesn't guarantee private engineering escalation, tho. If u have access to an Azure support case, that's the right place to provide the resource IDs, failed operation details, and correlation IDs securely.

On the billing question, an empty subnet and a standard Network Security Group don't normally generate standalone hourly charges. Azure VNets, subnets, and NSGs themselves are generally free. Charges can still come from associated billable services, such as diagnostic log ingestion, traffic-processing services, or other networking resources. If the Relay, private endpoint, storage, and related billable resources have genuinely been removed, the remaining subnet and NSG shouldn't create ongoing infrastructure charges by themselves.

For validation after Microsoft completes the cleanup, I'd check that the service-managed ACI dependency is confirmed released, the SAL no longer appears, and the temporary subnet can be deleted normally. I'd also verify that the parent VNet and its unrelated subnets remain unchanged.

I wouldn't use another DELETE attempt or direct SAL removal as a test of whether the container group is gone. The safest sequence is service-side ownership verification, dependency reconciliation, and only then normal subnet deletion.

One question: does the SubnetInUse error consistently reference the same Microsoft-managed container group resource ID? If it does, that should give the ACI / Cloud Shell engineering team a specific dependency to trace rather than investigating the entire VNet.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

This is most likely a backend cleanup issue, not a customer configuration problem. The supported path is a Microsoft Azure Support escalation for orphaned Cloud Shell ACI/SAL cleanup.

Recommendation:

• Do not force-remove the SAL or change subnet delegation.
• Open a Microsoft Azure Support ticket (technical/support request).
• Provide:
  • Subscription ID
  • VNet/Subnet resource IDs
  • SAL name (acisal)
  • Correlation/activity log IDs
  • Timestamp when Cloud Shell session ended

Ask support to verify and clean up the orphaned service-managed ACI/SAL from the Microsoft-managed backend subscription.