Why this matters
Azure bills managed disks by provisioned size and SKU, not by how full they are. A 1 TiB Premium SSD that holds 80 GB costs the same as one that holds 800 GB. Snapshots work the same way: the first snapshot stores a full copy, later incremental snapshots store changed blocks, and the chain keeps billing until you delete it.
Disks get left behind when a VM is deleted, a cluster is rebuilt or a project moves on. A deallocated VM still owns its disks. A deleted VM may keep its OS disk if the delete option was off. Old snapshots pile up because no one owns the retention rule. Cost Management shows the spend, but it does not show the application owner.
The fix is a sequence, not a single setting. Build an inventory, agree on owners, delete the clear orphans, rightsize the rest and set a snapshot retention rule. Do the cheap deletions first so the later work starts from a smaller list.
Before you start
You need Reader on each subscription, Cost Management Reader for the cost export and delete rights in the resource groups you will clean. Ask for a maintenance window before any change that needs a disk detach or a data copy. Export 30 days of cost data with resource IDs and tags so you have a before picture.
List every managed disk with diskState, managedBy, diskSizeGB, sku.name, tier and timeCreated. Azure Resource Graph can return that across subscriptions in one query. Do the same for microsoft.compute/snapshots and include creationData.sourceResourceId so you can see the source disk. Azure Advisor flags unattached disks and underused VMs, but it will not catch every old snapshot.
Tag each disk by role: OS, data, backup or migration. Skip the VM temporary disk because it is local storage and not a managed disk. Mark disks that must stay for recovery, legal hold or a pending migration. Get the app owner to agree in writing before anything is deleted.
How to do it
Work from the inventory, not from a portal list. The portal hides some unattached disks and does not show an owner. A Resource Graph query returns all subscriptions in one table, so you can sort by size, age and tag coverage.
Change one group at a time. Delete clear orphans first, then rightsize the largest disks, then tighten snapshot retention. After each group, watch disk latency and app health for a day before you move on.
- Export the disk and snapshot baseline. In Cost Management, create an export for each subscription with resource details and tags. Group cost by resource and meter to separate managed disks, snapshots and unmanaged VHDs. Save the file as your before baseline.
- Find unattached and orphaned disks. Run a Resource Graph query for microsoft.compute/disks where diskState is Unattached or managedBy is empty. Pull resource group, size, SKU, tags and creation time. Check each disk against backup jobs and recovery plans before you delete it.
- Delete the clear orphans. Delete disks that are not attached and have no owner. If you need a final copy, take one incremental snapshot, tag it with an expiry date, then delete the disk. Turn on Delete with VM for new OS and data disks so the next cleanup is smaller.
- Rightsize by used space and IOPS. Check used space inside the guest with df or Get-Volume, and check Azure Monitor disk IOPS and throughput at peak. Compare that with the provisioned size and SKU. For Premium SSD v2 and Ultra Disk, lower IOPS and throughput first when the workload does not need them.
- Shrink with a copy, not in place. Azure managed disks cannot be shrunk in place. Create a smaller disk of the target SKU, copy the data, attach it to a test VM, then swap it in during a maintenance window. Keep the old disk until the app passes its checks.
- Set a snapshot retention rule. Use incremental snapshots and write down a retention rule, such as daily for 14 days and weekly for 8 weeks. Apply the rule through an Azure Backup policy or an Automation runbook that deletes snapshots past their expiry tag. Do not rely on storage account lifecycle rules for managed disk snapshots.
- Remove snapshots with no source disk. Query snapshots where creationData.sourceResourceId points to a disk that no longer exists. Confirm the snapshot is not the only recovery copy for an app. Delete the rest and tag the keepers with an owner and expiry date.
- Clean up unmanaged VHDs. List page blobs with the .vhd suffix in storage accounts that still hold unmanaged disks. Check last access time and the VM or image that used them. Delete the ones that are not part of a restore or migration.
- Add tags and budget alerts. Require owner, environment and costCenter tags with Azure Policy on new disks and snapshots. Create a budget alert on each resource group that holds production disks. Review the untagged list every month.
How to check it worked
Pull the same Cost Management export after a full billing cycle. Compare the disk and snapshot meters by resource group, not just the total. You want fewer provisioned GiB. A lower total with a spike in snapshots means you moved the cost, not removed it.
Run the Resource Graph queries again. Count unattached disks, snapshots past expiry and untagged disks. Those counts should fall and stay down. A one time cleanup that creeps back in two months is not a fix.
Watch disk latency, IOPS and queue depth for two weeks after each rightsize. Restore one test VM from a kept snapshot. If the restore works and the app meets its service level, the new retention rule is safe.
Mistakes to avoid
Do not delete snapshots before you test a restore. A snapshot is a recovery point, not a spare copy. Keep the oldest copy that your recovery plan needs and confirm the source disk before you delete anything.
Do not shrink an OS disk by guessing. Windows boot volumes and Linux fstab entries can point to disk IDs or UUIDs. Copy, test, then swap. Do not move a busy database from Premium SSD to Standard SSD just to save on capacity; latency will show up under load.
Do not trust deallocation to stop disk charges. A stopped (deallocated) VM still owns its disks. Delete the VM and the disks separately, or set Delete with VM where it fits. Check other subscriptions too, because orphaned disks often sit in old sandbox subscriptions.
Do not tune Premium SSD v2 or Ultra Disk by size alone. IOPS and throughput are separate settings. If you leave them at the old peak, you have not fixed the bill. If you would rather have someone trace the spend, the Cloud cost audit from Cloudverg is a fixed price of $4,500 and runs for two weeks; it is one option among others.
Frequently asked questions
How do I find unattached managed disks in Azure?
Use Azure Resource Graph to query microsoft.compute/disks where diskState is Unattached or managedBy is empty. Include resource group, size, SKU, tags and creation time in the result. Confirm that no backup or recovery plan depends on a disk before you delete it.
Are Azure managed disk snapshots full or incremental?
Azure managed disk snapshots are incremental after the first one. The first snapshot stores a full copy, and later snapshots store changed blocks. Billing follows the stored blocks and snapshot metadata, so a long chain still costs money even when each snapshot is small.
Can I shrink an Azure managed disk?
You cannot shrink a managed disk in place. Create a smaller disk, copy the data, test the boot or mount, then swap it in and delete the old disk. For Premium SSD v2 and Ultra Disk, lower IOPS and throughput first because those settings bill separately from capacity.