Cost

Right-size over-provisioned managed disks

One capability across every VM in the estate: make sure each managed disk's SKU, capacity and performance tier matches the IOPS and storage the workload actually uses, so you stop paying premium rates for headroom nobody touches.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Right-sizing managed disks: the basics

What does an over-provisioned managed disk actually look like?

A managed disk is billed on what you provision, not what you use, and that one rule is where the waste lives. Azure prices Premium SSD by fixed capacity tiers (4, 8, 16, 32, 64, 128, 256, 512, 1024 GiB and up) and rounds any disk up to the next tier, so a disk provisioned at 200 GiB is billed as 256 GiB. A 1 TiB Premium SSD bills at the P30 rate whether the workload drives 100 IOPS or 5,000. Over-provisioning shows up in a few distinct shapes: a Premium disk on a workload that never needs Premium IOPS, a capacity tier far larger than the data on it, or a performance tier that was bumped up for a one-off migration and never bumped back down.

Azure Advisor and the Cost Optimization workbook turn each of these into its own signal. Advisor flags unattached and idle disks directly, and the Cost Optimization workbook surfaces disks whose provisioned SKU, size or performance tier looks out of step with measured usage. They read as separate line items, but they are one job: bring each disk's SKU, capacity and tier back in line with the IOPS and storage the workload genuinely consumes.

Almost all of this is drift, not intent. A disk created as Premium because the VM template defaulted that way, a volume grown to 1 TiB for a migration that finished months ago, a performance tier raised to P50 to rush a data load and never returned to P10. The work is to find every disk whose provisioned configuration outruns its real usage, decide which genuinely need the headroom, and right-size the rest down to the tier that fits.

In this lesson you will learn how Azure prices managed disks, why provisioned configuration drifts away from real usage, and how to right-size SKU, capacity and performance tier across an estate without risking the workloads that genuinely need headroom. You will see the exact az CLI to find over-provisioned disks and the commands and Bicep to bring them back in line.

Fun fact

The terabyte that nobody filled

Because Azure rounds provisioned disks up to the next billing tier, a disk asked for at 130 GiB is billed as 256 GiB, and a disk at 1,025 GiB is billed as 2 TiB. The capacity you never use is invisible: the workload runs fine, the bill is paid, and the gap between provisioned and consumed quietly compounds. Performance tiers do the same. A disk bumped from P10 to P50 to rush a one-off data migration keeps billing at the P50 rate, several times higher, until someone deliberately sets it back, because Azure has no reason to assume the burst was temporary. The single most common managed-disk waste is not a wrong choice; it is a temporary choice that was never undone.

Finding over-provisioned disks across a subscription

Priya is the platform lead at a growing SaaS company whose Azure bill has crept up as the fleet scaled. The Cost Optimization workbook and Advisor both flag managed-disk spend, with Premium disks and oversized capacity tiers spread across two subscriptions that pre-date the team's current sizing standards.

Rather than guess, Priya starts by listing every disk with its SKU, provisioned size and performance tier, so the genuinely demanding workloads can be separated from disks that are simply over-provisioned by default before anything changes.

Start by listing every managed disk with its SKU, size and performance tier. Premium disks at large tiers are the widest-open savings.

$ az disk list --query "[].{name:name, sku:sku.name, sizeGiB:diskSizeGb, tier:tier, attached:managedBy!=null}" -o table

Name Sku SizeGiB Tier Attached

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

reports-data Premium_LRS 1024 P50 True

batch-scratch Premium_LRS 256 P15 True

old-migrate-vol Premium_LRS 512 P20 False

# reports-data is a 1 TiB Premium disk pinned to the P50 tier. Check its real IOPS first.

A large Premium disk on a bumped-up performance tier is the highest-value target. An unattached disk like old-migrate-vol bills its full size for nothing. Check each one's real usage before acting.

How Azure decides what a managed disk costsdeep dive

Three properties on the disk drive almost all of the cost. The first is the SKU ('sku.name'): Premium_LRS, StandardSSD_LRS, Standard_LRS and the newer PremiumV2_LRS, where Premium SSD costs several times what Standard SSD does for the same capacity. The second is the provisioned size ('diskSizeGb'): Azure rounds it up to the next fixed capacity tier and bills the tier, so unused capacity below the next tier boundary is free but capacity above it is billed in full. The third, for Premium SSD only, is the performance tier ('tier'): you can pin a disk to a higher tier such as P50 for more IOPS and throughput without resizing it, and you are billed at that tier's rate until you set it back.

Each property moves independently, and each can drift. A workload that no longer needs Premium IOPS keeps the Premium SKU because nobody converted it. A volume grown for a migration keeps the larger capacity tier because nobody shrank the filesystem and the disk. A performance tier raised for a burst keeps billing high because Azure has no signal that the burst was temporary. The Cost Optimization workbook compares provisioned configuration against measured IOPS, throughput and used capacity to surface exactly these gaps.

The cost-saving levers differ in what they require. Changing the performance tier or shrinking within the same SKU is an online operation with no downtime, and a tier downgrade takes effect immediately. Converting the SKU, for example Premium to Standard SSD, requires deallocating the VM first, because the disk type cannot change while it is attached to a running machine. Knowing which lever needs a maintenance window and which does not is what lets you bank the risk-free savings today and schedule the rest.

What is the impact of leaving disks over-provisioned?

The direct impact is recurring spend on capacity and performance nobody uses. Every over-provisioned disk bills its higher rate every hour it exists, and because storage is provisioned once and rarely revisited, that waste compounds silently for the life of the disk. A fleet that scaled up and then optimised its compute can still be carrying the disk footprint of its peak, paying Premium rates and large capacity tiers for workloads that shrank or moved.

The second-order impact is that the waste is invisible until you look. An over-provisioned disk does not fail, slow down or raise an alert; the workload runs perfectly on storage it half uses. That is exactly why disk right-sizing is so often left undone: nothing breaks, so nothing prompts the review, and the gap between provisioned and consumed quietly widens as the estate grows.

On the savings side, managed disks are one of the more reliable places to recover cloud spend without touching the workload. Microsoft's own disk cost-optimisation guidance treats right-sizing SKU, capacity and tier as a primary lever, and the newer Premium SSD v2 model, which prices capacity, IOPS and throughput independently with a base of 3,000 IOPS and 125 MB/s included, lets you stop paying for performance headroom you never drive. The recovered spend is recurring, it lands the hour the change is made, and most of it carries no performance cost at all.

How do you right-size disks safely?

Work the capability as one loop rather than chasing individual findings. The order matters: confirm real usage before you downgrade anything, so you bank the risk-free savings first and only model the trade-offs that actually exist.

1. Inventory every disk by SKU, size and tier

List every managed disk with its SKU, provisioned size, performance tier and whether it is attached. Treat this inventory, joined to measured IOPS, throughput and used capacity from monitoring, as the source of truth. One disk can be over-provisioned on more than one axis at once: a Premium SKU and an inflated capacity tier and a bumped performance tier.

2. Separate risk-free downgrades from trade-off calls

Most over-provisioning is unintended. A disk that never approaches its tier's IOPS can drop tiers with no trade-off; a disk that never needs Premium can convert to Standard SSD; a volume with free space to spare can shrink. The few that occasionally burst above a lower tier are the trade-off calls: model the saving against how often the burst actually matters before deciding.

3. Bank the no-downtime savings first

Performance-tier downgrades and capacity changes that do not cross a VM-deallocation boundary are online operations: run them and the rate drops immediately with no maintenance window. Do these first to bank the saving fast. Snapshot then delete genuinely unattached disks. Note that a Premium SSD performance tier can be downgraded only once every 12 hours, so plan the step down.

4. Schedule the SKU conversions and keep it reviewed

Converting SKU, for example Premium to Standard SSD, needs the VM deallocated, so batch these into a maintenance window. Then keep it from drifting back: put a quarterly right-sizing pass on the cadence, and consider Premium SSD v2 for new workloads so capacity, IOPS and throughput are provisioned, and paid for, independently against real demand.

# Bank the no-downtime saving first: drop an over-provisioned Premium
# performance tier back to its baseline. Online, takes effect immediately.
# A 1 TiB disk's baseline tier is P30, so P30 is as low as reports-data
# can go (you can't set a tier below the disk's baseline).
# (Tier downgrades are allowed only once every 12 hours.)
az disk update \
  --resource-group rg-prod \
  --name reports-data \
  --set tier=P30

# Convert a Premium disk that never needs Premium IOPS to Standard SSD.
# The SKU change requires the VM deallocated first, so schedule a window.
az vm deallocate --resource-group rg-prod --name vm-batch
az disk update \
  --resource-group rg-prod \
  --name batch-scratch \
  --sku StandardSSD_LRS
az vm start --resource-group rg-prod --name vm-batch

# Snapshot then delete a genuinely unattached disk billing for nothing.
az snapshot create \
  --resource-group rg-prod \
  --name old-migrate-vol-snap \
  --source old-migrate-vol
az disk delete --resource-group rg-prod --name old-migrate-vol --yes

Quick quiz

Question 1 of 5

Advisor and the Cost Optimization workbook flag managed-disk spend across SKU, capacity and performance tier on several disks. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure prices managed disks and the levers for bringing provisioned configuration back in line with real usage.

You can now treat managed disks as one savings capability rather than a scatter of findings: inventory every disk's SKU, capacity and tier against measured usage, bank the risk-free downgrades that lower the rate with no trade-off, schedule the SKU conversions that need a maintenance window, reclaim the unattached disks, and keep it on a cadence so the saving does not creep back. Most of it costs nothing in performance and lands the hour you run the command.

Back to the library

Right-sizing managed disks: the savings view

A recurring, compounding line item on the Azure bill that you can cut without touching the workload

Managed-disk over-provisioning is pure recurring waste: you pay the higher rate every hour the disk exists, for headroom no workload uses. The saving is immediate and it compounds, because a Premium-to-Standard SSD conversion or a performance-tier downgrade lowers the hourly rate from the moment it lands and keeps lowering it for the life of the disk. Microsoft documents the cut as material: its own disk cost-optimisation guidance frames right-sizing SKU, capacity and tier as one of the larger block-storage savings available, and a Premium SSD costs several times what the equivalent Standard SSD does.

Frame each flagged disk as a recurring line item, not a one-off fix. A 1 TiB Premium disk billed at the P30 rate while the workload drives a few hundred IOPS is money leaving every month until someone acts. The payback on the engineering time is effectively instant: a single 'az disk update' command changes the rate, and there is no migration project behind a tier downgrade.

The ROI here is one-sided in a way most cost work is not. The downgrades that carry no performance trade-off, converting a disk that never needs Premium IOPS, shrinking a capacity tier with free space to spare, are risk-free savings. The handful that do carry a trade-off, a disk that occasionally bursts above its lower tier, are a measured call: model the saving against the rare moment it matters, and the answer is usually still in favour of right-sizing.

This lesson is for the finance partner who sees a managed-disk line on the Azure bill that keeps climbing and wants to know how much of it is recoverable and how fast. It covers which right-sizing moves are risk-free savings, which carry a trade-off worth modelling, and how to turn a list of Advisor findings into a payback-ordered plan where the spend falls the hour each change lands.

Fun fact

The terabyte that nobody filled

How a finance partner frames the disk right-sizing decision

Priya is the finance partner working with the platform team on a cloud-cost review. The managed-disk line has grown to a meaningful share of the bill, and the Cost Optimization workbook lists fourteen disks flagged as over-provisioned or idle across two older subscriptions. The instinct is not to wave through the whole list as savings; it is to ask what each disk actually does. Converting a Premium disk that never needs Premium IOPS to Standard SSD, or downgrading a performance tier that was bumped for a finished migration, lowers the hourly rate the moment it lands and keeps lowering it. The unattached disk billing its full 512 GiB for nothing is a pure deletion saving once a snapshot is taken.

Priya asks the team to map each flagged disk to its measured usage. The 1 TiB reports disk sits on P50 but drives a few hundred IOPS, so it can drop to its P30 baseline with no trade-off; a Standard-SSD-eligible batch volume can convert and halve its rate; the unattached migration disk can be snapshotted and deleted. The finance pack reads: 'Most of this is risk-free recurring saving that lands the hour we run the command; two disks carry a small burst trade-off worth modelling; the only thing between us and a lower bill is a few az updates and a maintenance window for the SKU conversions, not a project.'

Why disk right-sizing is the cleanest line on the cost review

The savings model here is unusually clean. The change lowers the hourly rate from the moment it lands, the saving recurs for the life of the disk, and most right-sizing carries no performance trade-off, so there is no offsetting risk cost to net against it. A Premium-to-Standard SSD conversion or a P50-to-P10 tier downgrade is a rate cut you keep collecting every hour, not a one-off rebate.

The payback on engineering time is effectively instant. A performance-tier downgrade or a capacity shrink is a single command with no downtime; a SKU conversion needs a short maintenance window but no migration project. Against the recurring saving, that effort is trivial. The finance role is to order the work by recoverable spend, separate the risk-free downgrades from the few that carry a burst trade-off worth modelling, and make sure the savings are tracked as a banked, recurring reduction rather than a one-time number that quietly creeps back as new disks are provisioned generously again.

What finance can do about the disk gap

Finance cannot run an az update, but it owns the framing that turns a scatter of Advisor findings into a payback-ordered plan where the spend falls the hour each change lands. Three levers.

1. Separate the risk-free savings from the trade-off calls

Make explicit that most disk right-sizing is risk-free recurring saving: a tier downgrade on a disk that never approaches its IOPS, or a Standard SSD conversion for a workload that never needs Premium, lowers the rate with no offsetting performance cost. Only the few disks that occasionally burst above a lower tier carry a trade-off worth modelling. Budget the savings as a banked, recurring reduction and flag the trade-off cases as a separate, smaller decision, so nobody dismisses the whole capability as risky.

2. Order the work by recoverable spend, not by finding count

A 1 TiB Premium disk pinned to P50 and a small over-provisioned scratch disk both show up as a single Advisor finding, but the recurring spend they carry differs by an order of magnitude. Ask the team to attach the monthly rate delta to each flagged disk and order the work by that, biggest recoverable spend first. The metric that belongs on the cost review is realised monthly saving banked, not the raw count of findings closed.

3. Stop the savings from creeping back

Right-sizing erodes if new disks are provisioned generously by default and never revisited. Require a quarterly right-sizing pass so the banked saving stays banked, and make over-provisioning visible at provisioning time. For new workloads, Premium SSD v2, where capacity, IOPS and throughput are paid for independently, keeps spend aligned to real demand from day one rather than relying on a later cleanup.

Quick quiz

Question 1 of 5

The Cost Optimization workbook flags fourteen over-provisioned or idle disks. As the finance partner, what is the right starting assumption about the saving from right-sizing them?

Keep learning

Go deeper on how Azure prices managed disks and the levers for bringing provisioned configuration back in line with real usage.

You have finished the finance view of right-sizing managed disks. You know the savings model is one-sided: most downgrades carry no performance trade-off, the lower rate is billed from the hour the change lands, and the saving recurs for the life of the disk. Next time a cluster of disk findings appears, you will order them by recoverable spend, separate the risk-free wins from the few trade-off calls, and track realised recurring saving banked rather than a count of findings closed.

Back to the library

Right-sizing managed disks: the headline

Whether the estate pays premium storage rates for capacity and performance nobody uses

Storage is the quiet line on the cloud bill that grows by default. Disks are provisioned generously, workloads shrink or move, and nobody resets the disk, so the estate keeps paying premium rates for headroom that went unused months ago. Advisor and the Cost Optimization workbook show this as a scatter of separate findings, but the headline is one number: the recurring spend on disk capacity and performance the business does not consume.

The leadership question is not 'is storage cheap per gigabyte?' It is 'are we paying for what we use, or for what we provisioned and forgot?' The defensible end state is that disk SKU, capacity and tier are reviewed against real usage on a cadence, the risk-free downgrades are taken, and the few disks that genuinely need premium performance are a documented, owned decision.

This is a savings decision with almost no downside. Most right-sizing carries no performance trade-off at all, the change is reversible, and the payback is immediate. It is the kind of recurring saving that compounds quietly across a large estate, which is exactly why it tends to be left on the table.

A short read for the leader who needs to know why premium storage spend grows by default, why right-sizing it is a savings decision with almost no downside, and what a defensible, reviewed-on-a-cadence end state looks like across the estate.

Fun fact

The terabyte that nobody filled

What it looks like when storage spend tracks usage, not provisioning

After a finance review showed the managed-disk line had grown faster than the workload it supported, the CFO asked the obvious question at the next planning session: are we paying for storage we use, or storage we provisioned and forgot? The honest answer at the time was that nobody knew, because disk SKU, size and performance tier were set at deployment and almost never revisited.

The team's response was to stop treating disk sizing as a one-time deployment choice and start treating it as a recurring review. They listed every disk with its SKU, capacity and tier alongside its real IOPS and used space, took the risk-free downgrades immediately, scheduled the SKU conversions that needed a brief deallocation, and put a quarterly right-sizing pass on the cadence. The next time the CFO asked, the answer had changed from 'we think it is fine' to 'storage spend now tracks usage, the easy savings are banked and recurring, and the few disks that genuinely need premium performance are a documented, owned decision.' That shift, from provisioning generously and forgetting to paying for what is actually consumed, is the recurring savings signal this capability delivers, and most of it carries no performance trade-off at all.

Why this is a recurring savings lever worth a cadence

Almost every estate that has optimised compute still carries over-provisioned storage, because disks are set at deployment and rarely revisited. Right-sizing them is the capability that closes that gap, and a quarterly review keeps it closed as the fleet grows. The saving is recurring, it compounds across a large estate, and most of it carries no performance trade-off.

The cost of getting this wrong is not a breach or an outage; it is a steady, invisible overpayment that nobody is accountable for. The cost of fixing it is a few commands and an occasional maintenance window. This is the rare class of cost work where the saving is immediate and recurring and the downside is close to zero, which is exactly the trade leadership should be quickest to approve and put on a cadence.

The leadership move on disk right-sizing

The executive handle is not to approve each downgrade individually; it is to require that disk spend tracks usage, that the risk-free savings are banked, and that right-sizing is on a recurring cadence so the saving does not creep back.

1. Ask for the recoverable number and a date to bank it

Ask the team for the recurring monthly spend tied to over-provisioned and idle disks, and a date by which the risk-free downgrades are taken and the SKU conversions are scheduled. Because most of it carries no performance trade-off and the saving lands the hour the change is made, there is little reason to delay the easy wins behind a long planning cycle.

2. Put it on a cadence, not a one-off

A single right-sizing sweep saves money once; a quarterly review keeps it saved as the fleet grows and new disks are provisioned. Treat right-sizing as a standing cost-hygiene cadence with a named owner, and track realised recurring saving over time, so the banked reduction does not quietly creep back as the estate scales.

3. Treat the genuinely premium disks as named, owned exceptions

A small number of disks genuinely need Premium SSD or a high performance tier, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a usage justification, not a default nobody revisited. The goal is not zero Premium disks; it is zero Premium disks that nobody can explain.

Quick quiz

Question 1 of 5

At a planning review you ask whether the estate pays for storage it uses or storage it provisioned and forgot. What end state is the defensible answer?

Keep learning

Go deeper on how Azure prices managed disks and the levers for bringing provisioned configuration back in line with real usage.

Two takeaways. Disk right-sizing is the rare cost lever where the saving is immediate and recurring and the downside is close to zero, so it is the trade you should be quickest to approve. And a single sweep is not enough: put right-sizing on a quarterly cadence with a named owner, bank the risk-free savings, and keep the few genuinely premium disks as documented, owned exceptions, so spend tracks usage as the estate grows.

Back to the library

Part of the learning path Cut your Azure storage bill

Right-size over-provisioned managed disks

Right-sizing managed disks: the basics

The terabyte that nobody filled

Finding over-provisioned disks across a subscription

How Azure decides what a managed disk costsdeep dive

What is the impact of leaving disks over-provisioned?

How do you right-size disks safely?

1. Inventory every disk by SKU, size and tier

2. Separate risk-free downgrades from trade-off calls

3. Bank the no-downtime savings first

4. Schedule the SKU conversions and keep it reviewed

Quick quiz

Keep learning

Right-sizing managed disks: the savings view

The terabyte that nobody filled

How a finance partner frames the disk right-sizing decision

Why disk right-sizing is the cleanest line on the cost review

What finance can do about the disk gap

1. Separate the risk-free savings from the trade-off calls

2. Order the work by recoverable spend, not by finding count

3. Stop the savings from creeping back

Quick quiz

Keep learning

Right-sizing managed disks: the headline

The terabyte that nobody filled

What it looks like when storage spend tracks usage, not provisioning

Why this is a recurring savings lever worth a cadence

The leadership move on disk right-sizing

1. Ask for the recoverable number and a date to bank it

2. Put it on a cadence, not a one-off

3. Treat the genuinely premium disks as named, owned exceptions

Quick quiz

Keep learning

Related cost lessons