AZ-305 · Question #337
Hotspot Question You plan to deploy a containerized web-app that will be hosted in five Azure Kubernetes Service (AKS) clusters. Each cluster will be hosted in a different Azure region. You need to…
The correct answer is For global load balancing:: Azure Front Door; As the ingress controller:: Azure Application Gateway. AKS Multi-Region Web App - Hotspot Explanation --- Dropdown 1: Global Load Balancing -> Azure Front Door Why Azure Front Door is correct: Front Door operates at Layer 7 (HTTP/HTTPS) and uses Anycast routing with latency-based traffic distribution. It measures real-time latency…
Question
Exhibit
Answer Area
- For global load balancing:Azure Front DoorAzure Front DoorAzure Traffic ManagerCross-region load balancing in AzureStandard Load Balancer
- As the ingress controller:Azure Application GatewayAzure Application GatewayAzure Standard Load BalancerBasic Azure Load Balancer
Explanation
AKS Multi-Region Web App - Hotspot Explanation
Dropdown 1: Global Load Balancing -> Azure Front Door
Why Azure Front Door is correct:
Front Door operates at Layer 7 (HTTP/HTTPS) and uses Anycast routing with latency-based traffic distribution. It measures real-time latency to each backend (your 5 AKS clusters) and routes each request to the lowest-latency cluster. It also provides:
- Instant failover via health probes - when a cluster goes down, traffic is rerouted within seconds (not minutes), minimizing outage impact
- Native HTTPS termination and WAF capabilities
- Global Points of Presence (PoPs) that absorb and route traffic efficiently
Why the alternatives are wrong:
| Option | Why Wrong |
|---|---|
| Azure Traffic Manager | DNS-based routing only. Failover relies on DNS TTL propagation (minutes, not seconds). Doesn't minimize failover time as required. Also operates at Layer 4/DNS, not Layer 7. |
| Cross-region load balancer | Routes TCP/UDP traffic (Layer 4), not HTTPS-aware. No latency-based routing - it uses regional redundancy, not latency optimization. |
| Standard Load Balancer | Regional only - operates within a single region. Cannot route across 5 clusters in different regions at all. |
Key concept: Latency-based + fast failover = Layer 7 global load balancer -> Front Door.
Dropdown 2: Ingress Controller -> Azure Application Gateway
Why Azure Application Gateway is correct:
An ingress controller must operate at Layer 7 to route HTTPS traffic to specific pods within a cluster. Application Gateway Ingress Controller (AGIC) integrates directly with AKS and provides:
- Path-based and host-based routing to individual pods/services
- TLS termination at the ingress layer
- Kubernetes-native configuration via
Ingressresources - Full HTTPS inspection before forwarding to pods
Why the alternatives are wrong:
| Option | Why Wrong |
|---|---|
| Standard Load Balancer | Layer 4 (TCP/UDP) only. Cannot inspect HTTP headers, paths, or hostnames - cannot route to individual pods based on application-layer rules. |
| Basic Load Balancer | Also Layer 4, and deprecated/limited. Cannot function as an ingress controller. No path-based routing. |
Key concept: Ingress controllers must be Layer 7 (HTTP-aware). Only Application Gateway operates at the required layer to route HTTPS to individual pods.
Summary
Internet -> Azure Front Door (latency routing + fast failover)
↓
AKS Cluster (lowest latency region)
↓
Azure Application Gateway (ingress controller)
↓
Individual Pods
The two-tier architecture separates global traffic management (Front Door) from cluster-internal HTTP routing (App Gateway), satisfying all three requirements.
Topics
Community Discussion
No community discussion yet for this question.