LinkedIn

Cloud  /  Azure

Microsoft Azure 26 guides · updated 2026

Practical guides to Azure compute, networking, storage, and data services — built for engineers running production workloads on Microsoft's cloud.

Azure Disk Storage: Managed Disks, Ultra Disks, and Shared Disks for VMs

Every Azure Virtual Machine needs at least one disk for the operating system and usually one or more data disks for application files, databases, or swap space. Azure Managed Disks handle the underlying storage account placement, replication, and IOPS guarantees invisibly. You pick a disk type, a size, and whether you want zone redundancy — Azure handles the rest.

Managed disks have replaced unmanaged disks (where you controlled the storage account) in virtually every modern deployment. The benefit is that managed disks scale independently of storage account IOPS limits and do not require you to spread disks across multiple accounts to avoid throttling.

Real-World Scenario

A healthcare analytics company runs SQL Server on a D32s_v5 VM. The database files live on three Premium SSD v2 data disks striped with Storage Spaces to reach the required 120,000 IOPS. The OS disk is a standard Premium SSD (no need for extreme IOPS there). A snapshot policy runs nightly for the data disks, producing incremental snapshots stored in geo-redundant storage for disaster recovery to a secondary Azure region.

Disk Types at a Glance

Disk Type          | Max IOPS  | Max Throughput | Latency    | Use Case
-------------------|-----------|----------------|------------|------------------------------
Standard HDD       | 2,000     | 500 MB/s       | ~10 ms     | Dev/test, infrequent access
Standard SSD       | 6,000     | 750 MB/s       | ~4 ms      | Web servers, light workloads
Premium SSD (v1)   | 20,000    | 900 MB/s       | <1 ms      | SQL, Oracle, business apps
Premium SSD v2     | 80,000    | 1,200 MB/s     | <1 ms      | High-IOPS DBs, configurable
Ultra Disk         | 400,000   | 10,000 MB/s    | <0.5 ms    | SAP HANA, top-tier databases

Premium SSD v2 is notable because IOPS and throughput are configured independently from capacity. A 1 TB Premium SSD v2 disk can be set to 40,000 IOPS and 1,000 MB/s without increasing storage size — you pay separately for capacity, IOPS, and throughput. This flexibility eliminates the over-provisioning common with v1 Premium disks where you sized up purely to get more IOPS.

Disk Architecture for a Database VM

SQL Server VM (Standard_D32s_v5)
├── OS Disk: Premium SSD 128 GB (host-cached read/write)
├── Data Disk 1: Premium SSD v2 2 TB  ─┐
├── Data Disk 2: Premium SSD v2 2 TB   ├─ Storage Spaces stripe
├── Data Disk 3: Premium SSD v2 2 TB  ─┘  (D:\sqldata)
└── TempDB Disk: Local NVMe (ephemeral, Standard_D32s_v5 includes
                              2,400 GB local SSD for temp storage)


Backup:
  Azure Backup Vault <- incremental snapshots nightly

Striping data disks with Storage Spaces (Windows) or LVM (Linux) multiplies IOPS and throughput linearly. Three 2 TB Premium SSD v2 disks at 40,000 IOPS each gives 120,000 combined IOPS under the stripe set.

Disk Caching

Azure hypervisor-level caching stores a read cache on the host’s SSD memory (L1/L2 cache). Three settings:

Cache Mode    | Read  | Write | Best For
--------------|-------|-------|-------------------------------------------
None          | Off   | Off   | Write-heavy disks, SQL log files
ReadOnly      | Yes   | No    | Read-heavy disks, OS disk, SQL data files
ReadWrite     | Yes   | Yes   | Use only when data loss on host failure
              |       |       | is acceptable (not recommended for DB data)

Ultra Disk and Premium SSD v2 do not support host caching. For these disk types, the hardware latency is already so low that the cache benefit is minimal.

Snapshots

A snapshot is a read-only point-in-time copy of a managed disk. The first snapshot is a full copy; subsequent snapshots are incremental (only changed pages are stored).

Terminal window
# Create a snapshot of a data disk
az snapshot create \
  --resource-group prod-rg \
  --name sqldata-disk1-snap-$(date +%Y%m%d) \
  --source sqldata-disk1 \
  --sku Standard_ZRS   # geo-redundant snapshot storage


# Restore: create a new disk from the snapshot
az disk create \
  --resource-group prod-rg \
  --name sqldata-disk1-restored \
  --source sqldata-disk1-snap-20240615 \
  --sku Premium_LRS

Snapshots can be copied across regions with az snapshot copy, enabling manual DR strategies. Azure Backup automates this for VMs, providing application-consistent snapshots using VSS (Windows) or pre/post scripts (Linux).

Shared Disks

Shared disks allow a managed disk to be attached to multiple VMs simultaneously, enabling Windows Server Failover Cluster (WSFC) or Linux Pacemaker clusters without a third-party shared storage solution.

Windows Failover Cluster With Shared Disk
-------------------------------------------
[Primary VM]  [Secondary VM]
      \           /
       Shared Disk
   (Premium SSD / Ultra Disk)
      maxShares: 2


Only one VM has write access at a time (controlled by SCSI reservations)
Failover: primary fails -> secondary takes reservation -> writes resume

Shared disk is supported on Premium SSD (up to 5 shares) and Ultra Disk (up to 5 shares). The maxShares parameter is set at disk creation.

Zone-Redundant Storage for Disks

Standard and Premium SSD managed disks can use ZRS replication, synchronously copying data to three availability zones within the region. A VM with a ZRS disk survives a full zone outage: detach the disk from the failed VM and attach it to a VM in a healthy zone.

ZRS Disk Resilience
--------------------
Region: East US 2
  Zone 1: Copy A ──┐
  Zone 2: Copy B ──┼── Synchronous replication
  Zone 3: Copy C ──┘


Zone 2 outage:
  VM in Zone 1 continues reading/writing from Copy A
  No data loss (synchronous writes committed to all zones before ack)

ZRS disks cost approximately 40% more than LRS but remove the need for application-level replication for most non-cluster workloads.

Key Interview Points

Best Practices