Skip to content

Region Expansion

How to decide whether to add an Azure region to the platform, and which one. The technical steps are in Add a region. This page is about the decision.

When to consider a new region

Typical triggers:

  • the current region has capacity constraints that affect deployments or availability,
  • a wish for better geographical redundancy or a disaster-recovery target,
  • data residency or latency requirements of a workload,
  • a service you need is not available in the current regions.

Criteria

Compare candidate regions on the same list. Use current Microsoft information for each.

Criterion Questions
Service availability and maturity Are the services you use available, now and on the roadmap? (Check the services your workloads use, for example Kubernetes, databases and the Application Gateway SKU.)
Capacity and growth Has the region shown capacity expansion, and is more planned?
Latency Latency inside the region and to your existing regions. Low cross-region latency matters for disaster recovery and for synchronous replication.
Redundancy Are availability zones available (three or more)? Is the region geographically independent enough from the existing ones to protect against a regional outage?
Network costs Data egress and cross-region transfer charges for the traffic you expect
Connectivity Quality of connectivity to your on-premises sites and to the internet
Platform cost A new virtual hub, firewall and gateways have a fixed monthly cost

Guidance

  • Add one region at a time, next to the existing ones, instead of replacing a region at once. This lets you move selected workloads gradually and keeps the cost down.
  • Place workloads in the new region when capacity and service requirements are met. Use it as a failover target only when it is independent enough from the others.
  • Keep firewall rules consistent across regions, so that a failover works. See Firewall rule organisation.
  • Allocate the address ranges from the IP plan before you start, and keep them free of overlap with other regions and spokes.
  • Choose the short region name with care. It is used in every resource name and in the state keys, and some resource names have a length limit (Naming and tags).

Consequences

Effect Detail
Cost A new virtual hub in the Virtual WAN with a firewall, DNS resolver and optional gateways. Possible cross-region data transfer costs for workloads that talk across regions.
Complexity Operating three regions is more complex than two: more routing, more rule sets, more places for drift
Routing Routing may need changes so traffic flows correctly, including to on-premises networks
Placement Gives you an additional place to put workloads

Example

One platform ran in two regions (a primary and a failover). Because of capacity constraints in the primary region and a wish for better redundancy, the team compared several candidate regions on the criteria above and chose one additional region with a central location, a recent capacity expansion, a broad service portfolio, three or more availability zones and roughly 10 to 15 ms latency to the primary region. It was added next to the existing regions, so workloads could move gradually. This is an example of the reasoning, not a recommendation for a particular region.