Multi-Region Architectures in Azure

When to use multi-region

Multi-region architecture adds significant cost and operational complexity. It is not appropriate for every workload. Apply it when:

• Your SLA requires 99.99% or higher availability and you need to survive region-level failures.
• Regulations require data copies to be maintained in geographically separate locations.
• Your users are distributed globally and latency to a single region is unacceptable for some of them.
• Your RTO is measured in seconds or minutes — a cold standby that takes hours to warm up does not meet the requirement.

For most internal tools, development environments, and moderate-SLA applications, availability zones within a single region are sufficient and far cheaper to operate.

Active-active vs active-passive

The two fundamental multi-region patterns differ in whether the secondary region serves live traffic.

Active-active runs identical infrastructure in two or more regions simultaneously. Azure Front Door routes each user to the nearest healthy region. Both regions accept reads and writes. The data layer must handle concurrent writes — typically via Cosmos DB multi-region writes, or a primary-write architecture where both regions write to the same logical primary but readers go local.

Active-passive (warm standby) runs full infrastructure in the primary region and a scaled-down but functional copy in the secondary. The secondary is continuously synchronised but does not serve traffic. When the primary fails, Front Door or Traffic Manager switches traffic to the secondary. Warm standby typically achieves RTO of 5–15 minutes. Cold standby, where infrastructure in the secondary must be provisioned at failover time, has RTO measured in tens of minutes to hours.

Routing traffic with Azure Front Door

Azure Front Door is a global application delivery network that operates at Layer 7 (HTTP/HTTPS). It uses Microsoft’s private backbone network to route requests to backends, performing anycast routing so that each request enters Microsoft’s network at the edge point closest to the user. This reduces latency significantly compared to DNS-based routing because the user’s TCP connection terminates at the edge, not at the origin.

Front Door supports three routing methods relevant to multi-region architectures: priority routing (active-passive), latency routing (active-active to the nearest region), and weighted routing (canary deployments between regions).

# Create an Azure Front Door profile (Standard tier)
az afd profile create \
  --resource-group myRG \
  --profile-name myFrontDoor \
  --sku Standard_AzureFrontDoor

# Add an endpoint
az afd endpoint create \
  --resource-group myRG \
  --profile-name myFrontDoor \
  --endpoint-name myEndpoint

# Add an origin group with two regional backends
az afd origin-group create \
  --resource-group myRG \
  --profile-name myFrontDoor \
  --origin-group-name myOriginGroup \
  --probe-request-type GET \
  --probe-protocol Https \
  --probe-interval-in-seconds 30 \
  --probe-path /health \
  --sample-size 4 \
  --successful-samples-required 3

# Add primary region backend (priority 1)
az afd origin create \
  --resource-group myRG \
  --profile-name myFrontDoor \
  --origin-group-name myOriginGroup \
  --origin-name primary-eastus \
  --host-name myapp-eastus.azurewebsites.net \
  --priority 1 \
  --weight 1000

# Add secondary region backend (priority 2 — only used if primary fails)
az afd origin create \
  --resource-group myRG \
  --profile-name myFrontDoor \
  --origin-group-name myOriginGroup \
  --origin-name secondary-westeurope \
  --host-name myapp-westeurope.azurewebsites.net \
  --priority 2 \
  --weight 1000

Data replication across regions

Replicating data across regions is the most architecturally challenging part of multi-region design. The right approach depends on your consistency requirements and whether you need writes to be accepted from both regions simultaneously.

Azure Cosmos DB is the cleanest solution for multi-region write scenarios. You configure one or more write regions and Cosmos DB handles conflict resolution using last-write-wins (by timestamp) or a custom conflict resolution procedure. With the bounded staleness consistency level, reads are guaranteed to be no more than a configurable number of updates or time window behind. With strong consistency, reads reflect all prior writes but latency increases with region distance.

# Add a second write region to an existing Cosmos DB account
az cosmosdb update \
  --name myCosmosAccount \
  --resource-group myRG \
  --locations regionName=eastus failoverPriority=0 isZoneRedundant=true \
                regionName=westeurope failoverPriority=1 isZoneRedundant=true \
  --enable-multiple-write-locations true

Azure SQL Database geo-replication creates up to four readable secondary replicas in other regions. Replication is asynchronous — the primary commits the transaction locally and then replicates it, so there is a replication lag measured in seconds. The secondary is readable, which you can use to offload reporting queries.

# Create a geo-replica of an Azure SQL Database
az sql db replica create \
  --name myDatabase \
  --resource-group myRG \
  --server myPrimaryServer \
  --partner-resource-group mySecondaryRG \
  --partner-server mySecondaryServer \
  --partner-database myDatabaseReplica

Azure Storage geo-redundant storage (GRS) asynchronously replicates blob data to a paired region. The secondary is read-accessible only after a Microsoft-initiated failover, unless you configure read-access GRS (RA-GRS). For zone and region redundancy together, use GZRS (geo-zone-redundant storage).

Keeping application tiers stateless

Multi-region architectures work far more smoothly when application instances are stateless. Stateless instances do not hold user session data locally — instead, session state is externalised to a shared cache (Azure Cache for Redis) or database that is itself replicated. Any instance in any region can handle any request without needing to know which region the user previously hit.

Azure Cache for Redis Enterprise supports active geo-replication across regions. Session data written in East US is automatically replicated to West Europe with sub-second lag. If East US becomes unavailable, the West Europe instance has a consistent copy of all session state and users experience no loss of session.

Testing failover before you need it

A multi-region architecture that has never been tested is an untested assumption. Azure Chaos Studio can inject regional failures in a controlled manner, allowing you to observe whether Front Door actually routes traffic, whether your application handles the transition gracefully, and whether the secondary region’s infrastructure scales up to handle full traffic load.

At minimum, run a quarterly drill: deliberately force traffic to the secondary region, verify that the application functions correctly, verify that writes are being accepted and replicated, and then fail back to the primary. Document any issues found and address them before they become production incidents.

Real-world scenario: global API platform

A financial services company runs a REST API consumed by mobile apps in North America and Europe. The API must maintain 99.99% availability and comply with GDPR data residency rules for European users.

The architecture uses Azure Front Door with latency-based routing between an East US origin and a West Europe origin. European users route to West Europe; North American users route to East US. Both regions run identical App Service environments behind Application Gateway.

The data layer is Cosmos DB with multi-region writes enabled and two write regions. European user data is tagged with a partition key that maps to the West Europe region; North American data maps to East US. Custom conflict resolution logic in a stored procedure handles the rare case of concurrent updates to the same record. This satisfies GDPR by ensuring European user data primarily resides in European infrastructure while still allowing the global replication that enables disaster recovery.