Multi-region platform Architecture Guidance
Multi-region platform / Service behavior across regions

Storage, backup, and Key Vault across regions

October 2, 2026 · 4 min read

Storage replication, backup and restore, and Key Vault illustrate why regional qualification cannot stop at "the service exists in both regions."

Storage#

Paired-region options

  • Geo-redundant storage options such as GRS and GZRS replicate data asynchronously to the service-defined secondary region.
  • Built-in geo-redundancy and failover behavior must be evaluated separately from workload-level recoverability.

Region-of-choice options

  • Object replication can asynchronously replicate block blobs between selected storage accounts and regions.
  • It requires change feed on the source and blob versioning on source and destination accounts.
  • Object replication does not support append blobs, page blobs, or accounts with hierarchical namespace enabled.
  • A source account can currently replicate to no more than two destination accounts.

Important

Replicated data does not by itself make the workload recoverable. Validate the application recovery path end to end.

Backup and restore#

Paired-region capabilities

  • Azure Backup Cross Region Restore uses the Azure paired region for supported data sources when the required vault replication and configuration are enabled.
  • Support and behavior differ by backup workload and configuration.

Region-of-choice capabilities

  • Determine which backup technologies and restore targets support the intended recovery region.
  • Azure Site Recovery supports Azure VM disaster recovery between Azure regions, subject to its support matrix and regional restrictions.
  • Restricted-access regions can require explicit access approval.

Important

Demonstrate RTO and RPO through recovery testing, not configuration alone.

Key Vault#

Paired-region behavior

  • In most paired regions, Key Vault asynchronously replicates vault contents to the paired region.
  • Microsoft-managed regional failover is Microsoft initiated, best effort, and can occur only after significant delay; after failover, the vault operates with restrictions, including read-only management behavior. Workloads with tighter recovery objectives need an explicit multi-region design.
  • Some paired regions and all nonpaired regions do not use this Microsoft-managed cross-region replication and failover model. For the current list, see Reliability in Azure Key Vault.

Region-of-choice designs

  • Where built-in failover does not meet workload requirements, use separate regional vaults or another supported custom multi-region design.
  • Keys, secrets, and certificates each require their own recovery analysis. Secrets and certificates can often be provisioned independently into regional vaults through controlled deployment processes. Cryptographic keys, particularly customer-managed keys, can have additional constraints and should not be assumed to be reproducible by the same process.
  • Azure Managed HSM provides an optional two-region replication model with both regions active. It applies to keys, not to ordinary Key Vault secrets and certificates; not every region can serve as an extended region, and it has its own cost considerations.

Important

Key Vault is often a runtime dependency. Applications can require keys, secrets, and certificates simply to initialize, so data can be recoverable while the application still cannot start.

Independent Key Vault per workload per region. For workloads that require controlled region-of-choice recovery, design the runtime dependency so that each active or recovery region has the Key Vault capability it needs before failover is required.

  • Independent regional vault. Each workload uses the vault associated with its local region rather than depending at runtime on a vault hosted in another region.
  • Deploy configuration consistently. Infrastructure as code should consistently provision vault configuration, access controls, private connectivity, monitoring, and policy. Use an approved secret-management or deployment process to populate the required secrets and certificates in each regional vault; do not treat the IaC repository itself as a store for secret values.
  • Do not make failover the synchronization strategy. Populate and validate required runtime dependencies before an outage. Recovery should not depend on creating or restoring a regional vault after the primary region has already failed.
  • Design cryptographic keys separately. Select an appropriate key-resiliency pattern, such as supported Key Vault backup and restore constraints, Managed HSM multi-region capabilities, or another workload-specific design, based on security and recovery requirements.

Next step#

Resiliency scenarios