Managed Disks are one of the most popular places to look for Azure cost savings. They may not generate the biggest savings on their own, but they are usually easy to investigate — and in larger environments there can be quite a few of them.
One of the first things I check is how many disks are not attached to any VM. These are usually the easiest ones to investigate and clean up.
Start with the easy wins
An unattached disk can be a leftover from a deleted VM, an old migration or a test environment. Before removing it, I usually check the tags, creation date and resource owner to make sure it is really no longer needed.
Once that’s confirmed, there isn’t much more to it: delete the disk and stop paying for it.
And this is where the numbers can become interesting: ten unused 1 TiB Premium SSD P30 disks can easily add up to thousands of dollars per year, depending on the region and pricing model.
It’s also worth remembering that managed disks are billed based on their provisioned size and tier, not simply on how much data they currently contain.
Automating the discovery
I didn’t want to check every subscription manually, so I created a small PowerShell runbook to do it for me. It scans Azure subscriptions for unattached managed disks and exports the results to an Azure Storage Account. The report includes:
- Subscription and resource group
- Disk name and resource ID
- Size and SKU
- Creation date
- Tags
- Operating system type
Tags are particularly useful here because they can make finding the owner much easier. The script only finds potential candidates — it doesn’t delete anything automatically. I prefer to leave the final decision to the resource owner.
You can find the script on GitHub:
GitHub – Azure FinOps Unattached Managed Disks
Not every disk is an easy win
Unattached disks are the simple part. Things get more interesting when a disk is still attached to a VM. A disk may appear as attached to a VM in the Azure portal. However, that does not necessarily mean the operating system is using it. For example, a disk may be attached at the Azure level but never mounted inside the Linux operating system.
On a Linux VM, commands such as these below can help you verify what the operating system actually sees and mounts:
lsblkdf -hfindmnt
The next step is to look at actual disk usage and performance. A disk can be significantly larger than the workload requires or use a more expensive SKU than necessary. I would look at IOPS, throughput and read/write activity before changing the SKU or performance tier.
And be careful with reducing disk size. Increasing a managed disk is straightforward, but making it smaller can require creating a new disk and migrating the data.
So there is more to disk optimization than simply finding the cheapest SKU. You need to make sure the disk has the capacity and performance the workload actually needs.
A practical approach
When looking at managed disks, I usually start with the simple cases and then move towards the more complicated ones.
Managed Disks probably won’t give you the biggest saving in Azure, but they are a good example of the kind of small, repeatable cleanup that can make a difference across a larger environment.
Leave a Reply