How to review an Azure old snapshot
A snapshot is older than an organization’s documented recovery or retention window and appears to have no active legal, compliance, forensic, or recovery purpose. Age alone never proves a snapshot is safe to delete.
Match the snapshot to an approved retention ruleWho reviews this signal?
- Accountable owner
- Backup / data owner
- Review cadence
- Monthly
Check observation dates and read-only scope. Your team approves and implements changes outside Costframe.
How this finding happens
- →Manual and scripted snapshots accumulate without lifecycle rules.
- →Migration and upgrade snapshots remain after the success window closes.
- →A retention policy exists on paper but has no technical owner or expiry metadata.
Collected evidence and verification limits
Checked when available
- ✓Snapshot resource, size, incremental status, source disk reference, creation time, and tags
- ✓Documented retention threshold and policy owner
- ✓Backup-vault or other recovery copies where visible
- ✓Current storage charge and pricing basis
Not always verifiable
- —Costframe cannot infer legal hold or business retention from age.
- —Incremental snapshot billing is not always equal to provisioned source size.
- —A source-disk relationship does not prove the snapshot is still in a recovery plan.
Missing or stale evidence is a limitation, not a passed check.
Why this finding might be wrong
These conditions lower confidence or require manual owner review before action.
- Legal hold or regulatory retention
- Golden recovery point or forensic image
- Snapshot needed for an incomplete migration rollback
- Policy exception recorded outside Azure
Plan the change and recovery path.
- Adopt a retention matrix by workload class, environment, snapshot purpose, and legal requirement.
- Identify owner, recovery plan, last restore test, and alternative backups.
- Expire snapshots in batches, beginning with clearly temporary non-production copies.
- Add lifecycle automation and exception expiry to prevent recurrence.
Rollback / recovery
A deleted snapshot cannot simply be restored. Rollback depends on another verified backup or image, which must be confirmed before deletion.
How savings are calculated
Direct monthly saving is the snapshot’s observed net storage charge, not source-disk provisioned size multiplied blindly by a retail rate.
Do not quote a quantified saving when the billing scope, pricing basis or required workload evidence is incomplete or stale. Treat a modeled amount as estimated until suitable billed outcomes support it.
Check the billed outcome
Snapshot charge disappears and the documented recovery objective remains achievable.
Match the snapshot to an approved retention rule
Find its source workload, recovery purpose and policy owner. Record the retention deadline and any legal or migration exception. If this is the only usable recovery point, resolve that dependency before expiring it; snapshot age is not deletion approval.
Review the source disk's purposeIf the owner cannot resolve a dependency or recovery requirement, keep the candidate in review rather than treating it as approved.