Application delivery services

Choosing the service

How to read a question:

• HTTP(S) in one region, WAF, path-based routing is Application Gateway.
• HTTP(S) across regions with failover, caching, acceleration is Front Door.
• Non-HTTP protocols (SQL, RDP, game UDP) with a global requirement is cross-region Load Balancer or Traffic Manager.
• DNS-based, no proxying, works for any protocol, slower failover is Traffic Manager.
• Combine: Front Door (global) in front of Application Gateway (regional WAF) in front of backends. Or Traffic Manager across regional Application Gateways.

Azure Load Balancer

SKU and tier

Choose Standard always. Tiers of Standard: Regional (frontend in one region) and Global (cross-region).

• Public vs internal: a public load balancer has a public IP frontend and handles internet traffic. An internal (private) load balancer has a private IP in a subnet for east-west or on-premises-reachable traffic (for example a database tier).
• Regional vs cross-region (Global tier): the cross-region LB has a global-tier public IP that is an anycast address. It routes to the closest healthy regional Standard public load balancer (geo-proximity), with fast failover. It supports TCP/UDP only and preserves the client IP. Its home region hosts the resource. Backend must be regional public Standard LBs. Use it when non-HTTP traffic needs global distribution.

Components

Load balancing rules

• Distribution mode: default is a 5-tuple hash (source IP/port, destination IP/port, protocol). Source IP affinity uses a 2-tuple (client IP + destination) or 3-tuple (adds protocol) to keep a client on the same backend (session persistence).
• HA ports rule: protocol “All”, port 0. Load balances all TCP/UDP flows on every port in one rule. Internal Standard LB only. Used for NVA high availability.
• Floating IP (Direct Server Return): the backend receives packets with the frontend IP as the destination. Required for SQL Always On availability group listeners and some clustering. Requires the VM guest OS to accept the IP (loopback).
• TCP idle timeout: 4 minutes by default, up to 30. TCP reset on idle can be enabled. Keep-alives help for long-lived idle connections.
• Multiple frontends can share a backend with different rules.
• Health probe behaviour: a failed probe stops new flows to that instance. Existing flows persist (unless the instance shuts down). If all instances fail probes, Standard LB stops all new flows to the pool.
• Port-reuse and sessions: Load Balancer doesn’t terminate TCP or inspect HTTP. It passes packets through with a hash.

Inbound NAT rules

• V1 rules map one frontend port to one VM. V2 rules (used with scale sets) map a port range across the backend pool, so each instance gets its own frontend port automatically.
• A single backend VM can have more than one NAT rule. Inbound NAT rules and load balancing rules can’t use the same frontend IP and port.
• Prefer Azure Bastion to inbound NAT for management. It avoids exposing RDP or SSH.

Outbound connectivity and SNAT

• Backend instances use SNAT to reach the internet. Each frontend public IP provides 64,000 SNAT ports (allocated per backend instance by pool size). Exhaustion shows up as failed or slow outbound connections to the same destination.
• Outbound rules (Standard) define which frontend IPs to use, manual SNAT port allocation per instance, and idle timeout. This needs a separate public frontend or outbound-only frontend.
• Best practice for scale and predictability is NAT Gateway, which takes precedence over outbound rules. Default outbound access is being retired for new VNets.
• Don’t mix outbound rule logic with a NAT gateway on the same subnet and expect the LB’s outbound rule to apply: the NAT gateway wins.

Gateway Load Balancer

Gateway Load Balancer inserts third-party NVAs (firewalls, IDS, DPI) transparently in the path of a Standard Load Balancer or public IP, with no UDRs and no SNAT. The consumer’s frontend is chained to the gateway LB. Packets are encapsulated with VXLAN and sent to the NVA pool, then returned. Use it for bump-in-the-wire inspection at scale and for NVA high availability across subscriptions. It uses an internal Standard LB with a Gateway SKU/tier, tunnel interfaces (internal and external) and provider and consumer sides.

Traffic Manager

Traffic Manager is DNS-based global traffic distribution. It returns the DNS name of a healthy endpoint, based on the routing method. It doesn’t proxy traffic, so clients connect straight to the endpoint (any protocol works).

• Endpoints: Azure endpoints (App Service, public IP, cloud service), external (any FQDN, IP) and nested (another profile, to combine methods, for example performance across regions then weighted within).
• Health monitoring: HTTP, HTTPS or TCP probe on a path and port, interval 10 s (fast) or 30 s, timeout, and tolerated failures (0–9). Expected status code ranges are configurable.
• TTL matters for failover. Lower TTL means faster failover and more DNS queries. Failover isn’t instant: clients cache DNS.
• Traffic Manager is a zone apex challenge: it uses CNAME, so at the apex use an Azure DNS alias record.
• Real User Measurements and Traffic View improve Performance routing and show user distribution.

Azure Application Gateway

A regional layer 7 load balancer and reverse proxy, with optional WAF.

SKU and sizing

• Use v2 (Standard v2 or WAF v2). v1 retired on 28 April 2026. v2 adds autoscaling, zone redundancy, static VIP, faster provisioning, header and URL rewrite, mutual TLS (client certificate authentication) and Key Vault integration.
• Manual: fixed instance count (1–125). Autoscale: a minimum (can be 0 for cost saving) and maximum (up to 125) instance count that follows load, billed by capacity units. Choose manual only for a stable, predictable load or when you can’t tolerate scale-out delay. Set a sensible minimum for burst traffic.
• Needs a dedicated subnet (no other resource types). Use /24 for v2 so it can reach 125 instances. NSG rules: allow GatewayManager 65200–65535 (v2) inbound, AzureLoadBalancer, the client ports (80/443) and outbound to backends.
• Application Gateway for Containers is the newer layer 7 option for AKS (Gateway API), separate from the classic gateway.

Request path

Client → frontend IP (public, private, or both) → listener → routing rule → backend settings → backend pool (with health probe).

Listeners

• Basic listener: one site per port and IP.
• Multi-site listener: routes by host name (host header), allows many sites on one gateway, with wildcards in host names. Each HTTPS listener has its own certificate.
• Protocol HTTP or HTTPS, port, frontend IP. Custom error pages can be set per listener.

Routing rules

Rules can also redirect (HTTP to HTTPS, to another listener or an external site, permanent 301 or temporary 302/307/308). Rule priority is required in v2 (lower number is evaluated first, 1–20000).

Backend pools, backend (HTTP) settings and probes

• Backend pool: IPs, FQDNs, NICs, VMSS, App Service, on-premises targets. A pool can have mixed types.
• Backend (HTTP) settings: protocol and port to the backend, cookie-based affinity (gateway-managed cookie), connection draining, request timeout (default 20 s), override host name (important for multi-tenant App Service and Front Door-style backends), path override, and the custom probe to use.
• Health probe: default probe uses the backend settings’ protocol and port, path /, 30 s interval, 30 s timeout, unhealthy threshold 3, and treats 200–399 as healthy. A custom probe sets host, path, interval, timeout, thresholds and match conditions (status code range, body text), and can pick the host from the backend settings. Unhealthy servers are removed from rotation. If all are unhealthy, the gateway still sends requests to the pool (fail-open) and may return 502.

TLS

• TLS termination (offload): the gateway holds the certificate (PFX, or a Key Vault secret via a user-assigned managed identity) and speaks plain HTTP to the backend. Cheaper for backends.
• End-to-end TLS: re-encrypts to the backend (HTTPS in backend settings). v2 needs a trusted root certificate for the backend cert (unless it chains to a well-known CA) and the backend certificate’s CN/SAN must match the host name or override. Required when the whole path must be encrypted (compliance).
• TLS passthrough isn’t available on the classic L7 listener. A TCP/TLS proxy (layer 4) feature exists in preview.
• SSL policy: pick a predefined or custom policy with a minimum TLS version (current default is TLS 1.2). mTLS: the listener can require and validate client certificates.
• Certificates from Key Vault renew automatically. A missing role or network block to the vault breaks renewals.

Rewrite rule sets

Rewrite rules change requests and responses without touching the app: add, change or delete HTTP headers (for example add X-Forwarded-Proto, remove Server, set HSTS), and URL path and query string (url rewrite). Rules have conditions (on headers, variables) and use server variables (like {var_client_ip}, {http_req_host}). A rewrite rule set is associated to one or more routing rules. For URL rewrite on path-based rules, you can re-evaluate the path map.

Use cases

Path/host routing, TLS offload with Key Vault, WAF, session affinity, redirect, rewrite (including for multi-tenant App Service), internal L7 balancing in a private VNet, and as the regional WAF behind Front Door.

Azure Front Door

Front Door is a global, layer 7 entry point on Microsoft’s edge network. It’s a proxy with anycast IPs, split TCP, CDN caching, TLS offload, WAF and health-based global routing. It terminates the client’s connection at the nearest edge (POP) and carries traffic to the origin over the backbone.

Tiers

Front Door (classic) and CDN from Microsoft (classic) are retiring (classic Front Door on 31 March 2027). Migrate to Standard or Premium. Choose Premium when the requirement says Private Link to the origin or managed WAF rules.

Components

Routing to origins: first latency (within the sensitivity), then priority, then weight. Session affinity is optional.

TLS

• Client to Front Door: Front Door-managed certificate (free, auto-renewed, DigiCert, for custom domains validated by DNS CNAME/TXT) or bring your own from Key Vault (use the latest version for auto-rotation). The minimum TLS version is selectable (1.2 default).
• Front Door to origin: HTTPS to the origin (end-to-end TLS) or HTTP (TLS termination at the edge). Origin certificate must be from a trusted CA, and the name must match the origin host header. For compliance choose HTTPS only for forwarding.
• HTTP to HTTPS redirect is a route setting.

Caching and acceleration

• Caching is configured per route: enable caching, query string behaviour (ignore, use, ignore specified, include specified), compression (gzip/brotli for listed types), and cache duration from the origin’s Cache-Control or an override via a rule. Purge cached content by path. Caching is for static content. Dynamic requests pass through.
• Traffic acceleration (also called dynamic site acceleration) uses anycast, split TCP and persistent connections from the edge to the origin to cut latency for dynamic, uncacheable content. It’s on by default, with no extra setting. Origins closer to the edge matter, so put origins in regions near users.
• Compression and caching are what reduce origin load and bandwidth costs. Anycast + split TCP reduce latency.

Rules, URL rewrite and redirect

A rule set has rules that each have conditions (request URL, path, header, query string, device type, IP, geography, protocol and so on) and actions:

Securing the origin with Private Link

With Premium, Front Door connects to supported origins (Blob storage, App Service/Functions, Internal Load Balancer through a Private Link service, Application Gateway and others) over Private Link, so the origin has no public exposure. Front Door creates a private endpoint connection request that the origin owner must approve. For public origins, restrict access with the AzureFrontDoor.Backend service tag (NSG or firewall) and verify the X-Azure-FDID header (your profile’s ID), because the service tag alone allows any Front Door profile.

Front Door vs Traffic Manager vs Application Gateway