Stage 5 · Platform

SRE Patterns on Azure

Multi-Region AKS Architecture

Active-active and active-passive patterns, Azure Front Door, and Traffic Manager.

8 min readAzure Cloud EngineeringPlatform

Multi-Region Patterns

Multi-region architectures distribute workloads across Azure regions to achieve high availability, reduce latency for global users, and meet disaster recovery requirements. The choice between active-active and active-passive depends on your RTO/RPO targets.

Pattern	Complexity	Cost	RTO	Best For
Active-Passive	Lower	1.5x baseline	<5 min failover	Most workloads
Active-Active	Higher	2x baseline	Seconds (DNS)	Global low-latency
Active-Active-Active	Highest	2.5x baseline	Immediate	Mission-critical

Active-Passive

In active-passive, one region handles all traffic while the other stands by. If the primary fails, traffic is routed to the passive region. This is simpler and cheaper than active-active.

Deploy AKS in primary and secondary regions


# Primary cluster (East US)
az aks create \
  --resource-group rg-aks-primary \
  --name aks-payments-eastus \
  --node-count 3 \
  --network-plugin azure \
  --enable-managed-identity

# Secondary cluster (West US 2) — smaller for cost savings
az aks create \
  --resource-group rg-aks-secondary \
  --name aks-payments-westus2 \
  --node-count 2 \
  --network-plugin azure \
  --enable-managed-identity

In active-passive, the secondary cluster can be smaller since it only receives traffic during failover. Scale it up manually or via automation when a failover is triggered.

Active-Active

In active-active, multiple regions handle traffic simultaneously. Users are routed to the nearest healthy region. This provides the lowest latency and highest availability but requires data replication.

Active-active AKS deployment


# Deploy identical clusters in both regions
for REGION in eastus westus2; do
  az aks create \
    --resource-group "rg-aks-${REGION}" \
    --name "aks-payments-${REGION}" \
    --node-count 3 \
    --network-plugin azure \
    --enable-managed-identity \
    --location "$REGION"
done

# Configure geo-replication for the container registry
az acr replication create --registry craksprodeastus --location westus2
az acr replication create --registry craksprodeastus --location eastus

Active-active clusters must be identical — same node pools, same deployment, same configuration. Use GitOps (Flux/ArgoCD) to keep them in sync.

Azure Front Door

Azure Front Door is a global load balancer that routes traffic to the nearest healthy backend. It provides SSL termination, WAF protection, caching, and health probes.

Configure Azure Front Door


# Create a Front Door profile
az afd profile create \
  --resource-group rg-networking \
  --profile-name fd-payments-prod

# Create an origin group
az afd origin-group create \
  --resource-group rg-networking \
  --profile-name fd-payments-prod \
  --origin-group-name og-payments \
  --probe-path "/health" \
  --probe-request-method GET \
  --probe-interval-in-seconds 30

# Add origins (AKS public IPs)
az afd origin create \
  --resource-group rg-networking \
  --profile-name fd-payments-prod \
  --origin-group-name og-payments \
  --origin-name origin-eastus \
  --host-name payments-eastus.eastus.cloudapp.azure.com \
  --origin-host-header payments.contoso.com

az afd origin create \
  --resource-group rg-networking \
  --profile-name fd-payments-prod \
  --origin-group-name og-payments \
  --origin-name origin-westus2 \
  --host-name payments-westus2.westus2.cloudapp.azure.com \
  --origin-host-header payments.contoso.com

Front Door probes the /health endpoint every 30 seconds. If a region fails, it automatically routes traffic to the healthy region within seconds.

Traffic Manager

Azure Traffic Manager is a DNS-based load balancer. It routes traffic based on DNS responses, which means failover is faster (DNS TTL) but less precise than Front Door's HTTP-level routing.

Configure Traffic Manager


# Create a Traffic Manager profile
az network traffic-manager profile create \
  --name tm-payments \
  --resource-group rg-networking \
  --routing-method Priority \
  --unique-dns-name payments-contoso \
  --ttl 30

# Add endpoints
az network traffic-manager endpoint create \
  --name endpoint-eastus \
  --profile-name tm-payments \
  --resource-group rg-networking \
  --type azureEndpoints \
  --target payments-eastus.eastus.cloudapp.azure.com \
  --priority 1

az network traffic-manager endpoint create \
  --name endpoint-westus2 \
  --profile-name tm-payments \
  --resource-group rg-networking \
  --type azureEndpoints \
  --target payments-westus2.westus2.cloudapp.azure.com \
  --priority 2

Priority routing sends traffic to the lowest-priority endpoint. If it fails, traffic moves to the next priority. Set TTL to 30 seconds for faster failover.

Front Door vs Traffic Manager

Front Door operates at layer 7 (HTTP) and provides global anycast, WAF, and caching. Traffic Manager operates at layer 4 (DNS) and is simpler but less feature-rich. Use Front Door for web workloads, Traffic Manager for non-HTTP protocols.

AKS Fleet Manager

AKS Fleet Manager is a service for managing multiple AKS clusters across regions. It provides centralized management, consistent configurations, and orchestrated rollouts across your fleet.


# Register the Fleet Manager resource provider
az provider register --namespace Microsoft.ContainerService

# Create a fleet
az fleet create \
  --resource-group rg-fleet \
  --name fleet-payments-prod \
  --location eastus

# Add member clusters
az fleet member create \
  --fleet-name fleet-payments-prod \
  --resource-group rg-fleet \
  --name member-eastus \
  --cluster-resource-id "/subscriptions/{sub-id}/resourceGroups/rg-aks-primary/providers/Microsoft.ContainerService/managedClusters/aks-payments-eastus"

az fleet member create \
  --fleet-name fleet-payments-prod \
  --resource-group rg-fleet \
  --name member-westus2 \
  --cluster-resource-id "/subscriptions/{sub-id}/resourceGroups/rg-aks-secondary/providers/Microsoft.ContainerService/managedClusters/aks-payments-westus2"

Fleet Manager enables multi-cluster GitOps with Fleet API. Deploy the same manifests to all member clusters and track deployment status centrally.

Data replication is the hard part

Multi-region compute is straightforward — the challenge is data. Use Cosmos DB with multi-region writes, geo-redundant storage, or database-specific replication (PostgreSQL logical replication) for consistent data across regions.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.