Three-Tier Web App (PaaS)

RPO 0 for the app tier itself·RTO Seconds to minutes — automatic instance rerouting across zones

RPO Entirely dependent on the backing data store(s) behind the app — App Service itself holds no state to lose·RTO Routing failover: tens of seconds to a couple of minutes once configured — but keeping the second region's code, config, and secrets in sync is your CI/CD pipeline's job, not a platform feature

RPO 0·RTO Well under a minute — typically low seconds for Business Critical

RPO Typically ~5 seconds under normal load — not a hard guarantee, and lag can grow under heavy write volume·RTO Seconds once triggered for a clean (no-data-loss) failover — but only after you detect the outage and initiate it

RPO 0·RTO Effectively 0 — reads/writes continue through a zone loss; some DNS repointing may briefly affect in-flight requests

RPO ≤15 min, SLA-backed — but only for Block Blobs. Files/Tables/Queues/Page Blobs replicate best-effort with no committed RPO·RTO Reads: near-0, automatic, 99.99% SLA on the RA- secondary endpoint. Writes: failover process plus DNS update, typically under an hour once triggered

RPO N/A — routing layer·RTO Seconds — automatic

RPO N/A — routing layer only; the RPO for your application still depends entirely on the data tier behind each backend·RTO Probe-interval driven — typically well under a minute once a backend is marked unhealthy

RPO 0·RTO Near-instant — fully platform-managed, not customer-observable

RPO Not zero, and not committed — replication to the paired region is asynchronous, so changes made shortly before a region failure can be lost. Microsoft publishes no RPO number for this feature.·RTO Not customer-controlled and not committed — Microsoft's own guidance says failover 'can take several hours after the loss of the primary region, or longer,' and isn't necessarily aligned with when other Azure services in the region fail over. Your vault may just be unavailable until Microsoft acts.