10 — Azure Application Gateway

Répartiteur de charge applicatif L7 (HTTP/HTTPS) régional, dans ton VNet → comprend le contenu HTTP (URL, path, headers) pour routage avancé, terminaison TLS et rewrite.

A. Vue d'ensemble

Application Gateway (AGW) = load balancer L7 (Layer 7 — HTTP/HTTPS) régional, déployé dans ton VNet. Contrairement au LB (L4) qui ne voit que IP/port, l'AGW comprend le contenu HTTP : URL, path, headers, cookies, host.

A.1 L7 vs L4 — pourquoi AGW ?

Le load balancing se fait au niveau L7 : l'AGW comprend les URL, les paths, les headers, et peut router vers différents backend pools selon le contenu de la requête. Ce n'est donc pas un simple équilibrage IP/port comme en L4.

Grâce au L7, l'AGW peut :

• Path-based routing : /api/* → pool API, /images/* → pool images
• Multi-site hosting : app1.com et app2.com sur le même AGW (via host header)
• SSL termination / SSL offload : décharge le chiffrement
• Header / URL rewrite : modifier les requêtes/réponses en flight
• WAF (avec le SKU WAF_v2)
• Cookie-based session affinity

A.2 Features clés

• Path-Based Routing
• Multi-site routing
• End-to-end encryption
• WAF (avec WAF SKU)
• L7 features (rewrite, redirect, etc.)
• Integrated Autoscaling (v2)

A.3 AGW vs LB vs Front Door — positionnement

🎯 AGW = L7 régional. Pour du L7 global + CDN → Front Door. Pour du non-HTTP → LB.

B. SKUs / Tiers

B.1 v2 — pourquoi ?

• Autoscaling : min/max instances, scale automatique selon la charge
• Availability Zones : zone-redundant natif
• Provisioning plus rapide
• Header rewrite + URL rewrite
• Static VIP (l'IP ne change pas)

B.2 Manual vs Autoscale

Objectif AZ-700 : "Choose between manual and autoscale"

• L'unité de scale = Capacity Unit (CU) (combinaison compute + connexions + throughput)
• Autoscale recommandé en prod (encaisse les pics sans intervention)

C. Architecture & flux

C.1 Le flux complet

Client
  │  HTTPS request: https://shop.com/api/orders
  ▼
┌──────────────────────────────────────────────────┐
│ APPLICATION GATEWAY                                │
│                                                    │
│  1. Frontend IP (Public et/ou Private)             │
│         │                                          │
│  2. Listener (port 443, HTTPS, host=shop.com)      │
│         │  → termine le SSL ici (déchiffre)        │
│         ▼                                          │
│  3. Routing rule (Basic ou Path-based)             │
│         │  /api/* → api-pool                       │
│         ▼                                          │
│  4. Backend HTTP settings (port, protocole, probe) │
│         │  → comment parler au backend             │
│         ▼                                          │
│  5. Health probe (vérifie le backend sain)         │
└──────────────────────────────────────────────────┘
  │
  ▼
Backend pool (VMs, VMSS, App Service, IP, FQDN)

C.2 Les 5 composants — rôles précis

La différence clé avec un Load Balancer : un Listener AGW comprend le protocole HTTP + le host header + le SSL (L7), alors qu'une LB rule ne regarde que le port (L4). Le listener peut router selon le nom de domaine (multi-site), le LB ne peut pas.

C.3 Backend pool — plus riche qu'un LB

Le backend pool peut être public ou privé, et n'accepte pas que des VMs. Il accepte :

• VMs / VMSS
• App Service (Web Apps)
• Adresses IP (privées ou publiques)
• FQDN (ex backend.contoso.com, ou une App Service)
• AKS (via AGIC — Application Gateway Ingress Controller)

⚠️ Pas multi-region : le backend pool AGW est régional. Pour du multi-region → Front Door devant.

C.4 Subnet dédié

• L'AGW vit dans un subnet dédié de ton VNet
• /24 fortement recommandé pour v2 (jusqu'à 125 instances en autoscale). Minimum recommandé /26 (ancien SKU v1). Azure réserve 5 IP par subnet
• Pas d'autres ressources dans ce subnet
• ⚠️ Ne pas bloquer les ports de management v2 (65200-65535) avec un NSG

D. Listeners

D.1 Types de listeners

D.2 Multi-site hosting

Un seul AGW peut répondre à plusieurs URLs : on déploie plusieurs apps (un backend par domaine), puis on ajoute un listener multi-site par domaine sur l'AGW.

• Un seul AGW peut servir app1.contoso.com, app2.contoso.com, *.contoso.com (wildcard, max 5 par listener v2)
• Chaque listener multi-site matche un host header → route vers le bon backend
• Jusqu'à 100+ sites sur un AGW (les limites exactes — nb de listeners/sites/règles — sont plus strictes avec WAF ; vérifier les limites courantes Application Gateway si tu approches la centaine)

D.3 Listener HTTP vs HTTPS

• HTTP : port 80, pas de SSL
• HTTPS : port 443, termine le SSL sur l'AGW (besoin d'un certificat)

E. Routing Rules

E.1 Types de rules

E.2 Path-based routing

Listener (shop.com:443)
   │
   ├── /api/*     → api-pool   + http-settings-api
   ├── /images/*  → img-pool   + http-settings-img
   └── /* (default) → web-pool + http-settings-web

• Un default backend pool est obligatoire (catch-all)
• Chaque path map vers un pool + des HTTP settings spécifiques

E.3 Priority (v2)

• En v2, les routing rules ont une priority numérique (1-20000, bas = prioritaire)
• Permet de gérer l'ordre d'évaluation des rules

E.4 Routing vs Redirection

Exemple de redirection : http://shop.com → redirect 301 → https://shop.com (forcer HTTPS).

F. Backend HTTP Settings

C'est comment l'AGW communique avec le backend (port, cookie affinity, draining, etc.) :

F.1 Pick host name from backend target (piège)

• Si Yes : l'AGW envoie le hostname du backend (ex App Service attend son propre nom)
• Si No : l'AGW envoie le host header du client (ex shop.com)
• 🚨 Piège classique : App Service en backend → si "Pick host name from backend" = No → l'App Service reçoit Host: shop.com qu'elle ne connaît pas → 404. Mettre Yes.

F.2 Connection draining

Quand on retire une VM du pool (scale-in, maintenance), connection draining laisse les requêtes en cours se terminer proprement (au lieu de les couper) → pas d'erreur 502 pour les users en cours.

G. Health Probes

• Default probe : GET / toutes les 30s, attend un 200
• Custom probe : path custom (/health), intervalle, threshold, match status codes
• 🚨 Best practice : matcher 200-399 (pas 200 strict) pour gérer les redirects 301/302
• Best practice : exposer un /health qui vérifie les dépendances (DB, cache), pas juste /

H. TLS / SSL

H.1 SSL Termination (SSL Offload)

Client ──HTTPS (443)──► AGW [déchiffre] ──HTTP (80)──► Backend

• Le SSL est terminé (déchiffré) sur l'AGW
• Le trafic vers le backend est en HTTP clair (port 80)
• Avantages :
  • Décharge le CPU des backends (pas de déchiffrement)
  • Le certificat est centralisé sur l'AGW (pas sur chaque VM)
  • L'AGW peut inspecter/router selon le contenu (WAF, path)

H.2 End-to-End SSL (re-encryption)

Client ──HTTPS (443)──► AGW [déchiffre, inspecte, re-chiffre] ──HTTPS (443)──► Backend

• L'AGW déchiffre (pour inspecter/router), puis re-chiffre vers le backend
• Use case : compliance qui exige le chiffrement de bout en bout (PCI-DSS, santé, banque)
• Nécessite un certificat sur le backend aussi (l'AGW doit le trust)

H.3 Certificats

• Listener TLS certificate : le cert présenté au client (pour le SSL termination)
• Peut venir de :
  • Key Vault (recommandé — rotation auto via Managed Identity)
  • Upload manuel (PFX)
• Pour end-to-end : un trusted root certificate côté backend HTTP settings

I. Rewrite Rule Sets

🚨 v2 only : le rewrite (headers ET URL) n'existe que sur le SKU v2 (Standard_v2 / WAF_v2). Le v1 ne sait pas réécrire. Piège exam classique : "réécrire un header sur un v1" → impossible, il faut migrer en v2.

I.1 Concept

Les rewrite rules modifient les requêtes/réponses en flight (pendant le passage par l'AGW) :

• Réécrire des request headers (vers le backend) et response headers (vers le client)
• Réécrire l'URL : path, query string et host name
• Conditionnel : selon un header (request/response) ou une server variable

On peut ajouter, modifier ou supprimer un header. On ne peut pas réécrire les headers Connection, Upgrade ni X-Original-Host, et on ne peut pas supprimer le header Host.

I.2 Composants

• Rewrite rule set : ensemble de règles, attaché à une routing rule
• Conditions (optionnel) : si tel header / path / variable matche
• Actions : modifier header, réécrire URL

I.3 Exemples

URL rewrite : /application/* → réécrit vers /app/* (parce que le backend attend /app, pas /application).

Header rewrite :

• Ajouter X-Forwarded-For avec l'IP client
• Supprimer un header qui révèle la techno backend (Server: Apache)
• Ajouter un header de sécurité (Strict-Transport-Security)

Conditionnel : si le header User-Agent contient "mobile" → ajouter un header X-Device: mobile.

I.4 URL Rewrite vs URL Redirect

💡 Routing original vs réécrit : avec l'URL rewrite + path-based routing, on choisit de router (sélectionner le backend pool) selon l'URL d'origine OU l'URL réécrite (option reevaluate path map). Utile quand le path réécrit doit cibler un autre pool que le path d'origine.

I.5 Server variables — la syntaxe (cœur de l'exam)

L'AGW stocke des infos sur la connexion, le client et la requête dans des server variables, qu'on injecte dans les conditions et les actions de rewrite.

⚠️ Dans le portail, le champ "server variable" attend juste le nom (ex add_x_forwarded_for_proxy, host) ; c'est dans les value strings qu'on entoure de {var_...}.

Server variables utiles :

🚨 Piège : {var_uri_path} = path sans query string ; {var_request_uri} = path avec query string. Se tromper duplique ou perd la query string. Et {var_uri_path} ayant déjà un / initial, concaténer /apim/{var_uri_path} donne un // → écrire /apim{var_uri_path}.

I.6 La famille X-Forwarded (ajoutée auto par l'AGW vers le backend)

L'AGW insère automatiquement ces headers dans la requête envoyée au backend (le backend, derrière le proxy, perd sinon l'info du client réel) :

I.7 Les 2 scénarios "port" (à connaître par cœur)

(a) Enlever le port du X-Forwarded-For — le backend ne veut que l'IP, pas ip:port.

• Request header rewrite : header X-Forwarded-For ← valeur {var_add_x_forwarded_for_proxy}.
• Cette variable reconstruit le X-Forwarded-For avec l'IP client seule (sans port). Alternative : {var_client_ip}.

(b) Le header Host traîne le port (contoso.com:443) → le backend casse.

• {http_req_host} inclut le port quand le client l'envoie → le backend reçoit Host: contoso.com:443.
• Cas réel : backend IIS / ASP.NET qui utilise le Host pour générer des URLs → liens et redirections cassés.
• Fix : réécrire le header Host avec {var_host} (= host), qui donne le hostname sans port. Ou bien retirer carrément la réécriture du Host pour laisser passer le host client d'origine.

I.8 Cas d'usage fréquents

⚠️ Limitation : le rewrite ne s'applique pas aux réponses 4xx/5xx générées par l'AGW lui-même (502 backend down, 403 WAF) — pour celles-là, utiliser les custom error pages. Idem, pas de rewrite si la rule est en mode redirection ou page d'erreur custom.

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : E-commerce mono-région — checkout isolé + SSL end-to-end

Contexte business : Un retailer français (~2M visites/mois), site Magento sur VMSS, paiement via un prestataire externe. Besoins : chiffrement de bout en bout (PCI-DSS), envoyer /checkout/* vers des serveurs dédiés (plus gros, isolés pour la perf), et un WAF (les paiements sont la cible n°1). Choix architectural : App Gateway WAF_v2 en mode Prevention, routing par chemin d'URL, SSL de bout en bout et autoscale. Architecture / pattern :

• AGW WAF_v2 public, autoscale de 2 à 20 instances (pour absorber les pics)
• Routing par chemin : /checkout/* → premium-pool (grosses VMs), tout le reste /* → standard-pool
• HTTP settings en SSL de bout en bout : l'AGW re-chiffre vers le backend (exigence PCI-DSS)
• Le certificat du listener vient de Key Vault (rotation automatique)
• Health probe custom sur /health (vérifie la DB et le cache, accepte les codes 200-399)
• WAF en mode Prevention, ruleset DRS 2.2 (recommandé pour toute nouvelle policy ; CRS 3.2 reste possible mais c'est l'ancien) Trade-offs assumés :
• Gain : conformité PCI-DSS (TLS end-to-end + WAF), checkout isolé et autoscale absorbant les pics.
• Perte : re-chiffrement vers le backend coûteux en CPU, subnet large à réserver pour l'autoscale. Pièges à éviter :
• WAF en mode Detection (log seulement) → aucune protection réelle. En prod, c'est Prevention
• Déchiffrer puis envoyer en HTTP au backend, alors que PCI exige le bout en bout → la re-encryption est obligatoire
• Subnet AGW en /29 → trop petit pour l'autoscale. Prévoir /24
• Sonde sur / (qui renvoie 200 même si la DB est tombée) → utiliser un /health custom

📐 Réf. CAF/WAF — Sécurité (TLS/WAF) du service Application Gateway : pour les charges PCI, terminer le TLS sur l'AGW pour l'inspection WAF puis re-chiffrer vers le backend, et stocker les certificats dans Key Vault avec rotation automatisée. Architecture best practices for Azure Application Gateway v2 — Security

Scenario 2 : App LOB interne banque — AGW privé + accès on-prem

Contexte business : Une banque régionale a une app intranet RH/paie. Elle doit être joignable uniquement depuis le réseau interne via ExpressRoute. Il faut du routing applicatif (niveau 7) et un WAF (compliance), sans aucune exposition publique. Choix architectural : App Gateway WAF_v2 avec frontend en IP privée (mode interne) et une Private DNS Zone pour la résolution. Architecture / pattern :

• AGW v2 WAF avec IP privée en frontend dans un subnet dédié /24
• Pas d'IP publique en frontend (ou alors une IP publique juste pour le management v2, le listener restant sur l'IP privée)
• ExpressRoute → les postes on-prem atteignent l'IP privée de l'AGW
• Private DNS Zone app.corp.local → pointe vers l'IP privée de l'AGW (sinon les postes on-prem ne résolvent pas le nom)
• WAF en Prevention même en interne (défense en profondeur : un poste compromis sur le LAN passe quand même par là)
• Backend : VMs RH/paie sans IP publique, admin via Bastion Trade-offs assumés :
• Gain : aucune exposition publique, accès L7 + WAF réservé au réseau interne via ExpressRoute.
• Perte : Private DNS Zone à maintenir, IP publique de management v2 à garder ouverte (ports 65200-65535). Pièges à éviter :
• Croire qu'"interne = pas besoin de WAF" → un poste interne compromis contournerait tout. WAF même en interne
• Oublier la Private DNS Zone → les postes on-prem ne trouvent pas l'IP privée de l'AGW
• L'AGW v2 a quand même besoin d'une IP publique pour son plan de management (ports 65200-65535), même en mode interne — il ne faut pas la bloquer
• Subnet trop petit pour l'autoscale

📐 Réf. CAF/WAF — Déploiement privé (frontend privé only) : le déploiement privé v2 permet un frontend en IP privée uniquement, sans Public IP, en supprimant le trafic entrant GatewayManager et en définissant une règle sortante Deny All contre l'exfiltration. Private Application Gateway deployment

Scenario 3 : Defense-in-depth — Front Door + App Gateway (combo)

Contexte business : Une banque a une app web critique exposée dans le monde entier. Sécurité maximale demandée : un WAF en bordure (qui bloque l'attaque avant qu'elle n'arrive en Europe) ET un WAF régional (défense en profondeur), un CDN pour les fichiers statiques, et un backend jamais exposé publiquement. Choix architectural : Front Door Premium (bordure globale + WAF + CDN) placé devant un App Gateway WAF_v2 régional (niveau 7 + WAF), lui-même devant les backends. Architecture / pattern :

Internet → Front Door Premium (WAF global + CDN + anycast)
              ↓ (Private Link ou Service Tag AzureFrontDoor.Backend)
           App Gateway WAF_v2 (WAF régional + path routing + SSL)
              ↓
           Backends (VMs/App Service avec PE)

• Front Door : WAF Premium (DRS 2.2 + Bot Manager), CDN pour /static/*, routing par latence
• App Gateway : WAF_v2 (2e couche de WAF), routing fin par chemin, SSL de bout en bout
• Le backend n'accepte que le Service Tag AzureFrontDoor.Backend (ou Private Link) pour atteindre l'AGW
• 2 policies WAF séparées (une pour Front Door, une pour App Gateway) Trade-offs assumés :
• Gain : double WAF (bordure globale + régional), CDN et backend jamais exposé publiquement.
• Perte : coût et complexité élevés (2 services + 2 policies WAF), sur-ingénierie hors cas critiques. Pièges à éviter :
• Vouloir une seule policy WAF pour les deux → impossible (1 policy = 1 type de service). Il en faut 2 distinctes
• Laisser le backend de l'AGW accessible publiquement → l'attaquant contourne Front Door. Le restreindre via le Service Tag AzureFrontDoor.Backend ou Private Link
• Mettre /api/* (dynamique) en cache CDN → données périmées. Ne mettre en cache que /static/*
• Sur-ingénierie : ce combo est réservé aux cas critiques (banque, gouvernement). Pour une app classique, Front Door OU App Gateway suffit

📐 Réf. CAF/WAF — Origine sécurisée via Private Link (Front Door → AGW) : connecter Front Door Premium à l'AGW via Private Link désactive l'accès public direct à l'AGW une fois le private endpoint approuvé (l'attaquant ne peut plus bypasser Front Door). Connect Azure Front Door Premium to an Application Gateway with Private Link

DEMO — chemins portail

1. DEMO — Configuration App Gateway + Path-Based Routing

Reproduit ta démo. AGW avec 2 backend pools (app-pool, web-pool).

Étape 1 — Créer l'Application Gateway :

Home > Application gateways > + Create

1. Basics :
   • Name : agw-shop
   • Tier : Standard V2 (ou WAF V2)
   • Enable autoscaling : Yes, Min 2 / Max 10
   • Availability zones : 1, 2, 3
2. Virtual network : sélectionner le VNet, créer un subnet dédié agw-subnet (/27 min, recommandé /24)
3. Frontends :
   • Frontend IP type : Public (ou Both pour public + private)
   • Public IP : créer pip-agw-shop (Standard)
4. Backends : + Add a backend pool
   • app-pool (vide pour l'instant — on ajoute les targets après)
   • web-pool (vide)
5. Configuration : ajouter les routing rules (étape suivante)
6. Review + create

Étape 2 — Routing rule + Path-based :

Configuration > Routing rules > + Add a routing rule

• Rule name : rr-shop, Priority : 100
• Listener :
  • Listener name : listener-https
  • Frontend : Public
  • Port : 443, Protocol : HTTPS
  • Certificate : depuis Key Vault (kv-certs → cert-shop) via Managed Identity, OU upload PFX
  • Listener type : Basic (1 domaine) ou Multi site (host header)
• Backend targets > Path-based routing :
  • Default backend pool : web-pool + HTTP setting hs-web
  • + Add multiple targets to create a path-based rule :
    • Path /app/* → app-pool + hs-app
    • Path /web/* → web-pool + hs-web
• Backend settings (HTTP settings) :
  • Backend protocol HTTP, port 80 (SSL offload)
  • Cookie-based affinity : Disable
  • Connection draining : Enable 30s
  • Pick host name from backend target : Yes (si App Service)
  • Custom probe : /health, match 200-399

Test : https://shop.com/app/... → app-pool, /web/... → web-pool, /... → default web-pool.

2. DEMO — App GW avec URL Rewrite Rules

Reproduit ta démo. /application → /app.

Application Gateway > Rewrites > + Rewrite set

1. Name : rewrite-app
2. Associate routing rules : sélectionner rr-shop (et le path rule cible)
3. + Add rewrite rule :
   • Rule name : rewrite-application-to-app
   • Condition (optionnel) : var_uri_path matche /application/(.*)
   • Action type : URL
   • URL path value : /app/{var_uri_path_1} (réécrit /application/xyz → /app/xyz)
4. Save

Exemple header rewrite :

• Action type : Response Header
• Header name : Strict-Transport-Security
• Header value : max-age=31536000 → Ajoute le HSTS header à toutes les réponses.

3. DEMO — App Gateway Routing for Host Headers (multi-site)

Reproduit ta démo. AGW répond à plusieurs URLs.

Prérequis : plusieurs apps/backends + DNS pointant les domaines vers l'IP AGW.

Étape 1 — Créer les backend pools : app1-pool, app2-pool (avec les targets respectives).

Étape 2 — Créer des listeners multi-site :

Listeners > + Add listener

• Listener 1 : listener-app1, Multi-site, Host name : app1.contoso.com, port 443 HTTPS
• Listener 2 : listener-app2, Multi-site, Host name : app2.contoso.com, port 443 HTTPS

Étape 3 — Associer chaque listener à une rule :

Routing rules > + Add :

• Rule rr-app1 : Listener listener-app1 → backend app1-pool
• Rule rr-app2 : Listener listener-app2 → backend app2-pool

Test : app1.contoso.com → app1-pool, app2.contoso.com → app2-pool (le host header décide).

4. DEMO — Configure App Gateway Encryption (SSL/TLS)

Reproduit ta démo. Certificats self-signed pour le test.

Étape 1 — Générer un cert self-signed (pour test) et l'uploader :

En prod : utiliser Key Vault. Pour le lab, un self-signed suffit.

Étape 2 — Listener HTTPS avec certificat :

Listeners > listener-https > Edit

• Protocol : HTTPS
• Port : 443
• Listener TLS certificate : Upload (PFX self-signed) OU Key Vault
• Save

Étape 3 — SSL offload (front HTTPS, back HTTP) :

HTTP settings > hs-web :

• Backend protocol : HTTP, port 80 → Le client parle HTTPS à l'AGW, l'AGW parle HTTP au backend (offload).

Étape 4 — End-to-end SSL (optionnel, re-encryption) :

HTTP settings > hs-secure :

• Backend protocol : HTTPS, port 443
• Trusted root certificate : uploader le cert root du backend (pour que l'AGW le trust) → Le client parle HTTPS à l'AGW, l'AGW re-chiffre vers le backend en HTTPS.

Étape 5 — Nouvelle routing rule pour tester avec le listener HTTPS.