Azure Functions
Resiliency here is entirely a function of which hosting plan you pick. The (legacy) Consumption plan has no Availability Zone support at all, full stop — the only fix is migrating to Flex Consumption, Premium, or Dedicated. Those three do support zone redundancy, but — unlike Container Apps — it isn't a one-time, creation-only choice on Flex Consumption or Dedicated; it can be toggled on an existing plan (Microsoft's own docs disagree on whether that's also true for Premium). Functions itself is a stateless compute host: its real RPO/RTO comes from the host storage account behind it (must be ZRS to matter) and whatever your function code talks to.
Non-zone-redundant plan (the only option on Consumption; the default elsewhere)
Function app instances run without zone spread. This is the only configuration the Consumption plan offers — it has no Availability Zone support at all. It's also the default on Flex Consumption, Premium, and Dedicated (App Service) plans unless you explicitly enable zone redundancy.
- Replication
- None
- RPO
- N/A — Functions is a stateless compute host; any real RPO comes from the host storage account and whatever services your function code talks to
- RTO
- Not committed by Microsoft for a zone-level event. Microsoft's own guidance: without zone redundancy, 'your plan might experience downtime during an outage in any zone in the region' — no recovery-time figure is given. Individual crashed instances/processes are auto-restarted by the platform as ordinary transient-fault handling, separate from zone protection.
- Failover trigger
- N/A
- Relative cost
- No extra cost
Baseline — same per-instance/execution pricing whether or not zone redundancy is later enabled.
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 deployment (Flex Consumption, Premium, or Dedicated only)
On Flex Consumption and Premium plans, enabling zone redundancy spreads plan instances across all Availability Zones in the region, with a platform-enforced minimum of 2 always-ready instances. On Dedicated (App Service) plans, Functions inherits App Service's own zone-redundancy model (Premium v2–v4 tiers, minimum 2 instances). The Consumption plan has no zone-redundancy option — Microsoft's guidance is to move to one of the other three plans if this is required. In every case the function app's host storage account must also use zone-redundant storage (ZRS); otherwise 'your app might behave unexpectedly during a zone outage' even though compute is spread across zones.
- Replication
- None
- RPO
- 0 — the compute layer holds no state to lose. If the host storage account uses ZRS (required for this to actually work), Azure Storage replicates that data synchronously across zones too.
- RTO
- Microsoft describes 'brief interruptions that typically last a few seconds' while connections reroute to instances in healthy zones — but this isn't a committed figure. Microsoft explicitly states it does not guarantee that replacement instances for the lost zone's capacity actually get created ('the platform attempts to backfill lost instances on a best-effort basis... doesn't guarantee success'); its own mitigation advice is to overprovision always-ready instances.
- Failover trigger
- Automatic
- Relative cost
- Low cost premium
No separate per-feature charge, but zone redundancy enforces a minimum instance floor — 2 always-ready instances per function/group on Flex Consumption (which also blocks scale-to-zero), or minimumElasticInstanceCount=2 per app on Premium — so idle or lightly-used apps see a real bill increase even though the per-instance rate is unchanged.
Not a one-time, creation-only choice like Container Apps. Flex Consumption plans can have zone redundancy turned on or off on an existing plan via the portal (Scale and Concurrency > Zone redundancy) or CLI (`az functionapp plan update --set zoneRedundant=true`) — though the change forces an app restart and downtime. Elastic Premium plans can also be toggled on an existing plan, but Microsoft's own docs are inconsistent about this: the dedicated 'Configure Zone Redundancy' how-to (with explicit CLI steps) says the `zoneRedundant` property 'is mutable, so you can toggle availability zone support without creating a new plan,' while the 'Reliability in Azure Functions' page says the opposite — 'you can enable zone redundancy only during plan creation. You can't convert an existing Premium plan.' Verify directly against the CLI/portal for your target plan rather than trusting either page alone. On Flex Consumption specifically, zone redundancy forces at least 2 always-ready instances per function/group, so a zone-redundant Flex Consumption app can never scale to zero.
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.
Independent function app(s) in a second region + Front Door/geo-DR event source (customer-built)
Functions is a single-region service: 'If the region becomes unavailable, your Functions resource is also unavailable,' with no built-in cross-region failover. Microsoft documents two customer-built patterns instead of providing one: active-active for HTTP-triggered functions (Azure Front Door round-robins and health-checks function apps deployed in multiple regions), and active-passive for non-HTTP triggers (a secondary region's function app sits idle until an event source with geo-disaster-recovery — e.g. Service Bus or Event Hubs — fails over its alias to that region). You own deploying to every region, routing/health-checking traffic, wiring the failover mechanism, and keeping data consistent.
- Replication
- N/A
- RPO
- Entirely dependent on the backing services (event source, storage, database) behind the function app — Functions itself holds no durable state to lose
- RTO
- Entirely dependent on your own failover architecture and, for the active-passive pattern, on the failover time of whatever event source drives the switch (e.g. Service Bus/Event Hubs geo-disaster recovery)
- Failover trigger
- Automatic
- Relative cost
- High cost premium
A fully duplicated function app (and plan) in a second region, plus Front Door/Traffic Manager, and — for the active-passive pattern — geo-disaster-recovery-enabled Service Bus/Event Hubs namespaces spanning both regions.
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
Consumption plan has zero Availability Zone support — and it isn't coming
Microsoft's reliability docs are unambiguous: 'Consumption plans don't support availability zones. If zone redundancy is a requirement for your workload, consider using the Flex Consumption, Premium, or Dedicated (Azure App Service) plans instead.' There's no roadmap item to add it — the Consumption plan is now positioned as legacy in favor of Flex Consumption. If a workload on Consumption needs zone resiliency, the only path is migrating plans, not waiting for a feature flag.
Zone-redundant compute means nothing if the host storage account isn't ZRS too
The host storage account holds function code, host metadata, logging, and (for many trigger types) the blob leases used for concurrency management. Microsoft's guidance is explicit: if that storage account isn't configured for zone-redundant storage (ZRS), 'your app might behave unexpectedly during a zone outage' — even though your compute instances are correctly spread across zones. This is easy to miss because the zone-redundancy toggle lives on the plan/app, not on the storage account.
Microsoft's own docs disagree on whether Premium plan zone redundancy is a one-time choice
'Reliability in Azure Functions' states Premium plan zone redundancy 'can only [be enabled] during plan creation' and that an existing plan can't be converted. The dedicated 'Configure Zone Redundancy for Azure Functions' how-to says the opposite, with working CLI/Bicep/ARM steps: the `zoneRedundant` property 'is mutable, so you can toggle availability zone support without creating a new plan' (CLI/ARM/Bicep only — not the portal). Don't plan a migration strategy around either claim without confirming directly against the CLI for the specific plan in question.
Zone-redundant Flex Consumption apps can never scale to zero
Enabling zone redundancy forces at least 2 always-ready instances per function/scaling group, which are billed continuously (baseline meter) even when idle, on top of execution costs. An app that was previously idle most of the time and relied on scale-to-zero billing will see a real, ongoing cost increase the moment zone redundancy is turned on — this isn't a one-time setup cost, it's a permanent floor.
Backfilling lost zone capacity is best-effort, not guaranteed
During a zone outage, Functions 'attempts to locate or create replacement instances in the healthy zones' but 'doesn't guarantee success.' If your workload needs a specific instance count to hold its SLA, Microsoft's own recommendation is to overprovision always-ready instances ahead of time — the platform will not backfill on demand with any guarantee.
Cold start after scale-to-zero is a real RTO factor Microsoft doesn't quantify
On Consumption and on Flex Consumption apps without always-ready instances (including any non-zone-redundant Flex Consumption app, since zone redundancy is what forces the 2-instance floor), 'apps can scale to zero when idle, meaning some requests might have more latencies at startup.' No specific cold-start duration or RTO figure is published — budget for it as an unbounded, unquantified factor rather than assuming a number.