Azure snapshot cost: a museum of disks nobody visits
Every snapshot in your subscription was created by somebody being careful. That is what makes them awkward to delete. Nobody snapshots a disk out of carelessness; they do it before a change that might go wrong, and then the change goes fine, and the snapshot becomes a small monthly charge attached to a decision that turned out not to matter.
Azure snapshot cost is therefore mostly a retention problem rather than a pricing problem. The rates are modest. The accumulation is not.
How azure snapshot cost is calculated
There are two kinds of snapshot and the difference matters more than the rate.
Full snapshots bill for the used size of the source disk at the time the snapshot was taken, at a standard storage rate. Take a full snapshot of a disk with 60 GB of data on it and you are billed for roughly 60 GB, every month, until you delete it.
Incremental snapshots bill only for the changes since the previous snapshot of that disk. The first one is effectively a full copy of the used data. The second is the delta. The tenth is the delta from the ninth. A chain of ten incremental snapshots on a disk that barely changes can cost less than a single full snapshot of the same disk.
Two consequences follow. Incremental is almost always the right choice for anything recurring, and Microsoft's incremental snapshot documentation covers the mechanics and the regional caveats. And deleting one snapshot from the middle of an incremental chain does not free what you might expect, because the data another snapshot depends on has to stay.
That second point is why "delete everything older than 90 days" produces disappointing savings on an incremental chain and dramatic savings on a pile of full snapshots.
Where they come from
Four sources, roughly in order of how many they produce.
Backup tooling. Some third-party backup products snapshot before copying and tidy up afterwards, and some tidy up only when the job succeeds. A failed job at 2am leaves a snapshot behind, and a job that has been failing quietly for eight months leaves 240 of them. This is the single biggest producer I have found in small estates, and it is invisible because each individual snapshot is cheap.
Finished migrations. A migration takes a safety copy of everything before
it moves. Eighteen months later the safety copy is still there, named something
like snap-migration-final, and deleting it feels like tempting fate even
though the source disk no longer exists.
Cautious engineers, including me. Before a patch, before a schema change, before a resize. Entirely correct behaviour, followed by no cleanup step because the change worked and attention moved on.
Image builds. Custom image pipelines produce snapshots as intermediate artefacts. Whether they get cleaned up depends on whether the pipeline finished.
Finding the ones that have outlived their reason
The query is simple. The judgement is not.
resources
| where type =~ 'microsoft.compute/snapshots'
| extend created = todatetime(properties.timeCreated),
sizeGB = toint(properties.diskSizeGB),
incremental = tobool(properties.incremental),
sourceId = tostring(properties.creationData.sourceResourceId)
| extend ageDays = datetime_diff('day', now(), created)
| where ageDays > 180
| project subscriptionId, resourceGroup, name, sizeGB, incremental, ageDays, sourceId
| order by ageDays desc
The sourceId column is the interesting one, because it lets you answer the
question that actually decides things: does the disk this was taken from still
exist? A snapshot of a live disk is a rollback point somebody might want. A
snapshot whose source disk was deleted two years ago is a museum piece, and it
is often the only remaining copy of something, which is either the reason to
keep it or the reason nobody can approve deleting it.
Cross-reference against the unattached disks from the orphan sweep and a pattern usually appears: a decommissioned server, its disk, and three snapshots, all left behind by the same unfinished piece of work.
What deleting one actually saves
This is where snapshot work disappoints people who have promised a number.
On full snapshots the arithmetic is honest: delete a 60 GB snapshot and you stop paying for 60 GB. On incremental chains it is not, because the billed size of each snapshot is the delta it holds, and deleting a snapshot from the middle of a chain leaves its data in place if a later snapshot still needs it. Azure handles the consolidation for you, which is the right behaviour and also the reason the saving is smaller than the sum of the sizes you deleted.
So report snapshot findings as a range or as the total for the ones you are confident about, and separate the full snapshots from the incremental ones in the output. A finance conversation that starts with "we deleted 340 GB of snapshots and saved less than you would expect, here is why" goes better than one where the projected saving quietly fails to appear on the next invoice.
Retention as a decision
The reason snapshots accumulate is that nobody ever decided how long to keep them. Not "nobody decided correctly", nobody decided at all, because each snapshot was created as an individual act of caution rather than under a policy.
A retention rule does not need to be sophisticated to fix that. Something like: pre-change snapshots go after 30 days, migration snapshots go 90 days after the migration signs off, backup tool snapshots are the backup tool's problem and anything it leaves behind after 7 days is a fault to investigate rather than a snapshot to keep.
Write it down, tag snapshots with their reason at creation, and the monthly review becomes a query rather than an archaeology exercise. That is the same argument as the tagging note, and snapshots are the strongest case for it because the metadata you need at deletion time is the reason it was taken, which is exactly what nobody records.
The one that is genuinely load-bearing
Worth saying, because a cost note that only argues for deletion is a bad influence.
Sometimes the old snapshot is the only copy of something that was never backed up properly. A departed developer's environment. A database from before a migration that changed the schema. A configuration nobody has documented. That snapshot is not waste, it is an accidental archive, and its monthly cost is cheap insurance.
The correct action there is not to delete it. It is to notice that you are relying on a snapshot as a backup, and to either make it a real backup or accept the arrangement deliberately. Cost work that turns an accidental dependency into a conscious one has done something useful even when it saves nothing.
The AzClean Toolkit reports snapshot age, size, incremental status and whether the source disk still exists, which is the combination that lets you sort the museum from the archive.