Cost

Delete managed disks not attached to a VM

An unattached managed disk is a deleted virtual machine's storage that nobody turned off. It bills at the full provisioned size every hour, forever, while serving no workload. This lesson finds every one in the estate, tells the genuinely orphaned from the deliberately parked, and reclaims the spend safely.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Unattached managed disks: the basics

Why does deleting a VM sometimes leave its storage running?

When you delete an Azure virtual machine, its operating-system and data disks are not always deleted with it. A managed disk is an independent resource with its own lifecycle, and unless 'delete with VM' was set on it, it survives the VM and keeps billing. The result is an orphaned disk: a Premium or Standard managed disk that is not attached to anything, costs the same every hour as it did when it ran a workload, and serves nobody. Azure Advisor flags exactly this under the recommendation 'Review disks that aren't attached to a VM' (Recommendation ID 48eda464-1485-4dcf-a674-d0905df5054a).

Managed disks bill on provisioned size and performance tier, not on usage. You pay for the full size of the disk you selected regardless of how much data sits on it, and you pay whether or not it is attached to a running machine. A 128 GB Premium SSD that nobody mounts costs the same as one serving a production database. That is what makes unattached disks the cleanest line in an Azure bill to reclaim: there is no workload to migrate, no capacity to right-size, just storage that should have been deleted and was not.

The signal is two properties on the disk. 'managedBy' holds the resource id of the VM a disk is attached to; on an unattached disk it is null. 'diskState' reports 'Unattached' for a disk that is genuinely idle. Disks that Azure Site Recovery uses for replication look unattached too but report 'ActiveSAS', which is why the Advisor cost workbook's 'Unattached Managed Disks' query deliberately ignores them. The work in this lesson is to list every disk that is truly orphaned, separate the few that are parked on purpose, and delete the rest with a snapshot safety net where you are unsure.

In this lesson you will learn why Azure leaves managed disks behind when virtual machines are deleted, how to find every unattached disk across a subscription, how to tell a genuinely orphaned disk from one that is parked on purpose or used by Azure Site Recovery, and how to reclaim the spend safely with a snapshot net where you need one. It is grounded in the Azure Advisor recommendation 'Review disks that aren't attached to a VM' and the cost workbook's 'Unattached Managed Disks' query.

Fun fact

The disk that outlived the server by two years

Because a managed disk is its own resource, an operating-system disk can keep billing long after the virtual machine it booted is gone, and data disks survive even longer because nothing in the portal nudges you to delete them. Azure has since added a 'delete with VM' option you can set per disk so the storage is cleaned up automatically when the machine is removed, but it is off by default for data disks and for any disk created before the option existed. That default is why almost every long-lived Azure estate has unattached disks it has been paying for since well before anyone now on the team can remember creating them.

Finding orphaned disks across a subscription

Priya runs the platform team at a company that has been on Azure for four years across several subscriptions. The monthly bill has a steady storage line that nobody can fully account for, and Advisor has been quietly showing 'Review disks that aren't attached to a VM' for months.

Rather than open each disk in the portal, Priya lists every managed disk whose 'managedBy' is null and whose 'diskState' is 'Unattached', so the genuinely orphaned disks are separated from anything Site Recovery is using before a single delete is run.

List every disk that is truly unattached: managedBy is null and diskState is Unattached. This skips the ASR replication disks, which report ActiveSAS.

$ az disk list --query "[?managedBy==null && diskState=='Unattached'].{name:name, rg:resourceGroup, gb:diskSizeGb, sku:sku.name}" -o table

Name Rg Gb Sku

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

vm-web01_OsDisk rg-legacy-web 128 Premium_LRS

olddb-datadisk-01 rg-legacy-web 1024 Premium_LRS

tempclone-os rg-sandbox 30 Standard_LRS

# Two Premium disks billing full price for VMs deleted long ago. Reclaim these first.

A 1024 GB Premium data disk attached to nothing is the single highest-value line here. Size the reclaim by provisioned GB times tier, biggest first.

How Azure decides a disk is unattached, and why ASR disks are differentdeep dive

Two properties on a managed disk tell the whole story. 'managedBy' holds the resource id of the virtual machine the disk is attached to, and on a free disk it is null. 'diskState' is the disk's own lifecycle status: 'Attached' on a running VM, 'Reserved' when the VM is stopped-deallocated, 'ActiveSAS' when the disk has a live shared access signature against it, and 'Unattached' when it is genuinely idle and available to attach. A disk that is both managedBy null and diskState 'Unattached' is the clean orphan you can reclaim.

The ASR distinction matters because it is the one trap. Azure Site Recovery replicates disks for machines that do not yet have a target VM, so those disks have no managedBy but are not waste: deleting one breaks your disaster-recovery posture. They report diskState 'ActiveSAS' rather than 'Unattached', which is precisely why the Advisor cost workbook's 'Unattached Managed Disks' query filters on diskState 'Unattached' and so ignores them. Filtering on managedBy alone would sweep ASR disks into the list; filtering on diskState 'Unattached' does not.

Azure Advisor evaluates the recommendation 'Review disks that aren't attached to a VM' (Recommendation ID 48eda464-1485-4dcf-a674-d0905df5054a) on a periodic cycle, so a disk you delete does not clear the recommendation the instant you act; the control-plane delete is immediate but Advisor catches up on its next refresh. To prevent the leak reopening, set 'delete with VM' on disks at creation, or run the inventory on a schedule so new orphans are swept before they accumulate.

What is the impact of leaving unattached disks in place?

The direct impact is recurring spend for nothing. A managed disk bills on its provisioned size and performance tier every hour it exists, attached or not, used or not. An unattached Premium SSD of 128 GB is on the order of a low-tens-of-pounds-per-month line, a 1024 GB Premium disk many times that, and the charge continues indefinitely because nothing ever stops it. Across a multi-year estate these accumulate into a four-figure or larger annual run-rate that buys no capacity anyone uses.

The second-order impact is that the leak compounds and hides. Every VM that is deleted without its disks adds another orphan, and because the bill shows a single storage figure rather than a per-disk attribution, the growth is invisible unless someone runs the inventory. Left alone, the line only ever rises, one forgotten machine at a time, which is why this is best treated as a recurring sweep rather than a one-time cleanup.

There is no upside to leaving them. Unlike a VM you might still need or a database you cannot shrink without testing, an unattached disk supports no workload, so the only thing the spend protects is the small chance that a disk holds data someone will want back. That chance is fully covered by a snapshot, which costs a fraction of the live disk, so even the cautious path reclaims almost all of the run-rate.

How do you reclaim unattached-disk spend safely?

Treat it as one loop rather than a per-disk chore. The order matters: inventory and classify before you delete, so you never remove a disk Site Recovery is using or one that is parked on purpose.

1. Inventory every truly unattached disk

List disks where managedBy is null and diskState is 'Unattached', not managedBy alone, so Azure Site Recovery's replication disks (which report 'ActiveSAS') are excluded automatically. Capture provisioned size and SKU for each so the reclaim can be priced and ordered by value.

2. Separate orphans from deliberately parked disks

Most unattached disks are genuine orphans from deleted machines. A few are parked on purpose: a disk kept to re-attach to a rebuilt VM, or a golden image source. Tag those with a clear keep marker and an owner so future sweeps skip them, and treat everything untagged as a candidate for deletion.

3. Snapshot anything you are unsure about, then delete

Where a team cannot confirm a disk holds nothing they want, take an incremental snapshot first. It persists after the disk is gone, bills only for stored data on Standard HDD, and turns an irreversible delete into a reversible one. Then delete the disk and reclaim the full live-disk charge.

4. Stop the leak reopening

Set 'delete with VM' on disks at creation so storage is cleaned up when its machine is removed, and run the unattached-disk inventory on a schedule so any new orphans are swept before they accumulate. The sweep is what turns a one-off recovery into a permanently clean run-rate.

# 1. Inventory: only genuinely unattached disks (managedBy null AND diskState Unattached).
#    This excludes Azure Site Recovery disks, which report diskState 'ActiveSAS'.
az disk list \
  --query "[?managedBy==null && diskState=='Unattached'].{name:name, rg:resourceGroup, gb:diskSizeGb, sku:sku.name}" \
  -o table

# 2. Snapshot-then-delete each orphan, skipping any tagged to keep.
#    Set DELETE=1 only after reviewing the list above; DELETE=0 is a dry run.
DELETE=0
az disk list \
  --query "[?managedBy==null && diskState=='Unattached' && tags.keep!='true'].id" -o tsv \
| while read -r diskId; do
    rg=$(az disk show --ids "$diskId" --query resourceGroup -o tsv)
    name=$(az disk show --ids "$diskId" --query name -o tsv)
    if [ "$DELETE" = "1" ]; then
      # Incremental snapshot as a reversible safety net (bills only for stored data).
      az snapshot create --resource-group "$rg" --name "${name}-pre-delete" \
        --source "$diskId" --incremental true
      az disk delete --ids "$diskId" --yes
      echo "deleted $name (snapshot ${name}-pre-delete kept)"
    else
      echo "dry run: would snapshot and delete $name in $rg"
    fi
  done

Quick quiz

Question 1 of 5

Why does an Azure managed disk keep billing after its virtual machine is deleted?

Keep learning

Go deeper on finding, snapshotting and deleting managed disks, and on the Advisor recommendation that flags them.

You can now treat unattached managed disks as a clean, recurring saving rather than a mystery line on the bill: inventory every disk where managedBy is null and diskState is 'Unattached' so Site Recovery disks are excluded, separate the deliberately parked ones with a tag, snapshot anything in doubt, delete the rest to reclaim the full charge, and put the sweep on a schedule so the leak stays shut.

Back to the library

Unattached managed disks: the savings view

Recurring spend with zero workload behind it, and a near risk-free reclaim

This is the rare Azure cost line where the saving is pure subtraction with nothing to weigh against it. An unattached disk produces no value: it runs no workload, serves no request, and supports no service. Every pound it bills is recoverable in full the moment it is deleted, and unlike right-sizing a VM or moving to a reservation, deleting an orphaned disk does not trade performance, commitment or flexibility for the saving. The payback is immediate and the run-rate reduction is permanent.

The arithmetic scales with how long the estate has been running. Each deleted VM that left its data disk behind adds a small, fixed monthly charge that compounds across teams and years. A Premium SSD P10 of 128 GB is on the order of a low-tens-of-pounds-per-month line each, so a few dozen forgotten disks across an estate is a four-figure annual run-rate buying nothing. Microsoft does not publish a single saving figure because it depends entirely on the size and tier of the disks you find, so the number to put in the pack is your own: sum the provisioned size times tier price of every disk the inventory returns.

The only real decision is the safety net. The default move is delete, because the disk serves nothing. Where a team is unsure whether a disk holds data they might want back, take an incremental snapshot first: a snapshot bills only for the data actually stored, on Standard HDD, so it costs a fraction of the live disk and converts an irreversible delete into a reversible one. That converts the last objection to reclaiming this spend into a small, bounded line.

This lesson is for the finance partner who wants to turn a routine cost observation into a recovered run-rate. It covers why the saving is full and immediate, how to size it from the disks the inventory actually returns rather than a guessed figure, and where a small snapshot charge buys the reversibility that lets the team delete with confidence.

Fun fact

The disk that outlived the server by two years

How a finance partner sizes the reclaim

Priya is the finance partner who noticed the storage line on the Azure bill creeping up without a matching rise in workloads. Instead of asking for a target saving, she asks the platform team to run the inventory and hand back the list: every unattached disk with its provisioned size and tier. The list comes back with seventeen disks, and because managed disks bill on size and tier rather than usage, she can price the reclaim exactly: she sums provisioned GB times the per-GB price for each disk's SKU and gets a hard monthly figure, not an estimate.

Two Premium SSD disks dominate the number, a 1024 GB data disk and a 128 GB OS disk left behind when an old database VM was rebuilt, and they are worth more than the other fifteen combined. Priya reframes the work in the savings pack as a run-rate reduction rather than a project: 'Seventeen disks bill the cloud for storage attached to no workload; deleting them removes that line in full from next month, the two Premium disks alone account for most of it, and the only cost is a one-off snapshot of any disk the team is unsure about, which bills at a fraction of the live disk.' There is no payback period to calculate because there is no spend to recover: the saving starts the day the disks are deleted.

Why unattached disks are the cleanest line to reclaim

Most cost work is a trade: right-size a VM and you risk performance, buy a reservation and you commit capital, move tiers and you accept slower retrieval. Unattached disks have no such trade. The disk serves no workload, so deleting it removes spend with nothing on the other side of the ledger. That makes the saving full, immediate and permanent, and it makes the prioritisation trivial: order the disks by provisioned GB times tier price and reclaim the biggest first.

The number is knowable to the pound because managed disks bill on size and tier, not usage, so finance does not have to estimate. Sum the SKU price times provisioned size of every disk the inventory returns and that is the monthly run-rate reduction. The only cost on the other side is a one-off snapshot of any disk a team wants to keep recoverable, which bills only for stored data on Standard HDD and so is a small fraction of the live disk. The finance role here is simply to make the saving visible, fund the trivial snapshot line, and put the sweep on a schedule so it recurs.

What finance can do about unattached-disk spend

Finance cannot delete a disk, but it owns the framing that turns a quiet, growing storage line into a sized, scheduled and recovered saving. Three levers.

1. Price the reclaim from the inventory, not from a guess

Ask the platform team for the list of unattached disks with provisioned size and SKU, and price it directly: sum size times per-GB tier price for each disk. Because managed disks bill on size and tier rather than usage, this is a hard monthly figure, not an estimate. Put the run-rate reduction in the savings pack and order the disks largest first, since a handful of Premium disks usually carry most of the number.

2. Fund the snapshot net so caution does not block the saving

The one thing that stalls a delete is a team being unsure whether a disk holds data they might want. Remove that blocker by funding a small, one-off snapshot line: an incremental snapshot bills only for stored data on Standard HDD, a fraction of the live disk, and makes every delete reversible. It is cheaper to snapshot every doubtful disk than to keep one live disk billing indefinitely out of caution.

3. Put the sweep on a schedule so the saving recurs

A one-off cleanup recovers the backlog; a scheduled inventory keeps the run-rate clean as machines come and go. Ask for the unattached-disk query to run monthly and for the result to land on the cost review, so the saving is protected rather than re-earned each year. Track the count and pound value of unattached disks over time as the metric that tells you the leak is staying shut.

Quick quiz

Question 1 of 5

As the finance partner, how should you size the saving from deleting unattached disks?

Keep learning

Go deeper on finding, snapshotting and deleting managed disks, and on the Advisor recommendation that flags them.

You have finished the finance view of unattached disks. You know the saving is full, immediate and permanent because the disk serves no workload, that it can be priced to the pound from the inventory rather than guessed, and that a small one-off snapshot line is all it costs to make every delete reversible. Next time the storage line drifts up, you will ask for the inventory, size the reclaim, fund the snapshot net, and put the sweep on a schedule so the saving recurs rather than being re-earned each year.

Back to the library

Unattached managed disks: the headline

Money the estate spends every month on storage attached to nothing

Unattached disks are the simplest waste in a cloud bill to explain and the easiest to defend acting on. They are the storage left behind when machines were deleted, still billing at full price, serving no workload at all. Azure's own Advisor flags them as a cost recommendation, so there is no internal judgement call about whether they are waste: the platform already says they are.

The leadership question is not whether to act but whether anyone is looking. Orphaned disks accumulate quietly because deleting a VM does not always delete its storage, and nothing in the bill highlights the gap unless someone checks. The defensible end state is a routine sweep that lists every unattached disk, deletes the genuinely orphaned ones, and parks any deliberate exceptions behind a tag and a snapshot, so the run-rate stays clean rather than drifting upward one forgotten machine at a time.

This is the cost equivalent of free money. There is no workload to disrupt, no service to risk and no commitment to make. The only thing standing between the estate and the saving is the act of looking, which is why it is a fast yes rather than a budget debate.

A short read for the leader who wants to know why money is leaking on storage attached to nothing, why acting on it carries essentially no operational risk, and what a defensible end state looks like so the leak does not quietly reopen.

Fun fact

The disk that outlived the server by two years

What it looks like when waste is swept on a schedule, not by accident

A finance review flagged that the Azure storage line had grown faster than the business, and the question came back: are we paying for things we do not use? The honest answer was that nobody was systematically looking, so orphaned disks from years of deleted machines had been billing quietly the whole time.

The platform team's response was to stop treating it as a one-off cleanup and make it a routine. They ran the inventory, deleted the genuinely orphaned disks after snapshotting the handful anyone was unsure about, tagged the few that were parked on purpose so the next sweep would skip them, and put the same query on a monthly schedule. The next time finance asked, the answer had changed from 'we think there might be some waste' to 'we sweep unattached disks every month, here is what last month's removed, and the only ones left are tagged exceptions with an owner.' That shift, from waste accumulating unnoticed to waste being removed on a cadence, is the durable win, and the saving recurs every month rather than once.

Why this is the fastest yes in the cost portfolio

Across a cost-optimisation programme, most items carry a trade-off that needs weighing: commitment, performance, engineering effort. Unattached disks carry none. The platform itself flags them as waste through Azure Advisor, there is no workload to disrupt, and the saving is recoverable in full the moment the disks are deleted. This is the item that should clear the fastest because there is nothing to debate.

The only leadership ask is to make it routine rather than heroic. A one-off sweep recovers the backlog, but a scheduled sweep keeps the run-rate clean as new machines come and go. Funding a few minutes of platform time each month to run the inventory, plus a small snapshot line for the cautious deletes, locks in a recurring saving that needs no further decisions.

The leadership move on unattached disks

The executive handle is not to approve individual deletes; it is to require that unattached-disk waste is found and removed on a cadence, with the rare deliberate exceptions named and owned.

1. Approve the sweep as routine, not as a project

Ask for the unattached-disk inventory to run on a schedule and for its results to appear on the cost review. A one-off cleanup recovers today's backlog, but only a recurring sweep keeps the run-rate from drifting back up as machines are deleted over time. The decision to make is to fund the few minutes of platform time per cycle, not to approve each disk.

2. Require a safety net, then expect speed

Because deleting a disk is irreversible, ask that anything the team is unsure about is snapshotted first; the snapshot costs a fraction of the live disk and makes the delete reversible. With that net in place there is no reason for caution to slow the work, so expect the backlog cleared quickly rather than disk by disk over months.

3. Treat parked disks as named, owned exceptions

A small number of unattached disks are kept on purpose: a source image, a disk waiting to re-attach to a rebuilt machine. The leadership requirement is that each is tagged with an owner and a reason so the sweep skips it, not left untagged and indistinguishable from waste. The goal is not zero unattached disks; it is zero unexplained ones.

Quick quiz

Question 1 of 5

At a cost review you ask why the storage line keeps rising. What is the defensible answer you want to hear about unattached disks?

Keep learning

Go deeper on finding, snapshotting and deleting managed disks, and on the Advisor recommendation that flags them.

Two takeaways. Unattached disks are the fastest yes in the cost portfolio: the platform flags them as waste, there is no workload to disrupt, and the saving is recoverable in full on deletion. And the durable win is not a one-off cleanup but a scheduled sweep, with anything in doubt snapshotted first and the few deliberate exceptions tagged and owned, so the run-rate stays clean instead of drifting back up one forgotten machine at a time.

Back to the library

Part of the learning path Kill idle Azure waste

Delete managed disks not attached to a VM

Unattached managed disks: the basics

The disk that outlived the server by two years

Finding orphaned disks across a subscription

How Azure decides a disk is unattached, and why ASR disks are differentdeep dive

What is the impact of leaving unattached disks in place?

How do you reclaim unattached-disk spend safely?

1. Inventory every truly unattached disk

2. Separate orphans from deliberately parked disks

3. Snapshot anything you are unsure about, then delete

4. Stop the leak reopening

Quick quiz

Keep learning

Unattached managed disks: the savings view

The disk that outlived the server by two years

How a finance partner sizes the reclaim

Why unattached disks are the cleanest line to reclaim

What finance can do about unattached-disk spend

1. Price the reclaim from the inventory, not from a guess

2. Fund the snapshot net so caution does not block the saving

3. Put the sweep on a schedule so the saving recurs

Quick quiz

Keep learning

Unattached managed disks: the headline

The disk that outlived the server by two years

What it looks like when waste is swept on a schedule, not by accident

Why this is the fastest yes in the cost portfolio

The leadership move on unattached disks

1. Approve the sweep as routine, not as a project

2. Require a safety net, then expect speed

3. Treat parked disks as named, owned exceptions

Quick quiz

Keep learning

Related cost lessons