Use this sequence to establish the first additional regional options. Start with one candidate region and the workloads that need it. The same process scales to a broader portfolio, and later regions reuse the decisions made for the first.
- Name the drivers. Identify what is prompting the discussion: business growth, regulation, service or SKU availability, resiliency, a datacenter or connectivity event, cost, or another measurable requirement. See common drivers.
- Understand the concepts. Learn how a multi-region platform differs from a multi-region workload, the four connectivity profiles a region can provide, and the four Workload Landing Zone archetypes that describe what applications need. You make no decisions here. You learn the terms the next steps use.
- Shortlist and qualify candidate regions. Work through the four qualification checks. Start with the two that need no technical assessment, business and geography and data and compliance, and remove regions that cannot satisfy mandatory conditions. For the regions that remain, identify workload requirements and dependencies, then validate regional capability and availability. Record each option as excluded, candidate, conditional, or qualified for the defined requirements, with evidence and revalidation triggers. See Assessment outcome.
- Select the regional design. For each qualified region, select the most efficient connectivity profile that meets the requirements, decide where each shared service is provided, and confirm whether the hybrid connectivity you already have is enough. Write the three choices into the regional design record, and agree who owns each decision.
- Prepare the region. Build what the record says, through the automation you already run. Read only the page for the profile you selected: Disconnected Spokes, Remote Hub Connected, Minimal Regional Hub, or Full Regional Hub. Use the platform readiness checklist to confirm the region is ready before the first workload arrives.
- Place the first workload. Apply the workload-placement process using current evidence. Revalidate regional capabilities at decision time, govern the placement and resiliency decisions, and feed newly discovered requirements or platform gaps back into regional qualification.
Tip
What success looks like: Being able to qualify a regional option, enable only the platform capabilities it requires, and onboard workloads through a repeatable governed process.
Related resources#
- Regional qualification decision tree
- Using availability zones and regions in the Azure Well-Architected Framework