Site Reliability

Turn on zone redundancy for Cosmos DB regions

A Cosmos DB region without zone redundancy can park all of its replicas in one datacentre, so a single availability-zone outage takes the region offline. Spreading those replicas across zones keeps the account serving reads and writes while one zone is down, and on most accounts it costs nothing extra.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Zone redundancy for Cosmos DB: the basics

What does a region without zone redundancy actually expose you to?

An availability zone is a physically separate group of datacentres within an Azure region, each with its own power, cooling and network. A region typically has three of them, and a zonal outage, a power or cooling fault in one zone, is a far more common event than a whole region failing. Cosmos DB keeps four replicas of your data behind each region. When zone redundancy is off, those replicas can all sit in a single availability zone, which Microsoft does not reveal to you, so if that one zone has an outage the region loses read and write availability until the zone recovers. When zone redundancy is on, Cosmos DB distributes the replicas across multiple zones, and the region keeps serving traffic while any single zone is down.

Azure Advisor surfaces this as a reliability recommendation, 'Enable zone redundancy for multi-region Cosmos DB accounts', because the gap is invisible until the day a zone fails. The account looks healthy, throughput is fine, latency is fine, and nothing in normal operation tells you that every replica for a region is one datacentre away from going dark together. Zone redundancy is the setting that turns a zonal outage from an availability incident into a non-event the platform handles for you, with no failover to initiate and no application code to change.

The important detail is that zone redundancy is configured per region, not per account. A Cosmos DB account can span several Azure regions, and each one is enabled, or not, independently. Some older regions do not support availability zones at all, but that never blocks you from enabling zone redundancy on the regions that do. So the work is not one switch: it is finding every region on every account that could be zone redundant and is not, and deciding which to fix.

In this lesson you will learn how Cosmos DB places replicas across availability zones, why a region without zone redundancy is exposed to a single zonal outage, how to find every region on every account that could be zone redundant and is not, and how to enable it safely, including the migration path for regions that already exist. Because zone redundancy can only be set when a region is added, the safe sequence matters and is covered step by step.

Fun fact

Four replicas, possibly one room

Cosmos DB keeps four replicas of your data in every region for durability, which sounds like plenty of resilience until you learn that, without zone redundancy, all four can live in the same availability zone, and Microsoft deliberately does not tell you which one. Four copies in one datacentre protect you from a disk or a node failing; they do nothing for the whole zone losing power. Turning zone redundancy on is what spreads those copies across separate datacentres, and Microsoft applies synchronous replication across the zones so quorum is maintained, which is why a zone can drop without losing committed data and usually without you noticing more than a few seconds of redistribution.

Finding non-zone-redundant Cosmos DB regions across a subscription

Priya runs the platform team at a payments business. Azure Advisor has raised a reliability recommendation against the Cosmos DB account behind the checkout service, flagging that its regions are not zone redundant.

Before changing anything on a live database, Priya lists every Cosmos DB account and inspects the zone-redundancy flag on each of its regions, so she can separate the genuinely exposed accounts from the ones already protected and the ones in regions that cannot support zones at all.

List each account's regions with their zone-redundancy flag. A region showing False is one zonal outage away from going dark.

$ az cosmosdb list --query "[].{name:name, group:resourceGroup, regions:locations[].{r:locationName, az:isZoneRedundant}}" -o json

[

{ "name": "checkout-prod", "group": "rg-payments",

"regions": [ { "r": "West Europe", "az": false } ] },

{ "name": "catalog-prod", "group": "rg-shop",

"regions": [ { "r": "North Europe", "az": true } ] }

]

# checkout-prod: single region, zone redundancy off. Highest-value fix.

A single-region account with isZoneRedundant false is the highest-priority target: one zonal outage takes the whole database offline. Fix the revenue-bearing accounts first.

How Cosmos DB places replicas, and why Advisor flags the gapdeep dive

Each region in a Cosmos DB account holds a replica set of four replicas. With zone redundancy disabled the region is nonzonal: the platform may place all four replicas in a single availability zone, and you cannot see or choose which one. A power, cooling or network fault in that zone then takes the region's read and write availability with it until the zone recovers. With zone redundancy enabled, Cosmos DB spreads the replicas across separate availability zones and applies synchronous replication between them to hold quorum, so a single zone can drop without losing committed writes. When a zone fails, the platform detects it, terminates in-flight requests to the affected replicas, and reroutes traffic to healthy replicas in the surviving zones automatically; the application just retries, exactly as it should for any transient fault.

Azure Advisor evaluates this from the account's location configuration: the per-region 'isZoneRedundant' flag. When it is false on a region that sits in an availability-zone-capable region, Advisor raises the reliability recommendation to enable it. The flag is the same property you see in the CLI, in Bicep and ARM templates, and as the 'Availability Zone' toggle in the portal. Because the flag is per region, a multi-region account can legitimately show a mix: redundant where it can be, nonzonal where the region has no zones to spread across.

The constraint that shapes all the remediation work is that 'isZoneRedundant' can only be set when a region is added to the account. It is not a property you can flip in place on a region that already exists. That is why making an existing region zone redundant is a migration, not an edit: you add a temporary region, move the write workload to it, remove the original region, and add it back with zone redundancy on. Single-region serverless accounts are stricter still, they can only be made zone redundant at creation time, which is why Microsoft steers mission-critical workloads to provisioned throughput.

What is the impact of leaving a region non-zone-redundant?

The direct impact is availability. A nonzonal region can have all four of its replicas in one availability zone, so a single zonal outage, the most common kind of datacentre failure short of a full region loss, removes read and write access to that region until the zone is restored. For a single-region account that is a total outage of the database. For a multi-region account it means losing that region's local availability and leaning on the others, with whatever latency and failover behaviour that implies. None of this requires the dramatic scenario of a whole region failing; it only takes one datacentre having a bad day.

The second-order impact is everything that database sits under. Cosmos DB rarely fails alone: it backs a checkout, an auth service, a session store or an order pipeline, so its unavailability cascades into the user-facing service. The cost of that downtime, lost transactions, support load, customer churn, accrues for the full duration of the zone impairment, which is outside your control. Zone redundancy converts that from an outage you wait out into a few seconds of request redistribution the platform handles for you.

On the resilience and assurance side, an Azure Advisor reliability recommendation against a production database is exactly the kind of finding that looks negligent in hindsight after an outage. A clean reliability posture on the accounts that back revenue, every zone-capable region zone redundant, is a cheap and defensible artefact: it shows the single most common regional failure mode was designed out rather than left to chance.

How do you enable zone redundancy safely?

Work it as a per-region decision, and respect the one hard rule: zone redundancy can only be set when a region is added, never edited in place. New accounts get it for free at creation; existing regions need a careful migration so you never drop the write workload.

1. Inventory every region by its zone-redundancy flag

List every Cosmos DB account and the 'isZoneRedundant' flag on each of its regions. A region showing false in an availability-zone-capable region is the gap Advisor is flagging. Treat this inventory as the source of truth, and prioritise by what each account sits under, not by the order Advisor lists them.

2. Set it at creation for anything new

For new accounts and new regions, enable zone redundancy up front: it is a single flag at deploy time, with no migration and, on autoscale or multi-region-write accounts, no premium. In the portal it is the Availability Zones toggle; in the CLI, Bicep and ARM it is 'isZoneRedundant'. This is the cheapest possible moment to do it, so make it the default for production.

3. Migrate existing regions without dropping writes

Because the flag cannot be flipped in place, making an existing region zone redundant is a migration: add a temporary region, fail the write workload over to it, remove the original region, then add it back with zone redundancy on and fail back. Expect a few seconds of write unavailability as the platform checks cross-region consistency during the add and remove, and a short-lived cost for the temporary region and its replication. Plan it in a maintenance window.

4. Hold the line with policy and Advisor

Keep the Azure Advisor reliability recommendation in view so any new non-redundant production region is caught, and where you template deployments, bake 'isZoneRedundant: true' into the Bicep or ARM module so new regions are zone redundant by default rather than by memory. The goal is that the safe configuration is the one you get without thinking about it.

# Enabling zone redundancy on an EXISTING region is a migration: the flag
# can only be set when a region is added, never edited in place. The safe
# sequence adds a temporary region, fails over, then re-adds the original
# with zone redundancy on. Include ALL existing regions in every call.

ACCOUNT=checkout-prod
RG=rg-payments

# 1. Add a temporary region (West US) alongside the existing one (East US).
az cosmosdb update --name "$ACCOUNT" --resource-group "$RG" \
  --locations regionName=eastus failoverPriority=0 isZoneRedundant=False \
  --locations regionName=westus failoverPriority=1 isZoneRedundant=False

# 2. Wait for West US to show as Available, then fail writes over to it.
az cosmosdb failover-priority-change --name "$ACCOUNT" --resource-group "$RG" \
  --failover-policies westus=0 eastus=1

# 3. Remove the original region so it can be re-added zone redundant.
az cosmosdb update --name "$ACCOUNT" --resource-group "$RG" \
  --locations regionName=westus failoverPriority=0 isZoneRedundant=False

# 4. Add East US back WITH zone redundancy enabled.
az cosmosdb update --name "$ACCOUNT" --resource-group "$RG" \
  --locations regionName=westus failoverPriority=0 isZoneRedundant=False \
  --locations regionName=eastus failoverPriority=1 isZoneRedundant=True

# 5. Fail writes back to the now zone-redundant region, then remove the temp.
az cosmosdb failover-priority-change --name "$ACCOUNT" --resource-group "$RG" \
  --failover-policies eastus=0 westus=1
az cosmosdb update --name "$ACCOUNT" --resource-group "$RG" \
  --locations regionName=eastus failoverPriority=0 isZoneRedundant=True

# --- For NEW accounts/regions, zone redundancy is free of migration. ---
# Bake it into the locations array in Bicep so it is the default:
#
# resource account 'Microsoft.DocumentDB/databaseAccounts@2024-11-15' = {
#   name: 'checkout-prod'
#   location: 'eastus'
#   properties: {
#     databaseAccountOfferType: 'Standard'
#     locations: [
#       {
#         locationName: 'eastus'
#         failoverPriority: 0
#         isZoneRedundant: true
#       }
#     ]
#   }
# }

Quick quiz

Question 1 of 5

Without zone redundancy, where can Cosmos DB place the four replicas it keeps in a region?

Keep learning

Go deeper on how Cosmos DB uses availability zones and how to enable zone redundancy safely on new and existing accounts.

You can now treat Cosmos DB zone redundancy as a per-region reliability decision rather than a single switch: inventory every region by its isZoneRedundant flag, set it for free at creation on anything new, migrate existing regions carefully because the flag cannot be edited in place, and keep Advisor and your templates holding the line. The one rule to remember is that zone redundancy is set when a region is added, never afterwards, so the migration sequence exists to enable it without dropping your write workload.

Back to the library

Zone redundancy for Cosmos DB: the cost and downtime view

A near-zero-cost setting that removes the most common cause of a Cosmos DB region going dark

This is a downtime decision, not a security one, and the cost arithmetic is unusually favourable. For accounts that use autoscale throughput, or that already write to more than one region, Microsoft waives the zone-redundancy premium entirely, so enabling it on those accounts changes nothing on the bill. The only accounts that carry an incremental charge are single-write-region accounts on standard provisioned throughput, where zone-redundant regions are billed at a premium rate. Even there the comparison is not premium versus free: it is premium versus the cost of a region outage on a database that backs live services.

Frame each Advisor recommendation as a line on the downtime risk register rather than a tidy-up task. A Cosmos DB account behind a checkout flow, an authentication service or an order pipeline has a cost of downtime measured in lost revenue per minute, plus support load and customer churn. A zonal outage on a non-redundant region takes that database offline for as long as the zone is impaired. The premium for zone redundancy, where it applies at all, is small and predictable; the cost of the outage it prevents is large and unpredictable.

The one genuine trade-off worth pricing is the migration itself. Zone redundancy can only be set when a region is added, so making an existing region zone redundant means temporarily standing up a second region, failing over to it, and removing and re-adding the original. That temporary region and its data replication carry a real, short-lived cost, and there is a few seconds of write unavailability during the swap. Both are bounded and one-off, and both should be on the plan rather than a surprise.

This lesson is for the finance partner who sees an Azure Advisor reliability recommendation against a Cosmos DB account and wants to know what it costs to act, what it costs to ignore, and how to tell the two apart. It covers which accounts get zone redundancy for free, which carry a small premium, the one-off cost of the migration, and how to weigh all of that against the cost of a region outage.

Fun fact

Four replicas, possibly one room

How a finance partner frames the zone-redundancy decision

Priya is the finance partner supporting the payments platform. Azure Advisor's reliability recommendation lands against three Cosmos DB accounts. The instinct is not to wave through a resilience budget or to dismiss it as gold-plating; it is to ask two questions per account: what does it cost to enable, and what does an outage of this database cost the business. The first question splits the accounts cleanly. Two of them use autoscale throughput, so the zone-redundancy premium is waived and enabling it is free on the bill. The third is a single-write-region account on standard provisioned throughput, where zone-redundant regions are billed at a premium rate, so that one carries a small, ongoing incremental cost.

The second question reorders them by what they sit under. The checkout account backs a flow with a known revenue-per-minute, so even a short zonal outage has a four- or five-figure cost; the catalog account degrades gracefully if it blips; the internal reporting account can tolerate an hour down. Priya's pack reads: 'Two accounts get zone redundancy at no incremental spend, do them now. The checkout account carries a small premium that is dwarfed by its cost of downtime, approve it. The reporting account is the only real cost-versus-risk judgement, and on its low downtime cost we can defer it.' The migration itself, a temporary second region for a few hours, is costed once as a one-off line, not a recurring charge.

Why a non-zone-redundant region belongs on the downtime risk register

The cost model here is asymmetric in the way that makes resilience easy to justify. For accounts on autoscale or with multi-region writes, the premium is waived, so the protection is free and the only thing you are weighing is the one-off migration. For standard single-write-region accounts there is a real but small recurring premium on the zone-redundant region. On the other side of the ledger is the cost of the outage that zone redundancy prevents, which is the database's revenue-per-minute multiplied by an outage duration you do not control, plus support and churn.

The finance role is to attach a cost of downtime to each account so the recommendation is prioritised by business impact rather than treated as a uniform line item. A checkout database with a high revenue-per-minute justifies the premium many times over and should be done first; an internal reporting database with a low cost of downtime is a genuine judgement call where deferral can be the right answer. The metric for the review is not 'how many Advisor recommendations are open', it is 'how much cost-of-downtime exposure is still sitting on non-redundant regions', with the migration costed once as a bounded one-off.

What finance can do about the zone-redundancy gap

Finance cannot toggle a region flag, but it owns the framing that turns an Advisor recommendation into a downtime-ordered plan with mostly zero incremental spend and one clearly bounded migration cost. Three levers.

1. Separate the free enablements from the priced ones

Make explicit that zone redundancy is free on accounts using autoscale throughput and on multi-region-write accounts, because Microsoft waives the premium there. The only recurring cost is the premium on zone-redundant regions for standard single-write-region accounts. Budget those few as discrete lines and treat the rest as no-cost reliability, so nobody can claim the whole recommendation is a spending decision.

2. Order the work by cost of downtime, not by recommendation count

A checkout database and an internal reporting database can both raise the same Advisor recommendation, but their cost of downtime differs by orders of magnitude. Ask the team to attach a revenue-per-minute, or a clear qualitative impact, to each account, and prioritise the high-downtime-cost databases first. The metric for the review is the cost-of-downtime exposure still sitting on non-redundant regions, not the raw recommendation total.

3. Cost the migration once, as a bounded one-off

Enabling zone redundancy on an existing region needs a temporary second region for a few hours and a short window of write unavailability. Price that as a single, one-off line per account, the temporary region's throughput and replication for the duration, not as a recurring charge. Distinguishing the one-off migration cost from the ongoing premium keeps the decision honest and stops the migration being mistaken for a permanent expense.

Quick quiz

Question 1 of 5

Azure Advisor raises the zone-redundancy recommendation against three Cosmos DB accounts. As the finance partner, what is the right starting assumption about the cost to remediate?

Keep learning

Go deeper on how Cosmos DB uses availability zones and how to enable zone redundancy safely on new and existing accounts.

You have finished the finance view of Cosmos DB zone redundancy. You know the cost model is one-sided: it is free on autoscale and multi-region-write accounts, carries only a small premium on standard single-write-region accounts, and the migration is a bounded one-off rather than a recurring charge, all weighed against a region outage measured in revenue-per-minute. Next time the recommendation lands, you will order accounts by cost of downtime, approve the free and small-premium fixes quickly, and ring-fence the genuinely deferrable internal databases as documented exceptions.

Back to the library

Zone redundancy for Cosmos DB: the headline

Whether a single datacentre fault can take a business-critical database offline

Zone redundancy is the difference between 'a power fault in one datacentre is a non-event' and 'a power fault in one datacentre takes our database down'. Cosmos DB sits under things customers feel directly, carts, logins, orders, so when one of its regions cannot serve traffic, that is usually a visible outage with a revenue number attached.

The leadership question is not 'is the database up today?' It is 'if one of our datacentres has a bad afternoon tomorrow, do our customers notice?' With zone redundancy on, the answer is no: Azure keeps the region serving from the surviving zones with no human in the loop. With it off, a single zone fault is an outage you wait out.

For most accounts this resilience is free, because the premium is waived on autoscale and multi-region-write configurations. Where a charge does apply it is small and bounded, and it buys down the most common class of regional failure. This is a downtime-versus-cost decision, and the cost side is modest against the price of the outage it removes.

A short read for the leader who needs to know what a non-zone-redundant Cosmos DB region actually risks, why enabling zone redundancy is usually a free reliability upgrade, and what the defensible end state looks like for the databases that sit under revenue-bearing services.

Fun fact

Four replicas, possibly one room

What it looks like when a zonal outage stops being an incident

After a regional cloud incident put a competitor's checkout offline for an afternoon and made the trade press, the CEO asked the obvious question at the next review: if one datacentre has a problem, do we go down too? The honest answer at the time was that it depended on the account, because the database behind checkout kept all its replicas in a single availability zone and a zone fault would have taken it offline until the zone recovered.

The team's response was to treat zone redundancy as a default for anything revenue-bearing rather than an optional extra. They listed every Cosmos DB region that was not zone redundant, enabled it for free on the accounts using autoscale, approved the small premium on the standard-throughput checkout account, and scheduled the one-off migration for the regions that already existed. The next time the CEO asked, the answer had changed from 'it depends' to 'the customer-facing databases ride through a single zone failure automatically, and the only accounts still exposed are internal ones we have consciously decided can wait.' That shift, from hoping a zone holds to the platform absorbing the failure, is the confidence this setting delivers, and on most of the estate it cost nothing to reach.

Why this is a board-level resilience question

The most common way a cloud region hurts you is not a full region failure, it is a single availability zone having an outage. A Cosmos DB region without zone redundancy is fully exposed to exactly that event, and the database behind a customer-facing service is precisely where an outage turns into a revenue number and a headline. Zone redundancy designs that failure mode out, and the platform absorbs it with no human intervention.

The cost of getting this wrong is the cost of the outage; the cost of getting it right is zero on most accounts and small on the rest. This is the rare reliability control where the protection is usually free, the residual cost is bounded, and the downside it removes is a visible, customer-facing outage, which is exactly the trade leadership should approve quickly for anything revenue-bearing.

The leadership move on zone redundancy

The executive handle is not to approve each region individually; it is to make zone redundancy the default for revenue-bearing databases and to require an explicit, owned decision wherever a production region is left non-redundant.

1. Make zone redundancy the default for revenue-bearing data

Set the expectation that any Cosmos DB account behind a customer-facing or revenue-bearing service is zone redundant on every region that can be, and that new accounts are created that way from the start. On most of these the premium is waived, so this is a reliability default that costs nothing, not a budget request.

2. Approve the bounded costs without ceremony

Where a standard-throughput account carries the small zone-redundancy premium, or an existing region needs the one-off migration, approve those quickly for the databases that sit under revenue. The premium and the migration are both small and bounded, and they buy down the most common regional failure mode. This is the trade that should not need a long discussion.

3. Require named, owned exceptions for what you leave exposed

Some accounts, internal reporting, low-traffic back-office stores, genuinely have a low enough cost of downtime to defer. That is fine, but make each one a deliberate, recorded decision with an owner, not an Advisor recommendation nobody got to. The goal is not zero non-redundant regions; it is zero non-redundant regions that anyone would be surprised to find exposed after an outage.

Quick quiz

Question 1 of 5

At a board review you ask whether a single datacentre fault could take a customer-facing database offline. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Cosmos DB uses availability zones and how to enable zone redundancy safely on new and existing accounts.

Two takeaways. Zone redundancy protects against the most common regional failure, a single datacentre outage, and on most production databases it costs nothing, so it is the reliability trade you should approve fastest. And the defensible end state is not 'the database was up last quarter'; it is that every revenue-bearing Cosmos DB account is zone redundant on every supported region, new regions are templated that way by default, and the few non-redundant ones left are deliberate, owned decisions nobody would be surprised by.

Back to the library

Part of the learning path Build in Azure resilience

Turn on zone redundancy for Cosmos DB regions

Zone redundancy for Cosmos DB: the basics

Four replicas, possibly one room

Finding non-zone-redundant Cosmos DB regions across a subscription

How Cosmos DB places replicas, and why Advisor flags the gapdeep dive

What is the impact of leaving a region non-zone-redundant?

How do you enable zone redundancy safely?

1. Inventory every region by its zone-redundancy flag

2. Set it at creation for anything new

3. Migrate existing regions without dropping writes

4. Hold the line with policy and Advisor

Quick quiz

Keep learning

Zone redundancy for Cosmos DB: the cost and downtime view

Four replicas, possibly one room

How a finance partner frames the zone-redundancy decision

Why a non-zone-redundant region belongs on the downtime risk register

What finance can do about the zone-redundancy gap

1. Separate the free enablements from the priced ones

2. Order the work by cost of downtime, not by recommendation count

3. Cost the migration once, as a bounded one-off

Quick quiz

Keep learning

Zone redundancy for Cosmos DB: the headline

Four replicas, possibly one room

What it looks like when a zonal outage stops being an incident

Why this is a board-level resilience question

The leadership move on zone redundancy

1. Make zone redundancy the default for revenue-bearing data

2. Approve the bounded costs without ceremony

3. Require named, owned exceptions for what you leave exposed

Quick quiz

Keep learning

Related site reliability lessons