Site Reliability

Span Cosmos DB across at least two regions

A single-region Cosmos DB account is one regional outage away from going dark. Adding a second region, and enabling service-managed failover, turns a full outage into a brief, recoverable event, and Azure Advisor flags every production account that is still single-region.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Spanning Cosmos DB across regions: the basics

What does a single-region Cosmos DB account actually risk?

An Azure Cosmos DB account placed in a single region is highly resilient inside that region: Cosmos DB keeps multiple replicas of your data behind a quorum, and within a region a node failure is invisible to your application. What it cannot survive is the loss of the whole region. If the Azure region hosting that account has an outage, the account is unreachable for reads and writes until the region recovers, and there is no second copy of the data anywhere else to fall back to. For a production workload, that is the difference between a transparent blip and a full outage.

Azure Advisor surfaces exactly this gap. Its reliability recommendation 'Add a second region to your production workloads on Azure Cosmos DB' fires on accounts that run in a single region, under the Business Continuity category for the resource type microsoft.documentdb/databaseAccounts. The recommendation's own guidance is direct: production workloads running in a single region can have availability issues, and you increase availability by configuring the account to span at least two Azure regions, with a single write region and at least one additional read region, and service-managed failover enabled.

Most single-region accounts are not single-region on purpose. An account is created in one region for a proof of concept, the workload quietly becomes production, and nobody revisits the topology. The work in this lesson is to find every production Cosmos DB account that is still single-region, add a second region with the right failover priority, turn on service-managed failover so Azure can promote the second region automatically, and understand what that does and does not protect against, so the resilience you buy matches the resilience you think you bought.

In this lesson you will learn why a single-region Cosmos DB account is a single point of failure, how Azure Advisor detects it, and how to add a second region and service-managed failover safely without taking the account offline. You will also learn what multi-region does and does not protect against, so you can right-size the topology per workload rather than over- or under-spending.

Fun fact

Resilient inside a region, helpless without a second one

A single-region Cosmos DB account already keeps several replicas of your data behind a quorum, so it shrugs off individual machine failures with no downtime at all. That local resilience is so good it can be misleading: teams see an account that never wobbles and assume it is highly available, when in fact its entire fate is tied to one Azure region. The replicas that make it bulletproof against a node failure are all in the same place. Adding a second region is the step that takes resilience from 'survives a server' to 'survives a region,' and it is the one Azure Advisor keeps reminding you about until you take it.

Finding single-region Cosmos DB accounts before an outage finds them

Priya runs platform reliability at a payments company. After a near miss when a dependency had a regional incident, she pulls the Azure Advisor reliability recommendations and sees 'Add a second region to your production workloads on Azure Cosmos DB' flagged on several accounts.

Before changing anything, she lists the Cosmos DB accounts that have only one configured location, so she can separate the genuinely production accounts that need a second region from the dev and test accounts that do not.

List every Cosmos DB account with how many regions it spans, so the single-region production accounts stand out.

$ az cosmosdb list --query "[].{name:name, group:resourceGroup, regions:length(locations)}" -o table

Name Group Regions

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

payments-prod rg-payments 1

ledger-prod rg-ledger 2

payments-dev rg-payments 1

# payments-prod is single-region AND production. That is the one to fix first.

A single-region production account is the real finding. A single-region dev account is fine. Match each Advisor hit to the workload before you spend on a second region.

How a second region and service-managed failover actually behavedeep dive

A Cosmos DB account's topology is its 'locations' array. Each location has a region name and a 'failoverPriority': priority 0 is the write region, and any priority greater than zero is a read region, in the order Azure would promote them. A single-region account has exactly one location at priority 0, which is why losing that region loses everything. Adding a location at priority 1 gives the account a second, continuously replicated copy of the data that can serve reads immediately and become the write region if needed.

'enableAutomaticFailover' (set with the CLI flag --enable-automatic-failover, sometimes called service-managed failover) controls what happens when the write region fails. With it on, you have told Azure the failover order through the priorities, and Azure will promote the highest-priority healthy region to be the new write region without you doing anything. With it off, reads still continue from the healthy region during a write-region outage, but write recovery waits for you to act. Either way, a second region is the prerequisite: there is nothing to fail over to without one.

Two behaviours matter for planning. First, service-managed failover is automatic but not instant: Microsoft documents that declaring an outage and triggering it can take a significant amount of time, potentially an hour or more, which is why a forced failover is the faster lever when you need writes back quickly on a critical path. Second, the data-loss exposure on failover depends on the account's consistency level: with strong consistency there is no data loss, while with weaker levels a small window of unreplicated writes could be lost, so the recovery point objective is a property of how you configured consistency, not just of having a second region.

What is the impact of leaving Cosmos DB single-region?

The direct impact is total dependence on one Azure region. A single-region account is fully available only as long as its region is. When that region has an outage, the account is unreachable for reads and writes for the duration, and recovery is entirely in Azure's hands because there is no second copy to serve from. For a production workload, that converts an Azure regional incident directly into your own outage, of the same length.

The availability difference is also documented in the service level. Microsoft publishes higher availability SLAs as you add resilience: a single-region account without availability zones carries a 99.99% availability SLA, a single-region account with zone redundancy 99.995%, and a multi-region account 99.999%. Each extra nine is an order-of-magnitude reduction in expected downtime, and a single-region account sits at the bottom of that ladder.

The second-order impact is that you have no lever to pull during an incident. With a single-region account, your incident response to a region outage is to wait and to communicate. With a second region and service-managed failover, you have options: reads keep serving immediately from the healthy region, writes recover automatically, and for the most critical workloads you can force a failover to restore writes faster than the automatic process. Resilience is partly about avoiding outages and partly about having something you can actually do when one starts.

How do you add a second region safely?

Treat this as a deliberate, per-account change, not a blanket sweep, because each second region costs money. The order matters: confirm the account is production, add the region, then enable service-managed failover, and remember that adding a region must be a separate operation from any other change to the account.

1. Confirm the account is genuinely production

A second region is recurring spend, so only add it where an outage actually costs money. List the single-region accounts, match each to the workload behind it, and ring-fence the production, customer-facing accounts. Dev, test and sandbox accounts can stay single-region by design.

2. Add the second region as its own operation

Add a location at the next failover priority, picking a paired or nearby region that suits your latency and residency needs. Adding or removing a region must be done on its own: you cannot change a region and another account property in the same call. Cosmos DB fully replicates the data into the new region before marking it available, so this is a non-disruptive online operation.

3. Enable service-managed failover

Once the account has two or more regions, turn on service-managed failover so Azure promotes the highest-priority healthy region automatically if the write region fails. Set the failover priorities deliberately so the order Azure would promote matches your intent. Without this, reads still survive a write-region outage but write recovery waits on you.

4. Decide your consistency level and rehearse failover

Your recovery point on failover depends on consistency: strong consistency means no data loss, weaker levels risk a small window of unreplicated writes. For the most critical path, rehearse a forced failover in a drill, because service-managed failover can take an hour or more to trigger, and a forced failover is the faster lever when you need writes back quickly.

# Step 1: add a second region. This must be its own operation; you cannot
# change regions and other account properties in the same call. Keep the
# existing write region at priority 0 and add the read region at priority 1.
az cosmosdb update \
  --name payments-prod \
  --resource-group rg-payments \
  --locations regionName="West Europe" failoverPriority=0 isZoneRedundant=False \
  --locations regionName="North Europe" failoverPriority=1 isZoneRedundant=False

# Step 2: once the account spans two regions, enable service-managed failover
# so Azure promotes the read region automatically if the write region fails.
accountId=$(az cosmosdb show -g rg-payments -n payments-prod --query id -o tsv)
az cosmosdb update --ids "$accountId" --enable-automatic-failover true

# Drill only: force a failover to test recovery (promotes North Europe to write).
# az cosmosdb failover-priority-change --ids "$accountId" \
#   --failover-policies 'North Europe=0' 'West Europe=1'

Quick quiz

Question 1 of 5

Azure Advisor flags 'Add a second region to your production workloads on Azure Cosmos DB' on an account. What is the underlying risk it is pointing at?

Keep learning

Go deeper on how Cosmos DB distributes data globally, what failover does, and how the availability SLA changes with topology.

You can now treat single-region Cosmos DB as the continuity risk Azure Advisor says it is: find every production account running in one region, add a second region as its own operation, enable service-managed failover so Azure promotes the secondary automatically, and rehearse a forced failover for the most critical path. Because the second region has a real recurring cost, you also know to spend it per workload, where an outage actually costs money, rather than estate-wide.

Back to the library

Spanning Cosmos DB across regions: the downtime-cost view

A predictable recurring cost weighed against the cost of an outage you cannot bound

Unlike many reliability fixes, this one does have a real and recurring Azure cost. A second region means a second copy of the data and the throughput to serve it, so a two-region account roughly carries the storage and provisioned throughput of both regions. Azure Advisor states this plainly: additional regions incur additional cost. That is the honest side of the ledger, and it should be budgeted as a line item, not buried.

The other side is the cost of the outage you are insuring against. A single-region Cosmos DB account that backs a customer-facing service has an unbounded downtime exposure: if its region goes down, the service is down for the duration, and you have no lever to pull. The cost of that is lost revenue per minute, breached customer commitments, support and incident-response time, and the reputational hit of a public outage. The finance question is not 'can we avoid the second-region spend?' It is 'is the predictable monthly cost of a second region smaller than the expected cost of the outage it prevents?' For anything revenue-bearing, it almost always is.

Frame the decision per account, not as a blanket policy. The second region is clearly worth it for the accounts behind production, customer-facing workloads, and clearly not worth it for dev, test and scratch accounts. Map each Advisor finding to the workload behind it and spend the resilience budget where an outage actually costs money.

This lesson is for the finance partner who sees an Azure Advisor reliability finding on a Cosmos DB account and needs to weigh a real, recurring second-region cost against the cost of the outage it prevents. It covers what the second region actually costs, why the decision should be made per workload, and how to tell the accounts worth protecting from the ones that are not.

Fun fact

Resilient inside a region, helpless without a second one

How a finance partner frames the second-region decision

Priya is the finance partner supporting the payments platform after that near miss. The Advisor report flags four single-region Cosmos DB accounts, and the platform team has asked to add a second region to all of them. The instinct is not to approve four second regions on sight, because unlike most reliability fixes this one carries a real, recurring cost: a second region roughly doubles the storage and provisioned throughput the account pays for. So the first question is which of the four are actually production.

Two of the four turn out to be the live payments and ledger paths, where a region outage means the company cannot take payments, an exposure measured in lost revenue per minute plus breached customer commitments. The other two are a dev account and an analytics sandbox where an outage is an inconvenience, not a business event. The finance pack writes itself: 'Approve the second region on payments-prod and ledger-prod, where the recurring premium is far smaller than the expected cost of a payments outage. Decline it on the dev and sandbox accounts, where there is nothing to insure. The recurring cost is real and budgeted, and it is spent only where downtime actually costs money.'

Why single-region Cosmos DB is a downtime line on the risk register

This is a rare reliability item where both sides of the ledger carry real money, so it deserves a genuine trade-off rather than a reflex yes or no. On the cost side, a second region is a recurring charge: a second copy of the data and the throughput to serve it, which Azure Advisor explicitly warns will increase cost. On the risk side, a single-region account behind a revenue-bearing service has an unbounded outage exposure, because a region incident takes the service down for its full duration with no failover available.

The way to make the call is to put an expected downtime cost against each flagged account. An account behind live payments has a high cost per minute of outage and a non-trivial annual probability of a regional incident, so the recurring second-region premium is small insurance against a large, bounded-only-by-luck loss. An account behind a sandbox has effectively no downtime cost, so the same premium buys nothing. The finance role is to fund the second region where the expected outage cost exceeds it, and to decline it where it does not, rather than approving or refusing it estate-wide.

What finance can do about the single-region gap

Finance cannot add a region, but it owns the trade-off that turns an Advisor list into funded resilience where it pays and a deliberate no everywhere else. Three levers.

1. Treat the second region as a budgeted, recurring line

Be explicit that this fix, unlike most reliability work, costs real and recurring money: a second region roughly carries the storage and throughput of the first again. Budget it as a named line per account rather than waving it through, so the resilience spend is visible and can be defended as insurance against a specific outage cost.

2. Fund it by expected downtime cost, not by finding count

Attach an expected cost-of-outage to each flagged account: revenue per minute lost, commitments breached, incident time. Fund the second region where that expected cost clearly exceeds the recurring premium, and decline it where it does not. The metric for the review is resilience spend mapped to the workloads it protects, not the raw count of Advisor findings closed.

3. Require a documented reason for any production account left single-region

If a genuinely production account is to stay single-region to save cost, that should be a recorded, finance-visible decision with the accepted outage exposure stated, not a silent omission. The difference between 'we accepted this risk deliberately' and 'we never funded it' is exactly what makes the posture defensible after an incident.

Quick quiz

Question 1 of 5

How does the cost profile of adding a second Cosmos DB region differ from most reliability fixes?

Keep learning

Go deeper on how Cosmos DB distributes data globally, what failover does, and how the availability SLA changes with topology.

You have finished the finance view of Cosmos DB resilience. Unlike most reliability fixes, this one costs real, recurring money, so the discipline is to fund the second region where the expected cost of an outage exceeds the premium, decline it where it does not, and record any production account deliberately left single-region as a named accepted risk. Next time an Advisor reliability finding lands, you will price the outage it prevents and fund accordingly, rather than approving or refusing it across the board.

Back to the library

Spanning Cosmos DB across regions: the headline

Whether a single Azure region outage can take a production service fully offline

This is a continuity question, not a security one. A single-region database is a single point of failure for everything that depends on it. If that one region has a bad day, the service it backs is down, and the only recovery is waiting for Azure to fix the region. Azure Advisor flags every production Cosmos DB account in that state.

The leadership question is simple: if an Azure region we rely on goes offline tomorrow, does our service stay up? With a single-region account the answer is no. With a second region and service-managed failover, the answer becomes 'reads keep serving from the healthy region, and writes recover automatically,' turning a total outage into a degraded but surviving service.

This one does cost money, because a second region is a second running copy of the data. That makes it a deliberate trade rather than a free win: pay a predictable monthly premium on the accounts that matter, and in exchange remove the unbounded cost of a region-out outage on your most important workloads.

A short read for the leader who needs to understand why a single-region database is a single point of failure, what a region outage would do to the service, and why spending a predictable monthly premium on a second region is the right trade for the workloads that carry revenue or commitments.

Fun fact

Resilient inside a region, helpless without a second one

What it looks like when a region outage stops being an existential event

After a competitor was knocked offline for most of a day by a single cloud-region incident, the board asked the obvious question: if that happened to us, what would it do? The honest answer at the time was that the core payments database lived in one Azure region, so a regional outage there would take payments fully offline for the duration, with no failover to pull.

The team's response was to add a second region to the payments and ledger accounts and enable service-managed failover, so Azure promotes the secondary automatically if the write region goes down. They were precise about what this buys: during a region outage, reads keep serving from the healthy region immediately, and write recovery is automatic, though service-managed failover can take a while to trigger, so for the most critical path they also rehearsed a forced failover to cut recovery time. The next time the board asked the question, the answer changed from 'we would be down until Azure recovered' to 'the service degrades but stays up, and we have a tested lever to restore writes quickly.' That shift, from a single point of failure to a surviving service, is what the second-region spend buys, and it is a deliberate, budgeted trade rather than a free one.

Why this is a board-level continuity decision

A single-region database under a production service is a single point of failure for the whole service. The risk is concentrated and external: one Azure region having a bad day becomes your outage, of the same length, and there is nothing the team can do to shorten it. That is exactly the kind of concentrated dependency boards are meant to scrutinise.

Unlike many reliability controls, the fix here is not free, so this is a deliberate trade rather than an obvious one. The decision is to pay a predictable monthly premium for a second region on the workloads that carry revenue or customer commitments, in exchange for removing an unbounded outage exposure on exactly those workloads. Spent selectively, it is cheap insurance against the kind of outage that makes the news; spent indiscriminately, it is waste. Leadership's job is to make sure it is spent on the former.

The leadership move on Cosmos DB resilience

The executive handle is not to approve each region individually; it is to set the rule that revenue-bearing workloads are multi-region with failover enabled, and that any production exception is a named, owned, accepted risk.

1. Set the rule: production-critical means multi-region

Ask that every Cosmos DB account behind a customer-facing or revenue-bearing service spans at least two regions with service-managed failover enabled, on a date. This turns Advisor's recommendation into a standard, so new production accounts are multi-region by default rather than by someone remembering.

2. Ask for proof, including a failover drill

The proof is not 'we added a region.' It is the account spanning two regions with service-managed failover on, plus a rehearsed forced failover showing the service recovers, because service-managed failover can be slow to trigger. Ask for the drill result, not just the configuration.

3. Make single-region production a named, accepted risk

Some production accounts may stay single-region because the second-region cost is not justified. That is a legitimate choice, but it must be an explicit, owned decision with the outage exposure stated, not an accident. The goal is not zero single-region accounts; it is zero single-region accounts that nobody chose.

Quick quiz

Question 1 of 5

At a board review you ask what a single Azure region outage would do to the core service. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Cosmos DB distributes data globally, what failover does, and how the availability SLA changes with topology.

Two takeaways. A single-region database under a production service is a single point of failure, and the only honest answer to 'what happens in a region outage?' is 'we are down until Azure recovers,' unless you add a second region. And because that second region costs money, the leadership move is to require multi-region with failover on the workloads that carry revenue or commitments, prove it with a failover drill, and make any single-region production account a named, accepted risk rather than an accident.

Back to the library

Part of the learning path Build in Azure resilience

Span Cosmos DB across at least two regions

Spanning Cosmos DB across regions: the basics

Resilient inside a region, helpless without a second one

Finding single-region Cosmos DB accounts before an outage finds them

How a second region and service-managed failover actually behavedeep dive

What is the impact of leaving Cosmos DB single-region?

How do you add a second region safely?

1. Confirm the account is genuinely production

2. Add the second region as its own operation

3. Enable service-managed failover

4. Decide your consistency level and rehearse failover

Quick quiz

Keep learning

Spanning Cosmos DB across regions: the downtime-cost view

Resilient inside a region, helpless without a second one

How a finance partner frames the second-region decision

Why single-region Cosmos DB is a downtime line on the risk register

What finance can do about the single-region gap

1. Treat the second region as a budgeted, recurring line

2. Fund it by expected downtime cost, not by finding count

3. Require a documented reason for any production account left single-region

Quick quiz

Keep learning

Spanning Cosmos DB across regions: the headline

Resilient inside a region, helpless without a second one

What it looks like when a region outage stops being an existential event

Why this is a board-level continuity decision

The leadership move on Cosmos DB resilience

1. Set the rule: production-critical means multi-region

2. Ask for proof, including a failover drill

3. Make single-region production a named, accepted risk

Quick quiz

Keep learning

Related site reliability lessons