Azure snapshot and backup cost is controlled by four decisions. Use incremental snapshots, which store only the blocks that changed since the previous snapshot rather than a full copy, and which sit in standard storage by default regardless of the source disk tier. Match the backup storage tier to the data: snapshot tier for fast recent restores, vault standard for operational retention, and archive tier for long term compliance copies. Set a retention policy that reflects how far back you would actually restore, not the longest period anyone might imagine. And run a routine that finds and deletes orphaned snapshots left behind by deleted disks. Replication choice, locally redundant versus geo redundant, then multiplies whatever total you land on.
None of this is exotic, which is exactly why it gets ignored until the storage line is a surprise. Here is the discipline that keeps it in check.
Why do incremental snapshots cost so much less?
A full snapshot copies the entire disk every time. An incremental snapshot copies only the blocks that changed since the last snapshot, so a chain of daily snapshots on a disk that changes slowly costs a fraction of repeated full copies. Incremental snapshots also bill against standard storage by default, even when the source is a premium SSD, which lowers the rate further.
The catch is that incremental snapshots form a dependent chain, so the cost picture is the sum of the changed blocks across the chain rather than any single snapshot. The discipline is to keep the chain length sensible and let a lifecycle routine retire the oldest links rather than holding every snapshot forever.
For most disks the practical answer is clear: use incremental snapshots, keep a short rolling chain for operational recovery, and push anything longer term into backup with an archive tier rather than an ever growing snapshot chain.
Which backup tier should each copy live in?
Azure Backup bills two things: a protected instance fee per item, and the storage the recovery points consume. The storage choice is where the money moves.
Snapshot tier holds the most recent recovery points for fast, local restores. Instant restore retention is configurable, often a day or two by default, and you pay for the snapshots held during that window.
Vault standard holds operational backups for weeks or months. This is the working tier for most retention.
Vault archive holds long term and compliance copies at a much lower storage rate, in exchange for a rehydration delay and a minimum retention period before a recovery point is eligible to move there. Moving rarely touched long term copies to archive is the single biggest backup saving for most estates.
The rule of thumb: keep only what you would restore this week in the fast tier, the rest in vault standard, and long term compliance copies in archive.
How does retention and replication multiply the bill?
Two settings act as multipliers on everything above. Retention sets how many recovery points you keep; a grandfather, father, son policy that keeps daily, weekly, monthly, and yearly points is sensible, but each yearly point held for seven years is seven years of storage. Replication decides how many copies of that exist: locally redundant storage keeps copies in one region, while geo redundant storage keeps a second copy in a paired region and bills accordingly. Soft delete, which retains deleted backups for a recovery window, adds a further holdover you pay for.
| Lever | Cheaper choice | More expensive choice |
|---|---|---|
| Snapshot type | Incremental, standard storage | Repeated full snapshots |
| Backup tier | Archive for long term copies | Everything in snapshot tier |
| Retention | Matched to real recovery need | Maximum on every policy |
| Replication | Locally redundant where allowed | Geo redundant everywhere |
A worked example: clearing the snapshot graveyard
A European SaaS company had geo redundant backup on every workload, including ephemeral test databases, and a long tail of snapshots from disks deleted months earlier. The orphaned snapshots alone were a meaningful slice of the storage line because nothing had ever pruned them. We moved long term copies to the archive tier, dropped non production backups to locally redundant storage, set retention to match each workload's real recovery objective, and ran a routine that deleted snapshots whose source disk no longer existed. Backup and snapshot storage fell sharply with no loss of any recovery point anyone actually needed. Figures are verified against billing data and anonymised.
How should you run this as a routine?
Make it monthly, not heroic. Review retention against real recovery objectives, confirm long term copies sit in archive, check that non production uses locally redundant storage, and run an orphaned snapshot sweep that flags any snapshot whose source disk is gone. Pair it with the disk side of the picture in managed disk tiers and rightsizing, since the same disks drive both. This storage hygiene is a standing line in the Azure cost optimization guide.
Frequently asked questions
Get the buyer side storage playbook
We read your Azure storage and backup spend the way an independent buyer does, separate real recovery need from habit, and cut the rest with zero provider commissions. It is the same discipline behind the 31 percent median reduction we see in the first 90 days. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.