# Azure Recovery Vault Orphan

> Vaults holding 0 Azure Backup protected items while billing a positive monthly cost are flagged as orphans, with the full vault cost as savings. Coverage is Azure Backup only, and Site Recovery replication is invisible to this signal, so operators must confirm no ASR-replicated items before deleting the Recovery Services vault.

Source: https://zop.dev/integrations/azure/recommendations/azure-recovery-vault-orphan
Updated: 2026-08-19

---

## Vaults with no Azure Backup protected items

- resource.Metadata.protected_items_count: list-pager count from the Azure Backup BackupProtectedItemsClient, written by the discoverer's Recovery Services Vault enricher. Absence of the key is fail-safe, so the rule treats missing as "unknown" and never fires (a transient SDK error must not masquerade as "zero" and trigger a delete recommendation on a still-active vault).
- Aggregator-supplied monthly cost via PricingAware.SetPricing. The rule short-circuits when cost ≤ 0.
- Optional subscriptionIsNonprod Metadata flag (read via hasTagValue(resource.Metadata, …)): when present it adds a non-prod context line to the recommendation description (does not change the firing decision).
protected_items_count is sourced exclusively from the Azure Backup control plane and has zero visibility into Azure Site Recovery (ASR) replicated items, which live under a separate replicationProtectedItems API the discoverer does not currently populate. A vault used purely for cross-region ASR failover (0 Azure Backup items, but actively replicating) is indistinguishable from a true orphan using this signal alone. There is no replicated_items_count-style ASR producer to gate on, so, rather than abstain entirely and lose the real Azure Backup orphan case, the rule fires but scopes its claim explicitly to the Azure Backup axis: Title, Description, and Remediation all say "Azure Backup protected items" (not "protected items") and instruct the operator to verify no active Site Recovery replication before deleting. Adding a hard gate on ASR item count is future producer work (would need an armrecoveryservicessiterecovery-backed signal).

## Why an empty vault is a clean delete

```text
vault must have positive monthly cost AND protected_items_count == 0 (exact, parsed as int). The optimised cost is 0; savings equals the full current cost. No environment gate -- the rule is intentionally distinct from RC-1379 (cost-threshold vault review) because an orphan vault is a clean delete candidate even below the RC-1379 $50/month floor; downstream low-savings filtering handles sub-threshold emits when enabled.
```

## Confirming Site Recovery is idle before deleting

(renders in the recommendation drawer):
1. Azure Portal → Recovery Services vault → Backup Items: confirm the list is empty across all workload types (VM, SQL, File Share, etc.)
2. Azure Portal → Recovery Services vault → Site Recovery: confirm there are no replicated items or protected containers (this signal does not cover ASR; the Azure Backup count above can be 0 while Site Recovery is still actively replicating)
3. Check for in-flight restore jobs under Backup Jobs, and wait for completion if any are running
4. Remove any legacy replication policies and site-recovery fabrics if present
5. Delete the vault; Azure will refuse if residual state remains, which surfaces anything the count missed

## Only the discoverer's protected-items count

None (signal is metadata-only: discoverer-populated protected_items_count)