Right-sizing Azure managed disk IOPS: stop paying P30 prices for P10 workloads

Premium SSD bills by the size tier you provisioned, not by what you use. A 1 TiB P30 running at 5% utilization costs exactly the same as one running flat out — and most fleets are full of P30s someone picked "to be safe." Here is the runbook I use to find them and fix them, including the part where you learn you cannot shrink a disk.

New to cloud? CAMPUX is a free, build-first course. Start here →

To reduce Azure managed disk costs, measure each disk's real P95 IOPS and throughput in Azure Monitor over two to four weeks, map those numbers against the Premium SSD tier ladder, and move any disk that fits two tiers down — knowing you can grow a disk in place but never shrink one. That last clause is the part most cost guides skip, and it changes how you do the whole exercise.

First, the billing model, because everything follows from it. Premium SSD (v1) is billed by size tier, not by usage. When you create a 1 TiB premium disk, Azure rounds you into the P30 tier and charges you the P30 rate every month. It does not matter whether the disk serves 200 IOPS or 5,000. There is no meter running on your actual reads and writes the way there is on, say, a transaction-billed standard HDD. You bought a bucket of capacity, IOPS, and throughput, and you pay for the bucket.

This is not a scandal — it is how provisioned-performance storage works, and it is what makes premium disk latency predictable. But it has a consequence that shows up on almost every Azure bill I have reviewed: disks get sized for fear, not for load. Someone stood up a SQL VM three years ago, did not know what it would need, and picked 1 TiB "to be safe." The database is 180 GB and does 800 IOPS at its wildest. Nobody has looked since, because the VM works fine — it has six times the headroom it needs, and you pay for all of it, every month.

Disk spend is usually the second line on a VM fleet bill after compute itself. If you have already read our piece on cutting Azure costs generally, this is the deep, specific version of one line item — the one that is pure waste when it is wrong, because unused IOPS deliver nothing at all.

Step 1: Measure reality before touching anything

The cardinal rule of right-sizing is that you never resize on a guess, a vibe, or what the app team says they need. You measure. Azure Monitor already collects everything you need at the platform level, free, with no agent required:

• Data Disk IOPS Consumed Percentage — what fraction of the disk's provisioned IOPS you are actually using. This is the single most useful metric here, because it does the tier math for you.
• Data Disk Bandwidth Consumed Percentage — same idea for throughput. A disk can be quiet on IOPS and hot on throughput (large sequential reads, backups), so check both.
• Data Disk Read Bytes/sec and Write Bytes/sec, plus Data Disk Read/Write Operations/Sec — the absolute numbers, which you will need when mapping to a target tier.
• The OS Disk equivalents of all of the above — OS disks are over-provisioned even more often than data disks, because they get created by default at whatever size the image suggested.

Now the trap, stated explicitly because it catches nearly everyone: do not look at averages. The average IOPS of almost any business workload is embarrassingly low, because most disks sit near idle most of the time. Size to the average and the disk falls over during the one window that matters. Instead, look at the 95th percentile over two to four weeks, with a window that includes the real peaks — month-end close, the weekly batch job, the Sunday full backup. A disk that idles for 29 days and needs 4,000 IOPS on invoice day is a 4,000-IOPS disk. P95 over a long-enough window tells you that; the average lies to you.

Size to the 95th percentile including month-end, not to the average. The average of a spiky workload is a number that describes nothing.

Practically: open the VM in the portal, go to Metrics, chart Data Disk IOPS Consumed Percentage with the aggregation set to Max, over 30 days. If the line never crosses 30–40%, you have found money. Do this across the fleet with a Kusto query against the metrics or with Azure Advisor's disk recommendations as a starting hint — but treat Advisor as a tip line, not a verdict, and confirm with the metrics yourself.

Step 2: Know the ladder you are standing on

Premium SSD v1 tiers are determined by disk size. Here are the common rungs. These are stable, published specs, but Microsoft does adjust them occasionally — verify against the current managed disk types page on learn.microsoft.com before you commit a change, and get prices from the official Azure pricing page rather than any blog, including this one.

Read the ladder with your P95 numbers in hand and the decision rule is simple: if your P95 IOPS and throughput both fit comfortably inside a tier two rungs down, you are paying for headroom you never touch. One rung down is a judgment call — you want some margin above P95, and growth happens. Two rungs down is not a judgment call; it is a finding. The 1 TiB P30 doing 800 IOPS and 40 MB/s at peak fits inside a P15 with room to spare. That disk is billing at roughly four times the tier it needs, month after month.

Notice P40 and P50 share the same IOPS and throughput. Past P30, you are mostly buying capacity, not performance — which is its own flag: if someone provisioned a P50 "for the IOPS," they bought the wrong thing entirely.

Step 3: The mechanics — and the asymmetry nobody warns you about

Here is where the exercise stops being a spreadsheet and starts being change management. Azure's resize rules are asymmetric:

• Growing a disk is easy. You can expand a managed disk, and in most current configurations you can do it without downtime, then extend the partition inside the OS. Going up the ladder is a few minutes of work.
• Shrinking a disk is not supported. At all. There is no button, no CLI flag, no support ticket that makes a 1 TiB managed disk into a 256 GiB one. The only path down is: snapshot the disk, create a new smaller disk, copy or restore the data onto it (or use a smaller disk restored from backup), deallocate the VM, and swap the old disk for the new one. That is downtime, a maintenance window, and a rollback plan.

This asymmetry is why the single highest-value habit is right-sizing on the way in. Every new disk should be created at the tier the measured or honestly-estimated workload needs, because going up later is trivial and going down later is a project. If your team's default answer to "how big should the disk be" is "1 TB to be safe," you are manufacturing next year's cleanup work at a premium rate.

The escape hatch: performance tier changes without resizing

There is one genuinely useful wrinkle on Premium SSD v1. As of 2026, Azure lets you set a disk's performance tier independently of its size — upward. A 128 GiB disk (P10 by size) can run at P20 or P30 performance for a known busy period, then return to its baseline. You pay the higher tier's rate while it is set, but you avoid permanently resizing a disk for a temporary need: year-end processing, a migration weekend, a bulk load. Check the current constraints on learn.microsoft.com — rules about minimum durations and allowed tiers have shifted — but the capability is real, and it is the closest thing v1 has to paying for performance only when you need it.

When Premium SSD v2 makes the whole problem go away

Everything above is a workaround for one design decision: v1 couples performance to size. Premium SSD v2 uncouples them. You provision capacity in GiB increments, then dial IOPS and throughput up or down as separate line items, each with its own price. A 200 GiB disk that needs 4,000 IOPS is just… a 200 GiB disk with 4,000 IOPS. The "buy a terabyte to get the IOPS" pattern — the entire reason this article exists — disappears.

So why isn't everything on v2? Honest caveats, as of 2026:

• Regional and feature availability is not universal. v2 has expanded steadily, but there are still regions, zone configurations, and scenarios where it is unavailable or restricted.
• No host caching. v1 premium disks can use the VM host's read/write cache; v2 disks cannot. For read-heavy workloads that lean on ReadOnly host caching, this is a real performance consideration, not a footnote.
• Feature gaps around specific scenarios — certain backup, disk-encryption, and OS-disk configurations have had restrictions. Some have been lifted; check the current limitations list on learn.microsoft.com before you plan a migration, because this list changes faster than any blog post can track.

My working rule: for new data disks on supported VMs in supported regions, v2 should be the default you have to argue your way out of. For existing v1 fleets, migrate opportunistically — when you are already rebuilding a VM, or when a single disk's overpayment is large enough to justify the swap downtime on its own.

When Standard SSD is simply enough

Some disks should not be premium at all. Dev and test environments, low-traffic app servers, utility boxes, disks that hold installers and log archives — these do not need premium latency, and Standard SSD serves them at a substantially lower rate with reasonable reliability characteristics. The tell in your metrics: single-digit IOPS consumption on a premium disk attached to something with "dev" or "tools" in its name. Our comparison of Azure disk types walks the full decision tree, and managed disks explained covers the fundamentals if the tier system is new to you. One caution: Standard SSD has lower IOPS ceilings and looser latency behavior, so keep it away from anything a database or a latency-sensitive app touches.

Bursting: the free escape valve on small tiers

Here is the fact that makes aggressive downsizing safer than it looks: P20 disks and below burst. Credit-based bursting lets a small premium disk spike to 3,500 IOPS and 170 MB/s for up to about 30 minutes at a stretch, banking credits while it idles. It is on by default and costs nothing. That P15 you were nervous about — 1,100 provisioned IOPS against a workload that touches 2,000 for ten minutes each morning — handles the spike on burst credits and never notices. Bursting is precisely designed for spiky-but-mostly-idle workloads, which is what most over-provisioned disks turn out to be.

For P30 and above, credit bursting does not apply, but on-demand bursting exists as a paid feature — an enablement fee plus charges for burst usage beyond provisioned targets. The specifics (caps, fees, which sizes qualify) are worth verifying on the current docs before you rely on them. It is occasionally the right answer for a big disk with one wild day a month, but run the numbers: sometimes the honest fix is a v2 disk with the dials set correctly.

The honest gap: disks are half the job, and not silently yours to change

Two things the tidy version of this runbook leaves out.

First, disk right-sizing without VM right-sizing is half a job. Compute is the number-one line on the bill; disks are usually number two. The same fear-driven over-provisioning that produced the P30 also produced the D8s v5 running at 12% CPU next to it — and the VM size itself caps the disk performance you can actually reach, so an oversized disk on an undersized VM was never delivering its IOPS anyway. Do both passes together: VM sizes and series covers the compute side, and once the sizes are honest, reservations vs savings plans is how you lock in the rate on what remains. Right-size first, then commit — committing to an oversized fleet just discounts the waste.

Second, storage changes are app-owner conversations, not silent platform changes. You are the one reading the metrics, but the app team owns the risk. A downsize needs a maintenance window they agree to, a peak calendar they confirm ("is month-end really the worst it gets, or is there an annual audit run?"), and a rollback plan they have seen. I have watched a technically correct downsizing get reversed at cost — new disk, second migration, two windows instead of one — because nobody asked about the quarterly data warehouse refresh. The metric window covers a month; institutional memory covers the year. Use both. Platform teams that resize other people's disks quietly are the reason platform teams lose the authority to resize anything.

The runbook, compressed

1. Pull metrics: Data Disk / OS Disk IOPS Consumed % and Bandwidth Consumed %, P95 over 2–4 weeks, window covering real peaks.
2. Map to the ladder: compare P95 IOPS and throughput against the tier table above (verify current specs on learn.microsoft.com).
3. Apply the rule: fits two tiers down with margin, including burst behavior for P20-and-below targets → candidate for downsizing.
4. Talk to the app owner: confirm the peak calendar, agree a window, write the rollback.
5. Execute: snapshot → new smaller disk → deallocate → swap. Or, for temporary needs, change the performance tier instead of the size.
6. Fix the intake: new disks get measured sizes; Premium SSD v2 by default where it is supported; Standard SSD for dev/test.
7. Do compute in the same pass — then, and only then, look at reservations.

Questions people also ask

How do I check if my Azure managed disk is over-provisioned?

Open Azure Monitor metrics for the VM and chart Data Disk IOPS Consumed Percentage and Data Disk Bandwidth Consumed Percentage (plus the OS disk equivalents) over the last two to four weeks. If the 95th percentile sits under roughly 30 to 40 percent of the disk's provisioned limits — including any month-end or batch-window peaks — the disk is over-provisioned and would fit a smaller tier. Do not judge on averages; averages hide the spikes that actually matter.

Can I shrink an Azure managed disk to a smaller size?

No. Azure lets you grow a managed disk in place but there is no supported way to shrink one. To move to a smaller tier you snapshot the disk, create a new smaller disk, copy or restore the data into it, deallocate the VM, and swap the disks. That takes downtime and planning, which is why right-sizing on the way in — when the disk is first created — is worth far more than cleanup later.

Does Azure charge for disk IOPS I don't use on Premium SSD?

Effectively yes. Premium SSD (v1) is billed by the size tier you provision — P10, P20, P30 and so on — and each tier carries fixed IOPS and throughput. You pay the tier price whether you use 5 percent of those IOPS or 95 percent. There is no usage-based refund. Premium SSD v2 works differently: capacity, IOPS and throughput are priced as separate dials, so unused performance is performance you simply do not buy.

Can I change an Azure disk's performance tier without resizing it?

On Premium SSD (v1), yes — as of 2026 Azure lets you set a disk's performance tier above its size-based baseline without changing its size, and later set it back down. A 128 GiB disk can temporarily run at P20 or P30 performance for a known busy period, then return to its baseline. Check the current rules on learn.microsoft.com before relying on it, because minimum durations and tier limits have shifted over time.

Is Premium SSD v2 cheaper than Premium SSD for the same workload?

Often, for exactly the workloads this article is about — disks that were sized up a tier or two just to buy IOPS. Premium SSD v2 lets you pay for capacity, IOPS and throughput independently, so a 200 GiB disk that needs 4,000 IOPS no longer has to be provisioned as a 1 TiB P30. But v2 has real caveats as of 2026: regional availability gaps, no host caching, and feature restrictions around some scenarios. Verify the current limitations page on learn.microsoft.com and check prices on the official Azure pricing page before migrating anything.