Architect's Note: Many tutorials show you how to set up an Application Gateway, but they often miss the critical layer required for true regional failover: DNS Traffic Management. In this guide, I will walk you through deploying a robust Layer 7 routing solution and then protecting it with Azure Traffic Manager to ensure your site stays up even if the East US region goes down.

1. Virtual Network (VNet) and Subnet Creation

We begin by creating a resource group and the necessary VNet infrastructure in the East US region.

Pro Tip: Always oversize your Application Gateway subnet. We use a /27 here, but a /24 is safer for production. If you use a subnet smaller than /27, Azure V2 Gateways will fail to scale during traffic spikes.

1.1 Resource Group & VNet Details

  • Resource Group Name: projectresourceRG
  • Region: (US) East US
  • VNet Name: projectVnet
  • Address Space: 10.0.0.0/16
  • Subnets:
    • vmsub-1: 10.0.0.0/24 (Used for VMs, systems 1 & 2)
    • applicationsubnet: 10.0.1.0/27 (Strictly dedicated to App Gateway)
The applicationsubnet is crucial. Do not deploy any VMs or other resources into this subnet, or the Gateway deployment will fail.

2. Deploying & Configuring Web Servers (VMs)

Two Virtual Machines are deployed into the VNet, and the IIS Web Server role is installed on each to serve different content. Both VMs are located in the East US region for this primary cluster.

2.1 VM Deployment Details

  • VM Name: Vmsystem-1 and Vmsystem-2
  • Region: East US
  • Image: Windows Server 2019 or 2022 Datacenter (Gen2)
  • Subnet: vmsub-1 (10.0.0.0/24)
  • Public IPs:
    • Vmsystem-1: 172.174.xx.xx
    • Vmsystem-2: 20.120.xx.xx

2.2 IIS Configuration (Vmsystem-1)

Once connected via RDP, turn OFF the Internet Explorer Enhanced Security Configuration (IE ESC) to allow easier browsing during setup. Install the Web Server (IIS) role.

The content is configured in two directories:

  • Webpage Server: Content placed in C:\inetpub\wwwroot\webpage
  • Image Server: Content placed in C:\inetpub\wwwroot\image

3. Application Gateway V2 Setup

The Application Gateway serves as the single entry point, performing SSL termination and routing traffic to the correct web server based on the URL path.

3.1 Gateway Basics

  • Resource Group: projecttestappgateway
  • Region: East US
  • Tier: Standard V2 (Required for Autoscaling and Zone Redundancy)
  • VNet/Subnet: projectVnet / applicationsubnet

3.2 Frontends and Backends

  • Frontend IP: A new Public IP named public-projectronendip (e.g., 13.68.175.201).
  • Backend Pools:
    • pool-webpage (targets Vmsystem-1)
    • pool-image (targets Vmsystem-2)
  • Backend Setting: A common HTTP setting named serverhttp (Port 80).

4. Path-Based Routing Rules

A single routing rule, serversrule, is configured with a listener on Port 80 (HTTP) to direct traffic based on the URL path.

4.1 Rule Configuration

The rule uses Path-based routing to map incoming URLs to the correct backend pool:

  • Path 1: /webpage/* is routed to the pool-webpage.
  • Path 2: /image/* is routed to the pool-image.

5. Adding Geo-Redundancy (Azure Traffic Manager)

To make this solution truly "Geo-Redundant" as promised in the title, we cannot rely on a single region. We must add Azure Traffic Manager, a DNS-based load balancer that sits above the Application Gateway.

5.1 Traffic Manager Profile

  • Name: global-access-profile
  • Routing Method: Priority (Use this for Active-Passive failover) or Performance (to route users to the closest region).
  • DNS Name: cicdclouds-app.trafficmanager.net

5.2 Adding the Endpoint

Once the profile is created, we add our Application Gateway as an endpoint:

  • Type: Azure Endpoint
  • Target Resource Type: Public IP Address
  • Target Resource: Select the public-projectronendip IP created in Step 3.

Note: In a real production environment, you would repeat Steps 1-4 in a second region (e.g., West Europe) and add that second Application Gateway as a second endpoint here.

6. Troubleshooting & Cost Analysis

This section covers the real-world issues I encountered while building this lab.

6.1 Common Errors (502 Bad Gateway)

If you see a 502 Bad Gateway error after deployment, check these two things immediately:

  1. NSG Blocking: The Application Gateway subnet needs an NSG rule allowing inbound traffic on ports 65200-65535. This is required for Azure infrastructure communication. If you block this, the gateway status will turn "Unhealthy."
  2. Health Probes: App Gateway probes your backend VMs on the root path / by default. If your IIS server only has content at /webpage/ and returns a 404 for /, the Gateway will mark the backend as "Unhealthy." You must configure a Custom Health Probe to check /webpage/ specifically.

6.2 Cost Warning

Be aware: Application Gateway V2 is not free tier eligible. It costs approximately $0.25 to $0.30 per hour just to run, regardless of traffic. This adds up to ~$200/month. For learning purposes, ensure you delete the resource group immediately after you finish your validation.

7. Final Validation

After the deployment completes, the application is tested using the Traffic Manager DNS name (or the direct App Gateway IP):

// Routes traffic to the webpage server
http://cicdclouds-app.trafficmanager.net/webpage/Default.html

// Routes traffic to the image server
http://cicdclouds-app.trafficmanager.net/image/Default.html
Successfully deployed a scalable, geo-redundant web front-end where Traffic Manager handles the global DNS and App Gateway manages the regional path routing.