Application Gateway solves layer 7 inside a region. The moment you serve users from multiple regions, or want TLS terminated close to the user, or need failover between regions measured in seconds, the answer moves to the edge: Azure Front Door. It is a global anycast service running at Microsoft points of presence worldwide, combining CDN, global load balancer, and WAF in one resource.

How Routing Works

A user connects to the nearest edge over anycast, TLS terminates there, and the request rides the Microsoft backbone to the best origin. Origins sit in origin groups with health probes and a load balancing policy: latency based by default, with priority values for active passive failover and weights for gradual traffic shifting. Because health probing happens from the edge fleet, failover to the secondary region typically completes in well under a minute with no DNS TTL games.

resource "azurerm_cdn_frontdoor_profile" "this" {
  name                = "afd-global"
  resource_group_name = azurerm_resource_group.edge.name
  sku_name            = "Premium_AzureFrontDoor"
}

resource "azurerm_cdn_frontdoor_origin_group" "api" {
  name                     = "og-api"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.this.id

  load_balancing {
    sample_size                 = 4
    successful_samples_required = 3
  }

  health_probe {
    path                = "/healthz"
    protocol            = "Https"
    interval_in_seconds = 30
    request_type        = "GET"
  }
}

resource "azurerm_cdn_frontdoor_origin" "weu" {
  name                          = "origin-weu"
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.api.id
  host_name                     = "agw-weu.internal.contoso.com"
  priority                      = 1
  weight                        = 1000
  certificate_name_check_enabled = true

  private_link {
    request_message        = "AFD access"
    target_type            = "sites"
    location               = "westeurope"
    private_link_target_id = azurerm_linux_web_app.api_weu.id
  }
}

Private Link to Origins

The Premium SKU’s killer feature: Front Door connects to your origins over Private Link. Your App Service, internal load balancer, or storage account keeps public access completely disabled, and the only path in is through Front Door. That eliminates the classic problem of attackers bypassing the CDN and WAF by hitting origin IPs directly. If Private Link is not an option for an origin, at minimum validate the X-Azure-FDID header at the origin so only your Front Door profile is accepted.

Caching and Compression

Attach caching per route: static assets get long TTLs with query string ignored, APIs stay uncached or use short TTLs with cache keys that include relevant query strings. Enable compression at the edge for text content. The metric to watch is cache hit ratio per route; a static route below 80 percent usually means the origin is sending Cache-Control headers that fight your edge policy, and the origin headers win unless you override them on the route.

WAF at the Edge

Front Door WAF runs the same managed ruleset engine as Application Gateway plus edge specific strengths: rate limiting per client, geo filtering, and bot protection, all enforced before traffic ever reaches your regions. A pattern I use constantly is a rate limit rule on login and token endpoints, which turns credential stuffing from an application problem into an edge configuration line. If you run Front Door in front of Application Gateway, let Front Door own the WAF and keep the gateway focused on routing, running two WAFs doubles tuning effort for marginal gain.

Operationally, watch origin health percentage per origin group, edge to origin latency, and 5xx rate split by edge versus origin so you know which side of the backbone owns a problem. And keep DNS simple: CNAME your apex or www to the Front Door endpoint with the managed certificate handling TLS, rotation included.

Cheers
Osama