Site Reliability

Choose zone-redundant storage for managed disks

One capability across your VM estate: make sure the disks behind the workloads you cannot afford to lose are replicated across three availability zones, so a single zone going dark does not take the application with it.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Zone-redundant disks: the basics

What does a single-zone disk actually risk?

A managed disk is the durable state behind a virtual machine, and the redundancy you pick for it decides what kind of failure it can survive. The default, locally redundant storage (LRS), keeps three synchronous copies inside one data centre. That protects against a failed drive or rack, but every copy lives in the same availability zone, so if that zone loses power, cooling or network, the disk and the workload on top of it go down together. Zone-redundant storage (ZRS) instead replicates every write synchronously across three separate availability zones in the region, each a physically distinct location with independent power, cooling and networking. A write only completes once it has landed in clusters in multiple zones, so the disk keeps serving even if an entire zone fails.

Azure Advisor surfaces this as a reliability recommendation: for maximum availability and durability, use a zone-redundant (ZRS) disk so the disk can tolerate a zonal failure without disrupting the application. It reads as a single line item per disk on the Advisor reliability tab, but the underlying decision is the same one every time: is this disk behind a workload whose outage you would have to explain, and if so, is it pinned to a single zone that can take it offline on its own.

Most single-zone exposure is default, not intent. A VM was created, its OS and data disks defaulted to LRS, and nobody revisited the redundancy choice once the workload became important. The work is to find the disks behind the workloads that matter, decide which genuinely need to survive a zone failure, and move those to ZRS, while leaving the throwaway and easily rebuilt ones on cheaper LRS on purpose.

In this lesson you will learn how Azure managed disks express zone resilience, how to find every disk behind a critical workload that is still pinned to a single zone, and how to move the ones that matter to zone-redundant storage without taking the workload offline or overspending on the ones that do not need it. You will see the exact Azure CLI to inventory and convert disks, the Bicep to make ZRS the default for new critical workloads, and the limits that decide whether a disk can be converted in place or needs a snapshot.

Fun fact

Three zones, one write

The thing that makes a ZRS disk feel like ordinary storage is that the cross-zone replication is synchronous and invisible: every write is acknowledged only once it has been committed to clusters in more than one availability zone, so there is no replica to fail over to and no lag to reconcile after a zone failure. The trade is a small amount of extra write latency, because a write now has to cross zones before it completes, where an LRS write stays inside one data centre. For the workloads people choose ZRS for, that millisecond-scale latency cost is exactly the price of never having to run a failover during a zone outage.

Finding single-zone disks behind critical workloads

Priya is the platform lead at a fintech whose payments API has a contractual uptime commitment to its own customers. Azure Advisor's reliability tab is showing ZRS recommendations against a handful of disks, and a recent regional incident, where a single zone degraded for a few hours, has made the question urgent.

Rather than convert everything Advisor flags, Priya starts by listing the Premium and Standard SSD disks that are still on a locally redundant SKU, so the disks behind the workloads that actually carry an uptime promise can be separated from the ones that can simply be rebuilt.

Start by listing the managed disks still on a locally redundant SKU, with the SKU and the VM each is attached to. These are the candidates a zone failure can take down.

$ az disk list --query "[?ends_with(sku.name, '_LRS')].{name:name, sku:sku.name, attachedTo:managedBy}" -o table

Name Sku AttachedTo

------------------ --------------- -----------------

payments-api-os Premium_LRS vm-payments-api

payments-api-data Premium_LRS vm-payments-api

batch-nightly-os StandardSSD_LRS vm-batch-nightly

# payments-api disks carry an uptime promise and are single-zoned. Move these first.

A disk behind a workload with a contractual uptime commitment, still on a locally redundant SKU, is the highest-value target. Convert these before the rebuildable batch boxes.

How Azure decides a disk can survive a zone failuredeep dive

Redundancy is expressed by the disk's SKU name. A locally redundant disk ends in '_LRS' (Premium_LRS, StandardSSD_LRS, Standard_LRS) and keeps all three of its synchronous copies in one zone. A zone-redundant disk ends in '_ZRS' (Premium_ZRS, StandardSSD_ZRS) and spreads its synchronous copies across three availability zones, which is why it carries about a quarter more durability on paper, twelve nines over a year against eleven for LRS, and why it keeps serving through a zone outage. ZRS is supported only on Premium SSD and Standard SSD; Premium SSD v2 and Ultra Disk do not offer a ZRS SKU, so for those tiers zone resilience has to come from the application layer instead.

There is a structural difference that matters when you plan the move. A ZRS disk is regional: it is not pinned to a single availability zone, and it can be attached to a VM in any zone in the same region. An LRS disk may be regional (no zone specified) or zonal (pinned to one zone). A regional LRS disk can be converted to ZRS in place by changing its SKU while the VM is deallocated. A zonal LRS disk cannot have its SKU changed directly; you take a snapshot and create a new ZRS disk from it, then swap it in.

Advisor evaluates these recommendations on its own cycle, so converting a disk does not clear the recommendation the instant the SKU changes; the control-plane change is immediate but the reliability tab catches up on the next assessment. The strongest position is not just to convert today's disks but to make ZRS the default redundancy in the templates and modules that stamp out new critical workloads, so a future VM behind an uptime commitment does not quietly land back on a single-zone disk.

What is the impact of leaving a critical disk single-zoned?

The direct impact is correlated downtime. When the availability zone holding a single-zone disk fails, every workload whose disk lived only in that zone goes down at once, and it stays down until the zone recovers or you restore from a backup into another zone. That is precisely the failure availability zones exist to contain, and a single-zone disk is what stops you from benefiting from the containment. The overwhelming majority of these exposures are accidents of default: the disk defaulted to LRS at VM creation and the redundancy choice was never revisited once the workload became important.

The second-order impact is recovery cost and complexity. Without zone redundancy, surviving a zone failure means a restore-and-failover exercise under incident pressure: provisioning new disks in a healthy zone, restoring from backup or snapshot, reattaching and validating, all while the service is down and the recovery point is whatever your last backup captured. A ZRS disk removes that exercise for zone failures entirely, because the disk simply keeps serving. The cost of the single-zone choice is paid not in the steady state but in the worst hour you will have.

On the commitments side, if you have promised your own customers an uptime figure, or you are aligning to an internal reliability target, a single-zone dependency under a critical workload is the gap an auditor or a post-incident review will find first. Evidence that the disks behind your committed workloads are zone-redundant by design is the cleanest artefact you can show that the commitment is engineered, not hoped for.

How do you move critical disks to ZRS safely?

Work this as a tiering exercise, not a blanket conversion. The order matters: decide which workloads must survive a zone failure before you change any SKU, so you spend the uplift only where an outage would actually cost you, and so you do not disrupt a workload that cannot tolerate the brief deallocation a conversion needs.

1. Inventory disks by redundancy and workload

List every managed disk still on a locally redundant SKU, with the VM it is attached to. Treat this inventory, mapped to the workloads behind it, as the source of truth rather than the raw Advisor count, because a single critical VM can have several disks and the OS disk matters as much as the data disks.

2. Tier by cost of an outage

For each disk, decide whether the workload behind it must survive a zone failure. Revenue-bearing services and anything with an uptime commitment to your own customers are ZRS candidates. Workloads that can be rebuilt from an image in under an hour with no contractual consequence stay on cheaper LRS on purpose. Write the decision down; the goal is deliberate tiering, not maximal redundancy.

3. Convert the critical disks the right way for their shape

A regional LRS disk can be converted in place by changing its SKU to the matching ZRS one while the VM is deallocated, then starting the VM again. A zonal LRS disk cannot change SKU directly: take a snapshot, create a new ZRS disk from it, and swap it in. Premium SSD v2 and Ultra disks have no ZRS SKU, so handle their zone resilience at the application layer instead.

4. Make ZRS the default for new critical workloads

Convert today's disks, then set ZRS as the redundancy in the Bicep modules and templates that stamp out new workloads in your committed tier, so a future critical VM does not quietly default back to a single-zone disk. This is what turns a one-off cleanup into a durable posture.

# Convert a REGIONAL (non-zonal) LRS disk to ZRS in place.
# The disk's SKU can be changed directly; the VM must be deallocated first.
RG="rg-payments"
VM="vm-payments-api"
DISK="payments-api-data"

az vm deallocate --resource-group "$RG" --name "$VM"

az disk update --resource-group "$RG" --name "$DISK" --sku Premium_ZRS

az vm start --resource-group "$RG" --name "$VM"
echo "$DISK: converted to Premium_ZRS, now replicated across three availability zones"

# For a ZONAL LRS disk the SKU cannot be changed directly: snapshot, then
# create a new ZRS disk from the snapshot and swap it in.
# az snapshot create --resource-group "$RG" --name "${DISK}-snap" --source "$DISK"
# az disk create --resource-group "$RG" --name "${DISK}-zrs" \
#   --sku Premium_ZRS --source "${DISK}-snap"

Quick quiz

Question 1 of 5

What does zone-redundant storage (ZRS) give a managed disk that locally redundant storage (LRS) does not?

Keep learning

Go deeper on how Azure managed disks express zone redundancy and how to convert the disks that need it.

You can now treat managed disk redundancy as one deliberate decision rather than a default: inventory the disks still on a locally redundant SKU, tier them by the cost of an outage of the workload behind each, convert the critical ones to zone-redundant storage the right way for their shape, and make ZRS the default in the templates that build new committed workloads. Single-zone exposure stops being something a zone failure can surprise you with and becomes a choice you have made and written down.

Back to the library

Zone-redundant disks: the downtime and cost view

A small, bounded uplift on the disks whose outage would cost more than the disk ever will

ZRS is one of the few reliability choices with a clear, visible price tag, which makes it an honest finance conversation rather than a free one. For Premium SSD, choosing ZRS over LRS raises the per-disk storage cost by roughly half (Microsoft documents the uplift as about 50 per cent), and it applies only to the disk capacity line, not to compute. So the question is never 'should every disk be ZRS', it is 'which disks sit behind revenue or a contractual uptime promise, where a single-zone outage would cost more in one incident than the redundancy uplift costs in a year'.

Frame each Advisor recommendation as a downtime-risk line rather than a storage upsell. A disk behind a customer-facing payments service carries a very different expected cost of outage than a disk behind a nightly batch box that can be rebuilt in an hour, yet both surface as the same recommendation. Map the disks to the workloads behind them and prioritise by the cost of an outage, not by the count of recommendations.

The arithmetic is usually lopsided for the workloads that matter. The uplift is a small, predictable percentage of an already-modest disk line. The downside of leaving a critical workload single-zoned is the documented cost of an outage: lost transactions, SLA credits owed to your own customers, staff pulled into incident response and the reputational hit of being down while the rest of the region stays up.

This lesson is for the finance partner who sees ZRS recommendations on the Advisor reliability tab and wants to know which ones are worth paying the uplift for. It covers why ZRS is not free, how to size the roughly-50-per-cent Premium SSD uplift against the cost of an outage, and how to turn a list of recommendations into a plan that pays for resilience only where an outage would actually hurt.

Fun fact

Three zones, one write

How a finance partner frames the ZRS decision

Priya is the finance partner supporting the platform team after a zone incident put the payments API at risk. Advisor's reliability tab lists nine ZRS recommendations across the estate, and the instinct is not to approve a blanket conversion budget; it is to ask what is behind each disk and what an hour of its downtime actually costs. ZRS is not free: on Premium SSD the uplift over LRS is roughly half the disk's storage cost, so the spend question is real but narrow, and it lands only on the capacity line, not on compute.

Priya asks the team to map each flagged disk to the workload behind it and the cost of that workload being down. Two disks sit behind the payments API, which owes its own customers an uptime commitment and loses real transactions per minute of outage. One pair sits behind an internal reporting tool that can be down for a morning with no contractual consequence. The rest are batch and scratch boxes that are rebuilt from images in under an hour. The list is reframed by downtime cost: the payments disks are converted to ZRS today, because one avoided zone outage pays for the uplift many times over; the reporting disks are a judgement call to revisit; the batch boxes stay on cheaper LRS on purpose. The finance pack reads: 'We are paying the ZRS uplift on the two disks where a zone outage would breach a customer commitment, and deliberately not paying it on the seven where we would just rebuild.'

Why single-zone disks are a downtime cost, not a storage line

The cost model here is asymmetric, but unlike a free security fix it has a real, visible price on one side. Paying for ZRS costs a bounded, predictable uplift, roughly half again on the Premium SSD disk capacity line, on only the disks you choose. Leaving a critical workload single-zoned costs nothing until a zone fails, and then it costs an outage: the value of the transactions or work lost while the service is down, any uptime credits you owe your own customers, the loaded cost of an incident response, and the goodwill spent being dark while the rest of the region is up.

The finance role is to attach a cost of downtime to each flagged disk, not a count. A disk behind a revenue-bearing service with a per-minute cost of outage justifies the uplift on the first avoided incident; a disk behind a workload that can be down for a morning with no contractual consequence does not, and paying for ZRS there is overspend dressed up as prudence. Sizing the uplift against the documented cost of an outage, workload by workload, is what turns a list of recommendations into a defensible spend rather than a blanket one.

What finance can do about single-zone disks

Finance cannot change a disk SKU, but it owns the framing that turns a list of ZRS recommendations into a spend that buys resilience only where an outage would actually hurt. Three levers.

1. Price the uplift against the cost of an outage, disk by disk

Make explicit that ZRS is not free: on Premium SSD the uplift is roughly half again on the disk capacity line. Then put that bounded, predictable cost next to the cost of the workload behind the disk being down for the duration of a zone outage. For a revenue-bearing or committed workload, one avoided incident pays the uplift back many times over; for a rebuildable one it does not. The decision is a per-disk comparison, not a blanket policy.

2. Tier the estate so you do not over-insure

Paying the ZRS uplift on every disk Advisor flags is overspend dressed up as prudence. Ask the team to sort the flagged disks into 'must survive a zone failure' and 'rebuild it if it dies', and pay the uplift only on the first tier. The metric that belongs on the cost-and-reliability review is the ZRS uplift spent on committed workloads, against the documented cost of an outage it removes, not the share of disks converted.

3. Require a recorded reason for each tier

Any critical workload left single-zoned to save money should carry a recorded, finance-visible decision that its outage cost is acceptable, and any non-critical workload paying for ZRS should justify it. The distinction between 'we priced this and chose LRS deliberately' and 'it defaulted to single-zone and nobody noticed' is exactly what makes the spend defensible and the resilience posture honest after an incident.

Quick quiz

Question 1 of 5

As the finance partner, what is the right starting assumption about the Azure-spend cost of acting on a ZRS recommendation?

Keep learning

Go deeper on how Azure managed disks express zone redundancy and how to convert the disks that need it.

You have finished the finance view of zone-redundant disks. You know ZRS is not free, that on Premium SSD the uplift is roughly half again on the disk line, and that the right move is to pay it only where an outage would cost more than the uplift over a year. Next time a list of ZRS recommendations lands, you will tier the disks by the cost of their workload being down, fund the committed ones, leave the rebuildable ones on cheaper LRS on purpose, and ask for both decisions on the record rather than approving a blanket conversion.

Back to the library

Zone-redundant disks: the headline

Whether the workloads you cannot afford to lose can survive one zone going dark

An availability zone is the unit of failure Azure is built to contain, and a single-zone disk is the thing that lets a contained, local failure become your outage. If a zone goes down and the disk behind a critical workload lived only in that zone, the workload is down even though the rest of the region is healthy. Advisor shows this as a scatter of per-disk recommendations, but the leadership question behind them is singular.

That question is not 'are all our disks redundant?' It is 'when a zone fails, and they do, which of the workloads we cannot afford to lose stay up?' The defensible end state is that the disks behind those workloads are zone-redundant by deliberate choice, the rest are single-zone on purpose to save cost, and which is which is written down.

This is a cost decision, but a small and asymmetric one. The uplift is a modest percentage on a disk line; the downside is an avoidable outage of a workload that mattered, during the exact failure Azure gives you the tools to ride through. It is a governance call about which outages you have decided you will not have.

A short read for the leader who needs to know what a single-zone disk risks, why moving the critical ones to ZRS is a small and asymmetric cost decision rather than a blanket spend, and what a defensible end state looks like when a zone fails.

Fun fact

Three zones, one write

What it looks like when a zone failure is a non-event

After a zone in the region degraded for a few hours and a competitor's status page went red while customers watched, the CEO asked the obvious question at the next review: when that happens to our region, does our payments service stay up? The honest answer at the time was that it depended on which zone failed, because the disks behind the service lived in a single zone chosen by default rather than by decision.

The team's response was to stop treating disk redundancy as a per-VM default and start treating it as a deliberate resilience tier. They listed every disk behind a workload with an uptime commitment, confirmed each was on a locally redundant SKU, and converted the critical ones to zone-redundant storage so a single zone failing could no longer take the service down on its own. The cheaper, rebuildable workloads were left single-zoned on purpose and documented as such. The next time a zone wobbled, the answer to the CEO's question had changed from 'it depends' to 'the payments service rode through it, because its disks are replicated across three zones, and the only things affected were the batch jobs we chose not to protect.' That shift, from hoping the failure lands in a zone you are not using to engineering so it does not matter which zone fails, is the confidence signal this capability delivers.

Why this is a board-level resilience question

Most avoidable cloud outages that took down a service while the wider region stayed healthy came back to a single-zone dependency under a workload that mattered. Zone-redundant disks make that specific failure mode, a contained zone outage becoming your outage, structurally difficult for the workloads you decide to protect, and making ZRS the default in the templates that build new critical workloads makes the regression close to impossible.

The cost of getting this wrong is an outage of a workload you said you would keep up, during the exact failure Azure gives you the means to ride through. The cost of getting it right is a small, bounded uplift on a short list of disks. This is the kind of resilience decision leadership should make explicitly: which outages have we decided we will not have, and have we paid the modest, visible price to back that decision.

The leadership move on zone redundancy

The executive handle is not to approve each conversion individually; it is to require that the disks behind committed workloads are zone-redundant by deliberate choice and that the cheaper single-zone workloads are single-zoned on purpose, on the record.

1. Decide which outages you will not have

Ask for the short list of workloads the business has committed to keeping up, and require that the disks behind them are zone-redundant so a single zone failing cannot take them down. The point is not to make everything redundant; it is to make a deliberate decision about which outages are unacceptable and to pay the modest, visible price to prevent them.

2. Ask for proof against a real failure, not assurance

The proof that this is closed is not a verbal 'the important things are redundant.' It is an inventory showing the disks behind committed workloads on a ZRS SKU, ideally with the resilience confirmed in a zone-failure or failover test, and the ZRS default baked into the templates that build new critical workloads. Because Advisor assesses on a cycle, ask for the inventory rather than relying on the recommendation count clearing.

3. Treat the single-zone critical workloads as named, owned decisions

A number of workloads will be left single-zoned to save cost, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner who has accepted its outage cost, not a default nobody chose. The goal is not zero single-zone disks; it is zero single-zone disks behind a workload you cannot afford to lose.

Quick quiz

Question 1 of 5

At a board review you ask whether the payments service would survive a single zone failing, like the one that took a competitor down. What end state is the defensible answer?

Keep learning

Go deeper on how Azure managed disks express zone redundancy and how to convert the disks that need it.

Two takeaways. Zone-redundant disks are how you decide, in advance, that a single zone failing will not take down a workload you committed to keeping up, and the price is a small, asymmetric uplift on a short list of disks. And the defensible end state is not 'we converted everything'; it is the disks behind committed workloads on a ZRS SKU by deliberate choice, ZRS set as the default for new critical workloads, and the single-zone exceptions documented and owned.

Back to the library

Part of the learning path Build in Azure resilience

Choose zone-redundant storage for managed disks

Zone-redundant disks: the basics

Three zones, one write

Finding single-zone disks behind critical workloads

How Azure decides a disk can survive a zone failuredeep dive

What is the impact of leaving a critical disk single-zoned?

How do you move critical disks to ZRS safely?

1. Inventory disks by redundancy and workload

2. Tier by cost of an outage

3. Convert the critical disks the right way for their shape

4. Make ZRS the default for new critical workloads

Quick quiz

Keep learning

Zone-redundant disks: the downtime and cost view

Three zones, one write

How a finance partner frames the ZRS decision

Why single-zone disks are a downtime cost, not a storage line

What finance can do about single-zone disks

1. Price the uplift against the cost of an outage, disk by disk

2. Tier the estate so you do not over-insure

3. Require a recorded reason for each tier

Quick quiz

Keep learning

Zone-redundant disks: the headline

Three zones, one write

What it looks like when a zone failure is a non-event

Why this is a board-level resilience question

The leadership move on zone redundancy

1. Decide which outages you will not have

2. Ask for proof against a real failure, not assurance

3. Treat the single-zone critical workloads as named, owned decisions

Quick quiz

Keep learning

Related site reliability lessons