Cost

Delete snapshots whose source disk is gone

An Azure managed disk snapshot keeps billing after its source disk is deleted. Find every snapshot whose source disk no longer exists, confirm none is a deliberate archive, and remove the rest to stop paying for backups of disks that are not coming back.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Orphaned snapshots: the basics

Why does a snapshot keep charging after its disk is gone?

A managed disk snapshot is an independent, point-in-time copy of a disk, stored as its own resource that bills by the gigabyte every month. It is deliberately decoupled from the disk it was taken from: deleting the source disk, or the virtual machine that owned it, does not delete the snapshots. That independence is the whole point during a migration or a restore, but it is also how a subscription ends up paying, month after month, for snapshots of disks that no longer exist and will never be restored.

These are orphaned snapshots: their 'sourceResourceId' points at a disk that has since been deleted. The disk is gone, the VM is gone, often the whole workload is gone, and yet the snapshot quietly keeps appearing on the bill. Nothing in Azure cleans them up for you, because Azure cannot know whether a given snapshot is dead weight or the one archived copy you are deliberately keeping for compliance. The Azure Cost Optimization workbook, available in the Advisor gallery, surfaces exactly this case in its Storage tab as the 'Snapshots with deleted source disk' query.

The work is small and almost always safe. You list every snapshot in the subscription, check which ones have a source disk that still exists, separate any that are intentional archives, and delete the rest. Each snapshot is a single resource with a single delete call, the saving starts the moment it is gone, and because the source disk has already been deleted there is rarely anything live depending on it.

In this lesson you will learn what makes an Azure disk snapshot orphaned, how to find every snapshot in a subscription whose source disk has been deleted, how to tell a deliberate archive from pure waste, and how to delete the waste safely and keep it from coming back. The grounding is the 'Snapshots with deleted source disk' query in the Azure Cost Optimization workbook's Storage tab.

Fun fact

The backup that outlived its data

Azure deliberately keeps snapshots alive when you delete their source disk, and the same is true when you delete the virtual machine: by default the OS and data disks, and any snapshots taken from them, all survive the VM. The design is a safety net, deletion should never quietly take your last copy of something, but it means the most common way an orphaned snapshot is born is a VM being torn down at the end of a project while its snapshots are left behind. Years later they can still be on the bill, point-in-time copies of a disk that was deleted long ago, faithfully preserved by a platform doing exactly what it was told.

Finding orphaned snapshots across a subscription

Priya is the platform engineer doing a quarterly cost sweep after the workbook's Storage tab flagged a cluster of snapshots whose source disk had been deleted, mostly left over from projects that wound down last year.

Rather than open each snapshot in the portal, Priya runs an Azure Resource Graph query that lists every snapshot in the subscription and joins it back to the disks that still exist, so the ones pointing at a deleted disk fall straight out.

Use Resource Graph to list every snapshot whose source disk no longer exists. The left-outer join keeps snapshots that found no matching disk.

$ az graph query -q "resources | where type =~ 'microsoft.compute/snapshots' | extend src = tolower(tostring(properties.creationData.sourceResourceId)) | join kind=leftouter (resources | where type =~ 'microsoft.compute/disks' | extend src = tolower(id) | project src, diskExists = id) on src | where isnull(diskExists) and isnotempty(src) | project name, resourceGroup, sizeGb = properties.diskSizeGB" -o table

Name ResourceGroup SizeGb

------------------------- ---------------- ------

vm-legacy-osdisk-snap rg-project-atlas 128

data01-2024-archive-snap rg-finance-keep 512

# atlas project closed last year: pure waste. The 'archive' one needs a check before deleting.

The join leaves only snapshots whose source disk is gone. Most are dead weight; treat anything named or tagged like an archive as a deliberate keep until you confirm.

How you prove a snapshot is orphaneddeep dive

Every managed disk snapshot records where it came from in 'properties.creationData.sourceResourceId', the ARM resource id of the disk it was taken from. A snapshot is orphaned when that id points at a disk that no longer exists. You cannot tell this from the snapshot alone, because the field still holds the id of the deleted disk; you have to compare it against the set of disks that currently exist and keep the snapshots with no match. That comparison is exactly what the Cost Optimization workbook's 'Snapshots with deleted source disk' tile does, and what the Resource Graph join in this lesson reproduces.

Two details matter for accuracy. First, the join must be case-insensitive: ARM resource ids are not case-stable across services, so comparing the raw strings can wrongly flag a live snapshot as orphaned. Normalising both sides to lower case before the join, as the query does, avoids that. Second, a snapshot can legitimately have an empty source id, for example one imported from a blob, so the query keeps only snapshots that had a source disk id and found no matching disk, rather than treating every unmatched row as waste.

Orphaned status is also not the same as old or unused. A snapshot can be days old and already orphaned because its disk was deleted, or years old and perfectly valid because its disk is still in service. The workbook keeps these as separate tiles, 'Disk Snapshots with + 30 Days' for age and 'Snapshots with deleted source disk' for orphaned, precisely because they answer different questions. This lesson is about the orphaned case: the source is gone, so the only question left is whether you are keeping the snapshot on purpose.

What is the impact of leaving orphaned snapshots in place?

The direct impact is recurring spend with no return. Each orphaned snapshot bills for its used data every month for as long as it exists, and because the source disk is already deleted, that spend buys nothing: there is no live disk to restore from it and, in most cases, no workload it relates to any more. Left alone, the set only grows, because every migration, VM teardown and project wind-down can leave fresh snapshots behind, and nothing in Azure removes them.

The second-order impact is drag on every cost conversation. Orphaned snapshots inflate the storage line, blur the true cost of the workloads that are still running, and make right-sizing and showback harder because spend is attributed to copies of things that no longer exist. A subscription that quietly carries dead backups is one where nobody can fully trust the storage number.

There is no offsetting benefit to weigh. Unlike most cost decisions, where trimming spend risks performance or resilience, removing an orphaned snapshot costs you nothing you are using: the disk it protected is gone. The only thing standing between the estate and the saving is the work of finding them and confirming none is a deliberate archive.

How do you clear orphaned snapshots safely?

Treat this as one loop: find, confirm, delete, then prevent. The confirm step is the only one that needs judgement, because the goal is to delete every orphaned snapshot except the ones you are keeping on purpose.

1. Find every snapshot whose source disk is gone

Run the Resource Graph query, or open the workbook's 'Snapshots with deleted source disk' tile, to list every snapshot whose source disk no longer exists. Export the list with each snapshot's used size and resource group so the saving can be totalled and the work can be tracked.

2. Separate deliberate archives from waste

A snapshot orphaned on purpose, a retained copy kept after its source was decommissioned for compliance or rollback, is a retention decision, not waste. Identify these by tag, name or owner, record why each is kept, and exclude them. Everything else, the OS and data snapshots left behind by torn-down VMs and closed projects, is recoverable.

3. Delete the waste, capturing the saving immediately

Delete each confirmed-orphaned snapshot. Billing stops as soon as the snapshot is gone, so the saving begins this month, not next term. Because the source disk is already deleted, there is rarely anything live to break. If you want a final safety margin on a large or uncertain snapshot, export it to a blob first, but for the bulk of leftover project snapshots a straight delete is appropriate.

4. Stop it coming back

Put the workbook check on a quarterly cadence and assign a policy that requires an owner and an expiry tag on new snapshots, so future orphans are attributable and time-boxed rather than silently permanent. Look the policy up by exact display name at assignment time rather than hardcoding a definition id, since built-in tagging policy ids differ by tenant and version.

# 1. Find every snapshot whose source disk no longer exists (subscription-wide).
orphans=$(az graph query -q "resources \
  | where type =~ 'microsoft.compute/snapshots' \
  | extend src = tolower(tostring(properties.creationData.sourceResourceId)) \
  | join kind=leftouter ( \
      resources \
      | where type =~ 'microsoft.compute/disks' \
      | extend src = tolower(id) \
      | project src, diskExists = id \
    ) on src \
  | where isnull(diskExists) and isnotempty(src) \
  | project id" \
  --query "data[].id" -o tsv)

# 2. Review the list, then exclude any deliberate archives (here: a 'keep=archive' tag).
for id in $orphans; do
  keep=$(az snapshot show --ids "$id" --query "tags.keep" -o tsv)
  if [ "$keep" = "archive" ]; then
    echo "SKIP (retained archive): $id"
    continue
  fi
  # 3. Delete the orphaned snapshot. Billing stops immediately.
  az snapshot delete --ids "$id"
  echo "DELETED: $id"
done

# 4. Prevent recurrence: require an owner tag on new snapshots (look the policy up by name).
pid=$(az policy definition list \
  --query "[?displayName=='Require a tag on resources'].name" -o tsv)
az policy assignment create \
  --name require-owner-on-snapshots \
  --policy "$pid" \
  --params '{"tagName":{"value":"owner"}}' \
  --scope "/subscriptions/<subscription-id>"

Quick quiz

Question 1 of 5

What makes an Azure managed disk snapshot 'orphaned'?

Keep learning

Go deeper on how Azure disk snapshots are billed, how to find them, and how to keep storage spend optimised.

You can now treat orphaned snapshots as a clean, recurring saving rather than invisible drag: find every snapshot whose source disk has been deleted, separate the deliberate archives, delete the rest to stop the billing immediately, and put the workbook check on a cadence so the leak stays closed. The grounding is the 'Snapshots with deleted source disk' query in the Cost Optimization workbook's Storage tab.

Back to the library

Orphaned snapshots: the savings view

A standing line on the storage bill for backups of disks that no longer exist

This is one of the cleanest savings on the Azure bill. A snapshot whose source disk has been deleted produces zero value: the disk it backed up is gone, so the snapshot is a copy of nothing anyone is using, and it bills every month for as long as it sits there. Deleting it removes a recurring charge outright, and the saving begins immediately rather than after a term or a commitment.

Managed disk snapshots are billed per gigabyte of used data, with full snapshots charged at a documented rate per GB per month and incremental snapshots charged only for the data that changed since the previous snapshot. The exact monthly figure depends on how many orphaned snapshots you hold and how large the deleted disks were, so the way to size the opportunity is to total the used gigabytes of the orphaned set and multiply by the snapshot rate, not to assume a headline number.

The payback is immediate and the risk is close to zero, which makes this the easiest kind of saving to approve. The only judgement call is the small set of snapshots that are orphaned on purpose, kept as a deliberate archive after the source was decommissioned. Those are a documented retention decision, not waste, and the savings case is simply to delete everything that is not one of them.

This lesson is for the finance partner who wants to turn a list of orphaned snapshots into a sized, risk-free saving. It covers how snapshots are billed, how to total the recoverable spend, why the payback is immediate, and how to ring-fence the few snapshots that are kept on purpose so the cleanup is defensible.

Fun fact

The backup that outlived its data

How a finance partner sizes the orphaned-snapshot saving

Priya is the finance partner running the quarterly cost review. The workbook's 'Snapshots with deleted source disk' tile lists nineteen snapshots whose source disk has been deleted, scattered across resource groups from projects that closed over the past two years. The instinct is not to celebrate nineteen deletions; it is to turn the list into a number. Priya asks the platform team to export the set with each snapshot's used size, because the saving is the total used gigabytes multiplied by the snapshot rate per GB per month, not a count of resources.

The export comes back as a clear picture: most of the nineteen are small leftover OS-disk snapshots from torn-down VMs, a few are large data-disk snapshots, and two are tagged as deliberate compliance archives kept after the source was decommissioned. Priya rings off the two archives as a documented retention decision and totals the rest. The finance note reads: 'Seventeen orphaned snapshots, X used GB in total, recoverable at the documented snapshot rate per GB per month, starting the month we delete them. Two are retained archives with an owner. Payback is immediate, the source disks are already gone, so the risk is effectively nil.'

Why this belongs at the top of the savings list

The cost case here is unusually clean. Most savings carry a trade: a smaller VM risks performance, a cheaper redundancy tier risks resilience, a reservation locks in a term. Deleting an orphaned snapshot carries none of those, because the source disk it backed up has already been deleted, so there is no capability to lose. It is recovered margin with no offsetting risk, which is exactly the profile finance should green-light fastest.

Size it properly so it is taken seriously. The recoverable amount is the total used gigabytes across the orphaned set multiplied by the documented snapshot rate per GB per month, with the deliberate archives excluded. Quote that as a recurring monthly saving that begins the month the snapshots are deleted, and pair it with the headcount-free effort to capture it: a single query to find them and a scripted delete to remove them. Few line items on a cost review have a payback this immediate or a risk this low.

What finance can do about the orphaned-snapshot saving

Finance cannot delete a snapshot, but it owns the framing that turns a raw list into a sized, defensible saving and keeps it from reopening. Three levers.

1. Size it in money, not in resource count

Nineteen snapshots is not a saving; the total used gigabytes multiplied by the documented snapshot rate per GB per month is. Ask the team to export the orphaned set with each snapshot's used size, exclude the deliberate archives, and report the recoverable amount as a recurring monthly figure that begins the month they are deleted. That number is what belongs on the cost review, not the count.

2. Frame it as risk-free margin recovery

Make explicit on the cost review that this saving carries no trade-off: the source disks are already deleted, so nothing running depends on these snapshots. That distinguishes it from right-sizing or redundancy changes that carry a performance or resilience risk, and it is why this should be approved and actioned first, ahead of harder calls.

3. Require it to be a recurring line, not a one-off

A single sweep recovers today's waste and then the leak reopens as the next projects wind down. Ask for the workbook's 'Snapshots with deleted source disk' check to be a standing item each quarter, and for new snapshots to carry an owner and an expiry tag, so the orphaned line stays near zero instead of having to be rediscovered every couple of years.

Quick quiz

Question 1 of 5

The workbook lists nineteen snapshots with a deleted source disk. As the finance partner, how should you express the saving?

Keep learning

Go deeper on how Azure disk snapshots are billed, how to find them, and how to keep storage spend optimised.

You have finished the finance view. You know how snapshots are billed, how to size the orphaned set in money rather than in resource count, and why the payback is immediate with no trade-off, because the source disks are already gone. Next time the workbook flags snapshots with a deleted source disk, you will total the recoverable monthly spend, ring-fence the deliberate archives, and ask for the check as a standing quarterly line rather than a one-off.

Back to the library

Orphaned snapshots: the headline

Recurring spend on copies of disks the business has already thrown away

Every cloud estate accumulates this kind of waste: an artefact that made sense at the time, kept billing after the thing it referred to was deleted, and was never cleaned up because nobody owned the cleanup. Orphaned disk snapshots are a textbook example. They are copies of disks the business has already decided it no longer needs, still charging the storage bill every month.

The decision here is not whether to spend, it is whether to stop spending. There is no trade-off to weigh and no capability being lost: the disk these snapshots backed up is already gone. Removing them is pure margin recovery, and the only governance requirement is to keep the handful that are deliberate archives and delete the rest.

Treated once, this is a small recurring saving. Treated as a habit, with the workbook check run on a cadence and a tagging rule so future snapshots carry an owner and an expiry, it is the difference between a one-off cleanup and an estate that does not quietly leak money as workloads come and go.

A short read for the leader who wants to know why the estate is paying for backups of deleted disks, why removing them is margin recovery rather than a trade-off, and how to make the cleanup a recurring habit instead of a one-off.

Fun fact

The backup that outlived its data

What it looks like when the estate stops leaking on dead backups

After a cost review surfaced that the estate was still paying for snapshots of disks deleted two years earlier, the CFO asked the obvious question: how much of our storage bill is for things we have already thrown away? The honest answer was that nobody had been tracking it, because snapshots are created during migrations and project work and then quietly outlive the workloads they belonged to.

The team treated it as a habit rather than a one-off. They cleared the orphaned set, keeping the two snapshots that were deliberate archives, and then put the workbook's 'Snapshots with deleted source disk' check on a quarterly cadence with a tagging rule so every new snapshot carries an owner and an expiry. The next review answered the CFO's question precisely: the orphaned-snapshot line was recovered, the small retained set was named and owned, and a recurring check meant the leak could not silently reopen. That shift, from discovering dead backups years later to catching them every quarter, is the lasting value, and it is pure margin recovery with nothing traded away.

Why this is an easy yes

This is the rare cost item with no downside to manage. The business has already decided it no longer needs the disks these snapshots copied, because it deleted them. Continuing to pay to back up deleted disks is simply a cleanup that never happened, and removing the spend takes nothing away from any running workload.

The leadership move is to make sure it does not silently reaccumulate. A one-time sweep recovers the current waste; a recurring check plus a tagging discipline, so every snapshot has an owner and an expiry, keeps the estate from leaking the same way as the next round of projects winds down. The cost of acting is a small amount of engineering time; the cost of ignoring it is a storage bill that drifts upward for copies of things nobody uses.

The leadership move on dead backups

The executive handle is not to approve each deletion; it is to require that the estate stops paying for backups of deleted disks and does not start again.

1. Approve the sweep and ask for the recovered figure

This is an easy yes: nothing running depends on these snapshots, so the only output to ask for is the recurring monthly amount recovered and confirmation that the deliberate archives were kept. Treat a clean recovered figure with a named retained set as the proof the sweep was done properly.

2. Make it a habit, not an event

Ask for the workbook check on a quarterly cadence and a tagging rule so every new snapshot has an owner and an expiry. The goal is an estate where orphaned snapshots are caught within a quarter of being created, not discovered years later, so the saving compounds into a leak that stays closed.

3. Keep the archives named and owned

A few snapshots are orphaned on purpose, retained after their source was decommissioned. The requirement is that each is a deliberate, documented, owned decision with a retention reason, not an accident left on the bill. The target is zero unintended orphans, not zero snapshots.

Quick quiz

Question 1 of 5

At a cost review you ask why the estate pays for backups of disks deleted two years ago. What is the right way to frame the fix?

Keep learning

Go deeper on how Azure disk snapshots are billed, how to find them, and how to keep storage spend optimised.

Two takeaways. Paying for snapshots of disks the business already deleted is pure waste, and removing it is margin recovery with nothing traded away, so it is the easiest cost call to approve. And the durable win is a habit, not an event: a recurring workbook check plus an owner-and-expiry tagging rule keeps the estate from quietly leaking on dead backups as workloads come and go.

Back to the library

Part of the learning path Kill idle Azure waste

Delete snapshots whose source disk is gone

Orphaned snapshots: the basics

The backup that outlived its data

Finding orphaned snapshots across a subscription

How you prove a snapshot is orphaneddeep dive

What is the impact of leaving orphaned snapshots in place?

How do you clear orphaned snapshots safely?

1. Find every snapshot whose source disk is gone

2. Separate deliberate archives from waste

3. Delete the waste, capturing the saving immediately

4. Stop it coming back

Quick quiz

Keep learning

Orphaned snapshots: the savings view

The backup that outlived its data

How a finance partner sizes the orphaned-snapshot saving

Why this belongs at the top of the savings list

What finance can do about the orphaned-snapshot saving

1. Size it in money, not in resource count

2. Frame it as risk-free margin recovery

3. Require it to be a recurring line, not a one-off

Quick quiz

Keep learning

Orphaned snapshots: the headline

The backup that outlived its data

What it looks like when the estate stops leaking on dead backups

Why this is an easy yes

The leadership move on dead backups

1. Approve the sweep and ask for the recovered figure

2. Make it a habit, not an event

3. Keep the archives named and owned

Quick quiz

Keep learning

Related cost lessons