Azure Managed Disks, in depth: the five disk types, VM and disk I/O ceilings, host caching, bursting, Premium SSD v2 and Ultra sizing, and protection

The five disk types

Azure offers five types. Standard HDD is for backup and infrequently accessed data. Standard SSD is for web servers, light applications and test environments. Premium SSD is the long-standing production type, sold in fixed tiers named P1 to P80 where size and performance move together. Premium SSD v2 and Ultra Disk let you set capacity, IOPS and throughput independently, and bill each separately.

Premium SSD is documented to deliver single-digit millisecond latency and its targets 99.9 percent of the time; Premium SSD v2 and Ultra are designed for submillisecond latency. Standard SSD and HDD also bill per transaction, with an hourly cap. If you also run on OCI, OCI Block Volume is a useful contrast: performance bought per gigabyte rather than per tier.

Three ceilings: disk, VM uncached, VM cached

Every I/O is limited by the disk's own provisioned IOPS and throughput, and then by the VM. Each VM size publishes two sets of storage limits. The uncached limits cover I/O to disks with host caching off; the cached limits cover I/O served through the host cache, a local SSD on the physical server. The two are separate, so a VM can use both at once.

Microsoft's own examples use a Standard_D8s_v3: 12,800 uncached IOPS and 192 MB/s, and 16,000 cached IOPS and 128 MB/s. Attach three P30 disks, each provisioned for 5,000 IOPS, and ask for 15,000 IOPS with caching off: the VM caps you at 12,800. Attach three Standard SSD E30 disks at 500 IOPS each and ask for 10,000: the disks cap you at 1,500, though the VM could do far more. Whichever ceiling is lowest wins, and the latency you see rises as you press against it.

Host caching: when it helps and when it lies

Host caching is set per disk: None, ReadOnly or ReadWrite. With ReadOnly, reads that hit the cache never reach the disk and count only against the cached limit; misses count against both; writes go through to the disk before they complete. With ReadWrite, a write completes when it reaches the host cache and is written to the disk later, unless the application flushes or uses force-unit-access writes.

That makes ReadWrite safe only for software that issues flushes correctly, such as the operating system on its OS disk, which is why OS disks default to ReadWrite. Data disks default to None. A good starting point for databases is ReadOnly on data-file disks, where repeated reads benefit, and None on log disks, which are written sequentially and gain nothing from a read cache. Premium SSD v2 and Ultra do not support host caching at all; their lower latency addresses some of the same problem.

Premium SSD: tiers, bursting and performance tiers

A Premium SSD's performance comes from its tier. A P30 is 1,024 GiB with 5,000 IOPS and 200 MB/s; a P40 is 2,048 GiB with 7,500 IOPS and 250 MB/s. Billing rounds up to the next tier, so a 600 GiB Premium SSD is billed and performs as a P30. Performance plus, which can only be set at creation, raises targets on larger disks, for example to 8,000 IOPS and 300 MB/s on a P30.

Bursting comes in two models. Credit-based bursting is on by default for Premium SSD up to 512 GiB and Standard SSD up to 1,024 GiB: a disk accrues credits whenever it runs below target and can burst, on a best-effort basis, for up to 30 minutes at full burst rate, to 3,500 IOPS and 170 MB/s on Premium SSD. On-demand bursting is for Premium SSD larger than 512 GiB; you enable it while the disk is detached or the VM stopped, and it allows bursting up to 30,000 IOPS and 1,000 MB/s with no time limit. It costs an hourly enablement fee plus a charge for transactions above the provisioned target, so if a workload would burst most of the time, a higher performance tier is cheaper. Changing the tier keeps the disk's size and moves only its performance.

Premium SSD v2 and Ultra: three independent knobs

Premium SSD v2 drops tiers. Every disk gets a free baseline of 3,000 IOPS and 125 MB/s. Above 6 GiB, the IOPS ceiling rises by 500 per GiB up to 80,000, reached at 160 GiB; throughput can be set up to 0.25 MB/s per provisioned IOPS, up to 2,000 MB/s, which needs at least 8,000 IOPS. You can change performance four times in 24 hours, and creating the disk counts as one. It cannot be an OS disk, and in most regions with availability zones it attaches only to zonal VMs.

Ultra Disk goes further: up to 1,000 IOPS per GiB and 400,000 IOPS per disk, 0.25 MB/s per IOPS up to 10,000 MB/s, a minimum of 100 IOPS and 1 MB/s. It also allows four performance changes per 24 hours, but a change can take up to an hour to apply and can fail if capacity is short. It is LRS only, does not support availability sets, and the VM must have the Ultra Disk capability enabled, which carries a per-vCPU reservation charge while no Ultra Disk is attached. Both default to a 4 KiB physical sector size and can be created with 512E for software that needs 512-byte sectors.

Worked example: a 600 GiB database disk

A database needs 600 GiB, 12,000 IOPS and 400 MB/s, on a Standard_D8s_v3 VM. The calculator below checks the request against the Premium SSD v2 rules, finds the smallest Premium SSD tier or stripe that meets it, and checks the VM's uncached limits.

# Premium SSD (v1) tiers: (GiB, IOPS, MB/s) from the Learn disk-types table.
P_TIERS = {"P20": (512, 2300, 150), "P30": (1024, 5000, 200), "P40": (2048, 7500, 250),
           "P50": (4096, 7500, 250), "P60": (8192, 16000, 500)}

def pv2(size_gib, iops, mbps):
    """Validate a Premium SSD v2 request against the documented limits."""
    max_iops = 3000 if size_gib <= 6 else min(80000, max(3000, 500 * size_gib))
    max_mbps = min(2000, max(125, 0.25 * iops))
    problems = []
    if iops > max_iops:
        problems.append(f"IOPS {iops} > {max_iops} allowed at {size_gib} GiB")
    if mbps > max_mbps:
        problems.append(f"{mbps} MB/s > {max_mbps:.0f} allowed at {iops} IOPS")
    return problems

def smallest_v1(size_gib, iops, mbps, stripe=1):
    for name, (gib, t_iops, t_mbps) in P_TIERS.items():
        if gib * stripe >= size_gib and t_iops * stripe >= iops and t_mbps * stripe >= mbps:
            return f"{stripe} x {name}"
    return None

need = dict(size_gib=600, iops=12000, mbps=400)   # a 600 GiB database
vm_uncached = dict(iops=12800, mbps=192)           # Standard_D8s_v3 remote-storage caps

print("Premium SSD v2 600 GiB / 12000 IOPS / 400 MB/s:", pv2(**need) or "valid")
print("Premium SSD v2 600 GiB / 12000 IOPS / 3500 MB/s:",
      pv2(600, 12000, 3500))
for stripe in (1, 2, 4):
    print(f"Premium SSD, {stripe}-disk stripe:", smallest_v1(stripe=stripe, **need))
for k in ("iops", "mbps"):
    if need[k] > vm_uncached[k]:
        print(f"VM cap: needs {need[k]} {k}, D8s_v3 allows {vm_uncached[k]} uncached")

Running it prints:

Premium SSD v2 600 GiB / 12000 IOPS / 400 MB/s: valid
Premium SSD v2 600 GiB / 12000 IOPS / 3500 MB/s: ['3500 MB/s > 2000 allowed at 12000 IOPS']
Premium SSD, 1-disk stripe: 1 x P60
Premium SSD, 2-disk stripe: 2 x P40
Premium SSD, 4-disk stripe: 4 x P30
VM cap: needs 400 mbps, D8s_v3 allows 192 uncached

One Premium SSD v2 disk satisfies the request exactly, paying for 600 GiB and the IOPS and throughput above baseline. With Premium SSD, the same numbers need a P60, 8 TiB of capacity bought for its performance, or a stripe of two P40s or four P30s, which adds a volume manager and more disks to snapshot consistently. The calculator also shows a request for 3,500 MB/s failing, because a v2 disk tops out at 2,000.

The last line is the real finding. The D8s_v3 allows only 192 MB/s of uncached throughput, so the disk's 400 MB/s is unreachable on this VM. The fix is a VM size with a higher uncached limit, not a bigger disk. Do this check first; the VM's storage limits are on its size page. If the database could run as a managed service instead, Azure SQL Database sizes storage for you.

Provisioning as code

The commands below use flags from the current az disk and az snapshot references. The CLI's help text still describes the IOPS and throughput flags as Ultra-only, but Microsoft's Premium SSD v2 deployment guide uses the same flags for v2 disks.

# A zonal Premium SSD v2 data disk with its own IOPS and throughput.
az disk create -g rg-db -n data01 --location eastus2 --zone 1 \
  --sku PremiumV2_LRS --size-gb 600 \
  --disk-iops-read-write 12000 --disk-mbps-read-write 400 \
  --logical-sector-size 4096

# Raise performance later without detaching (at most four changes per 24 hours).
az disk update -g rg-db -n data01 --disk-iops-read-write 20000 --disk-mbps-read-write 600

# Premium SSD v1: move to a higher performance tier, or enable on-demand bursting (> 512 GiB).
az disk update -g rg-app -n data02 --set tier=P50
az disk update -g rg-app -n data03 --enable-bursting true

# A shared disk two VMs can attach at once (the cluster software must arbitrate writes).
az disk create -g rg-cluster -n quorum01 --sku Premium_ZRS --size-gb 256 --max-shares 2

# An incremental snapshot: billed for changed data, chainable for backups.
diskId=$(az disk show -g rg-db -n data01 --query id -o tsv)
az snapshot create -g rg-db -n data01-snap-0930 --source "$diskId" --incremental true

A shared disk, with --max-shares above one, gives several VMs block access to the same disk for clustered software such as failover clusters. The disk does not coordinate writers; the cluster software must, usually through SCSI persistent reservations, or two VMs will corrupt the filesystem. For file sharing without that coordination, use Azure Files instead.

Redundancy, snapshots and encryption

Locally redundant disks keep three copies in one datacenter; zone-redundant disks, available for Premium SSD and Standard SSD as Premium_ZRS and StandardSSD_ZRS, replicate across three zones so a disk survives a zone failure and can attach to a VM in another zone. Neither protects against deleting or corrupting data, which is what snapshots and backups are for.

Incremental snapshots store only the changes since the previous snapshot of the same disk and are billed for used data, so a daily chain costs far less than full copies. Snapshot every disk of a striped volume at the same moment, or use a tool that groups them, or the restore will not be consistent. All managed disks are encrypted at rest with platform-managed keys by default; to use your own keys, create a disk encryption set backed by Key Vault and pass it with --disk-encryption-set.

Failure modes

• VM cap below disk target: a fast disk on a small VM performs like the VM, and latency rises as I/O queues at the cap.
• ReadWrite cache on a data disk: writes acknowledged before they are durable, lost if the host fails and the application never flushed.
• Credit bursting as capacity: a workload that runs fine for 30 minutes and then slows when credits run out.
• Buying size for IOPS: an 8 TiB Premium SSD bought for 16,000 IOPS where a Premium SSD v2 would buy the IOPS directly.
• Too many performance changes: automation that adjusts a v2 or Ultra disk more than four times a day gets refused.
• Zonal mismatch: a Premium SSD v2 disk in one zone cannot attach to a VM in another, and LRS disks cannot follow a VM out of a failed zone; spread stateless tiers with VM scale sets instead.

What to do next

1. For each VM, compare the sum of its disks' provisioned IOPS and MB/s with the VM's uncached and cached limits.
2. Set host caching deliberately: ReadOnly for read-heavy data, None for logs and write-heavy disks, ReadWrite only where the software flushes.
3. Price Premium SSD v2 against the Premium SSD tier or stripe you use today, including the capacity you buy only for performance.
4. Move steady over-target workloads from bursting to a higher tier or provisioned IOPS, and alert on burst credits on disks that rely on them.
5. Schedule consistent incremental snapshots, and test a restore into another zone or region.
6. Use zone-redundant disks or zonal replicas for anything that must survive a zone outage.