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.

Right-size a disk using required capacity, IOPS, throughput and latency, measured across the workload’s real busy periods. Percentiles help summarize load, but a rare month-end peak can fall outside P95. Check maxima and application requirements too. Azure supports expanding managed disks; reducing capacity requires a separate data migration, not a smaller snapshot restore.

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

Do not resize from a guess. Use platform I/O metrics as a starting point, then check guest filesystem capacity, application latency, peak periods and growth with the app owner. Platform metrics alone do not show every requirement.

• 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.

Do not size from averages alone. Review P95 alongside maximum IOPS, throughput and latency, and include month-end, backups, batch jobs and other known peaks. P95 excludes the highest five percent of samples: a short but critical monthly spike can disappear from it. Use the app owner’s peak calendar and required data capacity, with growth headroom, before choosing a smaller disk.

Check P95, rare maximum loads and required data capacity, not just the average. The average of a spiky workload is a number that describes nothing.

Chart IOPS and bandwidth consumption using a representative measurement window. Low consumption identifies a review candidate, not guaranteed savings: required capacity, VM limits, latency and rare peaks can still justify the current size. Advisor suggestions need the same workload checks.

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.

Treat a lower tier as a candidate, not an automatic recommendation. Check data size and expected growth as well as IOPS and throughput. A workload needing 800 IOPS and 40 MB/s may fit P15 performance, but it only fits a 256 GiB disk if its data, filesystem and growth requirements fit too. Compare regional prices and migration costs before changing it.

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. Check the disk and VM expansion requirements before planning downtime.
• Shrinking a managed disk is not supported. A snapshot preserves the source disk size; it cannot be restored as a smaller managed disk. For a data disk, create an empty target, copy data at the filesystem level or restore it through an application-supported process, verify integrity, and plan the cutover and rollback. OS disks require a separate rebuild or migration 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.

Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.

The runbook, compressed

1. Pull metrics: Data Disk / OS Disk IOPS Consumed % and Bandwidth Consumed %, P95 and maximum load over a representative window, including rare peaks and required data capacity.
2. Map to the ladder: compare peak IOPS, throughput and required capacity against the tier table above (verify current specs on learn.microsoft.com).
3. Apply the rule: capacity and peak load fit a lower tier with growth headroom; validate available burst credits → candidate for downsizing.
4. Talk to the app owner: confirm the peak calendar, agree a window, write the rollback.
5. Execute: backup → empty target disk → verified data copy or application restore → planned cutover. 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?

Review disk IOPS, bandwidth and latency across representative peak periods, alongside data capacity and growth requirements. P95 and maximum measurements help identify candidates, but low I/O utilization alone does not prove a smaller disk fits. Check the VM-level limits and bursting conditions, and validate with the app owner before migration.

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

No. A managed disk cannot be shrunk in place, and its snapshot cannot be restored into a smaller managed disk. For a data disk, create an empty smaller target, migrate using a filesystem copy or application-supported restore, verify the data, and arrange cutover and rollback. OS disks need a suitable rebuild or migration plan.

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.

Sources and review

Reviewed 1 October 2026. P95 is not a guarantee that rare peaks fit. Performance-tier changes cannot go below the disk’s baseline tier, and a snapshot does not shrink its source disk.

• Managed disk sizing, tiers and restrictions
• Managed disk FAQ — no shrinking
• Performance tiers cannot fall below the size baseline