Application Gateway: Layer 7

Application Gateway is Azure’s regional HTTP/HTTPS load balancer. Unlike Azure Load Balancer (Layer 4), Application Gateway understands HTTP — it can route based on URLs, host headers, and cookies.

🎬 Video coming soon

Application Gateway Components and Routing

Application Gateway Components and Routing

~13:00

Component Flow

Traffic flows through Application Gateway in this order:

Client
  ↓
Frontend IP (public or private)
  ↓
Listener (port + protocol + hostname)
  ↓
Routing Rule (basic or path-based)
  ↓
HTTP Settings (backend port, protocol, affinity, timeout)
  ↓
Backend Pool (VMs, VMSS, App Service, IPs)
  ↓
Health Probe (checks backend health)

Component details:

Component	Purpose	Options
Frontend IP	IP that clients connect to	Public IP, private IP, or both
Listener	Listens on a port/protocol for incoming requests	Basic: single site on a port. Multi-site: multiple hostnames on the same port (Host header routing).
Routing rule	Maps listener to backend	Basic: all traffic to one backend pool. Path-based: different URL paths to different pools (e.g., /images/* to pool A, /api/* to pool B).
HTTP settings	Defines how AG talks to the backend	Backend port, protocol (HTTP/HTTPS), cookie affinity, connection draining, request timeout, hostname override
Backend pool	Target servers	VMs, VMSS, App Services, IP addresses, FQDNs
Health probe	Checks backend health	Custom path, interval, unhealthy threshold, match conditions

Multi-Site Listeners

A single Application Gateway can host multiple websites using multi-site listeners:

Listener	Hostname	Backend Pool
Listener 1	app.pinnacle.com	Pool-App
Listener 2	api.pinnacle.com	Pool-API
Listener 3	portal.pinnacle.com	Pool-Portal

All three share the same frontend IP and port (443). The listener matches the Host header to route to the correct backend.

Path-Based Routing

Path-based routing sends different URL paths to different backend pools:

Path Rule	URL Pattern	Backend Pool
Rule 1	/images/*	Pool-Static (storage-optimised VMs)
Rule 2	/api/*	Pool-API (compute-optimised VMs)
Default	/* (everything else)	Pool-Web (general web servers)

🏢 Ravi’s scenario: Pinnacle Financial’s web application serves static images, an API, and web pages. Path-based routing lets Ravi optimise each backend pool independently — more CPU for the API, more storage for images.

Scaling

Mode	How It Works	Best For
Manual	You set a fixed instance count (1-125)	Predictable traffic, cost control
Autoscale	Set minimum and maximum instance count; AG scales based on traffic	Variable traffic, spiky workloads

Autoscale is recommended for production. You set min=2 (for HA) and max=125. Application Gateway scales within these bounds based on concurrent connections, throughput, and compute utilisation.

TLS Configuration

TLS termination (TLS offload):

• Client connects to AG over HTTPS (port 443)
• AG decrypts the traffic (using your certificate)
• AG forwards to backend over HTTP (port 80)
• Reduces backend CPU load; AG handles certificate management

End-to-end TLS:

• Client connects to AG over HTTPS
• AG decrypts, inspects (for routing and WAF), then re-encrypts
• AG connects to backend over HTTPS
• Backend must have its own certificate
• Required when compliance mandates encryption in transit at every hop

Certificate management:

• Upload PFX certificates to Application Gateway directly
• Or reference certificates stored in Azure Key Vault (recommended — centralised, auto-renewal)

ℹ️ Rewrite Rules

Rewrite rule sets modify HTTP headers and URL paths on requests and responses:

Common uses:

• Remove server headers (security: don’t expose backend server type)
• Add security headers (HSTS, X-Content-Type-Options)
• Redirect HTTP to HTTPS
• Modify request URLs before forwarding to backend
• Add/remove/modify cookies

Configuration:

• Create a rewrite rule set
• Add conditions (match on headers, URL, query string)
• Add actions (set, delete, or append headers; rewrite URL)
• Associate with routing rules

Rewrite rules are processed in order. You can have multiple rule sets associated with different routing rules.

When to Use Application Gateway vs Load Balancer

Application Gateway vs Azure Load Balancer

Feature	Application Gateway	Azure Load Balancer
OSI layer	Layer 7 (HTTP/HTTPS)	Layer 4 (TCP/UDP)
URL path routing	Yes — route /api/* and /images/* to different backends	No — routes by IP and port only
Host header routing	Yes — multi-site listeners for multiple domains	No
TLS termination	Yes — offloads TLS and supports end-to-end TLS	No — passes through encrypted traffic
WAF integration	Yes — built-in WAF v2 SKU available	No
Cookie affinity	Yes — cookie-based session affinity	Source IP affinity only (tuple hash)
Non-HTTP traffic	No — HTTP and HTTPS only	Yes — any TCP or UDP protocol
Scope	Regional only	Regional (cross-region available with global tier)

Rule of thumb: If your application uses HTTP/HTTPS and needs URL routing, TLS termination, or WAF — use Application Gateway. For non-HTTP protocols (databases, custom TCP services) — use Load Balancer.

Key Takeaways

• Application Gateway is a Layer 7 (HTTP/HTTPS) regional load balancer
• Multi-site listeners route based on Host header; path-based rules route by URL
• TLS termination offloads encryption; end-to-end TLS re-encrypts to backend
• Autoscale (min 2, max 125) is recommended for production
• Use AG for HTTP workloads; LB for non-HTTP or pure Layer 4

---

Test Your Knowledge

Question

What is path-based routing in Application Gateway?

Click or press Enter to reveal answer

Answer

Routing rules that send different URL paths to different backend pools. For example, /api/* goes to API servers and /images/* goes to storage-optimised servers. A default rule catches everything else.

Click to flip back

Question

What is the difference between TLS termination and end-to-end TLS?

Click or press Enter to reveal answer

Answer

TLS termination: AG decrypts HTTPS and forwards HTTP to backend (no encryption to backend). End-to-end TLS: AG decrypts, inspects, re-encrypts, and forwards HTTPS to backend (encrypted at every hop).

Click to flip back

Question

How do multi-site listeners work?

Click or press Enter to reveal answer

Answer

Multiple listeners share the same frontend IP and port (typically 443). Each listener matches a specific hostname from the Host header and routes to a different backend pool. This hosts multiple websites on one Application Gateway.

Click to flip back

Question

What is the recommended scaling mode for production Application Gateway?

Click or press Enter to reveal answer

Answer

Autoscale with minimum 2 instances (for HA) and maximum up to 125. AG scales based on concurrent connections, throughput, and CPU utilisation.

Click to flip back

---

Knowledge Check

Ravi's web application has three components: /api/*, /static/*, and general pages. Each needs different backend servers. Which Application Gateway feature should he use?

AMultiple Application Gateways — one per componentBPath-based routing rules with different backend poolsCMulti-site listeners with different hostnamesDWeighted load balancing across all servers

Check Answer

Knowledge Check

Aisha's compliance team requires encryption at every hop, including between Application Gateway and backend servers. What TLS mode should she configure?

ATLS termination — it encrypts everything automaticallyBEnd-to-end TLS — AG re-encrypts traffic to the backendCNo TLS — use IPsec between AG and backends insteadDClient-side TLS only — backends don't need certificates

Check Answer

---

Next up: Azure Front Door: Global Delivery — Global HTTP load balancing with CDN, WAF, and Private Link origins.