Adding an Azure region shouldn't mean starting another landing-zone project. If you already run Azure landing zones, most of what a new region needs already exists: the governance, identity, policy, automation, and operating model.
What adding a region involves#
A new region is often assumed to be a large project. With this approach, it is a short series of decisions and a targeted change to the platform you already run.
| Common assumption | With this approach |
|---|---|
| A new region needs its own landing-zone design. | Reuse the existing landing zone. The region is added to the policies, automation, and monitoring you already run. See Framework overview. |
| Every region needs a full hub. | Start with the most efficient connectivity profile that meets the requirements. Two of the four profiles need no local hub. |
| Every region needs another ExpressRoute circuit. | Reuse existing hybrid connectivity where reachability and resiliency requirements allow. Add circuits only when a requirement justifies them. See Confirm hybrid connectivity. |
| Enabling a region means migrating workloads. | Nothing has to move. Workloads use the region when their own requirements call for it. See Place workloads. |
| Qualification is a long assessment. | It is four checks, each with one question, answered from what your teams already know. Unknowns are recorded and revisited, not treated as blockers. See Regional qualification. |
The first additional region takes the most thought, because the decisions are made for the first time. Later regions reuse those decisions and become mostly configuration. For more examples, see Common misconceptions.
How it works#
The framework has five parts. Each part answers one question.
- Understand concepts. What is a multi-region platform, what can a region provide, and what do applications need? Four connectivity profiles describe the platform options. Four Workload Landing Zone archetypes describe what applications require.
- Qualify regions. Can this region support the workloads we expect? Four checks lead to one of four outcomes: excluded, candidate, conditional, or qualified.
- Select the regional design. What should the platform provide in a qualified region? Make three choices from short lists: the connectivity profile, where each shared service is provided, and whether the hybrid connectivity you already have is reused. The region is then selected.
- Prepare the region. What has to exist before workloads arrive? Build only what the selected design calls for, through the automation you already run. Two of the four profiles need no hub. The region is then ready for workloads.
- Place workloads. Should this workload use the region now? Decide per workload, with current evidence. The region is then in use.
Tip
New to the framework? Getting started walks through the first additional region in six steps.
From a fixed pair to governed options#
A fixed regional pairTraditional model
Primary region
Workloads
Shared services
Hub & connectivity
DR region
Workloads
Shared services
Hub & connectivity
MIRRORED
Evolving regional conditions
Business expansionData boundaries
Service & AI availabilityLatency requirements
Works while demand and placement remain predictable; becomes less adaptable as conditions evolve.
Extend,
not
replicate
not
replicate
An adaptable multi-region platformRegions as qualified options
Region A
Workloads
Shared
Full hub
Region B
Workloads
Shared
Full hub
Region C
Workloads
Minimal hub
Region D
Spokes
↔ remote hub
Region E
Isolated spokes
Region F
CandidateStrategic hub
Strategic hub
Minimal hub
Remote hub
Disconnected
Not enabled
One consistent, governed Azure landing-zone foundation
Identity · Connectivity · Security · Management · Application delivery
Related resources#
- Framework overview: the drivers, principles, planning constructs, and adoption journey behind the five parts.