Azure Managed Disks

What Are Managed Disks?

Azure Managed Disks are block-level storage volumes managed by Azure and used with Azure Virtual Machines. They're like virtual hard drives — you choose the size and type, and Azure handles everything else: where it's physically stored, how it's replicated, and how it recovers from failures.

Managed vs Unmanaged Disks

Before managed disks existed (pre-2017), Azure used unmanaged disks — VHD files stored in customer-managed Storage Accounts. This created many problems:

Disk Redundancy Options

Managed disks support different replication options to protect against hardware failures:

Disk Snapshots

A snapshot is a point-in-time, read-only copy of a managed disk. Use snapshots to back up disks before making risky changes, or to create copies of disks for testing.

Incremental Snapshots

Azure supports incremental snapshots — each snapshot only stores the changes since the last snapshot, not a full copy of the disk. This dramatically reduces storage costs for large disks.

# Get the disk ID first
DISK_ID=$(az vm show \
  --resource-group myResourceGroup \
  --name myVM \
  --query "storageProfile.osDisk.managedDisk.id" \
  --output tsv)

# Create an incremental snapshot
az snapshot create \
  --resource-group myResourceGroup \
  --name myVM-snapshot-$(date +%Y%m%d) \
  --source "$DISK_ID" \
  --incremental true \
  --location centralindia

az disk create \
  --resource-group myResourceGroup \
  --name myRestoredDisk \
  --source myVM-snapshot-20260507 \
  --sku Premium_LRS

Snapshot Best Practices

• Take a snapshot before any major change — OS upgrades, software installs, configuration changes
• Use incremental snapshots to minimise cost
• Snapshots are billed per GB of changed data
• Delete old snapshots you no longer need — they continue billing

Custom Images from Disks

You can create a custom VM image from a managed disk — useful for deploying multiple identical VMs (a "golden image" approach).

The process:

1. Set up a VM exactly as you want it — install software, configure settings
2. Run sysprep (Windows) or waagent -deprovision (Linux) to generalise the VM
3. Deallocate and generalise the VM in Azure
4. Capture the image
5. Deploy new VMs from this image

# Deallocate and generalise the VM
az vm deallocate --resource-group myRG --name myVM
az vm generalize --resource-group myRG --name myVM

# Create the image
az image create \
  --resource-group myRG \
  --name myGoldenImage \
  --source myVM \
  --os-type Linux

Shared Disks

Azure Shared Disks allow a single managed disk to be attached to multiple VMs simultaneously. This is designed for clustered applications like SQL Server Failover Cluster Instances or SAP ASCS.

Disk Bursting

Premium SSD managed disks support on-demand bursting — temporarily exceeding the disk's provisioned IOPS and throughput limits to handle spikes. This is similar to how B-series VMs handle CPU bursts.

• Available for Premium SSD disks up to 512 GB
• Can burst up to 3,500 IOPS and 170 MB/s
• Useful for workloads with occasional spikes (boot storms, batch jobs)
• No extra configuration needed — enabled automatically

Managing Disks with CLI

# List all managed disks in a resource group
az disk list \
  --resource-group myResourceGroup \
  --output table

# Create a standalone managed disk
az disk create \
  --resource-group myResourceGroup \
  --name myDataDisk \
  --size-gb 256 \
  --sku Premium_LRS \
  --location centralindia

# Resize a disk (VM must be deallocated first)
az disk update \
  --resource-group myResourceGroup \
  --name myDataDisk \
  --size-gb 512

# Delete a disk
az disk delete \
  --resource-group myResourceGroup \
  --name myDataDisk \
  --yes

Best Practices

• Always use managed disks — Never use unmanaged (Storage Account) disks for new workloads
• Take snapshots before changes — Snapshot OS disks before major updates or software installs
• Separate OS and data — Keep application data on dedicated data disks
• Use incremental snapshots — Significantly cheaper than full snapshots for large disks
• Delete orphaned disks — After deleting a VM, check for leftover disks in the portal and delete them
• Use ZRS for critical disks — Zone-redundant storage for production workloads needing higher availability