Recovery Services vaults with zero Azure Backup protected items that still carry cost
What does ZopNight detect here?
Azure Recovery Services vaults that no longer protect anything are clean delete candidates. ZopNight flags a vault when its Azure Backup protected item count is exactly 0 and the vault still has a positive monthly cost, reporting that full cost as the saving. Site Recovery replicated items are not counted, so check them before deleting.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1392 |
| Category | orphan |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | 0 Azure Backup protected items |
| Source | ZopNight |
| Permissions used | Microsoft.RecoveryServices/Vaults/read · Microsoft.RecoveryServices/Vaults/backupProtectedItems/read |
Where it applies
What a vault bills for
Azure Backup pricing has two parts: a fee for each protected instance, sized by the data it holds, and the backup storage consumed, which is charged separately. A vault that once protected a fleet of VMs can end up with no active items after those VMs are decommissioned, while still showing a cost in the bill. Vaults created for a test or a migration are the other common source.
Checking whether a vault still protects anything
List the vaults, then count the backup items in each. An empty list across every workload type is the orphan pattern:
az backup vault list --query "[].{name:name, group:resourceGroup, location:location}" -o table
az backup item list --resource-group <rg> --vault-name <vault> -o tableaz backup item list can be narrowed with --backup-management-type (for example AzureIaasVM,
AzureWorkload, AzureStorage) if you want to check one workload at a time.
The signal behind the finding
ZopNight counts the vault’s protected items through the Azure Backup API when it scans the subscription. The rule fires when:
- That count is present and is exactly 0.
- The vault has a positive monthly cost.
There is no environment filter and no minimum cost, so an orphan vault is reported even when its bill is small. Larger vaults that are in use but worth a cost review are covered by Azure Recovery Vault Review.
Blind spots stated plainly
If the protected item count could not be read, the vault gets no finding; an error is never read as zero. The count covers Azure Backup only. It has no view of Azure Site Recovery replicated items, so a vault used purely for cross-region failover looks the same as an empty one. The finding therefore talks about Azure Backup protected items specifically, and the fix steps below include a Site Recovery check. Microsoft’s deletion flow has you remove Site Recovery items as well as backup items before the vault can go, which gives a second chance to catch an active replication.
What deleting the empty vault recovers
saving = full monthly cost of the vaultcost after fix = 0Deleting an orphaned vault
- In the portal, open the vault’s Backup items and confirm the list is empty for every workload type (VMs, SQL, SAP HANA, file shares and so on).
- Open Site Recovery in the same vault and confirm there are no replicated items or protected containers.
- Check Backup Jobs for restores in progress and wait for them to finish.
- Clear any soft-deleted items; Microsoft’s vault deletion guide notes that soft-deleted backup items block deletion until they are permanently removed, 14 days after the delete.
- Delete the vault:
az backup vault delete --resource-group <rg> --name <vault>.