Managed Disks
Disk redundancy (LRS/ZRS) is a separate, explicit choice made on the disk SKU itself — it has nothing to do with which zone the attached VM is deployed in. A VM spread across Availability Zones can still be sitting on a disk that's pinned to a single zone.
LRS (Locally Redundant Storage)
Three synchronous copies within a single datacenter. The default for every managed disk, and the only option at all for Premium SSD v2 and Ultra Disk — those two SKUs have no ZRS path.
- Replication
- Synchronous
- RPO
- 0 within the datacenter
- RTO
- N/A beyond drive/rack failure — a zonal LRS disk (or the datacenter it's pinned to) going down leaves it unavailable until that zone recovers, with no automatic path to another zone
- Failover trigger
- N/A
- Relative cost
- No extra cost
Baseline — cheapest tier, and mandatory (not just cheapest) for Premium SSD v2 and Ultra Disk.
Microsoft's reliability docs state LRS disks 'provide at least 99.999999999% (11 9's) of durability over a given year' — that's a stated durability target, not a financially-backed SLA. Managed disks don't have one of their own; see the gotcha below.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
ZRS (Zone-Redundant Storage)
Synchronously replicates the disk across three Availability Zones in the region. Supported only for Premium SSD and Standard SSD managed disks — not available for Premium SSD v2, Ultra Disk, or Standard HDD, regardless of region.
- Replication
- Synchronous
- RPO
- 0
- RTO
- 0, automatic, if only the disk's own zone is impacted and the attached VM stays healthy — Azure transparently redirects I/O to a replica in a healthy zone. If the VM itself is also down, recovery is manual: force-detach the disk and reattach it to a VM in a healthy zone (data disks only) — unless it's a shared ZRS disk with a standby VM already running in another zone, where SCSI persistent reservation lets the standby take over.
- Failover trigger
- Automatic
- Relative cost
- Low cost premium
Higher than LRS from cross-zone replication overhead — Microsoft states the exact delta varies by region and disk type rather than publishing a flat percentage.
Microsoft recommends ZRS as the default choice for disks that need zone resiliency, citing 'at least 99.9999999999% (12 9's)' durability — again a stated target, not an SLA. Force detach only works on data disks, not OS disks.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
No native cross-region option — Azure Site Recovery or Azure Backup (customer-configured)
Azure Disk Storage is explicitly a single-region service with no native multi-region replication or automatic cross-region failover. Getting a disk's data into a second region means bolting on Azure Site Recovery (continuous async VM+disk replication), Azure Backup's cross-region restore (periodic, snapshot-based), or a custom cross-region snapshot-copy pipeline.
- Replication
- N/A
- RPO
- Entirely dependent on which mechanism you configure — ASR quotes as low as ~30 sec–5 min (not SLA-backed); Azure Backup's cross-region restore is only as fresh as the last completed backup job
- RTO
- Entirely dependent on the mechanism you've configured and whether you've actually tested the failover/restore path
- Failover trigger
- Manual (customer-triggered)
- Relative cost
- High cost premium
ASR's per-protected-instance charge plus secondary-region storage, or Backup vault storage plus cross-region restore — either way, a second copy of the data plus the tooling to move it.
Out of scope for the disk product itself: Azure's own reliability guidance for Disk Storage states it 'doesn't provide native multiregion capabilities or automatic failover between regions.' See the Virtual Machines catalog entry for Azure Site Recovery's own RPO/RTO detail.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
Gotchas
VM zone redundancy and disk zone redundancy are two separate settings
Deploying a VM across Availability Zones says nothing about the redundancy of the disk attached to it. Disk redundancy is chosen per-disk via the SKU (LRS vs ZRS) at disk creation, entirely independent of the VM's own zone placement. A VM that's correctly zone-redundant can still be running on an LRS disk pinned to a single zone or datacenter — which means the VM's zone protection is worthless the moment that disk's zone goes down.
ZRS isn't available for every disk type
Premium SSD v2 and Ultra Disk — the two highest-performance tiers, frequently chosen for the most latency- and IOPS-sensitive workloads — have no ZRS option at all; they support LRS only. Standard HDD is excluded too. If a workload needs both Ultra Disk performance and zone resiliency, the disk layer can't provide the second half — that has to come from replicating across VMs/disks in different zones at the application layer instead.
Converting an existing disk to ZRS isn't always in-place
Whether conversion is disruptive depends on whether the disk is 'regional' (no zone pinned) or 'zonal' (pinned to a specific zone). A regional disk can have its SKU changed directly — Microsoft calls the conversion itself 'instantaneous' — but the VM must be stopped/deallocated first, so it isn't truly zero-downtime. A zonal disk can't be converted directly at all: the only path is snapshot the disk, create a brand-new ZRS disk from that snapshot, and attach it to a VM, which means real downtime and a new disk resource, not an in-place upgrade.
Managed disks have no SLA of their own
Azure's reliability documentation states plainly: 'Azure Disk Storage doesn't provide its own availability SLA but is included in the SLA for VMs.' The 11-9s (LRS) and 12-9s (ZRS) durability figures quoted everywhere are stated design targets for data durability, not a financially-backed availability commitment — don't cite them as if they were an SLA number.
'Automatic' ZRS failover only covers the disk staying reachable, not the VM staying up
If a zone outage takes down only the disk's zone while the attached VM survives, Azure reroutes I/O to a healthy-zone replica with no action needed. But if the VM itself is also in the failed zone, there's no automatic recovery for a non-shared disk — you have to manually force-detach it and attach it to a VM in a healthy zone. Genuinely automatic cross-zone failover only exists for shared ZRS disks with a standby VM already deployed and clustered in another zone.