Azure Front Door vs. Application Gateway : L'affrontement architectural de 2026

En 2026, le débat architectural entre Azure Front Door (AFD) et Application Gateway ne se résume plus à un choix binaire « Global vs. Régional » ; il s'agit de savoir où vous comptez terminer votre TLS handshake et combien vous êtes prêt à payer pour le privilège d'un Private Link en backhaul. Si vous déployez toujours des Application Gateways comme principal point d'entrée ("edge ingress") pour vos microservices multi-régions, vous surchargez probablement vos coûts de compute tout en sous-utilisant la capacité Anycast massive de Microsoft.

La divergence structurelle : Layer 7 à l'Edge vs. dans le VNet

Azure Front Door est un service distribué et multi-tenant opérant dans plus de 190 PoPs (Points of Presence) de Microsoft. Il utilise Anycast pour acheminer le trafic vers l'emplacement edge le plus proche. Inversement, Application Gateway (AppGW) est une ressource régionale managée injectée directement dans votre Virtual Network (VNet). La distinction est cruciale : AFD termine le TCP/TLS à l'edge (réduisant le temps d'aller-retour pour le handshake initial), tandis qu'AppGW le termine dans votre région Azure spécifique.

Pour les workloads 2026 haute performance, l'architecture "Split-TCP" de Front Door est clairement gagnante en termes de latence. En terminant le handshake plus près de l'utilisateur, les paquets traversent le backbone de fibre optique privé de Microsoft du PoP vers l'origine, plutôt que l'acheminement "cold potato" d'Internet public. Si vos utilisateurs sont distribués mondialement, placer un AppGW derrière une Public IP est un modèle de conception archaïque qui introduit de la gigue ("jitter") et une latence inutile.

AFD Premium : La fin de l'Application Gateway exposée sur Internet ?

L'introduction d'Azure Front Door Premium et son intégration profonde avec Private Link ont fondamentalement modifié la matrice de décision. Auparavant, l'exigence de "Public IP" pour AFD signifiait que votre App Service ou Internal Load Balancer (ILB) devait mettre sur liste blanche les plages d'adresses IP d'AFD (Service Tags), ce qui représentait souvent un obstacle en matière de conformité.

Avec AFD Premium, vous pouvez désormais utiliser Private Link pour vous connecter à vos backends. Cela signifie que votre backend — qu'il s'agisse d'un ILB pour un cluster AKS, d'un compte de stockage ou d'un ensemble de VMs — n'a plus besoin d'un endpoint public. Cela rend de facto l'Application Gateway exposée sur Internet obsolète pour la plupart des scénarios multi-régions. Pourquoi gérer la complexité d'un AppGW Scale Set (et ses temps de déploiement d'une lenteur agonisante de 15 minutes) alors que vous pouvez exploiter l'échelle mondiale d'AFD avec un tunnel privé ?

# Exemple : Vérification du statut Private Link pour une origine AFD via CLI
az afd origin show \
  --origin-name my-aks-origin \
  --profile-name my-afd-profile \
  --resource-group rg-prod-network \
  --query "privateLinkAlias"

Application Gateway v2 : Le dernier bastion du VNet

Alors, quand l'Application Gateway v2 a-t-elle réellement du sens en 2026 ? Il existe trois scénarios spécifiques où elle reste le choix supérieur, sinon le seul :

• Load Balancing interne uniquement : Si votre trafic est strictement "East-West" ou "North-South" depuis un ExpressRoute/VPN on-premise, AFD ne peut pas l'intercepter. Vous avez besoin d'AppGW pour le routage L7 interne au VNet.
• Règles WAF personnalisées avec des limites d'inspection élevées : Bien que le WAF d'AFD soit puissant, l'AppGW WAF v2 permet un contrôle plus granulaire sur les inspections du corps des requêtes (jusqu'à 128 KB standard, mais personnalisable dans certaines configurations) et des besoins spécifiques de résidence des données de conformité régionale.
• Exigences strictes de Mutual TLS (mTLS) : Bien qu'AFD prenne en charge le mTLS, la configuration et la gestion des certificats pour un mTLS complexe de niveau entreprise semblent souvent plus "natives" et contrôlables sur une instance AppGW où vous gérez la ca racine de confiance au niveau de la gateway.

Il est également important de noter que le SKU AppGW v2 "Basic" (si l'on peut appeler ainsi les versions allégées) reste un cauchemar en matière de performances lors des événements de scaling. Tenez-vous-en aux SKU Standard_v2 ou WAF_v2, et maintenez toujours une capacité minimale de 2 unités pour éviter la pénalité de démarrage à froid ("cold-start penalty").

La mathématique de l'Ingress : Coût par RPS

Parlons chiffres concrets. En 2026, le coût de l'egress de données et des "Request Processing Units" (RPUs) ou "Capacity Units" anéantira votre budget si vous choisissez mal. Pour un site à fort trafic traitant 5 000 Requêtes Par Seconde (RPS) :

Azure Front Door (Standard/Premium)

• Frais de base : Environ 35 $ (Standard) à 330 $ (Premium) par mois.
• Frais de requête : Environ 0,75 $ par million de requêtes.
• Transfert de données : Vous payez pour les données sortantes de l'Edge vers l'utilisateur. Les données de l'Origine Azure vers l'Edge sont à 0 $ (c'est une économie cachée considérable).

Application Gateway v2

• Coût fixe : Environ 180 $/mois (WAF_v2).
• Coût d'unité de capacité (CU) : 0,008 $ par CU-heure. 5 000 RPS (en supposant une taille moyenne de 10 KB et un header de 2KB) se traduit généralement par environ 10-15 CUs.
• Transfert de données : Vous payez les tarifs d'egress VNet standard, qui peuvent être nettement plus élevés que les tarifs réduits d'AFD pour de gros volumes.

Verdict : Pour un trafic global à grand volume, Front Door est presque toujours moins cher car il élimine la taxe d'egress "Origin-to-Internet". Pour plus d'informations sur l'optimisation de vos dépenses cloud, consultez notre guide sur l'optimisation des coûts pour ExpressRoute et l'Egress.

Stratégies WAF avancées : Rate Limiting et Bot Defense

Le WAF de Front Door Premium a des années-lumière d'avance sur le WAF régional d'AppGW. En 2026, les attaques de bots automatisées et les attaques DDoS "Low and Slow" sont la norme. AFD Premium inclut des Bot Manager Rule Sets basés sur le renseignement sur les menaces de Microsoft, qui identifie les "bons bots" connus (Google, Bing) et défie ou bloque les "bots malveillants" avant même qu'ils n'atteignent votre région Azure.

Le rate limiting sur AFD est également plus robuste. Vous pouvez définir des limites de débit basées sur l'IP du client, la localisation géographique ou même des Request Headers spécifiques. En passant d'une conception centrée sur AppGW à une conception centrée sur AFD, vous gagnez la capacité de bloquer le trafic à l'edge, économisant ainsi les cycles de compute de votre backend (et les coûts d'autoscale) pour les utilisateurs légitimes.

# Modèle ARM partiel pour une règle de Rate Limiting AFD
{
  "name": "RateLimitRule",
  "priority": 100,
  "ruleType": "RateLimitRule",
  "action": "Block",
  "matchConditions": [
    {
      "matchVariable": "RemoteAddr",
      "operator": "IPMatch",
      "negateCondition": false,
      "matchValue": ["0.0.0.0/0"]
    }
  ],
  "rateLimitThreshold": 1000,
  "rateLimitDurationInMinutes": 1
}

Haute disponibilité Multi-Régions (DR)

Si vous construisez pour une véritable haute disponibilité (99,99 % et plus), l'Application Gateway est un point de défaillance unique pour une région. Bien que vous puissiez déployer une AppGW dans chaque région et placer Azure Traffic Manager (basé sur le DNS) devant elles, il s'agit d'un Load Balancing global "du pauvre". Le failover basé sur le DNS est victime de la mise en cache TTL (Time to Live), ce qui signifie que vos utilisateurs pourraient atteindre une région hors service pendant des minutes après une défaillance.

Azure Front Door utilise des sondes de santé de niveau HTTP et Anycast. Si votre région West US 2 devient indisponible, les PoPs edge redirigent immédiatement (en quelques secondes) le trafic vers East US ou North Europe. Il n'y a pas de délai de propagation DNS. C'est pourquoi AFD est le backbone des services de Microsoft tels qu'Office 365 et Xbox Live.

Nous avons abordé des modèles architecturaux similaires dans notre analyse approfondie de Multi-Region AKS Networking, où nous expliquons pourquoi AppGW ne devrait résider derrière AFD que si vous avez une exigence spécifique d'injection VNet.

Verdict : La recommandation de TechLeague

En 2026, la hiérarchie des choix est claire. Si votre application est accessible publiquement, utilisez Azure Front Door Premium. La combinaison de la réduction de latence Anycast, du WAF Edge et du support d'origine Private Link en fait le choix supérieur en termes de sécurité et de performances. N'utilisez Application Gateway v2 que comme "consommateur de backend" pour le trafic interne ou si vous avez une exigence héritée de réécritures WAF spécifiques que le moteur AFD ne prend pas encore en charge.

Cessez de traiter le Cloud comme un datacenter physique. Votre WAF a sa place à la porte d'entrée d'Internet, et non niché dans un sous-réseau à 40 ms de vos utilisateurs. Pour des revues d'architecture ou des formations spécialisées sur ces stacks, consultez nos ateliers intensifs sur techleague.io.

Questions Fréquemment Posées