Azure Geo-Redundant Application Gateway & Traffic Manager Guide 🌐

1. The Problem: Regional Boundaries & Blast Radiuses

In cloud native architecture, designing for high availability requires eliminating single points of failure at every infrastructure tier. An Azure Application Gateway v2 provides robust Layer-7 routing, SSL termination, and Web Application Firewall (WAF) inspection. Furthermore, deploying App Gateway v2 across Availability Zones protects workloads against datacenter-level hardware, cooling, and power outages within a single region.

However, an Application Gateway is strictly a regional resource. If a widespread fiber severance, natural disaster, or regional Azure control plane outage impacts an entire region (e.g., Central India), the Application Gateway and all dependent compute resources within that region become unavailable.

To achieve enterprise business continuity with near-zero Recovery Time Objectives (RTO), platform architects combine regional Application Gateways with an upstream global traffic routing layer—utilizing either Azure Traffic Manager (DNS-based routing) or Azure Front Door (Layer-7 Anycast reverse proxy).

2. Global Routing: Traffic Manager vs. Azure Front Door

Selecting the appropriate global routing mechanism depends on protocol requirements, caching demands, and failover latency:

3. Multi-Region End-to-End Traffic Flow

The architecture pairs two redundant Azure regions configured in an Active-Active or Active-Passive (Hot Standby) configuration:

[Global Client Request: https://app.cicdclouds.com]
                       │
         ┌─────────────┴─────────────┐
         ▼                           ▼
[Azure Traffic Manager (DNS)]  OR  [Azure Front Door (Edge POP)]
         │                                   │
         ├─────────────────┬─────────────────┤
         ▼ (Primary)       ▼ (Secondary)     ▼
┌──────────────────────┐ ┌──────────────────────┐
│  Region 1: Central   │ │   Region 2: South    │
│  App Gateway v2(WAF) │ │  App Gateway v2(WAF) │
│  (Zone 1, 2, 3)      │ │  (Zone 1, 2, 3)      │
└──────────┬───────────┘ └──────────┬───────────┘
           │                        │
     ┌─────┴─────┐            ┌─────┴─────┐
     ▼           ▼            ▼           ▼
[VMSS / AKS] [VMSS / AKS] [VMSS / AKS] [VMSS / AKS]
  (/api/*)     (/web/*)     (/api/*)     (/web/*)

1. DNS Resolution / Ingress: The client resolves app.cicdclouds.com via Azure Traffic Manager. Traffic Manager evaluates endpoint health probes and returns the Static Public IP of the nearest healthy Application Gateway.
2. Regional WAF Inspection: Inbound packets arrive at the Application Gateway v2. The OWASP Core Rule Set (CRS 3.2) inspects the payload for SQL injection, cross-site scripting (XSS), and malicious user agents.
3. URL Path-Based Routing: The gateway evaluates path routing rules: requests to /api/* are forwarded to backend API scale sets, while /* is directed to the frontend web tier.
4. Automated Health Monitoring & Failover: Traffic Manager continuously queries the /healthz probe endpoint on both gateways every 10 seconds. If the Central India gateway returns consecutive HTTP 5xx errors or connection timeouts, Traffic Manager dynamically removes the endpoint from DNS responses, shifting 100% of global traffic to South India.

4. Provisioning Infrastructure via Azure CLI

Step 1: Dedicated Subnet & Network Security Group (NSG) Rules

Azure Application Gateway v2 requires a dedicated subnet containing no other compute resources. The associated Network Security Group must explicitly permit Azure infrastructure management traffic, or the gateway will fail to provision:

# 1. Create Resource Group
az group create --name rg-cicdclouds-ha --location centralindia

# 2. Create Virtual Network and Dedicated Gateway Subnet
az network vnet create \
  --resource-group rg-cicdclouds-ha \
  --name vnet-centralindia \
  --address-prefix 10.10.0.0/16 \
  --subnet-name snet-appgw \
  --subnet-prefix 10.10.1.0/24

# 3. Create NSG and Permit Essential Inbound Ports
az network nsg create --resource-group rg-cicdclouds-ha --name nsg-appgw-central

# Rule: Permit Public Web Ingress
az network nsg rule create \
  --resource-group rg-cicdclouds-ha \
  --nsg-name nsg-appgw-central \
  --name Allow-HTTP-HTTPS-Inbound \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes Internet \
  --destination-port-ranges 80 443

# CRITICAL Rule: Permit Azure GatewayManager Infrastructure Communications
az network nsg rule create \
  --resource-group rg-cicdclouds-ha \
  --nsg-name nsg-appgw-central \
  --name Allow-GatewayManager-Inbound \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes GatewayManager \
  --destination-port-ranges 65200-65535

Step 2: Deploy Zone-Redundant Application Gateway WAF_v2

# 1. Create Zone-Redundant Static Public IP
az network public-ip create \
  --resource-group rg-cicdclouds-ha \
  --name pip-appgw-centralindia \
  --location centralindia \
  --allocation-method Static \
  --sku Standard \
  --zone 1 2 3 \
  --dns-name appgw-central-cicdclouds

# 2. Deploy Application Gateway WAF_v2 with Autoscaling
az network application-gateway create \
  --resource-group rg-cicdclouds-ha \
  --name appgw-centralindia \
  --location centralindia \
  --sku WAF_v2 \
  --capacity 2 \
  --zones 1 2 3 \
  --vnet-name vnet-centralindia \
  --subnet snet-appgw \
  --public-ip-address pip-appgw-centralindia \
  --frontend-port 80 \
  --http-settings-port 80 \
  --http-settings-protocol Http

Step 3: Configure Azure Traffic Manager for Global Failover

# 1. Create Traffic Manager Profile with Priority (Active-Passive) or Performance (Active-Active) Routing
az network traffic-manager profile create \
  --resource-group rg-cicdclouds-ha \
  --name tm-cicdclouds-global \
  --routing-method Priority \
  --unique-dns-name cicdclouds-ha \
  --path "/healthz" \
  --protocol HTTP \
  --port 80 \
  --ttl 30

# 2. Add Primary Regional Endpoint (Central India)
az network traffic-manager endpoint create \
  --resource-group rg-cicdclouds-ha \
  --profile-name tm-cicdclouds-global \
  --name ep-centralindia \
  --type externalEndpoints \
  --target "appgw-central-cicdclouds.centralindia.cloudapp.azure.com" \
  --endpoint-status Enabled \
  --priority 1

# 3. Add Secondary Regional Endpoint (South India Hot Standby)
az network traffic-manager endpoint create \
  --resource-group rg-cicdclouds-ha \
  --profile-name tm-cicdclouds-global \
  --name ep-southindia \
  --type externalEndpoints \
  --target "appgw-south-cicdclouds.southindia.cloudapp.azure.com" \
  --endpoint-status Enabled \
  --priority 2

5. Production Pitfalls & Troubleshooting Common 502 Errors

Deploying Application Gateway v2 in complex enterprise topologies frequently surfaces common networking bottlenecks:

1. The 502 Bad Gateway (Unhealthy Backend Target)

If Application Gateway displays a 502 error to client browsers, the gateway is reachable, but its custom health probes to backend VMs or container pods are failing.

• Root Cause 1: Host Name Mismatch: If your backend servers (such as NGINX or IIS) enforce virtual host headers, ensure your HTTP Settings have "Pick host name from backend target" enabled, or explicitly define the host name header in the probe.
• Root Cause 2: Backend NSG Blocking: The Network Security Group attached to the backend VM subnet must allow inbound traffic from the Application Gateway subnet CIDR block on port 80/443.
• Diagnostic Command:

  az network application-gateway show-backend-health \
    --resource-group rg-cicdclouds-ha \
    --name appgw-centralindia

2. Gateway Deployment Failure: Missing Ports 65200–65535

If the NSG on the Application Gateway subnet blocks TCP ports 65200-65535 from the GatewayManager service tag, the Azure control plane cannot perform health monitoring, certificate syncing, or capacity scaling. The gateway will fail to start or report an unrecoverable degraded status.

3. DNS TTL Caching Delays in Traffic Manager

Because Traffic Manager operates at the DNS layer, client browsers and recursive resolver ISPs cache DNS responses for the duration of the Time-To-Live (TTL). If TTL is left at default values (300 seconds), failovers can take up to 5 minutes. In high-availability configurations, always reduce your Traffic Manager probe interval to 10 seconds and set the DNS TTL to 30 seconds.