By FinOps Beacon · Published October 23, 2026 · Updated October 23, 2026

Unattached Azure disks: find them and check the cost

Yes, an unattached Azure managed disk can still cost money. Detaching a disk does not delete its provisioned storage. But an unattached or “orphaned” disk is only a review candidate: it may hold recovery data or be intentionally retained.

Use the read-only inventory below to find candidates in one subscription, confirm why they exist, and check their cost before requesting a change. Nothing in this guide deletes disks or changes Azure resources. Managed-disk billing depends on disk configuration and applicable charges, not simply whether a VM is attached; see Microsoft's managed disks overview.

1. Find unattached disks in one subscription

Use an Azure CLI session authorized to read the subscription you intend to review. Replace <subscription-id> with that subscription's ID. These examples use Bash line continuation; the commands only read inventory. Keep the explicit subscription argument even if you usually work in the CLI's default subscription.

az disk list \
  --subscription "<subscription-id>" \
  --query "[?diskState=='Unattached']" \
  --output json

The filter returns full records for disks whose reported state is Unattached. Keep the resource ID so disks with similar names cannot be confused. Review the SKU, provisioned size, creation and ownership-update timestamps, attachment references and tags where available. See the Azure CLI disk-list reference.

An empty result only says no matching disks were returned within the successfully queried scope. It is not an estate-wide waste assessment. Check errors and permissions, and review other intended subscriptions separately.

This is a first-pass filter, not a list of every retained disk. For example, Reserved means a disk is attached to a stopped-deallocated VM, while Frozen relates to a hibernated VM. Export and upload states have their own workflows. Microsoft's disk-state reference explains the distinctions.

2. Inspect one disk by its full resource ID

Copy one returned id into this command. Its subscription is part of the full resource ID; check that it is the intended disk before interpreting the result.

az disk show \
  --ids "<full-disk-resource-id>" \
  --output json

This returns full metadata so you can inspect additional fields such as creationData without losing nullable or newly added fields in a projection. It does not establish whether the data stored on the disk is disposable. See the disk-show reference.

Field capitalization can vary with CLI output versions: disk size may appear as diskSizeGB or diskSizeGb, and the ownership timestamp as LastOwnershipUpdateTime or lastOwnershipUpdateTime. Preserve the full metadata and inspect the returned fields instead of assuming a missing projected value means zero size or no history.

• State and attachment references: inspect diskState, managedBy, managedByExtended and maxShares together. Shared disks can have multiple attachment references. Do not reduce the review to an empty single-VM field. See Microsoft's disk-property definitions.
• Timestamps: timeCreated is creation time, not time last used. The ownership-update timestamp can change on attach/detach or a VM start/deallocation, and a new disk may have no value until a state change. Do not substitute creation time for a missing detach date. Microsoft documents these limits in its unattached-disk guidance.
• Missing fields: a null or absent value means you need more evidence. Do not turn missing ownership metadata into a zero-risk conclusion.
• Tags: use owner, application and environment tags as leads to confirm. A missing or outdated tag does not prove there is no owner.

Recheck current state before any later approved action: the inventory is a point-in-time observation, not a lock on the disk.

3. Check ownership, recovery and retention

Ask the workload owner what the disk contains and why it is retained. Check recovery plans, backup and restore needs, Azure Site Recovery relationships, migrations, planned reattachment and applicable retention requirements. If you cannot confirm a dependency, keep the candidate in investigation.

Microsoft's storage review guidance excludes disks with certain Site Recovery tags and active-export states from its candidates. Treat tags such as ASR-ReplicaDisk or asrseeddisk as reasons to investigate that workflow. Their absence does not prove a disk has no recovery role.

A snapshot's existence is not proof that it is current, restorable, complete for your needs or approved as a replacement. Record the recovery requirement and evidence that it is satisfied. Removing one resource can also leave separately billed snapshots or backups.

These are three possible review outcomes, not three savings amounts. A keep or investigate decision can be the correct result even when a disk is incurring charges.

4. Verify the disk's cost and reporting window

1. Match the resource. In Azure Cost Analysis, select the appropriate subscription or billing scope and filter to the disk's full resource ID. Confirm the date range, currency and any other filters; the disk's name alone may be ambiguous.
2. Use a completed observation window. Record the covered dates and inspect relevant meters or charges. Cost data arrives after usage and may change before invoicing. Daily Cost Analysis dates use UTC; align your evidence accordingly.
3. Record the cost basis. Actual cost and Amortized cost answer different questions when purchases or commitments are involved. Amortized views are available only for supported account types. Keep the basis consistent when comparing later periods.
4. Explain a blank or zero. Check access, filters, delayed data, the reporting period and any commitment allocation before concluding the disk is free. A narrow resource filter does not show every related or unallocated charge.
5. Verify the result later. If an approved change is eventually made, inspect later completed cost data and separately retained resources. Historical charges will still appear in earlier usage periods.

Do not calculate a saving by multiplying provisioned GiB by a generic storage price. SKU, tier, region, provisioned performance, eligible reservations and other applicable meters can affect charges. Use recorded cost evidence for the observed period; evaluate any future estimate separately with its assumptions. See Microsoft's disk-billing guidance.

An existing disk reservation does not disappear when a disk is removed. Its benefit may apply to another matching disk, or the hourly reservation benefit may go unused. A resource-level cost reduction therefore does not establish an equal cash saving. See how disk reservation discounts apply.

Microsoft explains Cost Analysis filters and cost views and cost-data availability. A deallocated VM can also retain billed storage: see which charges continue after stopping or deallocating a VM.

5. Copy a disk review record

Select and copy this record into your own ticket or document. Fill it out there; this page has no form and does not collect your review details. Record one disk per decision.

UNATTACHED AZURE DISK REVIEW
Subscription and full disk resource ID:
Inventory observation date/time (UTC):
Disk state, managedBy and managedByExtended:
SKU, provisioned size and relevant configuration:
Creation/ownership-update timestamps and any missing fields:

PURPOSE AND DEPENDENCIES
Confirmed owner, workload and data purpose:
Recovery, backup, Site Recovery or reattachment needs:
Retention requirements and supporting evidence:
Unresolved checks and responsible person:

COST EVIDENCE
Billing scope, resource filter, currency and cost basis:
Completed observation period (UTC dates for daily data):
Observed charges and source/export reference:
Commitment allocation, related resources and coverage gaps:
Future estimate, if any, with separate assumptions:

DECISION
Keep / investigate / request change approval:
Reason, approval owner and next review date:
Current state rechecked before any approved action:
Later completed cost window and observed outcome:
Remaining uncertainty: