A multi-region platform and a multi-region workload operate at different layers. The platform creates governed regional choices for the customer estate; the workload applies one or more of those choices to a specific workload. Keeping these concepts separate prevents multi-region strategy from being treated as an automatic requirement for a new landing zone, workload migration, active-active high availability, or active/passive disaster recovery.
The city analogy#
Think of the platform as a city, and workloads as the people and businesses that live in it. The city builds neighborhoods, services, roads, transit, and laws once. A family settles in one neighborhood; a bank spreads across several. Neither builds a new city.
The household: a single-region workload
Most workloads live in one neighborhood: the one that fits how they live.
- Commutes to the office every day (hybrid-connected) picks Hillcrest, for transit plus the express lanes.
- Works fully remote and is self-sufficient (isolated) picks Lakeside; off-grid is fine.
- Works remote but relies on city services (connected) picks Midtown, one transit ride from the hospital.
- Extended family, always visiting (interconnected portfolio) picks Riverside, with local services for a close-knit group.
The bank: a multi-region workload
Some workloads need several neighborhoods, for reach and for resilience.
- Headquarters and core systems stay on the office campus: on-premises.
- Express lanes through two interchanges, so one can close: ExpressRoute with circuit diversity.
- Branches in Riverside and Midtown serve customers together: active-active.
- A backup operations center in Hillcrest stands by: active/passive recovery.
- Banking licenses and secure vaults on top of city law: compliance and specialized SKUs.
| In the city | In Azure |
|---|---|
| Neighborhoods | Azure regions |
| Transit between neighborhoods | Connectivity between regions |
| Express toll lanes | ExpressRoute |
| Office campus outside the city | On-premises |
| Police, fire, hospitals, utilities | Shared services |
| Laws, codes, zoning | Governance and policy |
Platform and workload layers#
| Multi-region platform | Multi-region workload | |
|---|---|---|
| Purpose | Enable placement flexibility across qualified Azure regions | Meet workload-specific objectives and requirements such as availability, disaster recovery, user proximity, or regulatory requirements |
| Focus | Regional readiness and consistency of shared platform capabilities | Application architecture, data, dependencies, traffic, availability, and recovery |
| Design driven by | The needs of the portfolio of workloads the platform is expected to support | The specific workload's requirements, such as availability, resiliency, RTO/RPO, latency, or data requirements |
| Outcome | Additional regions qualified through the existing landing-zone operating model, approved connectivity patterns, deployment automation, and quota planning | Net-new placement in another region, selective relocation, active/passive recovery, active-active distribution, or continued operation in one region |
Reuse the existing Azure landing-zone operating model by default. Extend regional policy parameters, connectivity, shared services, automation, and operations only where documented workload requirements justify them. A multi-region platform doesn't require a separate connectivity landing zone or identical shared services in every region; workload requirements determine the cross-region design.