TL;DR. To diagnose Premium SSD v2 latency, check two Azure Monitor metrics before you change anything: Data Disk IOPS Consumed Percentage and VM Uncached IOPS Consumed Percentage. If the VM metric sits at 100% over the same interval while the disk metric does not, the VM is the cap, and buying more disk IOPS adds cost with zero gain.
- Disk at 100%, VM below 100%: raise disk IOPS or MB/s. It is a live change, up to 4 times per 24 hours.
- VM at 100%, sustained: resize the VM or spread load. More disk IOPS will not help.
- Neither near 100%, latency still high: look at queue depth, I/O size, or a disk recently created from a snapshot.
- In our worked example, raising IOPS on a VM-capped disk adds $102 a month with no latency change.
When Should You Diagnose Premium SSD v2 Latency?
Diagnose Premium SSD v2 latency when application response times rise but you have not confirmed where I/O is queuing. The usual symptoms are slow database commits, rising Avg. Disk sec/Transfer on Windows, or high r_await and w_await in Linux iostat.
Azure Premium SSD v2 managed disks are designed for submillisecond latency and deliver provisioned IOPS and throughput 99.9% of the time (Microsoft Learn, disk types). That promise covers the disk only. The VM in front of it has its own uncached IOPS and MB/s ceiling, and every attached disk shares it.
Scope: Premium SSD v2 data disks on any VM size that supports them. Premium SSD v2 cannot be an OS disk and does not support host caching, so all its I/O counts against the VM uncached limit. For background on latency specs and benchmarking, see our Premium SSD v2 latency and performance reference.
Is It Disk Throttling or a VM Uncached IOPS Limit?
Azure disk throttling happens at two layers, and the metrics tell you which one is binding. Read both before you buy anything.
Microsoft's own example shows the trap. It uses P30 disks from the Premium SSD v1 family, but the VM uncached cap works the same way for Premium SSD v2. A Standard_D8s_v3 VM with a 12,800 uncached IOPS limit reached 100% VM Uncached IOPS Consumed Percentage while its data disks averaged about 42% of their provisioned IOPS. The fix was a larger VM, not faster disks (Microsoft Learn, disk metrics).

How Do You Check Disk and VM Limits From the CLI?
Pull one-minute maximums for the last 24 hours. Averages hide short throttling bursts, so always use Maximum.
Step 1. Get provisioned disk performance:
az disk show -g <rg> -n <disk> \
--query "{sku:sku.name, iops:diskIOPSReadWrite, mbps:diskMBpsReadWrite}"
Step 2. Get the VM size's uncached limits:
az vm list-skus --location eastus --size Standard_D8s_v3 \
--query "[0].capabilities[?name=='UncachedDiskIOPS' || name=='UncachedDiskBytesPerSecond']"
Step 3. Compare consumed percentages at the VM and per disk (LUN):
az monitor metrics list --resource <vm-resource-id> \
--metrics "VM Uncached IOPS Consumed Percentage" "VM Uncached Bandwidth Consumed Percentage" \
--interval PT1M --aggregation Maximum --offset 24h
az monitor metrics list --resource <vm-resource-id> \
--metrics "Data Disk IOPS Consumed Percentage" "Data Disk Bandwidth Consumed Percentage" \
--filter "LUN eq '*'" --interval PT1M --aggregation Maximum --offset 24h
Step 4. If only the disk hits 100%, raise its limits live:
az disk update -g <rg> -n <disk> --disk-iops-read-write 6000 --disk-mbps-read-write 250
Portal path: VM > Monitoring > Metrics, then add the four metrics above and split Data Disk metrics by LUN. Required role: Monitoring Reader to read metrics; Virtual Machine Contributor to change the disk or resize the VM.
What Does Buying IOPS on a VM-Capped Disk Cost?
It costs real money and returns nothing. Take two Premium SSD v2 data disks at 10,000 IOPS each on a VM capped at 12,800 uncached IOPS. The VM metric reads 100%; each disk reads about 64%.
A team sees latency and raises each disk to 20,000 IOPS. Premium SSD v2 IOPS above the free 3,000 cost $0.00511 per IOPS-month in East US ($0.000007 per IOPS-hour x 730, Azure Retail Prices API, Oct 2026).
Across a fleet of 50 such VMs that is about $61,300 a year of provisioned IOPS that can never be consumed. Formula: extra IOPS x $0.00511 x 12.
What Are the Gotchas When Diagnosing SSD v2 Latency?
- Data Disk Latency is a preview metric and is reported only for SCSI-attached disks, not NVMe. On NVMe VMs, use in-guest counters.
- Performance changes are rate limited. You can adjust IOPS and MB/s 4 times per 24 hours, and disk creation counts as one.
- Throughput is tied to IOPS. Above 6 GiB, max MB/s is 0.25 MB/s per provisioned IOPS, up to 2,000 MB/s per disk. Raising MB/s alone may fail.
- All attached disks share the VM cap. A busy log disk can starve a data disk on the same VM.
- No host caching. Premium SSD v2 I/O always counts as uncached, so cached VM limits do not help.
- Recent disk operations matter. A disk created from a snapshot shows higher latency and lower IOPS until its completionPercent reaches 100. This is known, temporary behaviour.
How Do You Verify the Fix Worked?
Re-run the same metric queries after 24 hours of normal load. Success means the binding metric now peaks below 90%, and in-guest latency (Avg. Disk sec/Transfer or iostat await) returns to your baseline.
If you raised disk IOPS, check that actual IOPS rose (Data Disk Read Operations/Sec and Data Disk Write Operations/Sec) and that VM Uncached IOPS Consumed Percentage stayed below 100%. That means the fix worked. If actual IOPS stayed flat while the disk percentage dropped, the VM was the cap, so roll the IOPS back to stop paying for them.
Find Throttled VMs Before Users Do
Want to know where provisioned IOPS sit unused before you buy more? Switch on Free Insights for a read-only report of disk utilisation and savings across your Azure subscriptions.
Frequently Asked Questions
Does Premium SSD v2 guarantee submillisecond latency?
No. Microsoft says Premium SSD v2 is designed for submillisecond latency; the 99.9% commitment covers provisioned IOPS and throughput. Measured latency still depends on queue depth, I/O size, and VM limits.
Can I raise Premium SSD v2 IOPS without downtime?
Yes. IOPS and MB/s changes apply live with no detach or restart. You can make 4 changes per 24 hours, and creating the disk uses one of them.
Why is latency high when consumed percentages are low?
The workload is likely queue-bound or using large I/O. Check Data Disk Queue Depth and average I/O size; a single-threaded app at queue depth 1 cannot use provisioned IOPS.
Should I switch to Ultra Disk for lower latency?
Only if you need more than Premium SSD v2's per-disk limits (80,000 IOPS). Ultra bills every IOPS and MB/s with no free baseline, so it costs more at the same performance.
Does enabling host caching help Premium SSD v2?
No. Premium SSD v2 does not support host caching. All its I/O counts against the VM uncached IOPS and MB/s limits.








