Site Reliability

Deploy Application Gateway across availability zones

One reliability capability: make sure the gateway that fronts your web traffic survives the loss of a single datacentre, so a zone outage degrades into a few seconds of redistribution rather than a full front-door failure.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Zone-redundant Application Gateway: the basics

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

Application Gateway is the layer-7 load balancer that fronts a web application: it terminates TLS, routes by path or host, and often runs the web application firewall. Because every request enters through it, the gateway is a single point of failure unless it is spread across the physically separate datacentres that Azure calls availability zones. Azure Advisor surfaces exactly this gap with the reliability recommendation 'Deploy your Application Gateway across Availability Zones', whose own words are that zone redundancy 'ensures continuity even if one zone is affected and enhances overall reliability'.

A zone-redundant gateway runs its instances across two or more availability zones in the region. If one zone is lost, the platform redistributes traffic to the healthy instances in the other zones automatically, and connections typically see only a few seconds of interruption. A zonal gateway, by contrast, pins every instance into one zone you choose, so it does nothing for a zone outage: if that single zone goes down, the gateway is unavailable until the zone recovers. Microsoft is explicit that a zonal gateway, by itself, does not provide resiliency to an availability zone outage.

The good news is that this is mostly a question of which gateways pre-date the current default. New Standard_v2 and WAF_v2 gateways are created zone-redundant by default, and availability zone support costs nothing beyond the standard capacity unit pricing you already pay. The work is to find the gateways that are still pinned to one zone, or still on the legacy V1 SKU that cannot use zones at all, and bring them onto a zone-redundant footing before a datacentre incident does it for you.

In this lesson you will learn how Application Gateway expresses zone redundancy, how to find every gateway that is still pinned to a single zone or stuck on a SKU that cannot use zones, and how to move them onto a zone-redundant footing without dropping live traffic. You will see the exact Azure Advisor recommendation behind this, the difference between zonal and zone-redundant behaviour during an outage, and the capacity planning that keeps a zone failure from becoming an overload.

Fun fact

The default that quietly fixed itself

For a long time, getting a zone-redundant Application Gateway meant remembering to specify zones at create time, and plenty of production gateways were stood up without them. Microsoft eventually flipped the behaviour so that new Standard_v2 and WAF_v2 gateways are zone-redundant by default, spread across the availability zones of the region with no extra charge. The catch is that the default only protects gateways created after it landed: every gateway provisioned before then, and every legacy V1 gateway that cannot use zones at all, still carries the old single-zone risk until someone checks and redeploys it. The Advisor recommendation exists precisely to surface that backlog.

Finding single-zone gateways across a subscription

Priya is the platform reliability lead at a retailer heading into its peak trading season. Azure Advisor has raised 'Deploy your Application Gateway across Availability Zones' against the gateway that fronts the checkout service, and she wants to know how many other gateways share the same exposure before she touches anything.

Rather than open each gateway in the portal, she lists every Application Gateway in the subscription with its SKU and its zones, so she can separate the genuinely zone-redundant ones from the ones still pinned to a single zone or stuck on the legacy SKU.

List every gateway with its SKU tier and the zones it occupies. A gateway showing one zone, or no zones on a V1 SKU, is the exposure.

$ az network application-gateway list --query "[].{name:name, sku:sku.name, zones:zones}" -o table

Name Sku Zones

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

checkout-appgw Standard_v2 ['2']

legacy-appgw Standard None

marketing-appgw WAF_v2 ['1', '2', '3']

# checkout-appgw is pinned to a single zone; legacy-appgw is V1 and cannot use zones at all.

A v2 gateway with a single zone, or any V1 gateway, is exposed to a zone outage. The gateway listing all three zones is the one already doing the right thing.

How a zone outage plays out for each gateway typedeep dive

Zone redundancy is set at the SKU and zone level. The gateway must be Standard_v2 or WAF_v2: the legacy V1 SKU cannot use availability zones at all, which is why migrating off V1 is a prerequisite, not an option. On a v2 gateway, the 'zones' property decides the behaviour. Omit it, or list two or more zones, and the gateway is zone-redundant, with the platform spreading its instances across the region's zones. Pin it to a single zone and it is zonal, with every instance in one datacentre. Microsoft recommends omitting the zone list so the gateway can use all of the region's availability zones unless you have a specific reason not to.

During a zone outage the two configurations diverge sharply. For a zone-redundant gateway, Microsoft manages detection and failover with no customer action: traffic is immediately redistributed to instances in the healthy zones, the platform spins up temporary instances elsewhere to hold capacity, and in-flight requests on the lost zone are terminated and should be retried as transient faults. Connections typically see a few seconds of interruption. For a zonal gateway, the gateway is simply unavailable until the zone recovers, and you are responsible for any failover to a separate gateway you built in another zone.

Two details matter for getting the change right. First, you cannot toggle a running gateway from zonal to zone-redundant in place: the zone configuration is fixed at creation, so moving to zone-redundant means deploying a new gateway and cutting traffic over. Second, the SLA has conditions. To be eligible for the Application Gateway availability SLA, a gateway must be configured correctly for HTTP load balancing and must either be zone-redundant or be configured to use autoscale, so pairing zone redundancy with autoscale is the configuration that both survives a zone loss and stays inside the SLA.

What is the impact of leaving the gateway in a single zone?

The direct impact is a front-door outage on a single datacentre fault. Because every request enters through the gateway, a single-zone gateway converts one zone's loss into total unavailability for everything behind it, however resilient those backend services are. Availability zones exist precisely to contain a datacentre incident inside one zone; a gateway pinned to that zone hands the incident the keys to your whole application. Microsoft is clear that a zonal gateway, on its own, gives no resiliency to a zone outage, and that the gateway stays down until the zone recovers.

The second-order impact is the SLA and the blast radius around it. A gateway that is neither zone-redundant nor autoscale-configured is not even eligible for the Application Gateway availability SLA, so you carry the downtime with no platform commitment behind it. And because the gateway is the choke point, its outage ripples outward: every downstream service that was healthy is now unreachable, support load spikes, and any commitments you made to your own customers are at risk on a fault you could have contained.

On the resilience side, the trade is unusually clean. Zone redundancy for Application Gateway adds no Azure cost over the capacity you already run, and turns a hours-long single-zone outage into a few seconds of automatic redistribution that Microsoft manages for you. A zone-redundant front door is one of the cheapest reliability artefacts you can put in place for the component with the widest blast radius in the stack.

How do you move a gateway to zone-redundant safely?

Work this as a controlled cutover rather than an in-place toggle, because the zone configuration is fixed at creation. The order matters: build and validate the zone-redundant gateway before you move live traffic, so the front door is never down during the change.

1. Inventory every gateway by SKU and zones

List every Application Gateway with its SKU and its zones. A v2 gateway showing a single zone is zonal; any V1 gateway cannot use zones at all and needs a SKU migration first. Treat this inventory as the source of truth, and order it by the value of the service each gateway fronts.

2. Size autoscale for the loss of a zone

A zone-redundant gateway redistributes traffic to surviving zones during an outage, so those zones must have headroom to absorb it. Enable autoscale with a maximum instance count high enough to carry peak load when a zone is gone, and set a minimum that keeps capacity ready. Autoscale also keeps the gateway inside the availability SLA.

3. Deploy a new zone-redundant gateway alongside the old one

Because you cannot flip a running gateway from zonal to zone-redundant in place, deploy a new Standard_v2 or WAF_v2 gateway with no zone list, so it uses all of the region's zones, and replicate the listeners, rules, WAF policy and backend pools. Validate it against the same backends before any traffic moves.

4. Cut traffic over, then retire the single-zone gateway

Move traffic to the zone-redundant gateway by repointing DNS or the upstream global load balancer, drain the old one, and only then delete it. Once the estate is zone-redundant, keep new gateways on the v2 default and treat any future single-zone gateway as a deliberate, documented exception.

# Build a zone-redundant gateway by OMITTING --zones, so it uses all of the
# region's availability zones (Microsoft's recommended default), paired with
# autoscale so it stays inside the availability SLA.
az network application-gateway create \
  --name checkout-appgw-zr \
  --resource-group rg-checkout \
  --sku Standard_v2 \
  --min-capacity 2 \
  --max-capacity 10 \
  --vnet-name vnet-checkout \
  --subnet snet-appgw \
  --public-ip-address pip-checkout-appgw
# Note: zones are fixed at creation. There is no in-place flip from zonal to
# zone-redundant; build this new gateway, validate it, then cut traffic over.

Quick quiz

Question 1 of 5

Azure Advisor raises 'Deploy your Application Gateway across Availability Zones' against a production v2 gateway. What does moving it to zone-redundant actually change?

Keep learning

Go deeper on how Application Gateway v2 expresses zone redundancy, how it behaves during a zone outage, and how to size it so a surviving zone can carry the load.

You can now treat Application Gateway zone redundancy as one reliability capability rather than a single recommendation: inventory every gateway by SKU and zones, size autoscale for the loss of a zone, deploy a zone-redundant gateway alongside any single-zone one, and cut traffic over before retiring the old one. The front door that every request passes through now survives the loss of a whole datacentre, at no extra Azure charge for the redundancy itself.

Back to the library

Zone-redundant Application Gateway: the downtime-cost view

A near-zero-cost change that removes a whole category of front-door outage from the risk register

The thing worth pricing here is not the gateway, it is the outage it prevents. A single-zone gateway turns one datacentre's bad day into a full front-door failure: every request stops, regardless of how resilient the application behind it is. Spreading the same gateway across zones is the cheapest insurance against that, because Microsoft documents that availability zone support for Application Gateway v2 does not incur extra charges beyond the standard capacity unit pricing. There is no premium SKU and no per-zone surcharge to budget for.

Frame each flagged gateway as expected downtime cost, not as a line item. Multiply your best estimate of revenue or productivity lost per hour of front-door outage by the probability and likely duration of a zone incident. The remediation against that is engineering time to redeploy onto a zone-redundant configuration, plus, in some cases, a small amount of extra reserved capacity so the surviving zones can absorb redistributed traffic. That is a bounded, one-off cost set against an unbounded outage.

The arithmetic is one-sided. The cost of acting is mostly people-time and no incremental Azure spend for the redundancy itself. The cost of not acting is the full price of a front-door outage: lost transactions, missed SLAs to your own customers, support load and the reputational cost of being down while a single Azure datacentre has a problem the rest of the region rode out.

This lesson is for the finance partner who sees a reliability recommendation against a production gateway and wants to know what the right response is and what it costs. It covers why the redundancy itself is free in Azure terms, where the only real costs sit, and how to weigh a one-off remediation against the expected cost of a front-door outage.

Fun fact

The default that quietly fixed itself

How a finance partner frames the gateway decision

Priya is the finance partner supporting the platform team before peak season. The reliability recommendation lands against the checkout gateway, and the instinct is not to wave through a resilience budget; it is to ask what is actually at stake and what the fix costs. The redundancy itself is free: Microsoft documents that availability zone support for Application Gateway v2 carries no charge beyond the standard capacity unit pricing already on the bill. So the spend question is narrow, and the risk question is large.

The team maps each flagged gateway to the service behind it. The checkout gateway, pinned to a single zone, fronts the revenue path, so its expected downtime cost is the headline number: revenue per hour lost if a single datacentre fault takes checkout down while the rest of the region stays up. A legacy V1 gateway fronts an internal tool, a lower number. The finance pack reads: 'The redundancy costs nothing extra in Azure spend; the only costs are a one-off redeploy of two gateways and a little extra reserved capacity so a surviving zone can absorb redistributed load. Against that, a single-zone checkout outage during peak is the largest avoidable downtime cost on the register.'

Why a single-zone gateway belongs on the risk register

The cost model here is asymmetric in a way that is rare for reliability work. Making the gateway zone-redundant costs nothing in Azure spend for the redundancy itself, and leaving it single-zone creates an open-ended downtime tail. Each single-zone gateway is a front door where one datacentre fault means total outage, and while the probability of a given zone failing in a given month is low, the cost when it lands on a revenue path during peak is large and concentrated.

The documented cost of a front-door outage is lost transactions for the full duration, breached commitments to your own customers, surge support cost and reputational damage from being down while the rest of the region stayed up. Against that, the remediation is engineering time to redeploy zone-redundant plus, where needed, a little extra reserved capacity so a surviving zone can absorb redistributed traffic. The finance role is to attach an expected downtime cost to each flagged gateway so the work is ordered by the value of the service it fronts, not by the order Advisor lists it.

What finance can do about the single-zone gap

Finance cannot redeploy a gateway, but it owns the framing that turns a reliability recommendation into a risk-ordered plan with no incremental spend on the redundancy itself and a clearly bounded set of one-off costs. Three levers.

1. Separate the free redundancy from the real costs

Make explicit that zone redundancy for Application Gateway v2 carries no Azure charge beyond the capacity unit pricing already on the bill. The only real costs are the one-off engineering time to redeploy a new gateway and cut traffic over, and any extra reserved capacity needed so a surviving zone can absorb redistributed load. Budget those as discrete lines and treat the redundancy as free, so nobody can frame the whole change as a spending decision.

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

A gateway fronting checkout and a gateway fronting an internal tool both show up as a single reliability recommendation, but their expected downtime cost differs by orders of magnitude. Ask the team to map each flagged gateway to the revenue or productivity behind it and tackle the revenue paths first. The metric that belongs on the reliability review is expected downtime cost per gateway, not the raw count of recommendations.

3. Require documented exceptions for any deliberate single-zone gateway

Occasionally a gateway is pinned to one zone on purpose, usually to keep cross-zone latency down for a specific workload. Any such gateway should carry a recorded, finance-visible reason and an explicit acceptance that it has no zone-outage resilience. The distinction between 'we pinned this deliberately and accepted the risk' and 'we never noticed it was single-zone' is exactly what makes the posture defensible after any outage.

Quick quiz

Question 1 of 5

Advisor flags a production gateway as single-zone. As the finance partner, what is the right starting assumption about the Azure-spend cost of making it zone-redundant?

Keep learning

Go deeper on how Application Gateway v2 expresses zone redundancy, how it behaves during a zone outage, and how to size it so a surviving zone can carry the load.

You have finished the finance view of zone-redundant Application Gateway. You know the cost model is one-sided: the redundancy is free in Azure terms, the only real costs are a one-off redeploy and a little extra reserved capacity, and the downside of leaving a gateway single-zone is the open-ended cost of a front-door outage on a single datacentre fault. Next time a reliability recommendation lands on a gateway, you will order the work by expected downtime cost, ring-fence any deliberate single-zone gateway as a documented exception, and ask for it on the record rather than asking how much resilience will cost.

Back to the library

Zone-redundant Application Gateway: the headline

Whether a single datacentre fault can take the whole web front door offline

Availability zones exist so that one datacentre catching fire, flooding or losing power does not take a region down with it. A gateway pinned to a single zone opts out of that protection: it is the one component that every request must pass through, sitting in one building. When that building has a bad day, the application is down even though Azure kept the region running.

The leadership question is not 'is the gateway healthy today?' It is 'if one of our region's datacentres fails tomorrow, does our front door stay up?' For a zone-redundant gateway the answer is yes, the platform redistributes traffic automatically and customers see seconds, not an outage. For a single-zone gateway the answer is no, you are down until that datacentre comes back, which can be hours.

This is not a cost decision. Zone redundancy for Application Gateway carries no extra Azure charge over the capacity you already pay for. It is a resilience decision about whether the front door is built to survive the failure mode availability zones were created to handle, or whether it quietly opted out of it.

A short read for the leader who needs to know what a single-zone gateway exposes the business to, why moving it to zone-redundant is a resilience decision rather than a budget one, and what a defensible end state looks like for the component every request passes through.

Fun fact

The default that quietly fixed itself

What it looks like when the front door survives a datacentre, not just a server

After a regional cloud incident took a competitor's checkout offline for an afternoon during a sale, the board asked the obvious question at the next review: if one of our datacentres fails, does our front door stay up? The honest answer at the time was that it depended on the gateway, because the checkout gateway had been stood up pinned to a single zone before zone redundancy became the default, and nobody had revisited it.

The team's response was to stop treating the gateway as a box that was either up or down and start treating it as a component with a defined failure mode. They listed every gateway, found the ones on a single zone or the legacy SKU, and redeployed them zone-redundant across the region's zones, sizing autoscale so a surviving zone could carry the redistributed load. The next time the question came up, the answer had changed from 'we think so' to 'the checkout front door now survives the loss of a whole datacentre, with customers seeing seconds of redistribution rather than an outage, and it cost nothing extra in Azure spend.' That shift, from a front door that depended on one building to one that rides out a zone failure automatically, is the confidence signal this capability delivers.

Why this is a board-level reliability risk

Availability zones are the mechanism that keeps a single datacentre failure from becoming a regional outage. A gateway pinned to one zone opts the most critical component in the stack, the one every request passes through, out of that protection. Making it zone-redundant is what restores it, and because the platform manages failover automatically, a zone loss becomes seconds of redistribution instead of an outage measured in hours.

The cost of getting this wrong is a visible, customer-facing outage on a fault the region itself survived, while the cost of fixing it is essentially engineering time with no extra Azure charge for the redundancy. This is the rare class of reliability change where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on the front door

The executive handle is not to approve each redeploy individually; it is to require that the components every request passes through are zone-redundant, and that any deliberate single-zone gateway is a documented, owned exception with the downtime risk accepted on the record.

1. Set a deadline to reach a zone-redundant front door

Ask for a date by which every production gateway is inventoried, the revenue-path gateways are zone-redundant with autoscale sized for a zone loss, and any remaining single-zone gateway is a named exception. A front door that survives the loss of a datacentre is the difference between an incident the region absorbed and an outage your customers felt.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'the gateway is fine.' It is the gateway listing showing the production gateways spread across multiple zones, autoscale configured, and the Advisor recommendation cleared. Because the change is a cutover rather than a toggle, ask for that evidence after the new gateway is live and traffic has moved, not while it is still planned.

3. Treat any single-zone gateway as a named, owned exception

A gateway may occasionally be pinned to one zone for a genuine latency reason, and that can be acceptable. The leadership requirement is that each such case is a deliberate, documented decision with an owner who has accepted that it has no resilience to a zone outage. The goal is not zero zonal gateways; it is zero gateways that are single-zone by accident.

Quick quiz

Question 1 of 5

At a board review you ask whether a single datacentre failure could take your web front door offline, as it did for a competitor. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Application Gateway v2 expresses zone redundancy, how it behaves during a zone outage, and how to size it so a surviving zone can carry the load.

Two takeaways. A single-zone gateway is the rare reliability risk where the cost of inaction is a visible, customer-facing outage on a fault the region itself survived, while the cost of action is essentially engineering time with no extra Azure charge, so it is the trade you should be quickest to approve. And the defensible end state is not 'the gateway was healthy when we last looked'; it is a front door spread across the region's zones with autoscale, where a datacentre failure becomes seconds of automatic redistribution, and any deliberate single-zone gateway is documented and owned.

Back to the library

Part of the learning path Build in Azure resilience

Deploy Application Gateway across availability zones

Zone-redundant Application Gateway: the basics

The default that quietly fixed itself

Finding single-zone gateways across a subscription

How a zone outage plays out for each gateway typedeep dive

What is the impact of leaving the gateway in a single zone?

How do you move a gateway to zone-redundant safely?

1. Inventory every gateway by SKU and zones

2. Size autoscale for the loss of a zone

3. Deploy a new zone-redundant gateway alongside the old one

4. Cut traffic over, then retire the single-zone gateway

Quick quiz

Keep learning

Zone-redundant Application Gateway: the downtime-cost view

The default that quietly fixed itself

How a finance partner frames the gateway decision

Why a single-zone gateway belongs on the risk register

What finance can do about the single-zone gap

1. Separate the free redundancy from the real costs

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

3. Require documented exceptions for any deliberate single-zone gateway

Quick quiz

Keep learning

Zone-redundant Application Gateway: the headline

The default that quietly fixed itself

What it looks like when the front door survives a datacentre, not just a server

Why this is a board-level reliability risk

The leadership move on the front door

1. Set a deadline to reach a zone-redundant front door

2. Ask for proof, not assurance

3. Treat any single-zone gateway as a named, owned exception

Quick quiz

Keep learning

Related site reliability lessons