5.2 Azure Application Gateway Architecture & Routing

Azure Application Gateway Architecture & Routing

Azure Application Gateway is a dedicated, fully managed Layer 7 (Application Layer) Application Delivery Controller (ADC) and reverse proxy. Unlike Azure Load Balancer which routes packets at Layer 4 without inspecting application data, Application Gateway terminates incoming client TCP connections, evaluates HTTP/HTTPS request headers, hostnames, and URI paths, and makes intelligent routing decisions before proxying requests to backend targets.

Application Gateway delivers enterprise application delivery capabilities including SSL/TLS termination, cookie-based session affinity, URL path-based routing, multi-site hosting, URL and header rewrites, and integrated Web Application Firewall (WAF) protection.

1. Application Gateway v2 SKU Architecture & Sizing

The modern standard for Application Gateway is the v2 SKU (available as Standard_v2 and WAF_v2). The legacy v1 SKU (Standard and WAF) has been deprecated.

Subnet Requirements & Sizing Calculations

Application Gateway requires a dedicated subnet within your Virtual Network:

• No other Azure compute resources (such as standard VMs, App Service environments, or Azure Bastion) can reside inside the Application Gateway subnet.
• The subnet minimum size is /28 (16 total IP addresses, yielding 11 usable addresses).
• Recommended Enterprise Sizing: Allocate a /26 (64 total IPs) or /24 (256 total IPs) subnet. When autoscaling is configured, Application Gateway provisions internal virtual machine instances to handle load surges. A /28 subnet restricts maximum autoscaling capacity units during peak traffic spikes.

Autoscaling Capacity Units (CU)

Application Gateway v2 scales automatically based on Capacity Units (CU). A single Capacity Unit represents:

1. Compute Unit: Processing capability (CPU consumption per request/rule evaluation).
2. Persistent Connections: Up to 2,500 persistent connections per CU.
3. Throughput: Up to 2.22 Mbps of data transfer per CU.
4. TLS Offload: Up to 50 new SSL/TLS connections per second per CU (using RSA 2048-bit keys).

2. Frontend IP Configurations & Listeners

Incoming traffic enters Application Gateway through a Frontend IP Configuration and is evaluated by one or more Listeners.

Frontend Configurations

Application Gateway v2 supports:

• Public Frontend IP: Binds a static Standard Public IP address for Internet-facing web traffic.
• Private Frontend IP: Binds a private IP address from the gateway subnet for internal Intranet traffic.
• Dual Frontend: Concurrently binds both a Public IP and a Private IP to serve both external Internet users and internal corporate clients on distinct listeners.

Listener Types

A Listener checks for incoming connection requests matching a specific IP, port, protocol, and hostname:

+-----------------------------------------------------------------------------+
|                        LISTENER ARCHITECTURE TYPES                          |
|                                                                             |
|   1. BASIC LISTENER:                                                        |
|      Frontend IP (52.183.40.10) + Port 443                                  |
|      --> Accepts ALL incoming requests regardless of Host header            |
|                                                                             |
|   2. MULTI-SITE LISTENER (SNI & HOST HEADER ROUTING):                       |
|      Frontend IP (52.183.40.10) + Port 443                                  |
|      +---> Host: shop.contoso.com  --> Uses SSL Cert A --> Shop Rule        |
|      +---> Host: blog.contoso.com  --> Uses SSL Cert B --> Blog Rule        |
|      +---> Host: *.partner.com     --> Wildcard Cert C --> Partner Rule     |
+-----------------------------------------------------------------------------+

1. Basic Listener: Listens on a single port and IP. It accepts all incoming requests regardless of the HTTP host header. Typically used when Application Gateway hosts a single application or behind a dedicated load balancing domain.
2. Multi-Site Listener: Listens on a single public IP and port (e.g., 443) but routes traffic for multiple domain names (e.g., shop.contoso.com, finance.contoso.com, *.internal.contoso.com).
   • Uses Server Name Indication (SNI) during the TLS handshake to present the correct SSL certificate corresponding to the requested hostname.
   • Evaluates the HTTP Host: header to associate the request with the appropriate routing rule.
   • Supports exact hostnames and wildcard hostnames (e.g., *.contoso.com).

3. Routing Rules: Basic vs. Path-Based Routing

Routing rules bind a Listener to a Backend Pool and a set of Backend Settings (HTTP Settings).

Basic Routing Rules

A Basic Routing Rule forwards all traffic arriving at the associated listener directly to a single designated backend pool without inspecting URI paths.

Path-Based Routing Rules (URL Path Maps)

A Path-Based Routing Rule evaluates the URL path of the incoming request and routes to different backend pools and backend settings:

• Path Pattern Matching:
  • /images/* or /media/* $\rightarrow$ Routes to Image Storage / CDN Backend Pool.
  • /api/* or /auth/* $\rightarrow$ Routes to Microservices Container / VMSS Backend Pool.
  • /* (Default Path) $\rightarrow$ Routes unmatched traffic to Default Web App Backend Pool.
• Path Evaluation Precedence:
  1. Exact String Matches (e.g., /api/v1/health) are evaluated first.
  2. Longest Prefix Wildcard Matches (e.g., /api/v1/* takes precedence over /api/*).
  3. Default Backend Pool handles all requests that do not match any path rule.

4. Backend Pools & Backend Settings (HTTP Settings)

Supported Backend Pool Targets

A backend pool defines the collection of servers servicing incoming client requests. Application Gateway supports heterogeneous backend target types:

• IPv4 / IPv6 IP Addresses: Virtual machines in the same VNet, peered VNets, or on-premises datacenters reachable via VPN or ExpressRoute.
• Fully Qualified Domain Names (FQDN): Public or private domain endpoints.
• Azure App Services: Multi-tenant Azure App Services and Azure Functions.
• Virtual Machine Scale Sets (VMSS): Auto-registered VMSS network interfaces.

Backend Settings (HTTP Settings / Backend HTTP Configuration)

Backend settings control how Application Gateway proxies the connection from the gateway to the backend instances:

+-----------------------------------------------------------------------------+
|                        BACKEND SETTINGS MECHANICS                           |
|                                                                             |
|   Client ====== (HTTPS 443) ======> [ Application Gateway ]                 |
|                                            |                                |
|   Backend Settings Parameters:             | (Proxy Connection)             |
|   - Backend Protocol: HTTP or HTTPS        |                                |
|   - Cookie-Based Affinity: ARRAffinity     |                                |
|   - Connection Draining: 300 seconds       v                                |
|   - Request Timeout: 60 seconds      [ Backend Target ]                     |
|   - Pick Host Name from Backend Address (App Service FQDN matching)         |
+-----------------------------------------------------------------------------+

5. TLS Termination & End-to-End TLS Encryption

Application Gateway provides enterprise SSL/TLS offloading and full cryptographic compliance across its proxy architecture.

+-----------------------------------------------------------------------------+
|                   TLS TERMINATION vs. END-TO-END TLS ENCRYPTION             |
|                                                                             |
|   1. TLS TERMINATION (SSL Offloading):                                      |
|      Client === (HTTPS / Encrypted) ===> [ App Gateway ] === (HTTP / Plain) ===> [ Backend VMs ]
|      (Reduces CPU overhead on backend VMs; unencrypted inside VNet)         |
|                                                                             |
|   2. END-TO-END TLS ENCRYPTION:                                             |
|      Client === (HTTPS / Encrypted) ===> [ App Gateway ] === (HTTPS / Encrypted) ===> [ Backend VMs ]
|      (Gateway decrypts for WAF/routing inspection, then re-encrypts)        |
+-----------------------------------------------------------------------------+

1. TLS Termination (SSL Offload)

• Client sends HTTPS traffic to Application Gateway.
• Application Gateway decrypts the traffic using its frontend SSL certificate.
• The gateway routes the decrypted plaintext HTTP traffic to backend servers over private VNet subnets.
• Advantage: Eliminates cryptographic overhead on backend compute instances.

2. End-to-End TLS Encryption

• Required for stringent regulatory standards (PCI-DSS, HIPAA, FedRAMP) where plaintext transmission inside the cloud perimeter is prohibited.
• Application Gateway terminates the initial client TLS session, performs Layer 7 inspection and WAF rule processing, and then establishes a second, independent TLS session to the backend instance.

Certificate Management in Application Gateway v2

• Frontend Certificates: Stored securely in Azure Key Vault. Application Gateway uses a User-Assigned Managed Identity to poll Key Vault for certificate updates, enabling automatic SSL certificate renewal without downtime.
• Backend Authentication Certificates:
  • If the backend uses certificates signed by well-known public Certificate Authorities (CAs) (e.g., DigiCert, Let's Encrypt), no certificate upload to Application Gateway is required.
  • If the backend uses certificates signed by an internal Enterprise Private CA, the public Root CA or Intermediate CA certificate (.cer format) must be uploaded to the Backend Settings as a Trusted Root Certificate.
  • SNI / Host Header Validation: The Common Name (CN) or Subject Alternative Name (SAN) on the backend certificate must match the host name configured in the Backend Setting (or overridden via Pick host name from backend address).

6. URL Rewrite & HTTP Header Modifications

Application Gateway v2 can dynamically rewrite HTTP request and response headers, as well as rewrite URI paths and query strings, before packets reach the client or backend.

Common Rewrite Use Cases

1. Security Header Injection: Automatically inject security response headers such as Strict-Transport-Security (HSTS), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Content-Security-Policy.
2. Sensitive Header Stripping: Remove backend information headers such as Server: Microsoft-IIS/10.0 or X-Powered-By: ASP.NET to prevent server fingerprinting.
3. URL Path Manipulation: Transparently rewrite legacy client URLs (e.g., /v1/products?id=42) to modern microservice endpoints (e.g., /api/v2/catalog/42) without issuing an HTTP 301/302 redirect.
4. Client IP Identification: Inject or preserve headers such as X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port so backend services identify the true client public IP.