Azure Orphans: Deallocated VM Leftovers, Disks, Vaults, Logs
Deallocating a VM ends its compute bill. What it leaves attached, and what nobody attached in the first place, is what these rules find.
Azure stops charging for a VM’s compute once it is deallocated, but its managed disks and networking resources keep billing. That residual is one of three families of Azure orphans ZopNight reports; the others are storage and protection resources left behind, and network monitoring that no longer watches anything.
What a deallocated VM still costs
Deallocated Azure VM Residual Cost fires only on VMs in the deallocated state, since a VM that is stopped but still allocated keeps billing compute and is a different problem. It finds the VM’s managed disks and its public IP through the NIC, prices each, and reports the sum. If the residual is zero, nothing is raised. Fact sheet: Azure VMs.
Storage and protection left behind
- Unattached Azure Managed Disk skips disks that belong to Azure Site Recovery replication, which are unattached by design. With a proven detach dwell of at least seven days, it is eligible for an evidence-backed delete. See managed disks.
- Orphaned Azure Snapshot works on a per-subscription and per-region rollup of snapshots whose source disk has been deleted.
- Azure Recovery Vault Orphan fires on a vault that protects zero items. Deleting an empty vault loses no backups, so the safety gate allows it to run automatically. See Recovery Services vaults.
- Azure Key Vault Unused is a guided delete with a type-to-confirm review.
Network objects with nothing behind them
- Azure Public IP Not Associated fires on Standard SKU addresses with no association, and can be deleted automatically on that evidence. See public IPs.
- Azure NSG Not Associated with Any Resource and Azure VNet Peering Disconnected carry no dollar figure; they are hygiene deletes, both guided. The peering rule flags only the Disconnected state, not a peering still being set up.
- Azure Duplicate Flow Logging fires when a network is already recorded by an unfiltered VNet-level log, so the second log adds cost without adding coverage. It abstains when the covering log is filtered or when an NIC-level binding is in play.
- Azure Flow Log on a Gateway Subnet and Azure Connection Monitor With No Surviving Source cover monitoring that runs against nothing.
How the deletes run
Each orphan delete goes through the remediation wizard: a precondition check, an admin approval step when a non-admin starts a destructive action, the delete, then validation. The safety gate only allows an automatic delete where there is authoritative evidence, and demotes stateful resources to advisory. A tenant-scoped Azure connection discovers every subscription beneath it, so orphans across subscriptions surface in one list; deletes need read + write permission. More on orphan cleanup; related Azure categories: idle, rightsizing. Every rule: Azure recommendations.