Context
Azure managed disks can deliver short bursts above their ordinary provisioned performance when their model supports it. The VM has separate storage limits. A workload that starts quickly and slows later may have exhausted burst capacity, reached the disk baseline or encountered the VM's aggregate I/O ceiling.
Prerequisites are the VM size, attached disk types and performance tiers, cache settings, LUN mapping and incident interval. Collect application latency and guest storage observations alongside platform metrics. Avoid a destructive benchmark on a production filesystem or live database volume.
1. Map application I/O to a disk
Identify the filesystem, data path and logical unit used by the slow operation. Separate database data, logs, temporary files and OS activity. A platform average across all attached disks can conceal one saturated LUN.
Record I/O size and whether the workload is limited by operations per second or bytes per second. Many small random operations differ from large sequential transfers. Correlate request latency with the storage interval so a downstream API timeout is not mistaken for local disk pressure.
2. Compare disk and VM ceilings
Inspect Data Disk IOPS Consumed Percentage and Bandwidth Consumed Percentage split by LUN where supported. Compare OS-disk metrics separately. Then inspect the VM's cached and uncached IOPS and bandwidth consumption metrics for the same period.
A disk may have spare provisioned capacity while the VM reaches its aggregate limit. Conversely, one disk can cap I/O while the VM remains below its allowance. Review the documented metric support for the VM series. Missing or coarse metrics should not be interpreted as proof that the layer is unconstrained.
3. Review the bursting model
Determine whether the disk uses credit-based bursting, supports separately enabled on-demand bursting or has another performance model. Disk bursting and VM bursting are distinct features. A credit-based workload that continually exceeds its baseline cannot rely indefinitely on an initial full bucket.
Compare the early fast period with sustained behavior and available burst evidence. For sustained pressure, evaluate the appropriate disk performance tier, workload distribution or VM size according to the limiting layer. Review current cost implications and eligibility before enabling on-demand bursting. Changing only the disk cannot overcome a VM ceiling, and changing only the VM cannot repair an insufficient disk baseline.
Diagnostic checkpoints
| Observation | Likely layer | Next evidence |
|---|---|---|
| One LUN reaches its allowance | Disk performance | Per-disk IOPS and bandwidth |
| Disks below limits, VM at ceiling | Aggregate VM budget | Cached and uncached metrics |
| Initial speed fades under steady load | Burst exhaustion | Model and credit timeline |
| Platform quiet, guest queue grows | Guest or workload issue | Filesystem and process evidence |
Illustrative scenario
A hypothetical nightly export completes its first segment quickly, then slows during a sustained sequential write. The team compares throughput, disk model and VM budget instead of assuming the network is responsible. It chooses a correction only after locating the constrained layer. This fictional example includes no invented throughput measurements or savings claims.
Verification and storage SOP
Validate using an authorized representative workload long enough to pass the initial burst period. Compare completed business work and sustained latency, not only the first minute's peak. Confirm that the change did not shift pressure onto another disk or VM budget.
Maintain LUN ownership, expected I/O patterns and baseline performance assumptions in the SOP. Monitor sustained utilization and application latency together. Review the plan after database growth, new batch jobs or changes in caching. Treat burst capacity as a documented temporary allowance, not the default sustained service target.
Explore Clouvenix managed infrastructure for implementation and operational handover.
Technical reference
Disk bursting and I/O metrics.