API Management
Zone and region redundancy exist only in the Premium tier — every other tier (Consumption, Developer, Basic, Basic v2, Standard, Standard v2, and even Premium v2) has no way to survive a zone or region outage beyond the automatic two-VM-per-unit redundancy every tier gets. And even Premium's 'multi-region' feature only replicates the gateway: the management plane and developer portal stay pinned to the primary region and go down with it, and Premium v2 doesn't offer multi-region at all.
Non-zone-redundant instance (Consumption, Developer, Basic, Basic v2, Standard, Standard v2, or Premium/Premium v2 without AZs enabled)
The default for every tier below Premium, and for Premium/Premium v2 instances that haven't enabled availability zones. Each 'unit' of gateway capacity is already backed by two compute resources behind the scenes — Microsoft's platform automatically manages and health-checks them — but that redundancy stops at a single datacenter. There's no zone or region protection at this level under any configuration.
- Replication
- None
- RPO
- N/A at this scope — no zone/region replication exists to lose. Developer/Basic/Standard/Premium (classic) tiers support an optional customer-triggered configuration backup/restore, but that's a manual snapshot, not continuous replication — your RPO is whenever you last ran a backup.
- RTO
- Not published as a number. Recovery from a single underlying compute-resource failure within a unit is automatic and platform-managed; recovering from anything larger (datacenter/zone loss) means restoring from a manual backup, if your tier supports it, or rebuilding the instance.
- Failover trigger
- Automatic
- Relative cost
- No extra cost
Baseline tier pricing (Consumption/Developer/Basic/Basic v2/Standard/Standard v2) — no redundancy premium built in.
Developer tier carries no SLA at all — Microsoft's SLA document states this explicitly. Basic v2, Standard v2, and Premium v2 additionally dropped the backup/restore feature entirely, so even the manual-snapshot fallback isn't available on those SKUs.
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.
Availability Zone support (Premium or Premium v2 only)
Premium (classic) and Premium v2 are the only tiers that can spread gateway units — and, in-region, the management plane and developer portal too — across Availability Zones. 'Automatic' (recommended) lets the platform best-effort spread your units across zones with no minimum unit count; manually picking specific zones ('zone-redundant') requires your unit count to divide evenly across the zones you choose. A 'zonal' config that pins everything to one explicit zone is a separate, unprotected option — see gotchas.
- Replication
- Asynchronous
- RPO
- Gateway configuration (APIs, policies) typically propagates between zones in under ~10 seconds — not an SLA commitment, just documented typical behavior. The internal cache and rate-limit counters are not fully protected: cache data isn't guaranteed to persist through a zone loss, and rate-limit counters may be out of date on the surviving zones afterward.
- RTO
- No downtime expected for automatic or zone-redundant configurations — the platform detects a zone failure and reroutes traffic to the remaining zones on its own, including for single-unit instances (whose compute resources are already split across two zones). In-flight requests connected to the failed zone are dropped and must be retried by the client.
- Failover trigger
- Automatic
- Relative cost
- High cost premium
Zone redundancy itself isn't a separate line item, but it's exclusive to the Premium/Premium v2 tier — a substantial price jump over Basic/Standard just to unlock it — plus whatever extra units you add for real failure headroom.
Only Premium and Premium v2 can do this — Consumption, Developer, Basic, Basic v2, Standard, and Standard v2 cannot enable Availability Zones under any configuration. Capacity backfill into a healthy zone during an outage is best-effort, not guaranteed — Microsoft recommends over-provisioning units if you need guaranteed headroom during a zone loss.
Multi-region deployment (Premium classic only — gateway component only)
Adds regional gateway units in additional Azure regions to an existing Premium (classic) instance; Premium v2 doesn't support multi-region at all as of this writing. Only the gateway is replicated — the management plane (where you author APIs and policies) and the developer portal live solely in the original primary region, in every configuration, with no option to relocate or duplicate them.
- Replication
- Asynchronous
- RPO
- Gateway configuration typically propagates to every region in under ~10 seconds — not SLA-backed. Rate-limit counters and the internal cache are region-local and are never replicated between regions at all, by design.
- RTO
- No gateway downtime is expected — API Management detects a regional failure and automatically routes traffic to gateways in the surviving regions, which keep serving the most recently synced configuration. But if the primary region itself goes offline, the management plane and developer portal become unavailable and stay that way until the primary region recovers — Microsoft publishes no RTO for that part, and there is no way to push configuration changes or use the developer portal from a secondary region during the outage.
- Failover trigger
- Automatic
- Relative cost
- High cost premium
Each additional region needs its own paid scale units, priced the same as the primary region's — effectively a second region's worth of Premium unit cost for gateway coverage only.
This is availability for API traffic, not full active-active DR: you can't author or publish API/policy changes, and the developer portal is dark, for as long as the primary region is down. Plan your primary-region choice and your incident runbook around that gap, not around 'multi-region means everything keeps working.'
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
Multi-region deployment doesn't cover the management plane or developer portal — only the gateway
Microsoft's own docs are explicit: 'If the primary region goes offline, the API Management management plane and developer portal become unavailable. However, secondary regions continue to serve API requests by using the most recent gateway configuration.' A regional outage in your primary region means you can't change APIs or policies, and the developer portal is down, until that region recovers — even though API traffic keeps flowing. Don't mistake 'multi-region' for 'everything survives.'
Premium v2 cannot do multi-region at all
Only the Premium (classic) tier supports multi-region deployment. Premium v2 supports Availability Zones but, per Microsoft's reliability documentation, 'doesn't currently support multiregion deployments.' If you migrate from classic Premium to Premium v2 for its other benefits, you silently lose the multi-region DR story unless you check for this first.
The v2 tiers dropped backup/restore entirely
Microsoft's tier feature comparison shows Backup and restore is supported on Developer, Basic, Standard, and Premium (classic) — but not on Basic v2, Standard v2, or Premium v2. If you're on any v2 tier, there's no built-in configuration backup/restore path at all; your only DR option is reconstructing configuration from your own IaC/APIOps source of truth.
Below Premium, there's no zone or region redundancy under any configuration
Consumption, Developer, Basic, Basic v2, Standard, and Standard v2 cannot enable Availability Zones or multi-region deployment — period, not a paid add-on you're missing. Developer tier compounds this by carrying no SLA whatsoever, per Microsoft's SLA document: 'No SLA is provided for the Developer tier of the API Management Service.'
A 'zonal' (pinned-to-one-zone) Premium config isn't zone redundancy
Premium lets you manually pin an instance to a single explicit Availability Zone, typically to cut cross-zone latency. Microsoft's docs warn: 'By itself, a zonal instance doesn't provide resiliency to an availability zone outage.' If that zone fails, your instance is down until the zone recovers, and — unlike automatic or zone-redundant configurations — you're responsible for detecting the failure and manually rerouting traffic to a separate instance you've built in another zone.