Site Reliability

Replicate storage accounts across availability zones

One reliability capability across Blob, File, Table and Queue: move accounts off locally redundant storage so their data is written synchronously across three availability zones and stays readable and writable when one zone goes dark.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Zone-redundant storage: the basics

What actually happens to a locally redundant account when a zone goes down?

A storage account's redundancy setting decides how many copies of your data exist and where they sit. Locally redundant storage (LRS) keeps three copies, but all three live in a single physical datacentre in the primary region. That protects you against a failed drive, server or rack, and Microsoft documents it at at least eleven nines of annual durability, but every copy shares one building. If that one datacentre has a power, cooling or networking event, every replica of the account can become unavailable at once, and the account stops answering reads and writes until the event clears.

Zone-redundant storage (ZRS) keeps the same three copies but spreads them across three or more Azure availability zones in the region, each a separate physical location with independent power, cooling and networking. A write returns successfully only after the data is committed across the zones, so the copies are always consistent, and if one zone becomes unavailable the account stays readable and writable from the others. Microsoft documents ZRS at at least twelve nines of annual durability. Geo-zone-redundant storage (GZRS) adds an asynchronous copy in a second region hundreds of miles away on top of the zone spread, taking documented durability to at least sixteen nines and protecting against a whole-region outage.

Most accounts that are still LRS are LRS by default, not by decision. LRS is the cheapest option and the one a bare ARM template or a quick portal click lands on, so an account created years ago for a workload that has since become business-critical can still be single-zone without anyone choosing that. The work in this lesson is to find every account whose data would be unavailable if a single zone failed, decide which ones genuinely need to survive a zone outage, and convert them to ZRS or GZRS with no downtime.

In this lesson you will learn how Azure Storage expresses zone redundancy, how to find every account whose data sits in a single zone, and how to convert the ones that matter to ZRS or GZRS with no application downtime. You will see how an LRS to ZRS conversion runs as a background operation, how long it takes and what the 72-hour rule means, and how to bake the right redundancy into new accounts so they are never single-zone by accident.

Fun fact

Durable is not the same as available

Locally redundant storage is advertised at eleven nines of annual durability, a number so large it reads as bulletproof. It is easy to assume that means the account will always be there. It does not. Durability measures the chance of permanently losing an object; availability measures whether you can reach it right now. An LRS account can hit its full durability target and still be completely unreachable for hours, because all three of its copies live in one datacentre and that datacentre is having a bad day. Zone-redundant storage is what turns near-perfect durability into near-perfect availability, by making sure the three copies are never in the same building.

Finding single-zone storage across a subscription

Priya is the reliability lead at a payments company running a post-incident review. A short availability-zone event in their primary region briefly knocked over a workload, and the question on the table is which other accounts would have gone down too.

Rather than guess, Priya starts by listing every storage account and its redundancy SKU, so the single-zone LRS accounts stand out from the ones already spread across zones.

List every storage account with its redundancy SKU. Anything reading Standard_LRS is single-zone: all its data sits in one datacentre.

$ az storage account list --query "[].{name:name, sku:sku.name, region:primaryLocation}" -o table

Name Sku Region

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

paymentsledgerprod Standard_LRS uksouth

checkoutsessions Standard_LRS uksouth

analyticsstaging Standard_LRS uksouth

marketingassets Standard_ZRS uksouth

# paymentsledgerprod and checkoutsessions are single-zone and business-critical. Convert first.

A business-critical account on Standard_LRS is the highest-value target: one datacentre event takes it offline. Convert the revenue-path accounts before the regenerable staging ones.

How a zone-redundancy conversion actually worksdeep dive

Zone redundancy is a property of the account's SKU, not a per-container toggle. Standard_LRS means one datacentre; Standard_ZRS means three zones; Standard_GZRS adds the geo copy, and the read-access variants Standard_RAGRS and Standard_RAGZRS make the secondary region readable. Because the setting is on the account, every blob container, file share, table and queue in that account inherits the same redundancy. You cannot make one container zone-redundant and leave another single-zone.

Changing the zone-redundancy aspect is a conversion, which Azure runs as a background operation with no data loss and, for standard accounts, no interruption to availability. Microsoft documents that hierarchical-namespace accounts may see a pause of under thirty seconds while the account switches resiliency level, and that requests complete automatically after it. Service endpoints, access keys and shared access signatures are unchanged by the conversion, so applications keep working throughout. A customer-initiated conversion typically begins within 72 hours of you starting it, and there is no SLA on how long it then takes, which is why a date-driven move sometimes uses a manual migration instead.

Two rules catch people out. Adding geo-redundancy and adding zone-redundancy cannot be done in one step: going from LRS straight to GZRS is a two-step process, switch to GRS first, then convert to GZRS, in either order. And after any zone-redundancy conversion you must wait at least 72 hours before changing the account's redundancy again, while background processes settle. Knowing both up front stops a multi-account programme from stalling halfway.

What is the impact of leaving a critical account single-zone?

The direct impact is availability. A locally redundant account keeps all three copies in one datacentre, so when that datacentre has a power, cooling or networking event, the account stops answering reads and writes until the event resolves. Microsoft's own outage-scenario table is explicit: when an entire datacentre becomes unavailable, an LRS account is neither durable nor available, while a ZRS account stays both. If that account is the data store behind a live workload, the workload goes down with it.

The second-order impact is blast radius and recovery. A zone event is not something you can fix from inside the account; with LRS you wait for Azure to restore the datacentre, and your recovery time is whatever theirs turns out to be. With ZRS the account simply keeps serving from the surviving zones, and the only application-side concern is handling the brief networking repoint with normal retry logic. You convert an unbounded, out-of-your-hands outage into a non-event.

On the reliability side, this is the difference between a workload that meets its availability target on paper and one that meets it when a zone actually fails. Surviving a single-zone outage is the baseline expectation for anything the business calls critical, and a storage account quietly left on LRS is the weak link that turns a contained zone event into a workload-level outage.

How do you make critical storage zone-redundant safely?

Work this as one programme, not account by account in a panic. The order matters: decide which accounts genuinely need to survive a zone outage before you start converting, so the recurring uplift lands only where downtime would actually cost you.

1. Inventory every account by redundancy SKU

List every storage account with its SKU and region. Anything on Standard_LRS is single-zone. Treat this list as the source of truth: redundancy is an account-level property, so one account is one decision regardless of how many containers, shares, tables or queues it holds.

2. Rank accounts by the cost of their downtime

For each LRS account, ask what stops if a single zone takes it offline. Revenue-path and operations-critical stores go to the top; data that can simply be regenerated goes to the bottom and can stay LRS. The output is a ranked list where the redundancy uplift is justified by an outage cost, not applied uniformly.

3. Convert the critical accounts with no downtime

Run a customer-initiated conversion to ZRS, or to GZRS where the workload also needs to survive a whole-region outage. The conversion runs in the background with no data loss and, for standard accounts, no availability interruption. Remember that LRS to GZRS is two steps, and that you must wait at least 72 hours after a zone-redundancy conversion before changing the same account's redundancy again.

4. Make new accounts zone-redundant by default

Stop the problem recurring by setting the SKU explicitly in your infrastructure-as-code templates and modules so new critical accounts are born ZRS or GZRS rather than defaulting to LRS. Back this with an Azure Policy audit so any new Standard_LRS account in a scope that should be zone-redundant is flagged for a deliberate decision rather than slipping through.

# Start a no-downtime, customer-initiated conversion of a critical account to ZRS.
# The conversion runs in the background; endpoints, keys and SAS tokens are unchanged.
az storage account migration start \
  --account-name paymentsledgerprod \
  --resource-group payments-rg \
  --sku Standard_ZRS \
  --no-wait

# Track the conversion status (the migration resource is always named "default").
az storage account migration show \
  --account-name paymentsledgerprod \
  --resource-group payments-rg \
  --name default \
  -o table

# Bake the right redundancy into new accounts so they are never single-zone by accident.
# Bicep: pin the SKU to Standard_ZRS (use Standard_GZRS to also survive a region outage).
cat > storage.bicep <<'EOF'
param location string = resourceGroup().location

resource criticalStore 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'paymentsledgerprod'
  location: location
  sku: {
    name: 'Standard_ZRS'
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    supportsHttpsTrafficOnly: true
  }
}
EOF

Quick quiz

Question 1 of 5

A storage account is on Standard_LRS. What is the key reliability limitation that converting it to Standard_ZRS removes?

Keep learning

Go deeper on how Azure Storage expresses redundancy across zones and regions, and how to change it without downtime.

You can now treat storage redundancy as one reliability capability rather than a per-account afterthought: inventory every account by SKU, rank them by the cost of their downtime, convert the critical ones to ZRS or GZRS with no application downtime, and pin the right SKU in your templates so new accounts are never single-zone by accident. The deliberately single-zone accounts become a recorded choice rather than a hidden risk.

Back to the library

Zone-redundant storage: the downtime and cost view

A small, documented uplift in storage cost against the much larger cost of a zone outage taking a workload offline

This is a rare reliability decision where both sides of the ledger are visible. Moving an account from LRS to ZRS raises the ongoing storage rate, because Azure now keeps and replicates copies across three zones rather than one datacentre, and GZRS adds a geo-replication rate and an egress charge at the moment the geo copy is seeded. Microsoft publishes these rates per redundancy option, ordered LRS, then ZRS, then GRS, then GZRS, so the uplift for any given account is a known number you can read off the pricing page, not a guess.

On the other side sits the cost of an outage. When a single-zone account is the data store behind a revenue or operations workload, a zone event does not just slow that workload down, it can stop it, and the cost is the value of whatever the workload produces per hour multiplied by the hours it is down, plus any contractual service credits owed to customers. The job for finance is to put those two numbers side by side per account: the bounded monthly uplift to spread it across zones, against the expected hourly cost if the one datacentre it sits in goes dark.

The point is to spend the uplift where it is justified and not where it is not. A staging account full of data that can be regenerated does not need to survive a zone outage and can stay LRS. The customer-facing transaction store does. Resilience is not a setting you switch on everywhere; it is a per-account decision priced against what downtime would actually cost.

This lesson is for the finance partner who needs to weigh a recurring storage uplift against the cost of an outage. It covers why ZRS and GZRS raise the bill, how to read the per-account uplift off Microsoft's published rates, and how to decide which accounts are worth spreading across zones by pricing the redundancy against what an hour of downtime would cost.

Fun fact

Durable is not the same as available

How a finance partner frames the redundancy decision

Priya is the finance partner sitting in on the post-incident review. The reliability team lands a list of nine accounts still on locally redundant storage, and the easy reaction would be to wave through converting all of them to be safe. The harder, cheaper reaction is to price each one. ZRS raises the ongoing storage rate per account, and GZRS adds a geo rate plus a one-off egress charge to seed the second region, and all of those are published numbers Priya can read off Microsoft's pricing page rather than estimate.

Priya asks the team to put a downtime cost against each account, not just a storage cost. The payments ledger and the checkout session store sit on the revenue path: an hour of those being unavailable has a number attached, in lost transactions and in service credits owed to customers under contract. Against that, the monthly ZRS uplift on two accounts is small and bounded, so they are obvious conversions. The analytics staging account holds data the pipeline can simply rebuild, so a zone outage costs a re-run, not revenue, and it stays LRS. The finance pack reads: 'Two revenue-path accounts move to ZRS for a small recurring uplift that is dwarfed by one hour of their downtime; the rest stay single-zone on the record because their outage cost does not justify the spend.'

Why redundancy belongs on the cost-of-downtime ledger

The trade here is unusually clean to price because both sides are knowable. The cost of action is the published storage uplift for ZRS or GZRS on the specific account, a recurring number you can read straight off Microsoft's pricing page. The cost of inaction is the expected cost of a zone outage on that account: the hourly value of the workload it backs, multiplied by the likely hours of downtime, plus any service credits owed to customers when an availability commitment is missed.

Because the uplift is bounded and the downtime cost can be large, the calculation usually resolves cleanly per account. Revenue-path and operations-critical stores clear the bar easily: a single hour of their downtime typically dwarfs a year of the ZRS uplift. Regenerable and low-criticality stores do not, and converting them is spend without a matching risk reduction. The finance role is to attach a downtime cost to each account so the redundancy spend lands on the accounts where an outage would actually hurt, and nowhere else.

What finance can do about the redundancy gap

Finance cannot run a conversion, but it owns the framing that stops this becoming either a blanket spend or an ignored risk. The goal is redundancy spend that tracks downtime cost. Three levers.

1. Price every conversion off the published rates, not estimates

Make explicit that the ZRS and GZRS uplift per account is a known number, because Microsoft publishes the rates per redundancy option from LRS up through GZRS. Ask for each proposed conversion to carry its real monthly uplift, so the programme is a list of priced decisions rather than a single 'make everything resilient' line that nobody can size.

2. Put a downtime cost next to every account, not just a storage cost

An account is only worth the uplift if its outage would cost more than the uplift. Ask the team to attach an hourly downtime cost to each LRS account: revenue lost, operations halted, service credits owed under contract. The metric that belongs on the review is the redundancy uplift weighted against the downtime cost of the workload behind it, so the spend lands where an outage would actually hurt.

3. Record the accounts you deliberately leave single-zone

Choosing to keep an account on LRS is a legitimate, money-saving decision when its data can be regenerated and its outage absorbed. The distinction that makes the posture defensible is between 'we reviewed this and accepted the zone risk to save the uplift' and 'we never noticed it was single-zone.' Require a recorded, finance-visible reason for each account left on LRS, so the saving is a choice on the record.

Quick quiz

Question 1 of 5

As the finance partner, how should you size the cost of converting an account from LRS to ZRS?

Keep learning

Go deeper on how Azure Storage expresses redundancy across zones and regions, and how to change it without downtime.

You have finished the finance view of zone-redundant storage. You know the trade is unusually clean to price: the ZRS or GZRS uplift per account is a published number, and the cost of inaction is the workload's hourly downtime value times likely outage hours plus any service credits owed. Next time a list of single-zone accounts lands, you will price each conversion off the rates, weigh it against the downtime cost of the workload behind it, convert where an outage would hurt, and record the ones you deliberately leave on LRS to save the uplift.

Back to the library

Zone-redundant storage: the headline

Whether a single datacentre event can take a business-critical workload offline

Azure regions are built from independent availability zones precisely so that one datacentre failing does not take a workload down. A storage account left on locally redundant storage opts out of that protection: all of its data lives in one datacentre, so a single zone event can make it unavailable and stop whatever depends on it. The report rarely shows this as one red line; it shows up as a scatter of accounts each quietly single-zone.

The leadership question is not how durable the data is on paper. Eleven nines sounds reassuring until you realise durability is about not losing data, not about staying online: a single-zone account can be perfectly durable and still go dark for hours when its datacentre has an event. The real question is whether the workloads that the business cannot run without can survive one zone going down.

This is a deliberate trade, not a free win. Spreading an account across zones costs more every month, so the decision is which workloads are worth that uplift to keep online through a zone outage, and the answer is the ones whose downtime would cost the business far more than the uplift ever will.

A short read for the leader who needs to know what a single-zone storage account risks, why surviving a zone outage is a deliberate cost decision rather than a default, and what a defensible end state looks like: the workloads the business depends on are zone-redundant, and the ones that are not are a recorded choice.

Fun fact

Durable is not the same as available

What it looks like when a zone outage is survivable by design, not luck

After the zone event that triggered the review, the CEO asked the blunt version of the question: if that happens again next quarter, does the business stop? The honest answer at the time was that it depended which datacentre was affected, because the accounts behind the critical workloads happened to be single-zone and nobody had decided that on purpose; it was just the default they were created with.

The team's response was to stop treating redundancy as a setting buried in each account and start treating it as a stated reliability posture. They listed every account, identified the handful whose downtime would actually stop the business, converted those to ZRS with no application downtime while the conversion ran in the background, and left the regenerable ones on LRS as a recorded choice rather than an accident. The next time the CEO asked, the answer had changed from 'it depends' to 'the workloads we cannot run without now survive a single zone going down, and the accounts we deliberately left single-zone are the ones whose outage we can absorb.' That shift, from default to decision, is the confidence signal this capability delivers, and it costs a known, bounded uplift to reach.

Why this is a resilience decision for leadership

Availability zones exist so that one datacentre failing is survivable. A critical workload sitting on a single-zone storage account silently opts out of that protection, which means the business has accepted a real outage risk without ever deciding to. Converting the accounts that matter to zone-redundant storage is the move that makes a single-zone event a non-event for the workloads that cannot afford one.

Unlike many reliability questions, the cost of getting this right is known and bounded: a published monthly uplift per account. The cost of getting it wrong is an outage whose length you do not control and whose hourly cost the business already understands. This is the trade leadership should be quickest to approve where the workload is critical, and equally quick to decline where it is not, so the spend tracks the risk.

The leadership move on storage redundancy

The executive handle is not to approve each conversion individually; it is to require that the workloads the business depends on survive a single-zone outage, and that the accounts deliberately left single-zone are a recorded, owned choice.

1. Set the survivability bar by workload criticality

State plainly which workloads must survive a zone outage and, where relevant, a region outage. Ask that the storage accounts behind those workloads are zone-redundant (ZRS) or geo-zone-redundant (GZRS) by a given date, and that the conversions run with no application downtime. The bar is set by what the business cannot run without, not by converting everything.

2. Ask for the redundancy posture, not a per-account count

The proof that this is handled is not 'we converted some accounts.' It is a posture statement: every critical workload's data store is zone-redundant, every account left on LRS is a recorded decision with an owner, and new critical accounts are zone-redundant by default in the templates. Ask for that posture, with the deliberate single-zone exceptions named.

3. Treat the single-zone accounts as named, owned exceptions

Some accounts can stay single-zone, and that is fine where the data is regenerable and the outage is absorbable. The leadership requirement is that each is a deliberate, documented decision with an owner and a reason, not an accident. The goal is not zero LRS accounts; it is zero critical workloads sitting on one by mistake.

Quick quiz

Question 1 of 5

At a board review after a zone event, what end state should you be looking for as the defensible answer on storage resilience?

Keep learning

Go deeper on how Azure Storage expresses redundancy across zones and regions, and how to change it without downtime.

Two takeaways. Durability is not availability: a single-zone account can be near-perfectly durable and still go dark for hours when its datacentre has an event, so the question is which workloads must survive that. And the defensible end state is not 'every account is zone-redundant'; it is that the workloads the business depends on survive a single zone going down for a known, bounded uplift, and the accounts you deliberately left single-zone are owned, documented choices.

Back to the library

Part of the learning path Build in Azure resilience

Replicate storage accounts across availability zones

Zone-redundant storage: the basics

Durable is not the same as available

Finding single-zone storage across a subscription

How a zone-redundancy conversion actually worksdeep dive

What is the impact of leaving a critical account single-zone?

How do you make critical storage zone-redundant safely?

1. Inventory every account by redundancy SKU

2. Rank accounts by the cost of their downtime

3. Convert the critical accounts with no downtime

4. Make new accounts zone-redundant by default

Quick quiz

Keep learning

Zone-redundant storage: the downtime and cost view

Durable is not the same as available

How a finance partner frames the redundancy decision

Why redundancy belongs on the cost-of-downtime ledger

What finance can do about the redundancy gap

1. Price every conversion off the published rates, not estimates

2. Put a downtime cost next to every account, not just a storage cost

3. Record the accounts you deliberately leave single-zone

Quick quiz

Keep learning

Zone-redundant storage: the headline

Durable is not the same as available

What it looks like when a zone outage is survivable by design, not luck

Why this is a resilience decision for leadership

The leadership move on storage redundancy

1. Set the survivability bar by workload criticality

2. Ask for the redundancy posture, not a per-account count

3. Treat the single-zone accounts as named, owned exceptions

Quick quiz

Keep learning

Related site reliability lessons