Azure Firewall
New deployments are zone-redundant by default and automatic — Azure spreads instances across at least two Availability Zones with no configuration needed. A single-zone ("zonal") deployment is now the exception, reachable only through API-based tools. Cross-region DR is always a separate, independently managed firewall.
Zonal (single AZ, API-only) or legacy nonzonal deployment
Deployed to one specific Availability Zone via CLI/PowerShell/Bicep/Terraform — not available through the portal — or a pre-2026 legacy deployment awaiting Microsoft's automatic migration to zone-redundant. A zonal firewall alone doesn't provide resiliency to a zone outage.
- Replication
- None
- RPO
- N/A — stateless, no persistent customer data
- RTO
- Unavailable until the zone recovers, unless you've built and manually fail over to a secondary firewall in another zone
- Failover trigger
- Manual (customer-triggered)
- Relative cost
- No extra cost
Same hourly + data-processed pricing as zone-redundant — this option is weaker, not cheaper.
Microsoft is migrating all existing nonzonal deployments to zone-redundant throughout 2026; zonal (pinned) deployments stay pinned until you redeploy.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
Zone-redundant (default for all new deployments)
Azure automatically distributes at least two firewall instances across every Availability Zone the firewall uses and load-balances active-active between them. This is the default the moment you deploy in a region with multiple AZs — no toggle to find or verify.
- Replication
- None
- RPO
- N/A — stateless; connections in the failed zone drop and retry through a healthy zone
- RTO
- Minimal — typically a few seconds; the platform detects and reroutes without you initiating anything
- Failover trigger
- Automatic
- Relative cost
- No extra cost
No extra charge — confirmed by Microsoft's own reliability documentation.
No extra cost. Portal deployments can only create zone-redundant firewalls — you'd have to use the CLI/API deliberately to get anything weaker.
Independent Firewall + Traffic Manager/Front Door in a second region (customer-built)
Azure Firewall is a single-region service with no cross-region replication of policy state or connections. Multi-region DR means a fully separate firewall instance per region, centrally managed via Firewall Manager, with Traffic Manager or Front Door steering traffic between them.
- Replication
- N/A
- RPO
- N/A — connectivity layer
- RTO
- Entirely dependent on your traffic-routing failover and how current the secondary firewall's policy is
- Failover trigger
- Manual (customer-triggered)
- Relative cost
- High cost premium
A fully separate Firewall instance — with its own hourly and data-processed charges — per region, centrally managed via Firewall Manager.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
Gotchas
A zonal deployment doesn't mean what it sounds like
"Zonal" in Azure Firewall's own terminology means pinned to one Availability Zone — the opposite of resilient. It's an intentional, API-only choice for capacity or latency reasons, not a lesser form of the default. If you see it in production without a documented reason, that's a finding.
Region-wide failure takes the firewall with it, policy and all
There's no cross-region replication for Firewall Policy or connection state. A second region needs its own firewall and, typically, its own policy management through Firewall Manager kept in sync deliberately — it doesn't happen by default.
Zone-redundant doesn't mean connection-preserving
Even in the default zone-redundant configuration, active connections routed through an instance in the failing zone are dropped and must be retried by the client. Applications behind Azure Firewall still need transient-fault handling, not just the firewall's own resiliency.