Site Reliability

Make Azure SQL databases zone-redundant

One reliability capability across every provisioned database and elastic pool: make sure the data layer and its backups are replicated across availability zones in the primary region, so a single datacentre failure does not take the database, and the application behind it, offline.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Zone-redundant Azure SQL: the basics

What does a single-zone database actually expose you to?

An Azure SQL database, by default, lives in one availability zone of its primary region. The compute replica that serves queries sits in that zone, and on the General Purpose tier the database files are held in storage that is local to it. Most Azure regions are built from three physically separate availability zones, each with its own power, cooling and networking, so a single zone can fail without the others. A database pinned to one zone inherits that zone's fate: if the datacentre behind it loses power or network, the database is unreachable until the platform recovers it elsewhere, and the application that depends on it is down for the duration.

Zone redundancy changes that. When you enable it, Azure SQL replicates the database across the availability zones in the primary region: the compute layer keeps standby replicas in other zones, and on General Purpose the data and backup storage move to zone-redundant storage so the files survive the loss of any one zone. The result is a higher availability SLA, from a baseline of 99.99 per cent to 99.995 per cent when zone redundancy is enabled in a region that supports availability zones, and a failover that the platform handles automatically with no change to your application's connection string or logic.

Most single-zone databases are not a deliberate choice; they are the default that nobody revisited. A database created before zone redundancy was an option, a module that never set the flag, a tier chosen for cost that happens to start non-redundant. Azure Advisor surfaces the gap as a reliability recommendation, but the underlying job is the same: find every production database whose availability is tied to a single zone, decide which genuinely need to survive a zone outage, and replicate them across zones before the outage arrives rather than after.

In this lesson you will learn how Azure SQL expresses zone redundancy, how to find every production database that is still tied to a single availability zone, and how to make them zone-redundant without an outage of their own. The lesson covers the General Purpose, Business Critical and Hyperscale tiers, the difference in how each enables zone redundancy, and the backup-storage side of the same capability.

Fun fact

The zone that took the region's headlines

Cloud outages that make the news are very rarely a whole region going dark. Far more often it is a single availability zone, one set of buildings, that loses power, cooling or a network link while the rest of the region carries on serving traffic. That is exactly the failure availability zones were designed to contain, and exactly the failure a single-zone database has no defence against. The quiet lesson from every one of these incidents is the same: the workloads that stayed up were the ones already replicated across zones before the event, because zone redundancy is a decision you can only make in advance, never during the outage.

Finding single-zone databases across a subscription

Priya is the reliability lead at a SaaS company whose checkout and customer portal both sit on Azure SQL. Azure Advisor has raised a reliability recommendation to enable zone redundancy, and she wants to know which databases are exposed before deciding what to change.

Rather than work the Advisor list blind, she starts by listing every database with its tier and its current zone-redundant state, so the revenue-bearing production databases can be separated from test and staging before anything is touched.

List every database on a server with its tier and whether it is currently zone-redundant. The False rows on production tiers are the exposure.

$ az sql db list --resource-group rg-prod --server sql-prod-uksouth --query "[].{name:name, tier:currentServiceObjectiveName, zoneRedundant:zoneRedundant}" -o table

Name Tier ZoneRedundant

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

checkout-prod GP_Gen5_4 False

portal-prod BC_Gen5_8 False

reporting-test GP_Gen5_2 False

# checkout-prod and portal-prod are revenue-bearing and single-zone. Fix these first.

A production database on a tier that supports zone redundancy but shows ZoneRedundant False is the highest-value target. Protect the revenue-bearing ones first; the test database can wait or stay single-zone on purpose.

How Azure SQL makes a database zone-redundantdeep dive

Zone redundancy resolves to a single property on the database, 'zoneRedundant', but what it sets up differs by tier. On General Purpose, the database is a single compute replica over remote storage, so zone redundancy replicates the data and backup storage across availability zones using zone-redundant storage and keeps spare compute capacity in other zones to recover into; the partner property, the backup storage redundancy, can be set to 'Zone' so the backups survive a zone loss too. On Business Critical, the tier already runs a cluster of replicas, so zone redundancy simply spreads those replicas across different availability zones instead of placing them together. On Hyperscale, zone redundancy spreads the compute and page-server replicas across zones, and for some Hyperscale configurations it can only be set when the database is created.

For General Purpose, Business Critical and Premium databases, enabling zone redundancy on an existing database is an online operation: the platform builds the redundant configuration in the background and completes with a brief disconnect, the same kind of momentary failover the database already handles during planned maintenance, so a connection that retries transient faults rides through it. The SLA reflects the change: the baseline 99.99 per cent availability rises to 99.995 per cent once the database is zone-redundant in a region that supports availability zones, with a recovery point objective of zero because the redundant replicas are kept in sync.

Not every tier supports it. Zone redundancy is available on the General Purpose, Business Critical and Hyperscale tiers of the vCore model and on the Premium tier of the DTU model. The Basic and Standard DTU tiers do not support it at all, so a database that needs zone redundancy on one of those tiers has to move to a supported tier first. This is why the capability is a database-by-database decision rather than a single switch: the tier, the cost and the criticality all feed into which databases are worth protecting.

What is the impact of leaving a production database single-zone?

The direct impact is downtime you cannot control or shorten. A single-zone database that loses its datacentre to a power, cooling or network failure is unreachable until the platform recovers it, and the application stacked on top of it is down for the whole of that window. Availability-zone failures are the most common shape of cloud outage, more common by far than a whole region failing, and they are precisely the failure a single-zone database has no answer to. A zone-redundant database, by contrast, fails over to a replica in another zone automatically and stays up.

The second-order impact is blast radius and recovery effort. When a single-zone database goes down, the incident is not just the minutes it is unreachable; it is the on-call response, the manual checks that the application reconnected cleanly, the reconciliation of anything that was in flight when it dropped, and the post-incident review. Zone redundancy turns that from a recovery operation into a non-event the platform absorbs, so the engineering cost of a zone failure shrinks to nothing for the databases that have it.

On the commitment side, an availability SLA you have promised to customers, or that an internal service depends on, is only as strong as the weakest single point of failure beneath it. A 99.99 per cent application built on a single-zone database cannot actually deliver 99.99 per cent if one datacentre failure can take that database down for hours. Making the database zone-redundant raises both the real availability and the SLA the platform stands behind it, from 99.99 to 99.995 per cent, which is the difference between a commitment you hope to meet and one the architecture supports.

How do you make a database zone-redundant safely?

Work the capability as one loop rather than reacting to the Advisor recommendation in isolation. The order matters: decide which databases justify the cost before you enable anything, and confirm the tier supports it, so you do not pay for redundancy where it is not needed or attempt it where it is not available.

1. Inventory every database by tier and zone state

List every database with its service tier and its current 'zoneRedundant' value. Treat this inventory as the source of truth rather than the Advisor count, because Advisor surfaces the gap but not the business value behind each database. Note which databases sit on Basic or Standard DTU tiers, since those cannot be made zone-redundant without first moving to a supported tier.

2. Rank by the cost of downtime, not by database count

For each production database, ask what an hour of it being unreachable actually costs: revenue, breached commitments, incident response. The databases behind revenue and behind customer-facing availability promises are the ones to protect; test, staging and internal reporting databases with no downtime cost can stay single-zone on purpose. The uplift is real, so target it where the outage is expensive.

3. Enable zone redundancy, highest-value first

For General Purpose, Business Critical and Premium databases this is an online operation with a brief disconnect, so run it during a low-traffic window and make sure clients retry transient faults. On General Purpose, set the backup storage redundancy to Zone in the same change so the backups survive a zone loss too. For Hyperscale, check whether your configuration allows enabling it on an existing database or whether it must be set at creation, and plan accordingly.

4. Make zone redundancy the default for new databases

Bake 'zoneRedundant: true' into the Bicep or Terraform module that provisions production databases, so new ones are zone-redundant from the start rather than inheriting the single-zone default and waiting for Advisor to flag them. Pair it with an Azure Policy audit so any production database created without zone redundancy is visible, turning a recurring cleanup into a standing guardrail.

# Make a revenue-bearing General Purpose database zone-redundant,
# and move its backups to zone-redundant storage in the same change.
# Online operation with a brief disconnect: run in a low-traffic window.
az sql db update \
  --resource-group rg-prod \
  --server sql-prod-uksouth \
  --name checkout-prod \
  --zone-redundant true \
  --backup-storage-redundancy Zone

# Confirm the change took effect.
az sql db show \
  --resource-group rg-prod \
  --server sql-prod-uksouth \
  --name checkout-prod \
  --query "{name:name, zoneRedundant:zoneRedundant, backup:currentBackupStorageRedundancy}" -o table

# Make it the default for new databases in Bicep:
#
# resource db 'Microsoft.Sql/servers/databases@2023-08-01-preview' = {
#   parent: sqlServer
#   name: 'checkout-prod'
#   location: location
#   sku: { name: 'GP_Gen5', tier: 'GeneralPurpose', capacity: 4 }
#   properties: {
#     zoneRedundant: true
#     requestedBackupStorageRedundancy: 'Zone'
#   }
# }

Quick quiz

Question 1 of 5

Azure Advisor raises a reliability recommendation to enable zone redundancy on your SQL estate. What is the most effective way to respond?

Keep learning

Go deeper on how Azure SQL expresses zone redundancy across tiers and on the backup-storage side of the same capability.

You can now treat Azure SQL zone redundancy as one reliability capability rather than a single Advisor recommendation: inventory every database by tier and zone state, rank by the cost of downtime, make the revenue-bearing ones zone-redundant with their backups, and bake the same configuration into the provisioning module so new databases inherit it. A single datacentre failure stops being an outage for the systems that matter and becomes a non-event the platform absorbs.

Back to the library

Zone-redundant Azure SQL: the cost-of-downtime view

A small, bounded uplift weighed against the unbounded cost of an outage you cannot control

Zone redundancy is one of the few reliability controls with a real, named cost attached, so finance has a genuine trade to weigh rather than a free fix to wave through. Enabling it on the General Purpose tier moves the database onto zone-redundant compute and storage, which carries a modest uplift over the single-zone price, and on the Business Critical tier it is included in the tier cost. The figure is bounded and predictable: it is a percentage on the database line, not an open-ended commitment, and it applies only to the databases you choose to protect.

The other side of the ledger is the cost of the outage you are buying insurance against. A single-zone database that goes dark in a datacentre failure takes its application with it, and the cost of that downtime is rarely the Azure bill. It is lost revenue per minute for anything customer-facing, the staff time spent firefighting and recovering, the missed transactions, and for many businesses a contractual or regulatory exposure when an availability commitment is breached. Frame each non-redundant production database as a line on the risk register: what does an hour of this database being unreachable actually cost, and how does that compare with the monthly uplift to make it survive a zone failure?

The arithmetic favours resilience wherever the database sits behind anything that earns money or that you have promised to keep available. The uplift is small, monthly and forecastable. The outage is large, unpredictable and outside your control once it starts. The finance role is to attach an expected downtime cost to each database so the spend goes where the revenue and the commitments are, not uniformly across every test and staging database that does not need it.

This lesson is for the finance partner who sees a reliability recommendation on Azure SQL and wants to know what it costs, what it buys, and which databases actually justify the spend. It covers why zone redundancy is one of the few resilience controls with a real price tag, how to weigh that uplift against the cost of an outage, and how to target the spend at the databases where downtime is expensive rather than across the whole estate.

Fun fact

The zone that took the region's headlines

How a finance partner frames the zone-redundancy decision

Priya is the finance partner supporting the platform team's reliability review. Azure Advisor's recommendation lands alongside a request to enable zone redundancy across the SQL estate, and the instinct is not to approve a blanket uplift on every database; it is to ask which databases actually carry a downtime cost worth insuring. Zone redundancy is one of the few reliability controls that does move the bill, so the spend question is real: on General Purpose it adds a bounded percentage to each database it is enabled on, and on Business Critical it is part of the tier cost already being paid.

Priya asks the team to map each database to the cost of it being unreachable. The checkout and portal databases sit directly behind revenue and behind an availability commitment in customer contracts, so an hour of either being down has a number attached that dwarfs the monthly uplift. The reporting and test databases have no such cost: a zone outage there means a delayed report, not lost revenue. The list is reframed as a risk-ordered plan: 'Make the two revenue-bearing databases zone-redundant now, where the uplift is a rounding error against an hour of checkout downtime; leave test and staging single-zone as a documented, deliberate choice; the total monthly cost is two database lines, not the whole estate.' The spend goes where the downtime is expensive, not uniformly.

Why a single-zone production database belongs on the risk register

The cost model here is a genuine trade, not a free fix, which is what makes it a finance decision rather than an engineering one. Zone redundancy adds a bounded, monthly uplift on the General Purpose tier, and is included in the Business Critical tier cost. Against that sits the cost of the outage it prevents, which for a revenue-bearing database is rarely the Azure bill. It is lost revenue per minute of downtime, the staff cost of the incident response, the transactions that did not complete, and any penalty or credit owed when an availability commitment is breached.

The asymmetry is the point. The uplift is small, predictable and chosen in advance; the outage is large, unpredictable and outside your control once a datacentre fails. For a database behind checkout or a customer portal, an hour of downtime can cost more than years of the redundancy uplift, so the trade is one-sided in favour of resilience. For a test or reporting database with no revenue behind it, the same uplift buys protection nobody needs, so the trade goes the other way. The finance role is to attach an expected downtime cost to each database and let that, not a blanket policy, decide where the spend goes.

What finance can do about the zone-redundancy gap

Finance cannot enable zone redundancy on a database, but it owns the framing that turns a blanket reliability recommendation into a targeted, justified spend. Three levers.

1. Treat it as a real, bounded cost, not a free fix

Make explicit that zone redundancy is one of the few reliability controls with a genuine price: a bounded monthly uplift on General Purpose, and part of the tier cost on Business Critical. That is a feature, not a problem, because it means the spend can be targeted. Budget the uplift as a discrete line per protected database rather than approving or refusing it across the whole estate, so the decision is made database by database on its merits.

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

A checkout database and a reporting database both show up as the same single reliability recommendation, but the cost of an hour of downtime on each differs by orders of magnitude. Ask the team to attach an expected downtime cost to each production database: lost revenue per minute, breached availability commitments, incident response. Protect the databases where that number dwarfs the uplift and leave the rest single-zone deliberately. The metric for the review is the downtime cost protected per pound of uplift, not the number of recommendations closed.

3. Require documented exceptions for databases left single-zone

Any production database deliberately left single-zone, because its downtime cost genuinely does not justify the uplift, should carry a recorded, finance-visible reason. The distinction between 'we reviewed this and judged the redundancy uplift not worth it' and 'we never noticed it was single-zone' is exactly what makes the posture defensible when a zone failure does land on a database nobody chose to protect.

Quick quiz

Question 1 of 5

Advisor recommends zone redundancy across the SQL estate. As the finance partner, what is the right starting assumption about its Azure-spend cost?

Keep learning

Go deeper on how Azure SQL expresses zone redundancy across tiers and on the backup-storage side of the same capability.

You have finished the finance view of zone redundancy. You know this is one of the few reliability controls with a real, bounded cost, that the trade is one-sided wherever downtime is expensive and the wrong call wherever it is not, and that the job is to attach an expected downtime cost to each database so the spend lands on the systems behind revenue and commitments. Next time an Advisor reliability recommendation arrives, you will order the databases by the cost of an hour of downtime, ring-fence the deliberate single-zone exceptions, and ask for the spend where it protects something worth protecting.

Back to the library

Zone-redundant Azure SQL: the headline

Whether a single datacentre failure can take a revenue-bearing system offline

Availability zones exist because datacentres fail, in ones, while the region around them keeps running. A database that lives in a single zone is one power or network event away from taking its application down, and the report shows this as a quiet reliability recommendation rather than an incident, until the day it becomes one.

The leadership question is not 'is the database running today?' It is 'if one datacentre in our region fails tomorrow, which of our systems go dark, and for how long?' The defensible end state is that the databases behind revenue and behind any availability commitment are replicated across zones and fail over automatically, and that the few left single-zone are a deliberate, documented choice rather than an oversight.

This one does cost something, unlike many reliability controls, but the cost is small, bounded and monthly, while the downside it removes is an outage you neither chose nor can shorten once it starts. It is a governance decision about which systems are allowed to depend on a single datacentre, made on purpose rather than by default.

A short read for the leader who needs to know what a single-zone database exposes the business to, why making the revenue-bearing ones zone-redundant is a small and bounded cost against an unbounded outage risk, and what a defensible end state looks like across the estate.

Fun fact

The zone that took the region's headlines

What it looks like when an outage is survived by design, not by luck

After a competitor lost its checkout for several hours when a single datacentre in their region failed, the CEO asked the obvious question at the next review: if one of our datacentres goes down, does our checkout go with it? The honest answer at the time was that it might, because the database behind checkout lived in a single availability zone and had since the day it was created. Nobody had chosen that exposure; it was simply the default that no review had revisited.

The team's response was to stop treating zone redundancy as a per-database setting and start treating it as a reliability decision about which systems are allowed to depend on a single datacentre. They listed every production database, identified the ones behind revenue and behind the availability commitments in customer contracts, made those zone-redundant so the platform fails them over automatically when a zone is lost, and recorded the handful left single-zone as a deliberate, accepted choice. The next time the CEO asked the question, the answer had changed from 'possibly, we would have to recover it' to 'no, checkout survives a zone failure automatically, and the systems that do not are ones we chose not to protect.' That shift, from inheriting a single point of failure by default to choosing where redundancy is bought on purpose, is the confidence signal this capability delivers.

Why this is a board-level reliability decision

Nearly every cloud outage that reached a customer came back to a single point of failure that survived right up until the day it failed. A production database tied to one availability zone is exactly that kind of single point of failure, sitting quietly beneath a revenue system until one datacentre event takes it down. Making the revenue-bearing databases zone-redundant removes that single point of failure for the systems that can least afford to lose it, and the platform handles the failover with no human in the loop.

Unlike many reliability controls, this one carries a real cost, but it is small, bounded and monthly, set against a downtime cost that is large, unpredictable and uncontrollable once it begins. This is the class of decision leadership should make on purpose: which systems are important enough to be worth a small, certain cost so that a single datacentre failure cannot take them offline. The wrong answer is to discover the database was single-zone during the outage rather than to have chosen its protection before it.

The leadership move on zone redundancy

The executive handle is not to approve each database individually; it is to require that every system behind revenue or behind an availability commitment is zone-redundant, and that the databases left single-zone are a deliberate, owned choice on the record.

1. Decide which systems may depend on a single datacentre

Ask for the list of production databases split into two groups: those behind revenue or behind a customer availability commitment, and those without. The first group should be zone-redundant so a single zone failure cannot take them down. The second can stay single-zone, but only as a named decision. The goal is not zero single-zone databases; it is zero single-zone databases that you did not choose to leave that way.

2. Weigh the certain small cost against the uncertain large one

This control costs money, and that is the point of the leadership decision. Frame it as a small, bounded, monthly cost set against an outage that is large, unpredictable and uncontrollable once a datacentre fails. For anything revenue-bearing, an hour of downtime typically dwarfs years of the uplift, so the trade is one-sided. Approve the spend where the downtime is expensive and decline it where it is not, on purpose.

3. Ask for proof the critical systems survive a zone loss

The proof is not a verbal 'it should fail over.' It is a list showing every revenue-bearing database with zoneRedundant set to true, a record of the deliberate single-zone exceptions, and zone redundancy baked into the provisioning module so new production databases inherit it. Make zone redundancy by default a property of how databases are created, not a cleanup that recurs every time Advisor raises the recommendation again.

Quick quiz

Question 1 of 5

At a board review you ask whether a single datacentre failure could take your checkout offline like a competitor's. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure SQL expresses zone redundancy across tiers and on the backup-storage side of the same capability.

Two takeaways. Zone redundancy is the reliability control that decides whether a single datacentre failure can take a revenue system offline, and unlike most such controls it carries a real but bounded cost, set against an outage that is large and uncontrollable once it starts, so for anything revenue-bearing the trade is one-sided. And the defensible end state is not 'the databases were running last time we checked'; it is that every system behind revenue or an availability commitment is zone-redundant by design, with the few deliberate single-zone databases documented and owned.

Back to the library

Part of the learning path Build in Azure resilience

Make Azure SQL databases zone-redundant

Zone-redundant Azure SQL: the basics

The zone that took the region's headlines

Finding single-zone databases across a subscription

How Azure SQL makes a database zone-redundantdeep dive

What is the impact of leaving a production database single-zone?

How do you make a database zone-redundant safely?

1. Inventory every database by tier and zone state

2. Rank by the cost of downtime, not by database count

3. Enable zone redundancy, highest-value first

4. Make zone redundancy the default for new databases

Quick quiz

Keep learning

Zone-redundant Azure SQL: the cost-of-downtime view

The zone that took the region's headlines

How a finance partner frames the zone-redundancy decision

Why a single-zone production database belongs on the risk register

What finance can do about the zone-redundancy gap

1. Treat it as a real, bounded cost, not a free fix

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

3. Require documented exceptions for databases left single-zone

Quick quiz

Keep learning

Zone-redundant Azure SQL: the headline

The zone that took the region's headlines

What it looks like when an outage is survived by design, not by luck

Why this is a board-level reliability decision

The leadership move on zone redundancy

1. Decide which systems may depend on a single datacentre

2. Weigh the certain small cost against the uncertain large one

3. Ask for proof the critical systems survive a zone loss

Quick quiz

Keep learning

Related site reliability lessons