6.1 Azure Front Door Architecture & Routing

Azure Front Door Architecture & Routing

Modern cloud-native applications serve globally distributed user bases where performance, availability, and edge security are critical. Azure Front Door (AFD) is Microsoft's global, scalable entry point that combines Layer 7 reverse proxying, content delivery network (CDN) caching, dynamic traffic acceleration, and Web Application Firewall (WAF) capabilities into a unified software-defined platform.

Front Door operates at the edge of Microsoft's global network, which consists of hundreds of Points of Presence (PoPs) distributed worldwide. By terminating client TCP/TLS connections at the closest edge PoP using BGP Anycast, Front Door drastically reduces round-trip times (RTT) and shields origin infrastructure from direct internet exposure.

---

1. Global Anycast Architecture & Split TCP

Traditional DNS-based load balancing routes users directly to a regional origin IP address. If a user in London connects to a backend hosted in East US (Virginia), the three-way TCP handshake and multi-step TLS 1.3 handshake must traverse the entire trans-Atlantic public internet, incurring high latency, packet loss, and jitter.

+-----------------------------------------------------------------------------+
|                   TRADITIONAL ROUTING VS. SPLIT TCP (AFD)                   |
|                                                                             |
|   TRADITIONAL DIRECT ROUTING:                                               |
|   [Client: London] ====( High Latency WAN Handshake across Internet )====> [Origin: East US]
|   - Latency: 3x-4x trans-Atlantic RTT (~300ms) before first byte sent        |
|                                                                             |
|   AZURE FRONT DOOR WITH SPLIT TCP:                                          |
|   [Client: London] ==( Rapid Local Handshake < 5ms )==> [AFD Edge PoP: London]
|                                                                 |           |
|                                                       (Pre-warmed Pooled)   |
|                                                       (Connections over )   |
|                                                       (Microsoft WAN    )   |
|                                                                 v           |
|                                                       [Origin: East US]     |
+-----------------------------------------------------------------------------+

How Anycast and Split TCP Accelerate Traffic:

1. Anycast IP Advertising: All Front Door edge PoPs advertise the exact same public IPv4 and IPv6 Anycast address prefixes via BGP. Client DNS lookups for an Azure Front Door hostname resolve to this Anycast VIP, and internet routers automatically steer the client packets to the topologically closest edge PoP.
2. Split TCP Connection Termination: The client establishes a short-haul TCP connection and completes the TLS handshake directly with the local edge PoP. This local handshake completes within milliseconds.
3. Pre-Warmed Connection Pooling: The edge PoP maintains pre-established, warmed TCP/TLS connection pools across the ultra-low-latency Microsoft Global Backbone to the origin servers. Data is transported across Microsoft's private dark fiber, bypassing public internet congestion and packet loss.
4. SSL Offloading: Front Door decrypts client HTTPS traffic at the edge PoP, inspects payloads for security threats via WAF, applies routing rules and URL rewrites, and forwards requests to the origin over HTTP or re-encrypted HTTPS.

2. Standard vs. Premium SKU Comparison

Azure Front Door is offered in two production tiers: Standard and Premium. Both tiers share the same core Layer 7 Anycast routing fabric, dynamic site acceleration, and custom domain management, but differ substantially in security controls, Private Link origin connectivity, and enterprise rules engine limits.

[!IMPORTANT] Exam Tip: Private Link Origin Reachability: If an exam scenario requires connecting Front Door to backend App Services, Internal Load Balancers (ILB), or Storage Accounts that have no public endpoints and no internet ingress, you must select Azure Front Door Premium. Standard SKU cannot initiate Private Link connections to origins.

---

3. Core Resource Hierarchy & Routing Engine

Configuring Azure Front Door involves creating a structured resource hierarchy that defines how traffic enters the edge, how it is processed, and where it is dispatched.

+-----------------------------------------------------------------------------+
|                     AZURE FRONT DOOR RESOURCE HIERARCHY                     |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   | Front Door Profile (Standard or Premium SKU)                        |   |
|   |                                                                     |   |
|   |   +-------------------------------------------------------------+   |   |
|   |   | Front Door Endpoint (e.g., app-prod-xyz.azurefd.net)         |   |   |
|   |   | - Custom Domains: www.contoso.com, api.contoso.com          |   |   |
|   |   +-------------------------------------------------------------+   |   |
|   |                                  |                                  |   |
|   |                                  v                                  |   |
|   |   +-------------------------------------------------------------+   |   |
|   |   | Routing Rules                                               |   |   |
|   |   | - Match: Domain + Path Pattern (/api/*, /images/*, /*)      |   |   |
|   |   | - Action: Forward to Origin Group, Redirect, or Rewrite     |   |   |
|   |   | - Attachments: Rules Engine Sets, Caching Configurations    |   |   |
|   |   +-------------------------------------------------------------+   |   |
|   |                                  |                                  |   |
|   |                                  v                                  |   |
|   |   +-------------------------------------------------------------+   |   |
|   |   | Origin Group (Logical grouping of backend endpoints)        |   |   |
|   |   | - Health Probe Settings (Protocol, Interval, Method)        |   |   |
|   |   | - Load Balancing Settings (Sample Size, Latency Sensitivity)|   |   |
|   |   | - Session Affinity (Cookie-based routing)                   |   |   |
|   |   +-------------------------------------------------------------+   |   |
|   |                   |                             |                   |   |
|   |                   v                             v                   |   |
|   |         +-------------------+         +-------------------+         |   |
|   |         | Origin 1 (East US)|         | Origin 2 (W Europe)|        |   |
|   |         | Host: app1.azure..|         | Host: app2.azure..|         |   |
|   |         | Priority: 1       |         | Priority: 2 (Fail)|         |   |
|   |         | Weight: 50        |         | Weight: 50        |         |   |
|   |         | Private Link: Yes |         | Private Link: Yes |         |   |
|   |         +-------------------+         +-------------------+         |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Health Probes and Traffic Routing Algorithms

When Front Door processes an incoming request matched by a routing rule, it selects the target origin within the designated Origin Group using a multi-step evaluation algorithm:

1. Health Probe Evaluation:

   • Front Door sends synthetic health probes from multiple edge locations to each origin.
   • Probe Protocols: HTTP or HTTPS.
   • Probe Methods: HEAD (recommended to save bandwidth) or GET.
   • Probe Interval: Frequency of probe transmissions (e.g., every 30 seconds, or down to 5 seconds for critical backends).
   • Health Evaluation Window: Defined by two parameters: Sample Size (e.g., 4 probe samples) and Successful Samples Required (e.g., 3 successful HTTP 200 responses). If 3 out of 4 probes succeed, the origin is considered healthy.

2. Priority-Based Filtering:

   • Each origin is assigned an integer Priority (e.g., 1 for primary, 2 for standby/failover).
   • Front Door filters the origin pool to only include healthy origins that have the lowest priority number (Priority 1).
   • If all Priority 1 origins become unhealthy, Front Door automatically fails over to healthy Priority 2 origins.

3. Latency Sensitivity Filtering:

   • Among the healthy, lowest-priority origins, Front Door measures the network latency from the specific edge PoP processing the request.
   • Front Door defines a Latency Sensitivity (Additional Acceptable Latency Window) in milliseconds (default: 0 ms; commonly set to 15–50 ms).
   • If Origin A has 10 ms latency and Origin B has 25 ms latency, and Latency Sensitivity is set to 20 ms, both origins fall within the acceptable latency band (10 ms + 20 ms = 30 ms maximum) and will receive traffic.

4. Weighted Round-Robin Distribution:

   • Among all origins that survive the priority and latency filters, traffic is distributed proportionally according to their assigned integer Weight (1–1000).

---

4. Dynamic Site Acceleration (DSA), Caching & Compression

Front Door provides native CDN capabilities, allowing organizations to accelerate dynamic content while offloading static file delivery.

Dynamic Site Acceleration (DSA)

For dynamic, non-cacheable API calls and database-driven web pages, Front Door utilizes DSA techniques:

• Route Optimization: Real-time BGP routing telemetry identifies the fastest network path across the Microsoft backbone.
• TCP Parameter Tuning: Window scaling, initial congestion window size optimization, and selective acknowledgments (SACK).
• TLS Session Resumption: Reusing cryptographic parameters to avoid redundant TLS handshakes.

Caching Behaviors & Query String Configurations

When caching is enabled on a routing rule, Front Door inspects incoming requests against its edge cache before forwarding to origins:

+-----------------------------------------------------------------------------+
|                    FRONT DOOR QUERY STRING CACHING MODES                    |
|                                                                             |
|   Mode                      Incoming Request              Cached As         |
|   -----------------------   ---------------------------   ---------------   |
|   Ignore Query String       /catalog/item?color=blue      /catalog/item     |
|   (Returns same cached      /catalog/item?color=red       /catalog/item     |
|    object for all params)                                                   |
|                                                                             |
|   Cache Every Unique URL    /catalog/item?color=blue      /catalog/item?b.. |
|   (Each parameter variant   /catalog/item?color=red       /catalog/item?r.. |
|    cached separately)                                                       |
|                                                                             |
|   Use Query String          (Custom caching based on specific designated    |
|   (Selective parameters)     query string keys while ignoring others)       |
+-----------------------------------------------------------------------------+

Cache Purging and Compression:

• Cache Purge: When backend content updates, administrators can trigger an on-demand cache purge via the Azure Portal, Azure CLI (az afd endpoint purge-content), or REST API. Purge paths can be explicit (/images/logo.png) or wildcard-based (/images/*).
• Dynamic Compression: Front Door can compress content at the edge using Gzip or Brotli before delivering it to the client, even if the origin served uncompressed responses. Content types (MIME types) eligible for compression are customizable (e.g., text/html, application/json, text/css).

---

5. URL Redirection vs. URL Rewriting

A critical requirement on the AZ-700 exam is distinguishing between URL Redirection and URL Rewriting within Front Door routing rules.

[!TIP] Host Header Preservation vs. Override: When forwarding traffic to multi-tenant PaaS origins (such as Azure App Service or Azure Functions), the backend requires the HTTP Host header to match its default service FQDN (e.g., app-backend.azurewebsites.net), unless a custom domain is explicitly bound in the App Service. Front Door allows configuring the Origin Host Header override per origin.

---

6. Custom Domains, DNS Validation & End-to-End TLS

Deploying enterprise applications on Azure Front Door requires mapping vanity custom domains (e.g., www.contoso.com or root apex contoso.com) and securing communication with TLS.

+-----------------------------------------------------------------------------+
|                        CUSTOM DOMAIN VALIDATION WORKFLOW                    |
|                                                                             |
|   1. Admin adds Custom Domain 'www.contoso.com' in Azure Front Door         |
|   2. AFD generates TXT Validation Token: _dnsauth.www.contoso.com           |
|   3. Admin creates DNS TXT Record in public DNS registrar / Azure DNS       |
|   4. AFD auto-validates ownership and provisions TLS Certificate            |
|   5. Admin creates CNAME (or Azure DNS Alias Record for Root Apex)          |
|      pointing 'www.contoso.com' -> 'app-endpoint.azurefd.net'               |
|   6. Domain state transitions to 'Approved' and 'Deployed'                  |
+-----------------------------------------------------------------------------+

Custom Domain Validation and Apex Support

1. Validation via DNS TXT Record: To prove ownership of a domain before shifting production traffic, Front Door generates a unique validation token. You create a _dnsauth.<subdomain> TXT record in your DNS zone.
2. CNAME Mapping for Subdomains: For standard subdomains (e.g., portal.contoso.com), create a DNS CNAME record pointing to the Front Door endpoint (<endpoint-name>.azurefd.net).
3. Root Apex Domain Support (contoso.com): Standard DNS specifications (RFC 1034/1035) prohibit CNAME records at the zone apex (@). To host a root domain on Front Door, you must host your DNS zone in Azure DNS and create an Alias record pointing directly to the Front Door profile resource.

TLS Certificate Management Models

Front Door enforces TLS 1.2 or TLS 1.3 and offers two certificate management models:

• Azure-Managed Certificate: Microsoft automatically provisions, validates, and rotates the SSL/TLS certificate at zero additional cost using DigiCert. Rotation occurs automatically ~45 days before certificate expiration.
• Bring Your Own Certificate (BYOC) with Azure Key Vault: Organizations upload their private certificate (PFX) to an Azure Key Vault. Front Door accesses the Key Vault via a managed identity or service principal. When the certificate is updated in Key Vault, Front Door automatically detects the new version and deploys it across all global PoPs within 24 hours.

End-to-End TLS Security

For strict regulatory compliance, Front Door supports End-to-End TLS:

• Frontend TLS: Secures communication between client browsers and the edge PoP.
• Backend TLS: Front Door establishes a new, dedicated TLS session from the edge PoP to the backend origin. The origin certificate must be issued by a trusted public Certificate Authority (CA) and contain a Common Name (CN) or Subject Alternative Name (SAN) matching the origin host header.