9 — Azure Load Balancer

Répartiteur de charge L4 (TCP/UDP) → distribue le trafic sur un backend pool, aveugle au contenu HTTP, en version publique ou interne.

A. Vue d'ensemble

Azure Load Balancer = load balancer L4 (Layer 4 — TCP/UDP). Il distribue le trafic sur un backend pool de ressources et sort les ressources unhealthy via les health probes.

A.1 L4 vs L7 — la distinction fondamentale

Le LB ne sait pas que /api/orders doit aller au backend orders : il route uniquement selon IP/port, jamais selon le contenu applicatif.

A.2 Quand utiliser Azure LB ?

• Trafic non-HTTP : bases de données (SQL listener), gaming (UDP), IoT, custom protocols
• Très haut débit / faible latence : millions de flux simultanés
• Load balancing interne entre tiers (app → DB)
• Chaînage de NVA (avec Gateway LB)
• ❌ Pour HTTP/S avec routing avancé, SSL, WAF → App Gateway (régional) ou Front Door (global)

B. Public vs Internal Load Balancer

💡 1 LB = 1 type (Public OU Internal). Pour les 2 besoins → 2 LB.

C. SKUs

Différences détaillées :

C.1 Matching SKU (piège classique)

• Le SKU du LB doit matcher celui de la Public IP (Standard ↔ Standard, Basic ↔ Basic)
• Une VM en backend peut ne pas avoir de Public IP (le LB sert de frontend)
• Si la VM a une Public IP, son SKU doit matcher celui du LB
• Résoudre un mismatch : upgrade la Public IP en Standard, OU retirer la Public IP de la VM

D. Composants

D.1 Les 4 composants clés

🚨 Le probe provient du Service Tag AzureLoadBalancer. Si un NSG bloque cette source, tous les backends apparaissent unhealthy et le trafic est dropé.

D.2 Health probe

• TCP probe : ouvre une connexion TCP sur le port → si succès, backend healthy
• HTTP/HTTPS probe : GET /path → attend un 200 OK
• Best practice : exposer un endpoint /health qui vérifie les dépendances (DB, cache), pas juste / qui retourne 200 même si l'app est cassée

D.3 Load Balancing Rule

Mappe le trafic frontend vers le backend :

• Frontend port (sur quoi on écoute, ex 80)
• Backend port (sur quoi on envoie, ex 80)
• Protocol : TCP / UDP
• Session persistence (voir §F)
• Idle timeout, TCP reset
• Floating IP (voir §E.3)

E. Règles spéciales

E.1 Inbound NAT Rule

Concept : un load balancing rule distribue vers tout le pool. Une Inbound NAT rule fait du port forwarding vers UNE seule VM précise.

Use case classique : accès RDP/SSH à des VMs individuelles derrière le LB, sans Public IP sur les VMs.

Exemple :

• LB Public IP : 50001 → VM1 privée : 3389 (RDP vers VM1)
• LB Public IP : 50002 → VM2 privée : 3389 (RDP vers VM2)

Chaque VM est joignable via un port unique sur l'IP publique du LB. Le LB NAT (traduit) le port public vers l'IP+port privé de la VM cible.

💡 Inbound NAT vs Load Balancing rule :

• Load balancing rule = 1 port frontend → tout le pool (distribution)
• Inbound NAT rule = 1 port frontend → 1 VM précise (forwarding)

E.2 Outbound Rule / SNAT

SNAT (Source NAT) : quand une VM en IP privée du backend pool sort vers internet, sa private IP est traduite en Public IP frontend du LB. Cette fonctionnalité est à utiliser avec parcimonie pour éviter le port exhaustion.

• Chaque connexion sortante consomme 1 port SNAT (~64k par Public IP)
• Trop de connexions simultanées → SNAT exhaustion = nouvelles sorties échouent

🚨 Standard LB bloque l'outbound par défaut → il faut soit une outbound rule, soit un NAT Gateway sur le subnet.

Outbound rule vs NAT Gateway (comparaison)

💡 Best practice 2026 : utiliser NAT Gateway sur le subnet pour l'outbound plutôt que les outbound rules du LB. Depuis le 31 mars 2026, les nouveaux VNets (créés via l'API) ont des subnets privés par défaut (plus de default outbound access implicite) → une méthode outbound explicite est obligatoire, NAT Gateway recommandé. (Voir fiche 1 §B.4.)

E.3 Floating IP (Direct Server Return / DSR)

Sans Floating IP (comportement par défaut) : le LB réécrit l'IP destination vers l'IP privée du backend. La VM reçoit le paquet destiné à sa propre IP.

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 pour accepter ces paquets.

Pourquoi ? Permet de :

• Réutiliser le même port backend pour plusieurs LB rules (avec plusieurs frontends)
• Configurations cluster qui ont besoin de voir l'IP frontend

Use cases typiques :

• SQL Server Always On Availability Group Listener
• NVA en cluster
• Plusieurs frontends sur le même port backend

💡 Cas standard (web app simple) → Floating IP Disabled. Cas cluster/SQL AG → Enabled + loopback configurée sur la VM.

E.4 HA Ports

HA Ports = une load balancing rule qui balance TOUS les ports et TOUS les protocoles simultanément (au lieu de spécifier un port précis).

Pourquoi ? Pour load-balancer tout le trafic sans énumérer les ports un par un.

Use case principal : NVA (firewalls) en active-active dans un VNet. Le firewall doit traiter tout le trafic (tous ports, tous protocoles) → impossible de créer une rule par port. HA Ports balance tout vers le pool de NVAs.

• Standard SKU ET Internal Load Balancer uniquement (pas Basic, pas Public LB) — c'est un piège classique : "Public LB + HA Ports" est un distracteur faux
• Configuré dans la load balancing rule : Protocol = All, Port = 0 (= tous)

F. Session Persistence (Distribution Mode)

Le mode de distribution contrôle la stickiness : faire revenir un même client sur le même backend.

Use case sticky : app stateful avec session/panier en mémoire sur le backend.

💡 Best practice moderne : app stateless (session dans Redis/DB), pas besoin de sticky → distribution optimale.

G. Gateway Load Balancer (AZ-700 specific)

G.1 Concept : bump-in-the-wire

Le Gateway Load Balancer (GWLB) insère de manière transparente des NVA (firewalls tiers, IDS/IPS) dans le chemin du trafic, avant qu'il atteigne l'application. C'est ce qu'on appelle le service chaining ou bump-in-the-wire.

Flux :

Internet → Public IP (Standard LB de l'app)
              ↓ (trafic encapsulé VXLAN)
          Gateway Load Balancer
              ↓
          NVA pool (firewall décapsule, inspecte, décide)
              ↓ (re-encapsule si OK)
          Gateway Load Balancer
              ↓ (décapsule)
          App backend (reçoit le trafic, source IP préservée)

G.2 VXLAN

Le trafic entre le Standard LB de l'app et le GWLB est encapsulé en VXLAN (Virtual Extensible LAN). Cela permet :

• De transporter le trafic vers les NVA sans modifier le routing existant
• De préserver l'IP source du client (le firewall voit la vraie IP)
• Le NVA décapsule, inspecte, re-encapsule

G.3 Flow symmetry & stickiness

Le GWLB garantit que les paquets aller et retour d'un même flux passent par la même instance NVA (flow symmetry) → essentiel pour les firewalls stateful (qui ont besoin de voir les 2 sens).

G.4 Cross-tenant / cross-subscription

Le VNet consumer (l'app) et le VNet provider (les NVA) peuvent être dans des subscriptions ou tenants différents → un fournisseur de sécurité managée peut opérer les NVA pour ses clients. ⚠️ Le cross-tenant chaining n'est pas supporté via le portail (CLI/PowerShell/ARM uniquement) ; il requiert la permission Microsoft.Network/loadBalancers/frontendIPConfigurations/join/action. (Le cross-region n'est pas un scénario documenté/supporté pour le chaînage GWLB.)

G.5 Quand utiliser GWLB ?

• Insérer un firewall tiers (Palo Alto, F5, Check Point, Fortinet) devant l'app sans refaire le routing
• Scaler les NVA en HA derrière un LB
• Conserver la même techno que l'on-prem (cohérence des règles)
• Alternative à Azure Firewall quand une stack NVA tierce existe déjà

H. Cross-Region Load Balancer (Global tier)

H.1 Concept

Le Cross-Region Load Balancer = tier Global du Standard LB. C'est un LB L4 global avec une IP anycast statique qui route vers des LB régionaux en backend.

              Cross-Region LB (anycast IP globale, statique)
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
   LB régional      LB régional      LB régional
   (West Europe)    (East US)        (SE Asia)
       │               │               │
   Backend VMs      Backend VMs      Backend VMs

H.2 Caractéristiques

• L4 global : le pendant L4 de Front Door (qui est L7)
• IP anycast statique : préservée, ne change jamais
• Failover instant (proxy, pas DNS comme Traffic Manager)
• Préserve l'IP client
• Le backend pool contient des Standard LB régionaux (pas des VMs directement)
• ❌ Ne marche pas avec un Gateway LB attaché aux LB régionaux

H.3 Quand l'utiliser ?

• TCP/UDP multi-région avec failover instant (Traffic Manager DNS est trop lent à cause du TTL)
• Apps non-HTTP qui ont besoin de présence mondiale
• Préservation de l'IP client cross-region

💡 Cross-Region LB vs Traffic Manager : les 2 sont globaux, mais Cross-Region LB est un proxy L4 (failover instant, préserve IP), Traffic Manager est DNS-based (failover lent, le client va direct au backend).

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

Scenario 1 : Gaming studio — backend matchmaking UDP haut débit

Contexte business : Un studio de jeux mobiles a des serveurs de matchmaking en UDP (ports 30000-30100). Jusqu'à 50k joueurs en même temps. Il faut du débit max et très peu de latence. Pas de HTTP ni de SSL ici. Choix architectural : Public Standard LB (niveau 4, TCP/UDP), affinité par IP source pour garder la session, et NAT Gateway pour gérer les nombreuses connexions sortantes. Architecture / pattern :

• Public Standard LB + IP publique Standard zone-redundant + un backend VMSS (50+ serveurs de jeu)
• Règle LB en UDP avec affinité IP source (2-tuple) : un joueur reste sur le même serveur toute sa partie
• Health probe en TCP sur le port 30099 : l'UDP n'a pas de sonde native, donc l'app expose un port TCP juste pour le health check
• NAT Gateway sur le subnet pour tout le trafic sortant (télémétrie App Insights, paiements) : c'est ce qui évite de manquer de ports SNAT
• Pour un plan de secours dans une autre région → Cross-Region LB (niveau 4 global, gère l'UDP, bascule instantanée) Trade-offs assumés :
• Gain : débit L4 UDP maximal à faible latence, ports SNAT garantis par NAT Gateway à 50k connexions.
• Perte : pas de WAF/TLS (L4 only), sonde UDP impossible → port TCP dédié à exposer pour le health check. Pièges à éviter :
• Utiliser une outbound rule du LB au lieu du NAT Gateway → on manque de ports SNAT en 10 min à 50k connexions. NAT Gateway obligatoire
• Le Standard LB bloque le sortant par défaut : sans NAT GW ni outbound rule, les serveurs ne peuvent même pas faire de DNS (et ça échoue sans message clair)
• Mettre une sonde HTTP sur / alors que c'est de l'UDP → il faut une sonde TCP dédiée
• Penser à Front Door ou App Gateway → ❌ ils ne font pas d'UDP. C'est LB (régional) ou Cross-Region LB (global)

📐 Réf. CAF/WAF — Load balancing options (sélection de service L4 non-HTTP) : pour du trafic TCP/UDP non-HTTP(S), Load Balancer (régional ou global) est le service recommandé ; Front Door et App Gateway sont HTTP(S) only. Lien

Scenario 2 : Banque — insertion firewall tiers via Gateway LB

Contexte business : Une banque utilise déjà des firewalls Palo Alto VM-Series on-prem. Elle migre des apps web vers Azure mais veut garder Palo Alto pour l'inspection (mêmes règles, équipe déjà formée, compliance). Elle ne veut pas d'Azure Firewall, qui est une autre techno. Choix architectural : Gateway Load Balancer avec les Palo Alto en backend (HA active-active), branché de façon transparente devant les Public LB des apps. Architecture / pattern :

• VNet provider : le GWLB + un pool de Palo Alto VM-Series (HA, encapsulation VXLAN, symétrie des flux)
• VNet(s) consumer : les Public Standard LB des apps web, reliés au GWLB
• Tout le trafic internet → IP publique de l'app → encapsulé en VXLAN → GWLB → Palo Alto (inspecte) → ré-encapsulé → backend de l'app
• L'IP réelle du client est conservée (Palo Alto voit la vraie IP pour ses règles géo/menaces)
• Le GWLB marche entre souscriptions : le VNet provider (équipe sécu) est dans une souscription séparée des apps (équipes dev) Trade-offs assumés :
• Gain : réutilisation des Palo Alto et des règles existantes, insertion transparente et symétrique sans UDR.
• Perte : NVA tierces à exploiter (pas de Firewall managé), pool HA à dimensionner, incompatible Cross-Region LB. Pièges à éviter :
• Faire le chaînage avec des UDR plutôt qu'un GWLB → fragile, pas de symétrie des flux garantie. Le GWLB est transparent et symétrique
• Une seule instance Palo Alto → point unique de panne. Il faut un pool HA active-active derrière le GWLB
• Oublier que l'IP source est conservée : les règles Palo basées sur l'IP client marchent (alors qu'un proxy classique masquerait l'IP)
• Vouloir mettre un Cross-Region LB par-dessus un GWLB → ❌ incompatible

📐 Réf. CAF/WAF — Gateway Load Balancer (insertion NVA / service chaining) : le GWLB insère les NVA de façon transparente avec flow symmetry et stickiness garanties, sans UDR, recommandé pour les scénarios north-south avec NVA tierces. Lien

Scenario 3 : SQL Server Always On — Internal LB + Floating IP

Contexte business : Migration vers Azure IaaS d'une app .NET avec SQL Server en cluster Always On (2 nœuds). Le listener de l'Availability Group a besoin d'une IP qui passe du nœud primaire au secondaire en cas de bascule. Choix architectural : un Internal Standard LB avec Floating IP activé pour le listener, et un health probe sur le port de sonde SQL. Architecture / pattern :

• 2 VMs SQL Server (primaire + secondaire) dans un subnet data
• Internal Standard LB dont l'IP privée frontend = l'IP du listener (ex 10.0.3.10)
• Backend : les 2 VMs SQL
• Floating IP : activé : l'IP frontend est conservée, et chaque VM porte cette IP listener sur une interface loopback
• Health probe sur un port SQL dédié (ex 59999) : seul le nœud primaire répond "sain", donc le trafic part vers lui
• En cas de bascule, le secondaire devient primaire et répond à la sonde → le LB redirige automatiquement Trade-offs assumés :
• Gain : listener AG hautement disponible, bascule automatique du trafic vers le nœud primaire sain.
• Perte : configuration loopback + Floating IP sur chaque VM SQL obligatoire, port de sonde dédié à maintenir. Pièges à éviter :
• Floating IP désactivé → le cluster ne marche pas (l'IP listener ne peut plus passer d'un nœud à l'autre)
• Oublier de configurer la loopback avec l'IP listener sur les VMs SQL → les paquets sont jetés
• Sonder le port SQL 1433 (toujours ouvert sur les 2 nœuds) au lieu du port de sonde dédié → le LB envoie au secondaire (lecture seule) → erreurs d'écriture
• Mettre un Public LB au lieu d'un Internal → la base est exposée sur internet, gros problème de sécu

📐 Réf. CAF/WAF — Internal LB + Floating IP (pattern SQL AG Listener) : l'AG Listener s'implémente avec un Internal Standard LB, Floating IP (DSR) Enabled et un health probe sur port dédié pointant le nœud primaire. Lien

DEMO — chemins portail

1. DEMO — Configure Azure Load Balancer (Standard)

Use case : 2 VMs en backend, LB Standard public.

Étape 1 — Créer le Load Balancer :

Home > Load balancers > + Create

1. Basics :
   • SKU : Standard
   • Type : Public
   • Tier : Regional
   • Name : lb-web
2. Frontend IP configuration : + Add
   • Name : fe-public
   • Public IP : créer pip-lb-web (Standard, Zone-redundant)
3. Backend pools : + Add
   • Name : bp-web
   • Backend Pool Configuration : NIC (ou IP Address)
   • Ajouter vm1 et vm2
4. Inbound rules > Load balancing rule : + Add
   • Name : lbr-http
   • Frontend IP : fe-public
   • Backend pool : bp-web
   • Protocol : TCP, Port 80, Backend port 80
   • Health probe : + Create → HTTP, port 80, path /health
   • Session persistence : None
   • Idle timeout : 4 min, TCP reset : Enabled
   • Floating IP : Disabled (cas standard)
5. Review + create

Test : ouvrir l'IP publique du LB dans un navigateur → réponse alternée des 2 VMs.

2. DEMO — Ajouter une Inbound NAT Rule (RDP vers VM1)

Load balancer > Inbound NAT rules > + Add

• Name : rdp-webvm1
• Frontend IP : fe-public
• Frontend port : 50001 (port public unique)
• Backend pool / Target VM : vm1
• Backend port : 3389 (RDP)
• Protocol : TCP

Test : mstsc /v:<IP-publique-LB>:50001 → connexion RDP à VM1 (le LB NAT le port 50001 public vers 3389 privé de VM1).

3. DEMO — Outbound SNAT Rule

Use case : permettre aux VMs du backend de sortir vers internet via l'IP frontend.

Load balancer > Outbound rules > + Add

• Name : outbound-web
• Frontend IP : fe-public (l'IP utilisée pour le SNAT)
• Backend pool : bp-web
• Protocol : All
• Port allocation : Manual (ex 1024 ports par instance) ou par défaut
• Idle timeout : 4 min

⚠️ Recommandation : pour la prod, préférer un NAT Gateway sur le subnet (gestion automatique des ports, pas de risque d'exhaustion). Les outbound rules LB sont à utiliser avec parcimonie.

4. DEMO — Configurer Gateway Load Balancer

Use case : insérer des NVA devant l'app via GWLB.

Étape 1 — Créer le Gateway Load Balancer :

Home > Load balancers > + Create

1. Basics :
   • SKU : Gateway
   • Name : gwlb-security
2. Frontend IP : IP du GWLB
3. Backend pool : ajouter les NVA (firewalls)
   • Le protocole interne sera VXLAN (identifiers internal/external)
   • HA Ports automatiquement (tout le trafic)
4. Load balancing rule : HA Ports (All protocols, all ports)
5. Review + create

Étape 2 — Chaîner le GWLB au LB de l'app :

Load balancer de l'app (lb-web) > Frontend IP configuration > fe-public > Gateway Load Balancer

• Sélectionner gwlb-security
• Save

Résultat : tout le trafic qui arrive sur lb-web est d'abord envoyé (encapsulé VXLAN) au gwlb-security → inspecté par les NVA → renvoyé vers le backend de l'app.

5. DEMO — Global / Cross-Region Load Balancer

Use case : LB global devant des LB régionaux.

Prérequis : des LB Standard régionaux déjà déployés (ex lb-weu, lb-eus), chacun avec son backend pool de VMs.

Étape 1 — Créer le Cross-Region LB :

Home > Load balancers > + Create

1. Basics :
   • SKU : Standard
   • Tier : Global
   • Name : lb-global
2. Frontend IP : IP anycast globale (Public IP Standard, Global tier)
3. Backend pool : ajouter les LB régionaux (lb-weu, lb-eus) — pas des VMs directement
4. Load balancing rule : port frontend → backend
5. Review + create

Test : l'IP globale anycast route automatiquement vers le LB régional le plus proche / disponible. Si une région tombe → failover instant vers l'autre.

⚠️ Ne marche pas si un Gateway LB est attaché aux LB régionaux.