A multi-region platform creates qualified regional options. Whether a specific workload uses more than one of those regions, and how, is a workload design decision.
This section isn't workload design guidance. The Azure Well-Architected Framework covers how to design a multi-region workload. This section covers the regional and service behaviors a platform team should understand when it qualifies regional combinations: region pairing is one input into resiliency design, not the definition of it, and cross-region behavior can differ significantly by service and regional combination.
Where workload design guidance lives#
- Using availability zones and regions — How to choose a single-region, zonal, or multi-region design for a workload.
- Architecture strategies for designing for redundancy — Multi-region deployment models, including active-active and active-passive.
- Design methodology for mission-critical workloads — The full multi-region active design for the most demanding workloads.
- Multi-region solutions in nonpaired regions — Service-by-service guidance for regions without a pair.
- Azure reliability service guides — Regional behavior for each Azure service.
In this section#
The articles in this section cover the dependencies that most often decide whether a regional combination works as built.
| Article | What it covers |
|---|---|
| Paired and nonpaired regions | What pairing provides, what it doesn't, and how region-of-choice designs shift responsibility for recovery. |
| Storage, backup, and Key Vault | Paired-region and region-of-choice behavior for three services that need special attention, and the recommended Key Vault pattern. |
| Resiliency scenarios | Three situations that show how service behavior changes a recovery design. |