Methodology
Resiliency tiers
Each tier defines a single RPO/RTO threshold, in minutes. A service scope only meets a tier if both its RPO and RTO figures fit under that threshold. For how to decide which tier a workload actually needs, see choosing your tier.
| Tier | RPO / RTO | Profile |
|---|---|---|
| Tier 0 | 15 minutes | Mission-critical. Loss of service or data beyond 15 minutes is unacceptable. |
| Tier 1 | 1 hour | Business-critical. Significant business impact if unavailable for more than an hour. |
| Tier 2 | 6 hours | Important. Moderate business impact tolerated for up to 6 hours. |
| Tier 3 | 24 hours | Standard. Limited business impact tolerated for up to a day. |
| Tier 4 | 1 week | Low priority. Extended outage or data loss window is acceptable. |
How Pass / Risk / Fail is decided
For each redundancy option (Local, Zonal, or Regional), the tool compares the option's stated RPO and RTO — in minutes — against the selected tier's threshold, then checks how the option actually fails over.
Both RPO and RTO fit within the tier threshold, and failover is automatic with an SLA-backed or explicitly committed RPO. This is the only status that represents a platform guarantee rather than an operational dependency.
The numbers technically fit the tier, but something about how you get there isn't guaranteed — failover requires a human or a runbook to trigger it, or the RPO is "typical" rather than contractual. The tier threshold assumes the clock starts immediately; a manual trigger means it doesn't start until someone notices and acts, which most vendor RTO figures don't include.
The option's RPO or RTO numerically exceeds the tier threshold, even in the best case.
There is no fixed RPO/RTO for this option — it depends entirely on an architecture you'd have to design and build (e.g. a custom multi-region pattern). Treat this as "needs a design decision," not as a pass.
Relative cost signals
Every redundancy option also carries a relative cost signal — a comparison against the option below it in the same service, not a price. Azure pricing varies by region, SKU, commitment discount, and volume, and changes often enough that a specific dollar figure here would go stale faster than this catalog can be re-verified. The signal exists so a tighter tier can be weighed against what it actually costs to get there, not just whether it's technically achievable.
No extra cost over the option below it.
A modest premium — roughly under 25% on one dimension.
A real but partial premium — a pricier SKU tier, or roughly double on one dimension (e.g. storage only, not compute).
Essentially a full duplicate deployment — compute, storage, and networking together.
Keeping this current
Azure changes redundancy features, SLAs, and retirement timelines regularly — several entries in this catalog reflect changes from the past year (Storage's Geo-priority replication RPO guarantee, Service Bus's data-replicating Geo-Replication feature, Cosmos DB's Per-Partition Automatic Failover, and the Azure Cache for Redis retirement, among others).
See the content freshness page for every service sorted by how long ago it was checked.
Each service entry has a lastVerified date and a list of source URLs. Data lives as plain TypeScript objects in src/lib/services/*.ts — one file per service — so updating a figure is a normal code change: check the linked Microsoft Learn page, edit the relevant field, bump lastVerified, and commit.
This is a reference and starting point for a resiliency review, not a substitute for the current Azure SLA documents or Microsoft Learn.