Site Reliability

Deploy App Service plans as zone-redundant

One capability across every web app, API and function on the plan: make sure the plan spreads its instances across availability zones, so the loss of a single datacentre does not take the workload offline.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Zone-redundant App Service: the basics

What does a single-zone App Service plan actually look like?

An App Service plan is the compute that every web app, API and function app on it runs on, and by default a plan can sit entirely inside one availability zone. An availability zone is a physically separate group of datacentres within an Azure region, each with its own power, cooling and network. When a plan is not zone-redundant, all of its instances can land in the same zone, so a power or network fault in that one zone takes every app on the plan down at once, even though the region as a whole is healthy.

Azure Advisor surfaces this as a reliability recommendation, 'Use zone-supported App Service Plan', because the fix is a property on the plan rather than a code change. Setting 'zoneRedundant' to true tells Azure to distribute the plan's instances across the availability zones the region offers, so the failure of any single zone leaves the workload running on the others. With two or more instances spread this way, the plan carries a 99.99% uptime SLA; without it, a single zone is a single point of failure.

Most single-zone plans are not a deliberate choice. They are a plan created before zone redundancy was easy to toggle, a module that never set the flag, or a plan left at one instance because it was cheaper and nobody revisited it once the app went to production. The work is to find every plan that runs production traffic on a single zone, decide which genuinely need resilience, and turn redundancy on, which is now a near-instant, in-place change with no redeploy.

In this lesson you will learn how an App Service plan expresses zone redundancy, how to find every plan running production traffic on a single zone, and how to turn redundancy on without a redeploy or downtime. You will see the exact Advisor recommendation behind the finding, the az CLI to inventory and fix it, and the Bicep that bakes resilience into every future plan so the gap does not come back.

Fun fact

The healthy region that still went dark

Cloud outages are rarely a whole region failing at once. Far more often a single availability zone has a bad day: a cooling failure, a power event, a network fault in one set of datacentres while the rest of the region runs normally. The teams that stayed up through those events were the ones whose compute was already spread across zones, so traffic simply shifted to the healthy ones. The teams that went down were running everything in the zone that happened to fail. Azure now lets you flip an App Service plan to zone-redundant in place, almost instantly and with no redeploy, so the cost of being on the wrong side of that line has never been lower.

Finding single-zone plans across a subscription

Priya is the platform lead at a scale-up whose checkout traffic runs on App Service. Azure Advisor has started flagging 'Use zone-supported App Service Plan' across several plans in the production subscription, and she wants to know which of them actually carry customer traffic before changing anything.

Rather than work the recommendations one by one, Priya starts by listing which plans are not zone-redundant and how many instances each runs, so the customer-facing plans can be separated from internal tooling before any change goes in.

Start by listing the plans that are not zone-redundant, with their SKU and instance count. These are the single points of failure.

$ az appservice plan list --query "[?!properties.zoneRedundant].{name:name, sku:sku.name, instances:sku.capacity}" -o table

Name Sku Instances

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

checkout-prod P1v3 1

internal-admin B1 1

# checkout-prod carries customer traffic on ONE instance in ONE zone. Fix it first.

A Premium plan carrying customer traffic on a single instance is the highest-value target. The Basic internal tool is a separate, lower-priority decision.

How a plan becomes zone-redundantdeep dive

Zone redundancy resolves to two things on the plan. The first is the 'zoneRedundant' property: when it is true, Azure distributes the plan's instances across the availability zones the region offers rather than placing them all in one zone. The second is the instance count, 'sku.capacity' or the number of workers: zone redundancy requires a minimum of two instances, because spreading a single instance across zones is meaningless. With two or more instances spread across zones, the plan carries a 99.99% SLA. Each scale unit exposes a 'maximumNumberOfZones' of 1, 2 or 3, and Azure spreads your instances as evenly as it can across the zones available, so even a two-instance plan lands in two distinct zones.

Zone redundancy is supported on the Premium v2 and Premium v3 tiers for multi-tenant App Service, and on Isolated v2 for App Service Environments. Basic and Standard plans cannot be made zone-redundant, so a plan flagged by Advisor on one of those tiers has to move up a tier first. The setting is now mutable for the life of the plan: you can toggle 'zoneRedundant' on or off in place, and the change takes effect almost instantly with no downtime and no redeploy, which is a recent improvement over the old behaviour where redundancy could only be set at creation time.

The strongest position combines the per-plan setting with a Bicep or policy standard: every production plan template sets 'zoneRedundant' to true with a capacity of at least two. That turns 'we remembered to make the important plans redundant' into 'no production plan ships single-zone in the first place', which is the difference between checking the estate is resilient today and guaranteeing the next plan is resilient by default.

What is the impact of leaving a plan single-zone?

The direct impact is downtime you did not have to take. When all of a plan's instances sit in one availability zone, a power, cooling or network fault in that single zone takes every app on the plan offline, even though the rest of the region is healthy and serving other customers normally. The overwhelming majority of cloud incidents that hit a single workload are exactly this shape: not a whole region down, but one zone having a bad day while a single-zone plan happened to be living in it.

The second-order impact is the blast radius of a plan. Every web app, API and function app on a single-zone plan shares its fate, so one unprotected plan can be the single point of failure behind a whole product surface. Spreading the plan across zones turns a hard outage into a transparent failover: instances in the healthy zones keep serving while the affected zone recovers, and the 99.99% SLA reflects that the platform expects to ride through a single-zone loss.

On the reliability side, resilience targets, customer SLAs and internal error budgets all assume that a single datacentre fault is survivable. A production plan that is not zone-redundant quietly breaks that assumption, and it is the kind of gap that stays invisible until the day the wrong zone fails. A passing set of zone-redundancy recommendations across the plans that matter is the cheapest evidence you can offer that your most important services are not one datacentre away from an outage.

How do you make a plan zone-redundant safely?

Work the capability as one loop rather than chasing individual recommendations. The order matters: find the plans that actually carry customer or revenue traffic before you spend on instances, so you protect what matters and do not over-provision what does not.

1. Inventory every plan by redundancy and instance count

List the plans where 'zoneRedundant' is false, with their SKU and instance count. Treat this inventory as the source of truth, not the Advisor count, because the right response differs sharply between a single-instance revenue plan and a one-instance dev plan that does not matter.

2. Separate the plans that matter from the ones that do not

For each plan, decide what an hour of its downtime actually costs. Plans carrying customer or revenue traffic earn resilience; internal tools and dev plans where a brief outage is harmless can be left single-zone as a documented decision. Resilience is a choice you make per plan, not a blanket mandate.

3. Turn redundancy on, highest cost-of-downtime first

For each plan you are protecting, confirm it is on a supported tier (Premium v2, Premium v3, or Isolated v2 for an App Service Environment), ensure it runs at least two instances, and set 'zoneRedundant' to true. The change is in place, near-instant and needs no redeploy, so there is no outage window to plan around. Protect the highest cost-of-downtime plans first.

4. Make it the default with Bicep or policy

Bake 'zoneRedundant' true with a capacity of at least two into the Bicep or template that every production plan is created from, and audit for it with Azure Policy. That way new plans ship resilient by default, so the gap is prevented at creation rather than caught later on the Advisor report.

# Make an existing production plan zone-redundant in place (no redeploy, no downtime).
# Premium v2/v3 (multi-tenant) or Isolated v2 (ASE) only; minimum two instances.
az appservice plan update \
  --name checkout-prod \
  --resource-group rg-prod \
  --set zoneRedundant=true sku.capacity=2

# Bake resilience into every future plan so the gap does not come back (deploy.bicep):
# resource plan 'Microsoft.Web/serverfarms@2024-11-01' = {
#   name: planName
#   location: location
#   sku: {
#     name: 'P1v3'
#     capacity: 2          // minimum two instances for zone redundancy
#   }
#   properties: {
#     zoneRedundant: true  // spread instances across availability zones
#   }
# }

Quick quiz

Question 1 of 5

Azure Advisor flags 'Use zone-supported App Service Plan' on several plans. What does the recommendation actually mean?

Keep learning

Go deeper on how App Service plans express zone redundancy and what the setting does across the tiers in this capability.

You can now treat App Service zone redundancy as one capability rather than a scatter of recommendations: inventory which plans run on a single zone, separate the ones whose downtime is expensive, turn redundancy on in place highest cost-of-downtime first, and make it the Bicep default so new plans ship resilient. A single-zone plan is a single point of failure; a zone-redundant one absorbs the loss of a datacentre and stays up.

Back to the library

Zone-redundant App Service: the downtime and cost view

A small, bounded compute cost that removes a whole class of single-zone outage risk

A single-zone App Service plan is a bet that the one zone your app happens to run in never fails. The cost of resilience here is specific and small: zone redundancy needs at least two instances, and Azure does not charge a premium for the availability-zone feature itself, so the only incremental spend is the second instance you run. For a plan already running two or more instances for load, redundancy is effectively free. For a plan running a single instance to save money, the cost of resilience is one more instance of the same tier.

Frame each failing plan as a line on the downtime risk register rather than a compliance checkbox. A plan hosting the customer-facing checkout API carries a far higher cost of outage than an internal admin tool that can wait, yet both surface as the same Advisor recommendation. Map the failures to the revenue and the users behind them and prioritise by the cost of an hour of downtime, not by recommendation count.

The arithmetic is usually one-sided for anything that earns money or faces customers. The cost of resilience is the bounded, predictable price of a second instance. The cost of leaving it single-zone is the unbounded cost of a zone outage: lost revenue per minute, breached customer SLAs, support and incident-response effort, and the reputational hit of being down while the rest of the region stays up.

This lesson is for the finance partner who sees a reliability recommendation on the Advisor report and wants to know what the right response is and what it costs. It covers why redundancy is effectively free on plans already scaled for load, what the single-instance plans actually cost to protect, and how to turn a list of recommendations into a plan ordered by the cost of an outage.

Fun fact

The healthy region that still went dark

How a finance partner frames the redundancy decision

Priya is the finance partner supporting the platform team. The Advisor report lands with five reliability recommendations across the production subscription, all of them 'Use zone-supported App Service Plan'. The instinct is not to wave through a blanket scale-up budget; it is to ask what is actually running on each flagged plan. Azure does not charge a premium for the availability-zone feature, so the spend question is narrow: redundancy needs at least two instances, so the only incremental cost is a second instance on the plans that run a single one today, and nothing at all on the plans already scaled to two or more for load.

Priya asks the team to map each flagged plan to the revenue and users behind it. The checkout plan runs a single Premium instance and takes customer orders, two plans already run two instances for load and so cost nothing extra to make redundant, one is an internal admin tool that can tolerate a short outage, and one is a dev plan that does not matter. The list is reframed on the downtime risk register: the checkout plan is a one-instance cost to protect today because an hour of checkout downtime dwarfs the price of a second instance, the two already-scaled plans are zero-cost wins to toggle on now, and the internal and dev plans are documented as deliberately single-zone. The finance pack reads: 'Two plans become redundant at no incremental spend; one revenue plan needs one more instance to remove its single point of failure; the rest are a recorded decision to accept the risk.'

Why single-zone plans belong on the downtime risk register

The cost model here is asymmetric for anything that earns money or faces customers. Making a plan zone-redundant costs the price of a second instance at most, and nothing at all on plans already running two or more for load, because Azure charges no premium for the availability-zone feature itself. Leaving a revenue plan single-zone creates an unbounded tail risk: the probability of any one zone failing in a given month is low, but the cost when it happens to the zone your checkout runs in is measured in lost revenue per minute plus the incident that follows.

The cost of an outage is rarely just the lost transactions during the window. It includes breached customer SLAs and the credits they trigger, support and engineering time pulled onto the incident, and the slower drag of customers who saw you down while the rest of the region stayed up. Against that, the remediation is a bounded, forecastable line: one extra instance per single-instance plan you choose to protect. The finance role is to attach a cost-of-downtime figure to each flagged plan so the work is ordered by what an outage would actually cost, not by the order Advisor happens to list it.

What finance can do about the single-zone gap

Finance cannot toggle a plan setting, but it owns the framing that turns a list of reliability recommendations into a plan ordered by the cost of an outage, with a small and clearly bounded set of plans that actually need spend. Three levers.

1. Separate the zero-cost toggles from the one-instance spend

Make explicit that Azure charges no premium for the availability-zone feature, so any plan already running two or more instances for load becomes zone-redundant at no incremental spend. The only real cost is a second instance on the plans that run a single one today and that you choose to protect. Budget those as discrete lines and treat the rest as a free toggle, so nobody can claim the whole capability is a spending decision.

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

A plan carrying checkout traffic and an internal admin plan both show up as the same Advisor recommendation, but an hour of their downtime costs wildly different amounts. Ask the team to attach a cost-of-downtime figure to each flagged plan and protect the highest first. The metric that belongs on the reliability review is the count of single-zone plans weighted by the revenue or users behind them, not the raw total.

3. Require a documented decision for the plans left single-zone

Any production plan deliberately left single-zone, the internal tool, the dev environment, should carry a recorded, finance-visible reason that its downtime is cheap enough to accept. The distinction between 'we reviewed this and accepted the risk' and 'we never noticed it was a single point of failure' is exactly what makes the posture defensible at the next reliability review and in the aftermath of any zone outage.

Quick quiz

Question 1 of 5

Advisor flags five plans for zone redundancy. As the finance partner, what is the right starting assumption about their cost to fix?

Keep learning

Go deeper on how App Service plans express zone redundancy and what the setting does across the tiers in this capability.

You have finished the finance view of zone redundancy. You know the cost model is bounded: plans already scaled for load become redundant for free, only single-instance plans you choose to protect cost a second instance, and the downside of leaving a revenue plan single-zone is the unbounded cost of a zone outage. Next time a batch of reliability recommendations lands, you will order them by cost of downtime, ring-fence the plans that genuinely matter, and record the rest as a deliberate decision rather than asking for a blanket budget.

Back to the library

Zone-redundant App Service: the headline

Whether a single datacentre fault can take a customer-facing service offline

Zone redundancy is the difference between a localised Azure fault being a non-event and being your outage. When a plan runs in one zone, a power or network problem in that datacentre stops your service even though Azure has other healthy datacentres metres away in the same region. The report shows this as a quiet reliability recommendation, but what it really measures is whether your most important services can survive a single point of failure.

The leadership question is not 'are we up today?' It is 'when one datacentre in our region has a bad day, does our service stay up?' The defensible end state is that every plan carrying customer or revenue traffic spreads its instances across availability zones, so the loss of any single zone is absorbed automatically, and the few plans left single-zone are the ones where an outage genuinely does not matter.

This is a cost-against-downtime decision, not a free one. Resilience costs the price of a second instance per protected plan. The judgement is whether that bounded, predictable cost is worth more than the unbounded, unpredictable cost of being offline while a competitor in the same region stays up.

A short read for the leader who needs to know what a single-zone plan exposes, why turning on redundancy is a downtime-against-cost decision rather than a technical detail, and what a defensible end state looks like across the services that matter.

Fun fact

The healthy region that still went dark

What it looks like when an outage is absorbed, not suffered

After a competitor in the same Azure region was knocked offline by a single-zone fault and lost a day of trading while rivals stayed up, the CEO asked the obvious question at the next review: if one datacentre near us fails, do we go down too? The honest answer at the time was that it depended which plan and which zone, because resilience across the estate was a matter of how each plan happened to be configured rather than a deliberate posture.

The team's response was to stop treating zone redundancy as a per-plan afterthought and start treating it as a standard. They listed every plan running customer or revenue traffic on a single zone, turned on redundancy in place for each, scaling the revenue plans to two instances where they ran on one, and set a Bicep standard so every new production plan ships zone-redundant by default. The next time the CEO asked the question, the answer had changed from 'it depends' to 'the customer-facing services stay up through a single-zone fault, and the only plans that would not are the ones where being briefly down does not cost us anything.' That shift, from hoping the zone you are in does not fail to spreading across zones by design, is the confidence signal this capability delivers, and on plans already scaled for load it costs nothing extra to reach.

Why this is a board-level risk

Most cloud outages that take a single company offline trace back to the same root cause: a workload running in one availability zone when that zone had a fault, while the region around it stayed healthy. Zone redundancy is the capability that makes that root cause survivable, turning a single-zone fault from your outage into a non-event that the platform absorbs automatically.

The cost of getting this wrong is a customer-facing outage with lost revenue and reputational damage, while the cost of getting it right is bounded and small: the price of a second instance on the plans that matter, and nothing on the ones already scaled for load. This is the class of decision leadership should make deliberately, protecting the services where downtime is expensive and documenting the ones where a brief outage genuinely costs nothing.

The leadership move on zone redundancy

The executive handle is not to approve each plan individually; it is to require that every service whose downtime is expensive is zone-redundant by default, and that the plans left single-zone are a deliberate, recorded decision.

1. Set a deadline to reach a resilient-by-default end state

Ask for a date by which every plan carrying customer or revenue traffic is zone-redundant, the single-zone exceptions are documented, and the Bicep standard ships new production plans redundant by default with at least two instances. A default that new plans inherit is the difference between checking the estate is resilient today and guaranteeing the next plan does not reintroduce the gap.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'the important ones are covered.' It is the Advisor reliability recommendation passing across the plans that matter, plus evidence the Bicep standard sets zoneRedundant on new plans. Because resilience is only tested when a zone actually fails, the time to confirm it is now, on the record, not during the incident.

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

Some plans are fine to leave single-zone, the dev environment, the internal tool nobody loses money over. The leadership requirement is that each is a deliberate, documented decision with an owner who has confirmed its downtime is cheap, not a single point of failure nobody examined. The goal is not zero single-zone plans; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a single-zone outage like a competitor's could take your service down. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how App Service plans express zone redundancy and what the setting does across the tiers in this capability.

Two takeaways. Zone redundancy is the rare reliability control where the cost of action is bounded and small, the price of a second instance on the plans that matter, while the cost of inaction is a customer-facing outage when a single zone fails. And the defensible end state is not 'we think the important ones are covered'; it is every revenue-carrying plan zone-redundant by default through Bicep, with the deliberately single-zone plans documented and owned.

Back to the library

Part of the learning path Build in Azure resilience

Deploy App Service plans as zone-redundant

Zone-redundant App Service: the basics

The healthy region that still went dark

Finding single-zone plans across a subscription

How a plan becomes zone-redundantdeep dive

What is the impact of leaving a plan single-zone?

How do you make a plan zone-redundant safely?

1. Inventory every plan by redundancy and instance count

2. Separate the plans that matter from the ones that do not

3. Turn redundancy on, highest cost-of-downtime first

4. Make it the default with Bicep or policy

Quick quiz

Keep learning

Zone-redundant App Service: the downtime and cost view

The healthy region that still went dark

How a finance partner frames the redundancy decision

Why single-zone plans belong on the downtime risk register

What finance can do about the single-zone gap

1. Separate the zero-cost toggles from the one-instance spend

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

3. Require a documented decision for the plans left single-zone

Quick quiz

Keep learning

Zone-redundant App Service: the headline

The healthy region that still went dark

What it looks like when an outage is absorbed, not suffered

Why this is a board-level risk

The leadership move on zone redundancy

1. Set a deadline to reach a resilient-by-default end state

2. Ask for proof, not assurance

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

Quick quiz

Keep learning

Related site reliability lessons