Key Vault
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.
Standard/Premium vault (default)
Microsoft transparently replicates vault data within the region across fault domains — no configuration required or available.
- Replication
- Synchronous
- RPO
- 0
- RTO
- Near-instant — fully platform-managed
- Failover trigger
- Automatic
- Relative cost
- No extra cost
Baseline — Key Vault is billed per-operation, not per redundancy feature.
Built-in intra-region zone replication
In regions with Availability Zones, Microsoft automatically spreads replicas across zones. There is no separate SKU, toggle, or setting to enable or verify this — it's simply how the service behaves where AZs exist.
- Replication
- Synchronous
- RPO
- 0
- RTO
- Near-instant — fully platform-managed, not customer-observable
- Failover trigger
- Automatic
- Relative cost
- No extra cost
Built in, automatic, and not a separate SKU or line item.
You cannot confirm zone redundancy is active for a specific vault through the portal or API — it's implicit to the region.
Microsoft-managed failover to paired region (most regions), or a customer-built secondary vault
For vaults in most paired regions, Microsoft automatically replicates your vault's contents asynchronously to the paired region — no configuration needed. If Microsoft judges the primary region's outage to be prolonged, it may trigger a failover to that paired region on its own initiative. There's no customer-facing switch to trigger this yourself, and no way to opt out. Brazil South, Brazil Southeast, West US 3, and any region without a pair get none of this — for those, and for anyone whose RPO/RTO needs are tighter than this feature can promise, the fallback is the same as any other service without native cross-region DR: a second vault you build and sync yourself (backup/restore or app-side dual-write), with application config repointed to it.
- Replication
- Asynchronous
- 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.
- Failover trigger
- Microsoft-managed (rare, slow)
- Relative cost
- Low cost premium
The built-in paired-region replication has no extra cost. A fully customer-built secondary vault is cheap in Key Vault billing terms — the real cost is the engineering time to build and maintain the sync process.
After failover, the vault is read-only and only supports a limited operation set (list/get secrets, keys, and certificates; encrypt, decrypt, wrap, unwrap, sign, verify; backup) — you can't change vault properties, access policies, or firewall rules while running from the secondary region.
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
Microsoft decides if and when regional failover happens — you can't trigger it
The built-in paired-region failover is Microsoft-managed and best-effort: Microsoft's own docs describe it as likely occurring 'after a significant delay,' on a best-effort basis, and possibly out of step with the failover timing of other Azure services in the same incident. Don't budget an RTO around it — if you need a controlled, predictable failover, build your own secondary vault instead.
A failed-over vault is read-only with a short allow-list of operations
Once Microsoft fails your vault over to the paired region, you can read secrets/keys/certificates and use crypto operations (encrypt/decrypt/wrap/unwrap/sign/verify), but you can't write new values, change vault properties, or update access policies and firewall rules until failback. Plan for "read-only" as the real post-failover state, not "business as usual in a new region."
Brazil South, Brazil Southeast, West US 3, and nonpaired regions get none of this
Microsoft-managed cross-region replication and failover doesn't exist for vaults in these regions. If your vault lives in one of them, the only path to regional resiliency is a customer-built secondary vault — there's no built-in fallback to lean on.
Soft-delete isn't a DR feature
Soft-delete and purge protection (mandatory since 2020) protect against accidental or malicious deletion, not a region outage — don't count them toward your regional resiliency story.
HSM-backed key backups are geography-locked
Key backup/restore for Managed HSM and Premium HSM-backed keys only works within the same Azure geography — this constrains which region your secondary vault can realistically live in if you're relying on native backup/restore rather than re-generating keys.