Azure Managed Disks: Ultra, Premium SSD v2, and Standard

Attached storage gives an otherwise temporary virtual machine long-term memory. The VM itself is a lease on some compute, the disks attached to it are what survive a resize, a redeploy, or a rebuild. That makes the disk decisions — type, size, caching, encryption — the ones with the longest half-life on any VM you deploy, and several of them can't be changed later without downtime.

The three disk roles

Every VM has up to three kinds of disk attached, and they behave very differently.

The OS disk contains the operating system and boot files, and every VM has exactly one. It maxes out at 4,095 GiB, but because many operating systems default to a master boot record partition, the usable size is often capped at 2 TiB unless the disk is converted to a GUID partition table. Store data on data disks, not here.

The temporary disk is attached automatically to most VMs. It's usually faster than the OS disk but isn't for persistent data. Its contents are lost when the VM is deallocated, redeployed, or hits a maintenance event, though they survive an ordinary restart. It's intended for page files, swap files, and tempdb-style scratch. It isn't a managed disk, which is why several encryption options treat it separately.

Data disks are persistent volumes attached separately, for application data, databases, and files. How many you can attach depends on the VM size. They survive the VM being deallocated or deleted unless explicitly removed, and can be detached from one VM and attached to another.

The five disk types

Managed disks are designed for 99.999% availability, keeping three replicas of your data. LRS disks provide at least 11 nines of durability over a year; ZRS disks at least 12 nines. You can create up to 50,000 disks of each type per subscription per region.

Microsoft is always updating their products and services so this table may not hold water for too long after the time of writing. Fur the current offering visit Azure managed disk types | Microsoft Learn

Ultra Disk delivers the highest throughput, highest IOPS, and consistently sub-millisecond latency available, for data-intensive workloads like SAP HANA, top-tier databases, and transaction-heavy systems. Its performance parameters can be changed without restarting the VM, though only four times in any 24-hour window, with up to an hour for a change to take effect.

Its constraints: data disks only (use Premium SSD as the OS disk), limited to specific VM types, regions, and availability zones, LRS only — no ZRS, no availability sets, and no disk caching at all.

Premium SSD v2 offers higher performance than Premium SSD while generally costing less, and it's what to reach for when a workload's shape doesn't match the fixed size tiers. Capacity, throughput, and IOPS are set independently and adjustable at any time without downtime, so a transaction-intensive database needing high IOPS at small capacity, or a game needing high IOPS only at peak, stops being an awkward fit. For most general-purpose workloads it gives the best price-performance.

It suits SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data analytics, and gaming, on VMs or stateful containers. Like Ultra it's data disks only and doesn't support host caching, though its low latency addresses much of what caching was solving. Every disk gets a free baseline of 3,000 IOPS and 125 MB/s; beyond 6 GiB the IOPS ceiling rises 500 per GiB up to 80,000, and throughput rises 0.25 MB/s per provisioned IOPS up to 2,000 MB/s. In most regions with availability zones, Premium SSD v2 disks attach only to zonal VMs, so the zone has to be chosen when the VM is created.

Premium SSD delivers high performance and low latency for I/O-intensive workloads. It's usable only with compatible VM series — the ones with an s in the size name, so a Dsv3 supports Premium SSD where a Dv3 doesn't. Sizes are fixed tiers from P1 (4 GiB) to P80 (32,767 GiB), with capacity, IOPS, and throughput guaranteed on provisioning. The performance tier can be changed independently of the disk size, so a disk can be provisioned for capacity and temporarily uprated for a busy period.

Standard SSD sits between Standard HDD and Premium SSD on performance and cost. Its real purpose is the case where you have a VM that doesn't support premium storage but still want SSD-backed I/O. It's the only way to get SSD behaviour on those VMs. Suits web servers, low-IOPS application servers, lightly used enterprise applications, and non-production workloads.

Standard HDD is backed by conventional spinning disks, billed at the lowest rate, and usable with any VM size. It suits latency-tolerant workloads doing large sequential I/O. It's explicitly not suitable for OS disks or transactional databases.

Using Standard HDD as an OS disk is being retired on 8 September 2028.

Performance levers

For Ultra Disk and Premium SSD v2, capacity and performance are decoupled by design. For the fixed-tier types, two other levers exist:

• Disk bursting: Both Premium SSD and Standard SSD offer it, which helps with unpredictable I/O and is particularly useful during OS disk boot and for applications with spiky traffic. Smaller Premium SSDs (P1–P20) burst on a credit-based model for up to 30 minutes. P30 and above support on-demand bursting with unlimited duration.
• Performance plus: which raises IOPS and throughput ceilings on larger Standard and Premium disks.

Host caching is worth one note of its own: it's supported on Premium SSD, Standard SSD, and Standard HDD, but not on disks 4 TiB and larger. Changing the cache setting detaches and reattaches the disk. If it's the OS disk, the VM restarts.

Replication

Managed disk data is replicated automatically. LRS replicates within the same data centre, surviving a node failure but not a data centre failure. ZRS replicates synchronously across three storage clusters in separate availability zones in one region, so data stays accessible if a zone goes down.

One exception to carry: Ultra Disks support LRS only. If zone redundancy is required at the disk level, Ultra is off the table.

Encryption

Four options, and the distinctions between them matter more than the names suggest.

Server-side encryption (SSE): also called encryption at rest or Azure Storage encryption, is always enabled and can't be turned off. It encrypts data on managed OS and data disks as it's persisted to the storage clusters, and supports customer-managed keys when configured with a disk encryption set. Critically, SSE does not encrypt temp disks or disk caches.

Encryption at host: is a VM-level option that extends SSE to close exactly that gap. Temp disks and disk caches are encrypted at rest, and data flows encrypted from the host to the storage clusters. The encryption is performed by the server hosting the VM, so it consumes no guest CPU.

This is where course material commonly goes wrong, describing encryption at host as being performed "by the operating system" and providing "double encryption". Both halves are incorrect. It happens on the host, not in the guest OS — which is why it's free of guest CPU cost — and it isn't double encryption; it's SSE extended to cover the temp disk, the caches, and the compute-to-storage hop.

Azure Disk Encryption (ADE) encrypts the OS and data disks inside the VM, using BitLocker on Windows and dm-crypt on Linux, integrating with Azure Key Vault for key management with an optional RSA-based key encryption key. The cmdlet is Set-AzVMDiskEncryptionExtension. Its requirements are strict: the Key Vault and VMs must be in the same region and subscription, only specific VM sizes and operating systems are supported (A-series and Basic tier are not), and the VM needs outbound connectivity to both Storage and Key Vault endpoints. Because it runs in the guest, it uses the VM's own CPU, and it doesn't work for custom Linux images.

Confidential disk encryption binds disk encryption keys to the VM's TPM, making the protected content accessible only to that VM. It covers the OS disk, with temp disk encryption as an opt-in, and is specific to confidential VM sizes.

That last row is a practical detail: Microsoft Defender for Cloud marks a VM with SSE alone as "Unhealthy", precisely because temp disks and caches are unencrypted. Encryption at host is the lowest-friction way to clear it.

ADE is retiring, and the failure mode matters

Azure Disk Encryption is scheduled for retirement on 15 September 2028. Until then it works normally. On that date, ADE-enabled workloads keep running — but encrypted disks fail to unlock after a VM reboot, causing service disruption. A VM that reboots after the deadline without having been migrated doesn't come back.

All ADE-enabled VMs, including their backups, must migrate to encryption at host before then. For new VMs, use encryption at host from the start, or confidential VM sizes with OS disk encryption for confidential computing workloads.

Two Key Vault behaviours matter alongside this. Purge protection enforces a mandatory retention period for deleted objects — for disk encryption that isn't optional housekeeping, because losing the key means losing the disk. And soft delete is on by default, retaining deleted vaults for 90 days.

Making a new data disk usable

Provisioning a disk in Azure is only half the job — the guest OS hasn't done anything with it yet.

1. Create the disk from the VM's Disks settings, specifying name, type, and size.
2. Set encryption: a Microsoft-managed key or customer managed key.
3. Apply, then connect to the VM.
4. Open Disk Management inside the VM.
5. Initialise the disk, choosing GPT is the recommended partition style for modern systems.
6. Create a new simple volume on the unallocated space.
7. Assign a drive letter and format as NTFS.

Configuring ADE, while it lasts

From the VM's Disks settings, select Azure Disk Encryption under Additional Settings and choose the disk to encrypt; with no data disks attached, only the OS disk is offered. Create a Key Vault in the same resource group if one doesn't exist, on the standard pricing tier. Then enable the Key Vault access policy for Azure Disk Encryption — this is the step that grants ADE permission to use the keys, and without it encryption simply fails. Save the encryption settings with the key field left blank so Azure generates and manages a key in the vault, then acknowledge the reboot prompt: encryption is disruptive and the OS has to restart for the data to be encrypted properly.

What goes wrong

Encryption fails outright: almost always the Key Vault access policy for Azure Disk Encryption not being enabled.

Encryption takes a long time on large disks. Make sure the VM has enough CPU and memory allocated.

Deleting the VM and its disks loses the data permanently. When a VM is deleted you choose whether its disks go with it — consider that deliberately and keep backups.

The wrong tier for the workload: an HDD behind a database produces poor performance that looks like an application problem.

Ultra Disk on an unsupported VM type or region fails outright. Verify both before designing around it.

The disk isn't visible in Disk Management: confirm the Azure-side creation completed, and restart the VM if needed.

Initialisation fails: check the disk isn't already initialised with a partition style.

Unused data disks cost money. Review and detach them.

The VM won't start after a reboot: check the Key Vault and its access policies are still active and reachable. Networking problems or a deleted vault stop the VM decrypting its disks at startup.

Sources

• Overview of Azure Disk Storage — Azure Virtual Machines | Microsoft Learn
• Select a disk type for Azure IaaS VMs — Azure Virtual Machines | Microsoft Learn
• Overview of managed disk encryption options — Azure Virtual Machines | Microsoft Learn
• Migrate from Azure Disk Encryption to encryption at host — Azure Virtual Machines | Microsoft Learn
• Migrate your Standard HDD OS disks by September 08, 2028 — Azure Virtual Machines | Microsoft Learn