Skip to article
Compute Managed disk performance

Disk bursting

Disk bursting is an Azure managed disk capability that lets supported disks temporarily exceed baseline IOPS or throughput targets to handle short workload spikes.

Source: Microsoft Learn - Managed disk bursting Reviewed 2026-05-13

Exam trap
Changing production before checking the exact Azure scope, owner, identity, dependency, and rollback or recovery procedure.
Production check
Can you name the Azure scope, owner, resource ID, dependency, and rollback or recovery path without guessing?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
managed disk bursting, Premium SSD bursting, Standard SSD bursting, on-demand disk bursting
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-13
Learning paths Graph Compute concept cluster Disk bursting
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Disk bursting is the managed disk capability that lets supported disks temporarily exceed baseline performance targets during short I/O spikes. In Azure, it helps teams absorb startup spikes, batch bursts, unpredictable I/O, and temporary workload peaks without permanently upsizing every disk. Plainly, it is a named part of the architecture that operators can point to when they need evidence, ownership, and a safe change path. A useful glossary entry should explain where it appears, what it controls, what depends on it, and which signal proves it is healthy.

Why it matters

Disk bursting matters because a small Azure design choice can shape customer experience, security posture, operational visibility, and incident recovery. When it is shallowly documented, teams may troubleshoot the wrong tenant, policy, storage account, migration project, disk, telemetry path, or SQL table while the real dependency remains hidden. In enterprise Azure work, the value is shared language: application, platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit quality, clarifies ownership, and makes production changes safer because failure modes and graph relationships are visible before change. Treat Disk bursting as production owned when customer traffic, regulated data, migration planning, shared infrastructure, or release automation depends on it.

Technical context

Technically, Disk bursting appears in managed disk SKU settings, burstingEnabled property, Premium SSD and Standard SSD capabilities, disk metrics, VM disk limits, and workload performance tests and interacts with Azure Disk Storage, Azure Virtual Machines, Azure Monitor, and Premium SSD disks. Configuration is reviewed through disk SKU, bursting mode, burstingEnabled property, and provisioned IOPS, while operators validate live state through bursting enabled value, IOPS consumed percentage, throughput consumed percentage, and credit or on-demand behavior. Scope determines which permissions, logs, commands, and dependencies matter.

Exam context

Compare with

Premium SSD disk Standard SSD disk Managed disk SKU

Where it is used

Where you see it

  1. In disk configuration, bursting appears as a supported performance feature for selected Premium SSD and Standard SSD managed disks during production review when operators collect repeatable evidence.
  2. In Azure Monitor metrics, it appears when disk IOPS or throughput consumed percentage spikes above normal workload behavior during production review when operators collect repeatable evidence.
  3. In cost analysis, it appears when on-demand bursting charges rise because a workload repeatedly exceeds provisioned performance targets during production review when operators collect repeatable evidence.

Common situations

  • Handle temporary I/O spikes without permanent disk upsizing.
  • Improve VM boot or batch-job performance for bursty workloads.
  • Investigate whether disk latency is caused by exhausted burst capacity.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Disk bursting in action for retail ecommerce Scenario, objectives, solution, measured impact, and takeaway.
Scenario

PeakLane Commerce, a retail ecommerce organization, needed to address order-processing VMs experienced disk latency during flash-sale batch reconciliation. The architecture team used Disk bursting as the control point for a measurable production improvement.

Goals
  • Keep reconciliation jobs under 45 minutes
  • Avoid permanent premium disk upsizing
  • Measure burst cost against performance gain
Approach using Disk bursting

Engineers reviewed disk metrics, confirmed the Premium SSD data disks supported bursting, and enabled bursting for the reconciliation window. Azure Monitor workbooks tracked IOPS percentage, latency, and bursting charges, while job schedules were tuned to avoid overlapping high-I/O workloads. The team validated Disk bursting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Disk bursting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes
  • Reconciliation time dropped from 71 to 38 minutes
  • Permanent disk upsizing was avoided for 42 VMs
  • Bursting charges stayed below the approved event budget
What to learn

Disk bursting is valuable when workload spikes are real, measured, and cheaper than constant overprovisioning.

Scenario 02 Disk bursting in action for medical imaging analytics Scenario, objectives, solution, measured impact, and takeaway.
Scenario

BioNova Imaging, a medical imaging analytics organization, needed to address image conversion workers needed high I/O at startup but sat mostly idle between processing batches. The architecture team used Disk bursting as the control point for a measurable production improvement.

Goals
  • Reduce worker startup time by 30 percent
  • Keep storage spend predictable
  • Avoid latency spikes during clinical processing windows
Approach using Disk bursting

The cloud team enabled disk bursting on supported Standard SSD data disks after confirming the workload had short startup spikes. Metrics were captured before and after the change, and scheduling rules prevented too many workers from bursting at the same time. The team validated Disk bursting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Disk bursting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes
  • Worker startup time improved 36 percent
  • Clinical processing windows met SLA for three consecutive months
  • Storage spend remained below the planned premium upgrade cost
What to learn

Bursting is a targeted performance lever, not a replacement for right-sizing every disk.

Scenario 03 Disk bursting in action for industrial analytics Scenario, objectives, solution, measured impact, and takeaway.
Scenario

StoneMill Analytics, a industrial analytics organization, needed to address engineers kept increasing disk SKUs to hide slow nightly data loads. The architecture team used Disk bursting as the control point for a measurable production improvement.

Goals
  • Find the real cause of disk latency
  • Reduce unnecessary premium disk upgrades
  • Keep nightly loads within the batch window
Approach using Disk bursting

Operations compared disk throughput, VM disk limits, and bursting metrics. They discovered the VM size capped disk bandwidth before several disks could use their provisioned targets. The fix combined selective bursting, a better VM size, and fewer parallel jobs rather than more disk upgrades. The team validated Disk bursting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Disk bursting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes
  • Nightly load duration improved 41 percent
  • Eight unnecessary disk upgrades were canceled
  • Performance troubleshooting shifted from guesswork to metric evidence
What to learn

Disk bursting works only when VM limits and workload shape are understood together.

Azure CLI

CLI checks for Disk bursting are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show scope, state, owner, permissions, destinations, configuration, metrics, or discovered inventory. Run mutating, security-impacting, or cost-impacting commands only after approval, because the wrong scope can affect production availability, spend, access, or telemetry.

Useful for

  • Handle temporary I/O spikes without permanent disk upsizing.
  • Improve VM boot or batch-job performance for bursty workloads.
  • Investigate whether disk latency is caused by exhausted burst capacity.

Before you run a command

  • Run az account show, confirm tenant and subscription, and verify the operator identity has approved read access for the exact Azure scope.
  • Confirm resource group, service name, resource ID, environment, owner, and change record before collecting evidence or modifying production configuration.
  • Prefer read-only commands first; review any command that changes access, policy evaluation, disk state, migration discovery, telemetry, or data distribution before running it.

What the output tells you

  • Whether the target tenant, policy, storage account, migration project, disk, trace resource, or SQL pool exists at the expected Azure scope.
  • Which state, assignment, property, identity, key reference, attachment, metric, trace, table design, or discovered inventory value is visible to the operator.
  • Whether the issue is wrong scope, stale configuration, missing permissions, weak evidence, failed discovery, disk pressure, trace sampling, or table distribution skew.

Mapped commands

Disk bursting operational checks

direct 
az disk show --name <disk> --resource-group <resource-group> --query "{sku:sku.name,bursting:burstingEnabled,diskIOPS:diskIOPSReadWrite,diskMBps:diskMBpsReadWrite}"
az diskdiscoverCompute
read-only Microsoft Learn 
az monitor metrics list --resource <disk-resource-id> --metric "Data Disk IOPS Consumed Percentage"
az monitor metricsdiscoverCompute
read-only Microsoft Learn 
az disk update --name <disk> --resource-group <resource-group> --bursting-enabled true
az diskconfigureCompute
mutating Microsoft Learn 
az disk update --name <disk> --resource-group <resource-group> --bursting-enabled false
az diskconfigureCompute
mutating Microsoft Learn

Architecture context

Disk bursting belongs to Compute architecture decisions where identity, monitoring, cost ownership, reliability, and production support need shared evidence.

Security
Security for Disk bursting starts with least privilege, trusted configuration, and evidence that access matches workload risk. Review change approval, least-privilege disk updates, metric access control, workload data protection, and operations separation before approving production use. A common failure is assuming that a working feature, successful deployment, visible resource, or populated dashboard proves the configuration is safe. Use Microsoft Entra groups, managed identities, RBAC, private connectivity, diagnostic logging, source-controlled definitions, and approval records where applicable. Keep exceptions ticketed, time-bounded, and owned. For regulated workloads, align the term with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale keys, unreviewed contributors, and undocumented exception paths before Disk bursting becomes an incident path.
Cost
Cost for Disk bursting appears through licensing impact, compute capacity, transaction volume, diagnostic retention, policy remediation, storage consumption, migration assessment effort, disk performance choices, and the human effort required to recover from mistakes. Review on-demand bursting charges, oversized disk avoidance, premium SKU selection, idle performance capacity, and batch window tuning before expanding production use. Some costs are direct, such as retained logs, provisioned disks, storage transactions, or SQL pool capacity; others are indirect, such as failed releases, duplicated troubleshooting, emergency restores, and support escalation. Tag related resources, monitor usage, and separate exploratory work from production. A cost review should connect spend to a real owner and measurable value.
Reliability
Reliability for Disk bursting depends on repeatable configuration, tested dependencies, and clear failure signals. Watch burst depletion, unsupported disk SKUs, VM-level disk limits, latency under spikes, and fallback capacity plan because drift often appears later as failed releases, blocked sign-ins, missing telemetry, slow migration assessments, VM disk pressure, or poor query behavior. Use lower environments, source-controlled definitions where possible, deployment validation, monitoring, and recovery notes before changing production. Operators should know which tenant, endpoint, policy, appliance, VM, dependency, or downstream application fails first and which metric or log proves the failure. The goal is predictable recovery: detect Disk bursting drift, preserve service, restore safely, and explain the incident without guessing.
Performance
Performance for Disk bursting depends on workload shape, service limits, data volume, network path, diagnostic destination, policy evaluation, disk throughput, trace sampling, SQL distribution, and the monitoring path used to confirm success. Review IOPS spike handling, throughput spike handling, disk latency, VM disk bandwidth ceiling, and queue depth behavior before increasing capacity or retrying blindly. The better fix might be correcting access scope, reducing log noise, improving discovery cadence, choosing a different disk SKU, tuning trace collection, or changing table distribution. Measure under representative production conditions. Operators should connect symptoms to evidence: latency, throttling, backlog, failed operations, dropped logs, skew, or stale state.
Operations
Operations for Disk bursting should focus on ownership, observability, and safe repeatability. Standardize names, tags, owner groups, environment labels, diagnostic destinations, runbook links, approval records, and change windows so support teams do not reverse-engineer the platform during incidents. Use read-only CLI, API, policy, diagnostic, or portal checks first, then compare live state with intended configuration. For production, connect alerts, audit events, cost records, graph links, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and recovery procedure before changing Disk bursting in a production environment.

Common mistakes

  • Changing production before checking the exact Azure scope, owner, identity, dependency, and rollback or recovery procedure.
  • Treating a portal screenshot as sufficient evidence when CLI output, Activity Logs, diagnostics, and source-controlled configuration are repeatable.
  • Assuming a name match proves the correct resource when tenants, subscriptions, disks, storage accounts, workspaces, and SQL pools can look similar.