Service catalog

IaaS compute. Resiliency is entirely a function of how many instances you run and where you place them — a single VM has no failover story at all.

The AKS SLA only ever covers the Kubernetes API server, never your workloads. There is no native multi-region failover for a cluster — cross-region resilience is a fully custom architecture.

Zone redundancy requires Premium v2/v3+ and a minimum instance count. There is no native regional failover feature — multi-region App Service is Front Door/Traffic Manager plus a second, independently deployed app.

Zone redundancy is a one-time choice made at environment creation — you can't enable or disable it later, and the SLA doesn't change either way. A fully managed, serverless container host with no durable state of its own and no native cross-region failover.

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.

Redundancy is set per storage account via the SKU (LRS/ZRS/GRS/GZRS). Geo-redundant tiers replicate to the paired region, but write access after a regional outage requires a failover you trigger yourself.

Disk redundancy (LRS/ZRS) is a separate, explicit choice made on the disk SKU itself — it has nothing to do with which zone the attached VM is deployed in. A VM spread across Availability Zones can still be sitting on a disk that's pinned to a single zone.

Zone-redundant HA (Premium/Business Critical/Hyperscale) is synchronous and near-instant. Cross-region continuity via auto-failover groups is asynchronous and, per Microsoft's own guidance, should be triggered by you — not left to the 'automatic' policy.

The best-positioned data service in this catalog for tight RPO/RTO — but only if you explicitly enable Per-Partition Automatic Failover (PPAF). The default 'service-managed failover' setting most teams reach for can take an hour or more to trigger.

Every SKU of this service (Basic, Standard, Premium) is retiring on September 30, 2028, in favor of Azure Managed Redis — any resiliency plan built today should target the replacement service. Geo-replication here has no guaranteed recovery point.

Control plane and compute both spread across zones automatically, but losing a cluster's driver node restarts the whole cluster and its running job — zone redundancy doesn't remove that. Classic and Hybrid are the same workspace type under two different names; Serverless is a genuinely different one, with its own compute plane, its own storage, and no VNet for you to get wrong. No native multi-region capability; Databricks' own managed disaster recovery is a distinct, opt-in feature, not something every workspace gets.

Zone-redundant HA is synchronous with zero data loss and automatic failover in 60-120 seconds — but same-zone HA, a separately-named and identically-priced option, offers the same automatic failover mechanics while never leaving the zone, so it doesn't survive a zone outage at all. Cross-region continuity is read replicas only: asynchronous, with unbounded replication lag, and Microsoft is explicit that promotion is always customer-triggered, even during a declared regional outage. There is no auto-failover-group equivalent for PostgreSQL Flexible Server.

In-region resiliency (including zone spread, where supported) is fully automatic and not user-configurable. Most paired regions also get built-in, Microsoft-managed asynchronous replication and best-effort failover to the paired region — but Microsoft decides if and when to trigger it, it can take hours, and the vault comes back read-only with a limited operation set. Brazil South, Brazil Southeast, West US 3, and any nonpaired region don't get this at all — there, and wherever the built-in option's RPO/RTO isn't tight enough, you build and maintain a second vault yourself.

The legacy Geo-DR feature — still what most existing docs and architectures reference — replicates namespace metadata only, not messages. The newer Geo-Replication feature (Premium) replicates message data too, but promotion is always customer-triggered.

Zone redundancy is automatic and transparent on Standard/Premium/Dedicated. Cross-region DR (Dedicated/Premium only) replicates namespace metadata only — unlike Service Bus, there is no message-data-replicating alternative.

Load Balancer and Application Gateway are regional services — zone resiliency only. Azure Front Door is the actual cross-region failover mechanism for HTTP(S) traffic, via automated health-probe-based routing.

Zone-redundant gateway VMs are automatic on eligible SKUs — Azure explicitly states you don't need to initiate or validate zone failover. A gateway is always a single-region resource, though: regional DR means deploying independent gateways yourself.

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.

The StandardV2 SKU is zone-redundant by default; the older Standard SKU is a zonal resource pinned to one Availability Zone (or, if you skip zone selection, a nonzonal placement Azure picks for you — the weakest option). The zone configuration is locked in at creation and can't be changed afterward. Like other networking appliances, it's single-region with no native cross-region failover.

An NSG's rule set is control-plane configuration, not a running instance — it's synchronously replicated across every zone in the region automatically, with nothing to configure or verify. Microsoft doesn't publish a dedicated SLA for it, the same way it doesn't for Virtual Network itself. Cross-region means an entirely separate NSG with its own rules, kept in sync by you.

The general-purpose recovery mechanism behind most other services in this catalog. Backup gives point-in-time restore (RPO = policy schedule); Site Recovery gives a continuously-replicating standby with orchestrated, still-manual failover. Neither is fast enough for Tier 0/1 on its own.

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.