Recovery Services vaults whose default policy retains backups past the 30-day baseline
What does ZopNight detect here?
Recovery Services vaults costing at least $50/month whose default backup policy retains longer than Azure's 30-day baseline are flagged by RC-1382. Savings apply a retention haircut to an assumed 70% storage share of vault cost. The recommendation labels that estimate explicitly, since no producer reports the real fee/storage split.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1382 |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | recovery_vault_retention.go |
Where it applies
Retention is the multiplier on every backup bill
A Recovery Services vault’s storage charge scales almost linearly with how long recovery
points are kept: 90-day retention holds roughly three times the recovery points of the
30-day Azure baseline. Teams set long retention once, often copying a production policy
onto dev vaults, and the charge compounds silently as protected items grow. RC-1382 reads
the vault’s default_policy_retention_days metadata (populated by the discoverer, readable
with Reader) and fires when it exceeds 30, sizing the saving from a cut back to the
baseline: cost × 0.70 × (1 − 30/actual).
The 70% is an assumption, and the rule says so
Vault bills mix two meters: a fixed per-protected-instance fee and a retention-scaled storage charge. Azure Cost Management keeps those line items distinct, but the pricing feed ZopNight consumes collapses them into one vault rate, so the rule applies an industry-typical 70% storage share rather than a per-vault measured split, and excludes the fixed fee from the haircut. The recommendation text states this basis explicitly. For a fee-dominated vault (many small protected items) the estimate overstates what is reclaimable; unlike a fabricated saving, though, the driver here (the retention value) is a real measured fact about your vault. When the discoverer could not populate the retention key, or when replication and item-count enrichments are missing, the affected signal is simply omitted; a missing retention value abstains entirely.
Small vaults are filtered out on purpose
Vaults under $50/month never fire. Below that floor the achievable haircut is pocket change, and a sibling rule (RC-1379) already covers general vault review; duplicate findings on the same $30 vault would be noise. Missing or non-positive pricing also abstains.
Inspect the policy the rule is judging
az backup policy show \ --resource-group <rg> --vault-name <vault> --name DefaultPolicy \ --query "properties.retentionPolicy.dailySchedule.retentionDuration"Shrinking retention without breaking RPO
Reduce daily retention on the default policy toward 30 days, or to whatever your workload’s recovery-point objective genuinely requires, which for most dev/test vaults is less than 30. Existing recovery points beyond the new window expire on their original schedule, so the saving phases in rather than landing instantly. Check with application owners before touching a vault protecting production: a retention number is cheap to change and expensive to regret, and the compounding works both ways: pairing the haircut with a GRS→LRS replication downgrade (where acceptable) multiplies the effect.