What is the most efficient regional platform design that supports the identified requirements?
Determine how workloads in the region will reach geographic hubs, shared platform services, application dependencies, other Azure regions, and hybrid environments. Those connectivity and dependency requirements determine which connectivity profile fits: Disconnected Spokes, Remote Hub Connected, Minimal Regional Hub, or Full Regional Hub.
Start with the matrix to see which connectivity profiles each archetype typically uses. Then apply the selection principles and use the decision tree to pick the most efficient profile that meets the requirements.
| Archetypes What applications require |
Disconnected spokes | Remote-hub-connected spokes | Minimal regional hub | Full regional hub | What drives the choice |
|---|---|---|---|---|---|
| 1Hybrid-Connected Applications | — | Typical | Typical | Typical | Dependency latency, resiliency, regulatory, operational, and shared-service requirements. |
| 2Isolated Cloud-Native or AI Applications | Often | Where justified | Where justified | Where justified | Often disconnected spokes. A connected profile where private management, security, data access, or centralized services justify connectivity. |
| 3Connected Cloud-Native or AI Applications | — | Typical | Typical | Typical | Private connectivity to selected dependencies; dependency latency, traffic patterns, resiliency, security, and operational requirements decide which profile. |
| 4Interconnected Application Portfolios | Spoke-to-spoke | Where acceptable | When justified | When justified | Aggregate portfolio connectivity, shared-service, resiliency, scale, and operational requirements. |
Profile selection principles#
- Start with the workload requirements and dependencies identified during regional qualification, including portfolio-level dependencies. Use Workload Landing Zone archetypes to spot recurring needs, then validate the profile against the actual workloads.
- Select the most efficient profile that satisfies those requirements, not the maximum possible one.
- Keep capabilities remote when latency, dependency, data, security, resiliency, availability, and operational requirements permit. Add local capabilities only when a measurable requirement justifies the larger regional footprint; adoption growth alone doesn't.
- Consider direct spoke-to-spoke connectivity where workloads have significant east-west traffic and a hub transit path is unnecessary. Add regional routing, inspection, or shared services when broader requirements justify them.
Which connectivity profile should this region provide?#
Each question comes from the "fits when" criteria of the connectivity profiles. Stop at the first profile that satisfies the requirements identified in check 3.
The same tree as a table, from the smallest regional footprint to the largest:
| Profile | Fits when the workloads expected in the region | What the region gets |
|---|---|---|
| Disconnected Spokes | Need no private access to enterprise services, on-premises systems, centralized security inspection, another application portfolio, or geographic-hub capabilities. | No hub and no gateway. Workload spokes use the estate's standard identity, policy, security, and deployment practices. |
| Remote Hub Connected | Need that access, and can tolerate the latency, availability coupling, and dependency on connectivity to another region. | No local hub. Workload spokes consume an existing geographic hub. |
| Minimal Regional Hub | Need some capabilities locally, without a comprehensive local set. | A limited hub with only the services that must be local. Everything else stays remote. |
| Full Regional Hub | Need a comprehensive local capability set, or independence from other hubs. | The complete local connectivity and shared services that the region's workloads require. |
Two of the four profiles need no local hub, and only the Full Regional Hub approaches the footprint of an existing geographic hub.
Select the most efficient regional platform connectivity profile that satisfies the identified requirements and can evolve as regional adoption changes.
Considerations and reassessment by profile#
Check these points before you settle on a profile, and revisit the profile when its reassessment trigger applies. Profiles can move in both directions.
Disconnected Spokes#
Validate administration, identity, DNS, secrets, telemetry, data movement, software distribution, private endpoints, incident response, and support procedures. Where applications require east-west communication within the region, evaluate direct spoke-to-spoke connectivity without assuming that a regional hub is required. Confirm that no hidden dependency requires connectivity to a geographic hub or on-premises environment.
Workloads require private access to enterprise services, centralized security inspection, on-premises systems, another application portfolio, or capabilities hosted through a geographic hub.
Remote Hub Connected#
Measure latency and bandwidth using representative traffic. Evaluate cross-region data-transfer cost, routing and transit behavior, inspection paths, geographic hub scale, dependency criticality, and operational ownership. Document how workloads behave if the geographic hub or cross-region connectivity is degraded or unavailable.
Cross-region traffic, latency, east-west communication, dependency criticality, regulatory requirements, scale, or availability coupling justify deploying selected connectivity or shared-service capabilities locally.
Minimal Regional Hub#
Clearly define which capabilities operate locally and which remain remote. Avoid ambiguous routing, overlapping responsibilities, and unnecessary duplication of platform controls. Validate workload and operational behavior when either local capabilities or remote dependencies are unavailable. When connectivity to on-premises environments is required, determine whether existing ExpressRoute circuits and gateway topology can provide the required reachability before introducing additional circuits; do not assume that each Azure region requires a dedicated ExpressRoute circuit.
Workload growth introduces additional local connectivity or shared-service requirements, multiple interconnected application portfolios require broader regional capabilities, stricter independence requirements emerge, significant hybrid connectivity is required locally, or other requirements justify expanding the regional platform footprint.
Full Regional Hub#
Confirm that the required level of independence justifies the additional cost and operational scope. Validate automation, observability, support ownership, security operations, configuration consistency, dependency behavior, and lifecycle management. Where on-premises connectivity is required, determine whether existing ExpressRoute circuits can provide the required reachability and resiliency before introducing additional connectivity.
Workload demand or requirements decrease, services can be safely centralized, dependencies change, or the full regional footprint no longer provides sufficient value relative to its cost and operational complexity.
What each step up costs#
Greater local capability and independence usually increase fixed platform cost and operational scope, but they can reduce cross-region dependencies, latency exposure, and availability coupling.
