Site Reliability

Deploy load balancers with zone-redundant front-ends

One capability across every Standard Load Balancer in the estate: make sure the front-end that receives and distributes traffic survives the loss of a single availability zone, so a zone fault degrades the service instead of taking it down.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Zone-redundant front-ends: the basics

What does a single-zone load balancer actually look like?

A load balancer is the front door to a workload: it owns the IP that clients connect to and decides which backend instance serves each request. An Azure Standard Load Balancer can place that front-end in one of three states. It can be zone-redundant, where the front-end IP is served by independent infrastructure in several availability zones at once. It can be zonal, where the front-end is pinned to one named zone. Or it can be left without a zone configuration at all on an older or hand-built deployment. The first survives the loss of a zone. The other two do not: if the zone holding that front-end has an outage, the IP stops answering and the whole service behind it goes dark, however healthy the backends are.

Azure Advisor surfaces this as a reliability recommendation: configure Standard Load Balancer, and the public IP or front-end IP configuration it depends on, to use availability zones. A zone-redundant front-end keeps traffic distribution working if a single zone fails, because the data path is spread across zones rather than anchored to one. Advisor raises it per resource, so an estate with a dozen load balancers can show the same recommendation a dozen times. They read as separate findings, but they are one job: make sure the thing that receives your traffic is not itself a single point of failure.

Most of this exposure is drift, not a decision. A load balancer created before zone-redundancy was the default, a Bicep module that never set the zones property, a front-end built on a public IP that was provisioned without zones. Nobody chose to make the front door fragile; it simply inherited the shape of whatever template or click-path created it. The work is to find every Standard Load Balancer whose front-end is pinned to one zone or has no zone redundancy, decide which genuinely need to be zonal, and give the rest a zone-redundant front-end.

In this lesson you will learn how an Azure Standard Load Balancer expresses zone redundancy, why the front-end is the part that decides whether a zone fault is survivable, how to find every load balancer in a subscription that is pinned to a single zone, and how to give them zone-redundant front-ends without an unplanned outage. You will also see the one constraint that catches teams out: zone redundancy cannot be switched on in place, so a fragile front-end has to be rebuilt rather than edited.

Fun fact

The healthy app that still went dark

The counter-intuitive part of zone redundancy is that you can do everything else right and still take an outage. Teams routinely spread their virtual machines across all three availability zones, watch the backend pool stay healthy through a zone fault, and then discover the service was unreachable the whole time because the single front-end IP in front of it happened to sit in the zone that failed. Azure makes a Standard public IP zone-redundant by default when you create it without specifying a zone, but every front-end built before that behaviour, or pinned to a single zone on purpose, or carried over from a Basic SKU, is still a single point of failure sitting in front of a perfectly resilient backend.

Finding single-zone load balancers across a subscription

Priya is the platform lead at a payments company that just had a near miss: an Azure zone in their primary region degraded for forty minutes, the backends rode it out, but one internal service went fully offline. The post-incident review traced it to a load balancer whose front-end was pinned to the affected zone.

Rather than wait for the next incident, Priya starts by listing which Standard Load Balancers have a zone-redundant front-end and which are pinned to a single zone, so the fragile front doors can be separated from the resilient ones before anything changes.

Start by listing every load balancer's front-end and the zones it is configured for. A front-end with all three zones is zone-redundant; one zone, or none, is a single point of failure.

$ az network lb list --query "[].{name:name, sku:sku.name, frontend:frontendIPConfigurations[0].name, zones:frontendIPConfigurations[0].zones}" -o table

Name Sku Frontend Zones

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

lb-payments-prod Standard fe-public 1 2 3

lb-internal-svc Standard fe-private 2

lb-legacy-api Standard fe-public

# lb-internal-svc is pinned to zone 2; lb-legacy-api has no zones at all. Both go down if their zone fails.

A front-end listing one zone, or no zones, is a single point of failure in front of the service. These are the front doors that need a zone-redundant rebuild.

How Azure decides a load balancer front-end is zone-redundantdeep dive

Zone redundancy lives on the front-end, and where the zones property sits depends on the load balancer type. For a public load balancer, the front-end IP configuration points at a Standard public IP, and it is that public IP that carries the zones: a public IP created with all three zones is zone-redundant, and the load balancer in front of it inherits that resilience. For an internal load balancer there is no public IP, so the zones property sits directly on the front-end IP configuration of the load balancer itself. In both cases the rule is the same: a front-end spread across multiple zones survives the loss of any one of them, and a front-end with a single zone, or pinned to a Basic SKU that has no zone concept at all, does not.

The constraint that catches teams out is that zones cannot be changed after the resource is created. You cannot edit a single-zone front-end IP into a zone-redundant one, and you cannot flip a public IP from zonal to zone-redundant in place. The supported path is to create a new zone-redundant front-end IP, attach it to the load balancer, re-point the load-balancing and inbound NAT rules at it, and remove the old one. For an internal load balancer this can often be done with no change to the address. For a public load balancer the IP address itself changes, which is exactly why public front-ends need a planned cutover rather than an in-place edit.

The strongest position pairs the per-resource fix with prevention. Once the existing front-ends are zone-redundant, an Azure Policy in audit or deny mode against the load-balancer and public-IP availability-zone rules, or simply a shared module that always sets the zones property, means no new front door enters the estate as a single point of failure. That is the difference between fixing the load balancers you can see today and guaranteeing the next one is born resilient.

What is the impact of a single-zone front-end?

The direct impact is a single point of failure in front of an otherwise resilient service. You can spread every backend instance across all three availability zones, pass every backend health check, and still go completely offline when one zone fails, because the front-end IP that receives client traffic was anchored to that zone. The whole point of running across zones, to absorb the loss of a data centre without an outage, is silently undone by the one component that sits in front of everything else.

The second-order impact is that the failure mode is invisible until it happens. A single-zone front-end behaves identically to a zone-redundant one every single day that all three zones are healthy, which is almost always. It looks fine in every test, every demo and every normal week. The gap only reveals itself during the rare zone fault, which is precisely the moment you most need the front door to stay open, and precisely when it is hardest to fix under pressure.

There is also a commitment dimension. Microsoft documents that zone-redundant deployments are how you reach the higher availability tiers for fronting a workload, and many internal and customer availability commitments are written assuming the service can survive a single-zone loss. A front-end pinned to one zone undercuts that commitment quietly: the number on the page says one thing, and the actual resilience of the front door says another. Making the front-end zone-redundant is the cheapest way to make the architecture match the promise.

How do you make front-ends zone-redundant safely?

Work the capability as one loop rather than chasing individual findings. The order matters: zone redundancy cannot be switched on in place, so for public load balancers you are rebuilding the front-end and changing the IP, which must be a planned cutover, not a live edit.

1. Inventory every load balancer by front-end zones

List every Standard Load Balancer and the zones on its front-end. A front-end with all three zones is zone-redundant; one zone is zonal; none, or a Basic SKU, is a single point of failure. Treat this inventory as the source of truth rather than the Advisor finding count, and note for each whether the front-end is public, whose IP will change on rebuild, or internal, where the address can often be preserved.

2. Order by cost of downtime, not by finding count

Map each fragile front-end to the service behind it and what an hour of that service being unreachable would cost. A front-end on a revenue or customer path is a different priority from one on an internal tool, even though they show as the same finding. Rebuild the highest cost-of-downtime front-ends first.

3. Rebuild the front-end as zone-redundant, with a planned cutover for public IPs

Create a new zone-redundant front-end IP across all available zones, attach it to the load balancer, re-point the load-balancing and inbound NAT rules at it, and remove the old front-end. For internal load balancers this can often be done without changing the address. For public ones the IP changes, so schedule the cutover, update DNS or the upstream Front Door origin, and check that backends are also spread across zones, because a zone-redundant front-end in front of single-zone backends still fails when that zone does.

4. Make the next front door born resilient

Once the estate is fixed, prevent regressions. Set the zones property in the shared load-balancer and public-IP modules so every new front-end is zone-redundant by default, and back it with an Azure Policy in audit or deny mode against the availability-zone rules so a single-zone front-end cannot quietly re-enter the estate.

# A public LB front-end cannot be made zone-redundant in place. Create a new
# zone-redundant public IP, attach it as a second front-end, move the rule,
# then remove the old front-end. Run this as a PLANNED cutover: the IP changes.
RG=rg-payments
LB=lb-payments-prod
LOCATION=uksouth

# 1. New zone-redundant Standard public IP (all three zones = zone-redundant).
az network public-ip create \
  --resource-group "$RG" \
  --name pip-payments-zr \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3

# 2. Add it as a new front-end on the existing load balancer.
az network lb frontend-ip create \
  --resource-group "$RG" \
  --lb-name "$LB" \
  --name fe-public-zr \
  --public-ip-address pip-payments-zr

# 3. Re-point the load-balancing rule at the new zone-redundant front-end.
az network lb rule update \
  --resource-group "$RG" \
  --lb-name "$LB" \
  --name rule-https \
  --frontend-ip-name fe-public-zr

# 4. Once DNS / Front Door points at the new IP, remove the old front-end.
az network lb frontend-ip delete \
  --resource-group "$RG" \
  --lb-name "$LB" \
  --name fe-public-old

Quick quiz

Question 1 of 5

Azure Advisor raises the same load-balancer reliability recommendation across a dozen resources in the estate. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure Load Balancer expresses zone redundancy and how to migrate an existing front-end onto availability zones.

You can now treat load-balancer zone redundancy as one capability rather than a scatter of findings: inventory which front-ends are pinned to a single zone, order them by the cost of downtime of the service behind each one, rebuild the fragile ones as zone-redundant on a planned cutover, and make the shared modules ship a zone-redundant front-end by default so the next front door is born resilient. Remember the two traps: zones cannot be changed in place, so public front-ends need a planned IP cutover, and a zone-redundant front-end over single-zone backends still goes down, so the backends must span zones too.

Back to the library

Zone-redundant front-ends: the downtime and cost view

A near-zero-cost change that removes a whole class of single-zone outage from the estate

A zone-redundant front-end is one of the rare resilience controls that does not change your Azure bill. A Standard Load Balancer with a zone-redundant front-end costs the same as one pinned to a single zone: there is no premium meter for spreading the data path across zones. The spend question is narrow, and it sits in the cutover, not the steady state, because an existing front-end IP cannot be made zone-redundant in place and has to be rebuilt.

Frame each Advisor finding as a line on the availability risk register rather than a recommendation to clear. A load balancer fronting the checkout path carries a far higher cost-of-downtime than one fronting an internal admin tool, yet both surface as the same single finding. Map the findings to the revenue and the users behind each load balancer, and prioritise by what an outage of that service would cost per hour, not by the number of findings.

The arithmetic is one-sided in the way resilience rarely is. The fix is engineering time plus a planned cutover for the handful of public front-ends whose IP will change. The downside of leaving it is the cost of a single-zone outage: lost transactions for every hour the front door is dark, the support and recovery effort, and the contractual exposure if an availability commitment is missed. One avoided zone outage typically pays for the entire programme of work many times over.

This lesson is for the finance partner who sees a list of load-balancer reliability findings and wants to know what the right response is and what it costs. It covers why the change itself is free in Azure spend, where the real cost sits in the cutover, and how to turn a list of identical findings into a plan ordered by the cost of downtime for the service behind each one.

Fun fact

The healthy app that still went dark

How a finance partner frames the front-end decision

Priya is the finance partner supporting the platform team after the near miss. The reliability report lands with nine load-balancer findings across two subscriptions. The instinct is not to wave through a blanket resilience budget; it is to ask what is actually behind each finding and what an outage of that service would cost. Making a front-end zone-redundant changes nothing on the Azure bill, so the spend question is narrow: the only real cost is the engineering time to rebuild each fragile front-end, plus a planned cutover for the few public ones whose IP will change.

Priya asks the team to map each failing load balancer to the service it fronts and the cost of that service being unreachable for an hour. Two of the nine front-ends sit in front of customer-facing payment flows where an hour of downtime is measured in lost transactions and breached availability commitments. Three front internal tools where an outage is an inconvenience. The rest are non-production. The list is reframed on the availability risk register: the two revenue-path front-ends are rebuilt first and given a planned cutover window, the internal ones follow, and the non-production ones are swept up opportunistically. The finance pack reads: 'Nine findings, zero incremental Azure spend; the only cost is engineering time and two short, scheduled cutover windows; one avoided zone outage on the payment path pays for the whole programme many times over.'

Why a single-zone front-end belongs on the risk register

The cost model here is asymmetric in a way that is rare for resilience work, where the fix usually means paying for redundant capacity. A zone-redundant front-end is free: there is no premium meter, and the load balancer costs the same spread across zones as pinned to one. So the entire downside of leaving it is on the outage side of the ledger, and none of it is offset by ongoing savings from acting.

The cost of a single-zone outage is the cost of every hour the front door is dark: lost transactions and revenue for a customer-facing service, the engineering and support effort to respond and recover, any service credits owed against a missed availability commitment, and the harder-to-quantify trust cost of a visible outage. Against that, the remediation is engineering time plus a short, planned cutover window for the public front-ends. The finance role is to attach a cost-of-downtime-per-hour to each load balancer so the work is ordered by what an outage of that service would actually cost, not by the order the report happens to list the findings.

What finance can do about the front-end gap

Finance cannot rebuild a front-end, but it owns the framing that turns a list of identical findings into a plan ordered by cost-of-downtime, with zero incremental Azure spend and a clearly bounded set of cutover windows. Three levers.

1. State plainly that the change is free in Azure spend

Make explicit that a zone-redundant front-end costs the same as a single-zone one: there is no premium meter for spreading the data path across zones. The only cost is engineering time plus a short, planned cutover for the public front-ends whose IP changes. This stops the whole capability being mistaken for a spending decision and keeps the conversation on when the work happens, not whether the budget allows it.

2. Order the work by cost of downtime per service

A front-end on the checkout path and one on an internal admin tool both show as a single reliability finding, but the cost of each going offline for an hour differs by orders of magnitude. Ask the team to map each fragile front-end to the revenue and users behind it, and prioritise by cost-of-downtime-per-hour. The metric that belongs on the resilience review is findings weighted by the business impact of the service each one fronts, not the raw count.

3. Budget the cutover windows as named, bounded items

The public front-ends change IP on rebuild, so each needs a scheduled cutover with DNS or Front Door updates and a short risk window. Treat these as discrete, owned, time-boxed items rather than open-ended risk. The distinction between 'we scheduled a planned cutover and it was uneventful' and 'we changed a production IP on the fly and broke connectivity' is exactly what keeps the programme cheap and defensible.

Quick quiz

Question 1 of 5

A reliability report shows nine load-balancer findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure Load Balancer expresses zone redundancy and how to migrate an existing front-end onto availability zones.

You have finished the finance view of zone-redundant front-ends. You know the cost model is one-sided: the change is free in Azure spend, the only cost is engineering time plus a few short, scheduled cutover windows for the public front-ends, and the downside of leaving it is the cost of a single-zone outage measured per hour. Next time a list of load-balancer reliability findings lands, you will order them by cost of downtime, budget the cutovers as named items, and ask which services survive a zone loss rather than asking how much the fix will cost.

Back to the library

Zone-redundant front-ends: the headline

Whether a single data-centre fault can take a customer-facing service offline

Availability zones exist so that one data-centre going dark does not take a region down with it. A load balancer whose front-end lives in a single zone quietly opts the service out of that protection: the backends can be spread across every zone and the application can be perfectly healthy, but if the one zone holding the front door has a fault, the service is unreachable. The report shows this as a scatter of identical reliability findings across the estate.

The leadership question is not 'are we using availability zones somewhere?' It is 'if a single Azure data centre fails tomorrow, which of our customer-facing services go dark, and for how long?' The defensible end state is that every Standard Load Balancer in front of a service that matters has a zone-redundant front-end, so a zone fault degrades capacity rather than causing an outage.

This is not a budget decision. A zone-redundant front-end costs nothing extra to run. It is a resilience decision about whether the estate is built to absorb the loss of a zone or merely hopes the wrong zone never fails.

A short read for the leader who needs to know what a single-zone load balancer exposes the business to, why making the front door zone-redundant is a resilience decision rather than a spend one, and what a defensible end state looks like across every customer-facing service in the estate.

Fun fact

The healthy app that still went dark

What it looks like when a zone fault degrades instead of outages

After the forty-minute zone degradation that took an internal service offline, the CEO asked the obvious question at the next review: if that had been the checkout path instead of an internal tool, would we have gone down? The honest answer at the time was yes, because whether a given service survived a zone fault depended entirely on which zone its front-end happened to be pinned to, and nobody had been tracking that.

The team's response was to stop treating zone redundancy as a per-deployment detail and start treating it as a property of the estate. They listed every Standard Load Balancer, identified the ones whose front-end sat in a single zone, rebuilt the customer-facing ones with zone-redundant front-ends on a planned cutover, and then set a standard that every new load balancer module ships with a zone-redundant front-end by default. The next time a zone wobbled, the payment path stayed up on reduced capacity and recovered on its own. The answer to the CEO's question had changed from 'it depends which zone fails' to 'a single data-centre fault degrades us, it does not take us down,' and reaching that point cost nothing in Azure spend.

Why this is a board-level resilience risk

Availability zones are the headline reason an organisation pays for a multi-zone region at all: the promise that the loss of a single data centre is survivable. A single-zone load balancer front-end quietly breaks that promise for whatever sits behind it. The service can be engineered to ride out a zone loss in every other respect and still go fully offline because the front door was in the wrong place.

The cost of getting this wrong is a customer-visible outage during exactly the kind of infrastructure event the estate was supposed to be built to absorb, while the cost of fixing it is essentially engineering time with no ongoing spend. This is the rare class of resilience control where the downside is severe, the fix is free to run, and the only real effort is a planned cutover, which makes it one of the easiest resilience trades leadership will ever approve.

The leadership move on front-end resilience

The executive handle is not to approve each rebuild individually; it is to require that every load balancer in front of a service that matters has a zone-redundant front-end, and that new ones are born that way, on the record.

1. Set a deadline to reach a zone-redundant end state

Ask for a date by which every Standard Load Balancer fronting a customer-facing or revenue-path service has a zone-redundant front-end, the public ones have completed their planned cutovers, and the shared modules ship zone-redundant front-ends by default. A default that the next deployment inherits is the difference between fixing today's fragile front doors and guaranteeing tomorrow's are resilient from birth.

2. Ask for proof against a named failure, not assurance

The proof that this is closed is not 'we are using zones somewhere.' It is a list of every service-fronting load balancer with a zone-redundant front-end confirmed, and ideally a game-day or zone-down test showing the service degrades rather than outages. Ask for the inventory and the test result, not a verbal 'we are on it.'

3. Require backends to span zones too, or the front-end fix is hollow

A zone-redundant front-end in front of backends that all sit in one zone still goes down when that zone fails. The leadership requirement is end-to-end zone resilience for the services that matter: front-end zone-redundant and backend instances spread across zones. The goal is a service that survives the loss of a data centre, not a single component that does.

Quick quiz

Question 1 of 5

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

Keep learning

Go deeper on how Azure Load Balancer expresses zone redundancy and how to migrate an existing front-end onto availability zones.

Two takeaways. A zone-redundant front-end is the rare resilience control where the downside of inaction is a customer-visible outage and the cost of action is essentially engineering time, so it is one of the easiest resilience trades to approve. And the defensible end state is not 'we use availability zones somewhere'; it is every service-fronting load balancer with a zone-redundant front-end and backends spread across zones, proven by an inventory and ideally a zone-down test, so a single data-centre fault degrades the service instead of taking it down.

Back to the library

Part of the learning path Build in Azure resilience

Deploy load balancers with zone-redundant front-ends

Zone-redundant front-ends: the basics

The healthy app that still went dark

Finding single-zone load balancers across a subscription

How Azure decides a load balancer front-end is zone-redundantdeep dive

What is the impact of a single-zone front-end?

How do you make front-ends zone-redundant safely?

1. Inventory every load balancer by front-end zones

2. Order by cost of downtime, not by finding count

3. Rebuild the front-end as zone-redundant, with a planned cutover for public IPs

4. Make the next front door born resilient

Quick quiz

Keep learning

Zone-redundant front-ends: the downtime and cost view

The healthy app that still went dark

How a finance partner frames the front-end decision

Why a single-zone front-end belongs on the risk register

What finance can do about the front-end gap

1. State plainly that the change is free in Azure spend

2. Order the work by cost of downtime per service

3. Budget the cutover windows as named, bounded items

Quick quiz

Keep learning

Zone-redundant front-ends: the headline

The healthy app that still went dark

What it looks like when a zone fault degrades instead of outages

Why this is a board-level resilience risk

The leadership move on front-end resilience

1. Set a deadline to reach a zone-redundant end state

2. Ask for proof against a named failure, not assurance

3. Require backends to span zones too, or the front-end fix is hollow

Quick quiz

Keep learning

Related site reliability lessons