Cleaning up Azure snapshots and backups means finding and deleting orphaned snapshots whose source resources are long gone, converting full snapshots to incremental so you only pay for changed data, and setting retention policies in your Backup vaults so recovery points expire on a schedule instead of accumulating forever. Snapshots and backups bill on the storage they consume, and because almost nothing deletes them automatically, the total only climbs.
This article is part of our Azure cluster. For the wider context, start with the complete guide to Azure cost optimization, the pillar this piece links up to. Snapshot and backup sprawl is a textbook Cut-step target in our See, Cut, Lock, Run method: stored data nobody will ever restore, billing month after month.
Three habits drive snapshot and backup growth. Engineers take a manual snapshot before a risky change and never delete it once the change succeeds. A VM gets decommissioned but its disk snapshots are not, so they outlive the resource. And backup policies default to long retention, quietly multiplying recovery points. None of these is malicious; all of them bill indefinitely until someone goes looking. The cleanup is one-time; the savings recur.
Step 1: Find orphaned and stale snapshots
Start by inventorying every snapshot in the subscription and classifying it. The two categories worth deleting are orphaned snapshots, where the source disk or VM no longer exists, and stale manual snapshots taken before a change that has long since shipped. Query snapshots by creation date and source resource; anything months old with no living parent and no documented reason is a candidate. This is the same hunt described in how to find idle and orphaned Azure resources, applied to point-in-time copies rather than running resources. Confirm with the owning team, then delete.
Step 2: Use incremental snapshots
How you take snapshots changes what you pay to keep them. Azure supports incremental snapshots of managed disks, which store only the changes since the previous snapshot rather than a full copy of the disk every time. For any disk you snapshot regularly, incremental snapshots dramatically reduce the storage you accumulate, because a daily full snapshot of a large disk multiplies storage fast while an incremental chain stores only the deltas. Make incremental the default for scheduled snapshots and reserve full copies for the rare case that needs them.
| Type of stored copy | Cleanup move | Effect |
|---|---|---|
| Orphaned snapshot | Delete after owner confirmation | Removes recurring storage charge |
| Full scheduled snapshots | Convert to incremental | Store deltas, not full copies |
| Backup recovery points | Set retention policy | Points expire on a schedule |
| Long-term backups | Tier to archive where supported | Lower per-gigabyte rate |
Years of snapshots and backups nobody owns?
Our Azure cost audit inventories every snapshot and recovery point, deletes the orphaned ones with owner sign-off, converts scheduled snapshots to incremental, and sets retention that matches your real recovery needs. On the performance model, you pay only from realized savings. No savings, no fee.
Book an Azure cost audit →Step 3: Set retention policies in Backup vaults
Azure Backup keeps recovery points according to the retention defined in each backup policy, and the default retention is often far longer than the business actually requires. Review each policy against the real recovery point and recovery time objectives for the workload: a dev database rarely needs the same long retention as a regulated production system. Tighten daily, weekly, monthly, and yearly retention to what compliance and operations genuinely need, and the vault stops accumulating recovery points you will never restore. Be deliberate here, because retention is a data-protection decision as much as a cost one; coordinate the change with whoever owns recovery.
Step 4: Tier long-term backups and review vault redundancy
For backups you must keep for the long term but rarely touch, use archive-tier storage where the backup product supports it, so cold recovery points sit at a much lower per-gigabyte rate. Also review the storage redundancy on your vaults: geo-redundant storage costs more than locally redundant, and not every backup needs cross-region durability. Match the redundancy to the data's importance rather than defaulting everything to the most expensive option. The same tiering logic applies to ordinary data, covered in how to reduce Azure storage costs across blob tiers.
The incremental snapshot capability, Backup vault retention model, archive tiering, and redundancy options described here reflect Azure as of May 2026. Snapshot and backup features change, so verify the current behavior and any restore implications in Microsoft's Azure documentation before you delete data or change retention.
The Azure Cost Optimization Field Guide includes our snapshot inventory script and the backup retention review worksheet we use on engagements. It is the downloadable companion to this article.
The short version
Snapshots and backups only grow, because almost nothing deletes them on its own. Inventory and delete orphaned and stale snapshots with owner sign-off, convert scheduled snapshots to incremental so you store deltas instead of full copies, set Backup vault retention to match real recovery needs, and tier long-term backups to archive while matching vault redundancy to data importance. To stop new sprawl forming, pair this with the budgets and alerts in Azure budgets and cost alerts: a setup guide. When you want the whole snapshot and backup estate cleaned and policy-driven, that is exactly what our Azure cost optimization service delivers.