Azure Managed Disks: Types, Performance, and How to Choose

The four managed disk types

The numbers above are maximums for individual disks and depend on disk size and configuration. The VM size you use also caps disk throughput — a small VM cannot saturate a high-performance disk regardless of the disk tier.

Standard HDD

Standard HDD uses magnetic spinning disk storage. It is the cheapest option and is appropriate only for workloads that are not latency-sensitive. A 1 TB Standard HDD in East US costs roughly $45/month. A 1 TB Premium SSD v2 at comparable performance costs around $80–$120/month, so the savings are real — but only if your workload can tolerate higher and more variable latency.

Good uses for Standard HDD: VM backups, development environments where disk speed does not matter, archive VMs that are rarely booted, and VM image storage.

Do not use Standard HDD for OS disks on production VMs. Boot times are noticeably slower and application startup is sluggish compared to SSD-backed disks.

Standard SSD

Standard SSD is the entry-level SSD option. It provides consistent latency (typically under 10ms) without the cost of Premium SSD. For most web servers, lightly loaded application servers, and development VMs that need to boot quickly, Standard SSD is the right choice.

The key limitation compared to Premium SSD is the SLA. Standard SSD has no single-disk IOPS or throughput SLA for sizes under P30. If your workload requires predictable, consistent disk performance, Premium SSD v2 provides a stronger guarantee.

Premium SSD v2

Premium SSD v2 is the current recommended choice for production workloads. Unlike the original Premium SSD (P-series), v2 lets you independently configure the disk size, IOPS, and throughput — you are not locked into the bundled performance tiers of P10, P20, P30, and so on.

For example, you can provision a 256 GB Premium SSD v2 disk with 10,000 IOPS and 300 MB/s throughput, then later increase the IOPS to 20,000 without resizing the disk or rebooting the VM. This flexibility makes capacity planning much more straightforward.

# Create a Premium SSD v2 data disk
az disk create \
  --resource-group my-rg \
  --name my-data-disk \
  --size-gb 256 \
  --sku PremiumV2_LRS \
  --disk-iops-read-write 10000 \
  --disk-mbps-read-write 300 \
  --location eastus \
  --zone 1

# Attach it to a running VM
az vm disk attach \
  --resource-group my-rg \
  --vm-name my-vm \
  --name my-data-disk

Ultra Disk

Ultra Disk is for extreme performance scenarios: high-frequency trading systems, top-tier OLTP databases, and workloads that otherwise require expensive dedicated storage arrays. Sub-millisecond latency and up to 400,000 IOPS per disk.

Ultra Disk cannot be used as an OS disk — it is data disks only. It also has more deployment constraints: it requires specific VM families (mostly Ev3, Esv3, DSv3 or newer generations), is only available in certain regions, and requires Availability Zones. The cost is significantly higher than Premium SSD v2. For most organisations, the workloads that genuinely need Ultra Disk are limited to a handful of critical systems.

Disk caching and write acceleration

Azure managed disks support caching modes that affect read and write performance:

• Read/write caching. The host machine caches both reads and writes in memory. Fastest read performance but writes that have not been flushed to disk yet can be lost if the host fails. Use for OS disks where the data is reproducible.
• Read-only caching. Reads are served from cache; writes go directly to disk. Good for data disks that are read heavily but written rarely — static content, reference data.
• No caching. All I/O goes directly to disk. Required for database data and log files where write ordering and durability guarantees must be maintained. SQL Server, PostgreSQL, and Oracle all recommend no-cache for their data disks.

Getting caching mode wrong on a database disk is a classic source of data corruption after a host restart. Use no caching for any disk that a database is writing transactional data to.

Snapshots and backups

A snapshot is a point-in-time copy of a managed disk. Snapshots are stored as full copies initially, then as incremental changes. You can create a new disk from a snapshot — useful for cloning environments or recovering from data corruption.

# Create a snapshot of an OS disk
az snapshot create \
  --resource-group my-rg \
  --name my-vm-snapshot \
  --source /subscriptions/.../disks/my-vm_OsDisk_1

For deeper coverage of snapshot use cases and backup strategies, see Disk Snapshots.