6 — Connectivity and Load Balancing (AZ-305)

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

🎚️ 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

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

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 (depuis fiche 7 retiré)

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 (depuis fiche 7 retiré)

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.