Which regions can support the identified workload requirements?
Evaluate each candidate region against the workload requirements identified in check 3. Consider required Azure services, deployment models and SKUs, availability-zone support, regional service dependencies, latency, pricing, expected scale, regional access, and quota requirements.
Availability zones and region pairing#
Assess availability-zone support and region pairing separately. Prefer zone-enabled regions when zone resiliency is required, but do not assume that region pairing alone provides workload recovery or that a nonpaired region cannot be used as a recovery destination. Validate service-specific capabilities such as replication, backup and restore, and other regional dependencies against the resiliency requirements identified for the workload.
For requirements that depend on multiple regions, validate the intended regional combination at the service level. This includes built-in paired-region behavior such as Storage GRS and region-of-choice capabilities such as Azure SQL replication. Record material gaps, required changes, and owners for unresolved validation. For detailed design, see Service behavior across regions.
Prefer zone-enabled regions where they meet workload requirements.
Consider both paired and nonpaired options.
…that a paired region provides workload recovery.
…that a nonpaired region cannot support it.
Regional access and quota#
Validate whether the intended subscription and offer types can deploy in the region, and identify any regional access restrictions or approvals that must be resolved before deployment. Assess required quota based on expected workload scale and identify any quota increases that may be required.
Important
Quota should not be treated as an indication or guarantee of Azure capacity, which remains subject to availability at deployment time.
Evidence-based evaluation#
Where possible, evaluate objective regional characteristics programmatically, using the requirements above as inputs. The resulting assessment should identify candidate regions, unmet requirements, conditional constraints, and items that require additional validation. Use manual review for considerations that cannot be determined reliably from published or programmatically available information.
- Required services and SKUs
- Zone requirements
- Latency targets
- Pricing considerations
- Expected scale
- Access eligibility and quota
If a requirement that could materially affect regional suitability is unresolved, keep the region conditional until it is validated. Evaluate requirements that do not affect regional qualification later, during workload onboarding or reassessment.
Qualify candidate regions against identified workload requirements, documenting conditions, constraints, and unresolved validations while preserving viable options for future workloads.
Reference links#
- Azure region pairs and nonpaired regions
- Azure services that support multiple regions
- Azure services that support availability zones
- Zonal resources and zone resiliency
- Enable zone resiliency for Azure workloads