6 — Connectivity and Load Balancing

Répartir la charge → Load Balancer (L4), Application Gateway (L7 régional), Front Door (L7 global), Traffic Manager (DNS) : choisir selon couche, portée, mode et besoins SSL/WAF/failover.

A. Vocabulaire load balancing

A.1 L4 vs L7

LB (L4) ne sait pas que /api/orders doit aller au backend orders. App Gateway (L7) sait.

A.2 Proxy vs DNS-based

A.3 TTL DNS

Time To Live = durée pendant laquelle un resolver cache une réponse DNS. Traffic Manager : TTL bas (30s) = failover + rapide mais + de queries DNS = + cher. Default 60s.

A.4 Anycast IP

Une seule IP publique répliquée sur N POPs MS mondial. BGP route vers le POP le plus proche. → Front Door = anycast (Paris → POP Paris ~5ms, Tokyo → POP Tokyo).

A.5 Health probe

LB envoie périodiquement requête au backend (HTTP GET /health ou TCP ping). N échecs → backend marqué unhealthy, exclu du pool. → Best practice : exposer endpoint /health qui check les dépendances (DB, KV).

A.6 Session affinity (sticky)

Garantit qu'une session client revient au même backend (cookie ajouté par LB). Use case : app stateful avec panier en mémoire. → Best practice moderne : app stateless (Redis/DB), pas besoin d'affinity.

A.7 WAF + DRS

Web Application Firewall filtre requêtes malveillantes (SQL injection, XSS) avant backend.

• DRS (Default Rule Set) = règles MS-managed basées sur OWASP Top 10.
• Custom rules : whitelist/blacklist IP, geo-block, rate limit.
• Bot Manager : block scrapers/scanners.
• 2 modes : Detection (log only, tuning 1-2 semaines) → Prevention (block, prod).

B. Azure Load Balancer (étoffé)

B.1 C'est quoi

Load balancer L4 (TCP/UDP) Azure natif, régional ou global. Pour balancer le trafic non-HTTP ou très haut débit.

B.2 SKUs

B.3 Public vs Internal

B.4 Cross-Region Load Balancer

Global tier du Standard LB : L4 global avec anycast IP statique, route vers des LBs régionaux en backend.

• Préserve l'IP client.
• Failover instant (proxy, pas DNS).
• Le pendant L4 de Front Door (qui est L7).
• Use case : "TCP/UDP multi-région avec failover instant" (Traffic Manager DNS est trop lent).

B.5 Quand l'utiliser

• L4 régional simple (TCP/UDP, DB cluster, gaming, IoT) → Standard LB Public ou Internal.
• Chainage NVA (Palo Alto, F5) → Gateway LB.
• L4 global non-HTTP avec failover instant → Cross-Region LB.
• Pour L7 HTTP/S → préférer App Gateway (régional) ou Front Door (global).

B.6 Pièges 305

• 🚨 Basic SKU sunset → toujours Standard en prod.
• 🚨 Azure LB = L4 only : pas de SSL termination, pas de WAF, pas de path routing.
• 🚨 Cross-Region LB = L4 global anycast (différent de Traffic Manager qui est DNS).
• 🚨 Public vs Internal : 1 LB = 1 type, choisir selon scope.

C. Application Gateway (SHARED AZ-104 mais critique design)

🎯 Présentation

Load balancer L7 régional avec WAF intégré, path-based routing, SSL termination. Façade HTTPS pour apps déployées dans une région.

🏗️ Architecture

[Public/Private IP] → [Listener] → [Routing rule (priority v2)] → [Backend pool] + [Backend HTTP settings]

• Frontend IP : jusqu'à 4 (IPv4 public+privé, IPv6 public+privé) — dual-stack v2
• Listener : Basic (1 domaine) ou Multi-site (N domaines, wildcards *.contoso.com max 5/listener v2)
• Routing rule v2 : priority numérique (1-20000), Basic ou Path-based
• Backend pool : IP/FQDN/VM/VMSS/App Service/AKS via AGIC — pas multi-region
• Backend HTTP settings : port, protocole, cookie affinity, override hostname, custom probe, timeout, connection draining
• Health probe : default / 30s, custom /health recommandé
• TLS : termination + re-encryption optional. Cert depuis Key Vault (rotation auto via MI)
• Subnet dédié /27 min (recommandé /24 pour autoscale)
• Ports v2 : 1-64999 (sauf 22 si PE, 53)

🎚️ Tiers / SKU (v2)

AGW v1 deprecated, retire avril 2026 → toujours v2 design nouveau.

✅ Quand l'utiliser

• Load balancing L7 régional (1 région) avec WAF
• Path-based routing (/api/* → backend A, /static/* → backend B)
• Multi-site (N domaines même IP/port)
• SSL termination + cert via Key Vault
• Pour multi-region L7 → Front Door (AGW est régional uniquement)

D. Azure Traffic Manager

🎯 Présentation

Load balancer global DNS-based : pas un proxy, le client résout un FQDN et tape direct le backend. Idéal pour failover global non-HTTP et backends hors Azure.

🏗️ Architecture

• Profile Traffic Manager → FQDN *.trafficmanager.net
• DNS resolver retourne IP d'un endpoint selon la routing method
• Health probes : HTTP/HTTPS/TCP, intervalle 30s default
• Endpoints supportés : Azure (App Service, Public IP, Cloud Service), External FQDN (autres clouds, on-prem), Nested endpoints

🎚️ Tiers / SKU (Routing methods)

✅ Quand l'utiliser

• Trafic non-HTTP (TCP/UDP, gaming, IoT custom)
• Backends hors Azure (on-prem, autres clouds)
• Geographic routing strict (compliance data residency)
• Active-Passive cross-region simple
• Pour L7 HTTP + WAF + CDN global → préférer Front Door

🚨 Pièges

• Failover lent : limité par TTL DNS (default 60s) + cache resolver client
• Pas de proxy → pas de SSL termination, WAF, CDN, session affinity
• TTL trop bas (30s) = + de queries DNS = + cher
• Geographic routing utilise IP du DNS resolver (pas du client) → imprécis avec Google DNS 8.8.8.8
• Toujours définir endpoint Default sinon NXDOMAIN
• Probes externes payantes (External endpoints facturés différemment)

E. Azure Front Door

🎯 Présentation

Load balancer L7 global anycast (100+ POPs MS) avec CDN + WAF + SSL offload + Private Link backend. Solution pour exposer des apps multi-region avec latence optimale et sécurité avancée.

🏗️ Architecture

[Clients globaux] → DNS → Front Door anycast IP (POP edge)
                            ↓
                          [Endpoint = <name>.azurefd.net OR custom]
                            ↓
                          [Routes (pattern)] → [Origin Group] → [Origins]
                            (cache hit possible au POP)

Routing methods : Latency (default, POP le + rapide), Priority (active-passive), Weighted (A/B), Session affinity (sticky cookie). Caching : POP edge, TTL par route, compression Brotli/gzip, purge URL/wildcard.

🎚️ Tiers / SKU (2026)

✅ Quand l'utiliser

• App multi-region avec routage latence + failover instant (anycast)
• Besoin de CDN global + cache edge
• WAF + Bot Manager + Private Link backend → Premium
• Backends jamais exposés publiquement (zero-trust) → Premium + PE
• Pour single-region L7 sans CDN → préférer App Gateway

Front Door + Private Link (Premium) — zero-trust backend

• Backend privé (App Service+PE, Storage+PE, Internal LB)
• Approval workflow pour accepter la connexion Private Link
• Use case : backend jamais exposé publiquement

🚨 Pièges

• Classic tier sunset → toujours Standard/Premium pour nouveaux déploiements
• Private Link backend = Premium uniquement (Standard = backends publics)
• Cache TTL trop élevé sur /api/* → stale data → désactiver cache sur dynamic
• Custom domain : validation TXT DNS obligatoire + cert FD-managed (free) ou KV
• Anycast IP partagée → IP allowlist côté backend doit autoriser plages Front Door (utiliser Service Tag AzureFrontDoor.Backend)
• WAF mode Detection par défaut → activer Prevention en prod (après tuning)

F. WAF Policy — ressource indépendante

F.1 C'est quoi

Ressource Azure indépendante qui contient les règles WAF (managed + custom + bot manager). Attachée à un App Gateway OU à un Front Door (pas les 2).

F.2 Les 2 types de WAF policy + SKUs

🚨 1 WAF policy = 1 type de service (AGW ou FD, jamais réutilisable). Defense-in-depth = 2 policies.

F.3 Modes WAF (les 2 plateformes)

• Detection : log seulement → tuning 1-2 semaines
• Prevention : bloque → prod

F.4 Décision WAF

G. Comparaison Front Door vs Traffic Manager vs App Gateway vs LB

H. Decision tree consolidé AZ-305

Tu as quoi à load-balancer ?
├─ TCP/UDP non-HTTP (DB, gaming, custom protocol)
│   ├─ Intra-region                                  → Azure LB Standard (L4)
│   ├─ Cross-region failover instant                 → Cross-Region Load Balancer (L4 global)
│   └─ Cross-region failover OK lent (DNS)           → Traffic Manager
│
├─ HTTP/S régional (1 région, SSL, path routing)
│   ├─ Sans WAF                                      → Application Gateway Standard_v2
│   └─ Avec WAF                                      → Application Gateway WAF_v2 + WAF policy
│
├─ HTTP/S global (multi-région, edge, CDN)
│   ├─ Sans WAF avancé                               → Front Door Standard
│   ├─ Avec WAF managed + Bot Manager                → Front Door Premium + WAF policy
│   └─ Backend privé zero-trust (Private Endpoint)   → Front Door Premium + Private Link
│
├─ NVA chainage (Palo Alto / F5)                     → Gateway Load Balancer
│
├─ Failover DNS (Azure + autre cloud / on-prem)      → Traffic Manager
│
└─ Defense-in-depth bancaire/gov                     → Front Door + App Gateway + Firewall

I. Combo classique enterprise

[Internet] → [Front Door + WAF Premium global]
              ↓ Private Link
            [Application Gateway v2 regional]
              ↓
            [App Service / VMs (PE)]
              ↓
            [DB privée (SQL/Cosmos + PE)]

J. Scénarios 305 → solution

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

Scénario 1 : E-commerce retail — plateforme web multi-région 24/7

Contexte business : retailer européen, pics Black Friday (x20 trafic). Backends App Service en West Europe + North Europe. Besoin : WAF managé OWASP, protection anti-bots (scraping prix, credential stuffing), cache du catalogue statique. Backends jamais exposés sur internet (zero-trust). Choix architectural : Azure Front Door Premium (proxy L7 mondial) + WAF policy (DRS managé + Bot Manager) + Private Link vers les App Services (accès public coupé). Front Door entre l'utilisateur et le backend, au plus près de l'attaquant. Architecture / pattern :

• 1 origin group, 2 origins (WEU + NEU), routing Latency, health probe /health
• /static/* : cache edge activé ; /api/* : cache désactivé (contenu dynamique)
• WAF en Prevention : DRS managé + Bot Manager + règle Rate Limit sur /api/*
• Origins joignables uniquement via Private Link (aucune IP publique backend) Trade-offs assumés :
• Gain : failover quasi instant (anycast, pas d'attente DNS), cache edge = moins de latence et moins de charge backend, sécurité en bordure
• Perte : tier Premium plus cher que Standard ; Front Door ne fait que du HTTP/S (pas de TCP/UDP brut) Pièges à éviter :
• Cacher /api/* → données périmées : pas de cache sur le dynamique
• Backend mal verrouillé : l'IP de Front Door est partagée entre tous les clients Azure → il faut filtrer le tag AzureFrontDoor.Backend + l'en-tête X-Azure-FDID, sinon l'origin reste joignable par d'autres
• Croire que Standard suffit : DRS managé + Bot Manager sont Premium only (Standard = règles custom seulement) 📐 Réf. WAF — Service guide Azure Front Door : le Well-Architected Framework recommande le tier Premium pour les managed WAF rules + Private Link, l'inspection request body activée, et TLS 1.2 minimum sur les profils Front Door. Lien

Scénario 2 : Gaming / IoT — backend UDP multi-région à failover instant

Contexte business : éditeur de jeux temps réel, serveurs de matchmaking en UDP (pas du HTTP), dans 3 régions. Besoin : bascule régionale instantanée (un failover lent coupe les parties) et une IP d'entrée stable à coder en dur côté client. Choix architectural : Cross-Region Load Balancer (tier Global du Standard LB, niveau L4) devant un Standard LB régional dans chaque région. Choisi car c'est un proxy L4 mondial qui gère l'UDP, sans dépendre du DNS. Architecture / pattern :

• Global LB : 1 IP anycast statique unique, annoncée partout, routing geo-proximity
• Son backend pool = les LB régionaux (chacun devant un VMSS de serveurs de jeu)
• Pass-through L4 → l'IP réelle du client est conservée (utile pour l'anti-triche)
• Health probe toutes les 5s ; une région KO est retirée de la rotation Trade-offs assumés :
• Gain : failover instant (proxy, pas d'attente DNS), IP unique stable, IP client préservée
• Perte : aucune fonction L7 (ni WAF, ni terminaison SSL, ni routing par chemin) ; limité aux home regions supportées Pièges à éviter :
• Le confondre avec Traffic Manager : TM est basé DNS → failover lent (cache resolver) ; pour de l'UDP instantané, c'est bien le Cross-Region LB
• Vouloir y faire du HTTP/S avec cache : ce n'est pas son rôle → Front Door
• Le backend port du Global LB doit correspondre au frontend port du LB régional 📐 Réf. Architecture Center — Load balancing options (global vs régional, HTTP vs non-HTTP) : l'arbre de décision officiel route le trafic non-HTTP(S) global vers Load Balancer (tier global), distinct de Traffic Manager (DNS) et de Front Door (L7). Lien

Scénario 3 : Industrie hybride — conformité géographique + backends on-prem et multi-cloud

Contexte business : groupe industriel à cheval sur Azure, un datacenter on-prem et AWS. Deux besoins : (1) envoyer chaque utilisateur vers l'endpoint de son pays pour la résidence des données (RGPD), (2) basculer en active-passive d'un primaire Azure vers un secours on-prem. Choix architectural : Azure Traffic Manager (routage par DNS) — profil Geographic pour la résidence + profils Priority imbriqués pour le failover Azure ↔ on-prem/AWS. Choisi car c'est le seul à router vers des backends hors Azure et tout type de trafic. Le tout sur une topologie hub-spoke avec lien hybride VPN/ExpressRoute. Architecture / pattern :

• Profil Geographic : pays → endpoints régionaux, avec un endpoint Default obligatoire (sinon NXDOMAIN)
• Profils Priority imbriqués pour le failover (primaire Azure, secours External FQDN on-prem/AWS)
• Endpoints External pour on-prem et AWS ; health probes HTTP/HTTPS/TCP
• Lien hybride hub-spoke : ExpressRoute (prod) + VPN Gateway route-based (secours), GatewaySubnet /26+ Trade-offs assumés :
• Gain : seul service qui équilibre des backends hors Azure et tout protocole ; routage par pays pour la conformité
• Perte : failover lent (dépend du cache DNS client) ; aucune fonction proxy (pas de SSL, WAF, cache) Pièges à éviter :
• Geographic : TM lit l'IP du resolver DNS, pas du client → imprécis si l'utilisateur passe par un DNS public (8.8.8.8) ; toujours définir un endpoint Default
• Baisser le TTL à 30s pour accélérer : ça multiplie les requêtes DNS (coût) sans rendre la bascule vraiment instantanée
• Vouloir du failover instant ici : il faut un proxy (Front Door en L7, Cross-Region LB en L4), pas du DNS 📐 Réf. CAF — Network topology and connectivity (design area) & hub-spoke : la design area « Network topology and connectivity » du Cloud Adoption Framework recommande la topologie hub-spoke (hub régional, connectivité hybride centralisée VPN/ExpressRoute) comme fondation pour les scénarios hybrides et multicloud. Lien

DEMO

Demo Portail — Regional Load Balancer (L4) pour 2 VMs

1. Load balancers > + Create — Basics : SKU Standard, Tier Regional, Type Public
2. Frontend IP : fe-public + new Public IP pip-lb (zone-redundant)
3. Backend pools : bp-vms, config NIC (ou IP), ajouter vm1 + vm2
4. Inbound rules > Load balancing rule :
   • Name lbr-http, Frontend fe-public, Backend bp-vms
   • Protocol TCP, Port (listen) 80, Backend port (send-to) 80
   • Health probe : + Create → Protocol HTTP, Port 80, Path /health (ou TCP)
   • Session persistence None, Idle timeout 4 min, TCP reset Enabled
   • Floating IP : Disabled (cas standard — voir ci-dessous)
5. Review + Create → test sur IP publique LB

Floating IP (Direct Server Return, DSR) — c'est quoi ? Par défaut, le LB réécrit l'IP destination vers l'IP privée du backend. Avec Floating IP enabled, l'IP frontend est préservée comme destination → la VM doit avoir une loopback interface configurée avec l'IP frontend. Cas AZ-305 : SQL Server Always On AG Listener, NVAs en cluster, réutiliser même port backend pour plusieurs LB rules. Sinon → Disabled.

Demo Portail — App Gateway v2 + Path-based routing (scénario 2 ACI)

Scénario : 2 ACI aci-app et aci-web (FQDN public). /app/* → aci-app, /web/* → aci-web, /* (default) → aci-app.

Étape 1 — App Gateway

1. Application Gateways > + Create → Basics :
   • Name agw-shop, Tier Standard V2 (ou WAF V2), Autoscale min 2 max 10, AZ 1+2+3
   • VNet vnet-agw, Subnet agw-subnet dédié /27 min (recommandé /24)
2. Frontends : Type Both (Public+Private possible v2) → pip-agw-shop zone-redundant
3. Backends : + Add a backend pool :
   • bp-aci-app → Target type IP address or FQDN = aci-app.eastus.azurecontainer.io
   • bp-aci-web → FQDN aci-web.eastus.azurecontainer.io

Étape 2 — Routing rule (Listener + Backend targets)

Configuration > Routing rules > + Add a routing rule : Name rr-shop, Priority 100 (v2 : 1-20000, bas = prioritaire)

Sous-onglet Listener :

• Listener name listener-https, Frontend Public, Frontend port 443, Protocol HTTPS
• Choose a certificate from Key Vault → KV kv-certs, cert cert-shop-contoso-com, MI mi-agw (RBAC "Key Vault Certificate User" + "Secrets User")
• Listener type : Basic (1 domaine) OU Multi site (N domaines via Host header, jusqu'à 100+ sites, wildcards *.shop.com max 5/listener)
• (Multi-site) Host name : shop.contoso.com

Sous-onglet Backend targets > Path-based :

• Default backend pool (obligatoire) : bp-aci-app + new HTTP setting hs-aci-app
• + Add multiple targets :
  • Path /app/*, Target name path-app, Backend bp-aci-app, settings hs-aci-app
  • Path /web/*, Target name path-web, Backend bp-aci-web, settings hs-aci-web

Backend settings (HTTP settings) :

• Backend protocol HTTP (ou HTTPS pour re-encryption), Backend port 80
• Cookie-based affinity : Disable (stateless) ou Enable (sticky)
• Connection draining 30-60s en prod
• Pick host name from backend target : Yes (sinon backend reçoit Host: shop.contoso.com → 404)
• Use custom probe : Yes → probe /health, match 200-399 (pas 200 strict pour gérer 302)

Étape 3 — Test

DNS : shop.contoso.com → pip-agw-shop → https://shop.contoso.com/app/... (ACI app), /web/... (ACI web), /... (default = ACI app).

Demo Portail — Traffic Manager Priority (2 VMs)

1. Traffic Manager profiles > + Create → Name myapp-prod (FQDN myapp-prod.trafficmanager.net), Routing Priority, RG rg-tm → Review + Create
2. myapp-prod > Configuration : TTL 30s, Protocol HTTPS, Port 443, Path /health, Interval 30s, Failures tolerated 3 → Save
3. myapp-prod > Endpoints > + Add (primary) : Type Azure endpoint, Target type Public IP, Target pip-vm1-eastus, Priority 1
4. + Add (secondary) : Target pip-vm2-weu, Priority 2
5. DNS public : app.contoso.com CNAME myapp-prod.trafficmanager.net
6. Test : nslookup myapp-prod.trafficmanager.net → IP vm1. Couper vm1 → après ≈ 3×30s probe failures → re-nslookup → IP vm2

Geographic routing : si method = Geographic, onglet Geographic mapping apparaît sur chaque endpoint pour associer les pays (EU → FR/DE/ES, etc). Traffic Manager utilise l'IP du DNS resolver (pas du client direct) → imprécis avec Google DNS 8.8.8.8. Toujours définir un endpoint Default sinon NXDOMAIN.

Demo Portail — Front Door (profile + endpoint + origin group)

Scénario : 2 App Services webapp-eastus + webapp-weu (peuvent être dans n'importe quelle région, contrairement à AGW qui est régional). Routing Latency.

1. Front Door and CDN profiles > + Create > Custom create
2. Basics : Profile name afd-shop, Tier Standard (LB+CDN+SSL+custom domain) ou Premium (Standard + Microsoft DRS + Bot Manager + Private Link backend)
3. Endpoints : + Add an endpoint → name shop-prod → URL shop-prod-<hash>.z01.azurefd.net (on peut créer plusieurs endpoints, ex shop/admin/api)
4. Origin groups : + Add → Name og-webapp, Health probe /health HTTPS 30s, Session affinity Disabled
5. Dans le groupe, + Add an origin (1er) :
   • Origin type : App Services (auto-discover Azure ; types possibles : App Service, Storage, Cloud Service, API Management, App Gateway, Public IP, Static Web App, Container Apps, Container Instances, Spring Apps, Custom pour non-Azure)
   • Host name : webapp-eastus.azurewebsites.net
   • Origin host header : auto-populé (override possible si backend attend autre host)
   • Priority 1, Weight 1000
   • Private link : (Premium only)
6. + Add an origin (2e) : webapp-weu.azurewebsites.net, Priority 1, Weight 1000
7. Routes : + Add a route → Name route-default, Patterns /*, Accepted protocols HTTPS only (redirect HTTP→HTTPS), Origin group og-webapp, Caching Disabled pour /api/*, Enabled pour /static/*
8. Custom domain : + Add → www.shop.com → validate TXT _dnsauth.www.shop.com → cert FD managed (free) ou KV → DNS www.shop.com CNAME shop-prod-xxx.azurefd.net

Origin type vs Origin host name : Origin type = catégorie de ressource (App Service, Storage, Custom...). Origin host name = FQDN réel joint par FD. Plusieurs origins dans un origin group = HA + LB. Routing method (Latency/Priority/Weighted) défini au niveau Route, pas origin group.

Demo Portail — Front Door Premium + Private Link backend (zero public)

1. App Service > webapp-eastus > Networking > Public access : Disabled
2. Front Door Premium > Origin groups > + Add an origin : type App Services, host webapp-eastus.azurewebsites.net, Private link Enable, Region East US, sub-resource sites
3. App Service > Networking > Private endpoint connections → connexion Front Door Pending → Approve
4. Flux : Client → Front Door (anycast public) → Private Link → App Service privé (aucune Public IP)

Demo Portail — Front Door Premium WAF

1. Front Door and CDN profiles > Create > Custom create → Tier Premium → Name myafd → Review + Create
2. WAF policies > + Create :
   • Policy for : Global WAF (Front Door), Tier Premium
   • Policy name : mywaf
   • Policy mode : Detection (audit avant Prevention)
3. Onglet Managed rules :
   • + Assign : Microsoft_DefaultRuleSet 2.1
   • + Assign : Microsoft_BotManagerRuleSet 1.0
4. Onglet Custom rules :
   • + Add : Name BlockNorthKorea, Priority 100, Match RemoteAddr GeoMatch KP, Action Block
   • + Add : Name RateLimitGlobal, Rate limit rule, Priority 200, threshold 1000/min, RequestUri contains /api/, Action Block
5. Onglet Association : associer au profile myafd (endpoint cible)
6. Review + Create
7. Après 1-2 semaines de tuning → mywaf > Policy settings > Mode = Prevention > Save

Managed vs Custom rules : Managed (DRS / CRS / Bot Manager) = règles MS auto-updated, désactivables individuellement. Custom = TES règles (match RemoteAddr/RequestUri + action Allow/Block/Log) priority 1-100 évaluées AVANT managed.

Demo Portail — App Gateway WAF v2

1. Application Gateways > Web Application Firewall > + Create policy
2. Basics : Policy for Regional WAF (Application Gateway), Name agwaf, Mode Detection (puis Prevention)
3. Onglet Managed rules : Rule set OWASP 3.2
4. Onglet Custom rules : + Add → Name BlockEU, Priority 100, Match RemoteAddr GeoMatch FR, DE, ES, Action Block
5. Onglet Association : associer au App Gateway myagw
6. Review + Create

WAF AGW vs FD : 1 policy = AGW OU FD (pas les 2). Defense-in-depth FD+AGW = 2 policies. AGW peut scope la WAF policy listener/path (granularité fine). FD = global au niveau profile/endpoint.