10 — Load Balancing & Edge Security

Distribuer le trafic + sécuriser les accès au périmètre Azure :

• Load Balancing : LB (L4), App Gateway (L7 régional), Front Door (L7 global), Traffic Manager (DNS global)
• Edge Security : Azure Firewall (filtre L3-L7), Azure Bastion (RDP/SSH sans Public IP)

A. Décider : quel service de load balancing ?

Règle d'or AZ-104 : multi-region + L7 + WAF + CDN → Front Door. Single-region L7 → App Gateway. Trafic non-HTTP (DB, IoT, gaming) → LB. Active-passive simple cross-region → Traffic Manager.

B. Azure Load Balancer

L4 (TCP/UDP), distribue le trafic vers un backend pool (VMs, VMSS, NICs). Très haute perf, faible latence.

Types

SKUs

Le SKU du LB doit matcher celui de la Public IP + des VMs en backend.

Backend pool — règles à connaître (piège exam)

Pour attacher une VM au backend pool d'un Standard LB :

• ✅ La VM peut être en état Stopped (Deallocated ou Running)
• ✅ La VM 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 (Public IP Standard ↔ LB Standard, Basic ↔ Basic)
• → Pour résoudre un mismatch : upgrade la Public IP en Standard, OU retire la Public IP de la VM (la VM peut être attachée sans Public IP)

Composants

Outbound (piège classique)

• Standard LB bloque outbound par défaut → besoin d'outbound rule OU NAT Gateway sur le subnet.
• 🚨 Default outbound access des nouveaux VNets retiré après 31 mars 2026 → MS pousse NAT Gateway comme méthode standard.

Algorithmes de distribution

• 5-tuple hash (default) : src IP + src port + dst IP + dst port + protocol → distribue.
• Source IP affinity (2-tuple ou 3-tuple) : sticky session par IP source.
• HA Ports (Standard only) : load-balance tous les ports simultanément (utilisé pour NVA actives-actives).

Distribution mode (session persistence)

• None : default
• Client IP : 2-tuple (src IP + dst IP)
• Client IP + Protocol : 3-tuple

C. Application Gateway

L7 (HTTP/HTTPS/HTTP/2/WebSockets) régional, dans ton VNet. Routing avancé + WAF.

SKUs

Architecture

Client → Frontend IP (Public/Private)
          ↓
        Listener (HTTP/HTTPS, port, host header) — termine SSL ici
          ↓
        Routing rule (Basic ou Path-based)
          ↓
        Backend HTTP setting (port, protocol, timeout, probe)
          ↓
        Backend pool (VMs, VMSS, App Service, IPs, FQDNs)

Composants clés

• Listener : ce qu'écoute l'AGW (port, protocol, host header pour multi-site).
• Backend pool : VMs / VMSS / App Service / IPs / FQDN.
• HTTP settings : comment l'AGW parle au backend (port, probe, cookie affinity, override host header).
• Rules :
  • Basic : 1 listener → 1 backend pool
  • Path-based : /api/* → pool A, /images/* → pool B
• Probes : custom (path, intervalle, threshold) — checker la santé.
• Rewrite rules : modifier headers/URL en flight.

Features importantes

• SSL termination : décharge SSL côté AGW, trafic HTTP en interne (ou re-encrypt SSL en backend).
• End-to-end SSL : SSL re-chiffré vers le backend.
• WebSocket / HTTP/2 : supportés.
• Multi-site hosting : un seul AGW pour app1.com, app2.com (via host header).
• Autoscaling v2 : min/max instances, instances facturées par capacity unit (CU).
• Subnet dédié dans le VNet (réservé à l'AGW, /27 minimum).
• AGIC (App Gateway Ingress Controller) pour AKS.

💡 App Gateway mode interne (ILB-like L7) : App Gateway peut avoir un Frontend IP privé (au lieu de public) → fonctionne comme un ILB L7 pour des apps LOB accessibles uniquement depuis VNet, VNets peerés, ou on-prem (via VPN/ER).

Use case typique : LB du trafic on-prem multi-sites (S2S VPN) vers backend VMSS Azure avec routing L7 + SSL termination, sans exposer publiquement. Pour ce scénario → App Gateway interne OU Internal LB (L7 vs L4 selon besoin).

WAF v2

• OWASP Core Rule Set (3.2 / 3.1 / 3.0) — règles préconfigurées contre injection SQL, XSS, etc.
• Custom rules : whitelist IP, geo-block, rate limit (preview).
• Bot Manager : block bad bots.
• Modes : Detection (log only) ou Prevention (block).

D. Azure Front Door

L7 global (anycast, edge MS dans 100+ POPs). Fait : load balancing global + CDN + WAF global + SSL offload.

SKUs

Use cases

• App multi-region : route les utilisateurs vers le backend régional le plus proche.
• Static + dynamic content acceleration.
• Failover global (region down → bascule vers la suivante).
• WAF global au plus proche de l'attaquant (avant que la requête atteigne le backend).

Routing methods

Architecture

• Endpoint : URL globale <name>.azurefd.net (ou custom domain).
• Origin group : pool de backends (App Service, VM, Storage static site, AGW, IP arbitraire).
• Origin : un backend individuel (avec health probe, priority, weight).
• Route : matche un pattern (/api/*) → origin group.

Front Door + Private Link (Premium)

• Backend privé (App Service avec PE, Storage avec PE, ILB) accessible depuis Front Door sans l'exposer publiquement.
• Approval workflow.

Pour AZ-104 : retenir Front Door = global + WAF + CDN. Souvent utilisé devant App Gateway pour combo edge + régional.

E. Traffic Manager

DNS-based load balancer global. Renvoie l'IP du backend le plus approprié à chaque résolution DNS.

Routing methods

Limites par rapport à Front Door

• Failover lent (dépend du TTL DNS, default 60s+).
• Pas de SSL termination, pas de WAF, pas de CDN.
• Le client va directement au backend (pas de proxy au milieu).

Quand préférer Traffic Manager à Front Door

• Trafic non-HTTP (TCP/UDP).
• Backend hors Azure (sites on-prem, autres clouds).
• Geographic routing strict (compliance).

F. Azure Firewall

Pare-feu stateful L3-L7 managé, avec haute dispo intégrée. Souvent utilisé en hub dans une architecture hub-and-spoke pour filtrer le trafic egress + east-west.

SKUs

Composants

• Firewall policy (recommandé) : ressource séparée qui contient les règles, héritable (parent → enfant).
• Rule collections dans la policy :
  • DNAT rules : forwarding inbound (Public IP firewall → IP privée backend)
  • Network rules : L3-L4 (IP / Port / Protocol)
  • Application rules : L7 (FQDN, FQDN tags, web categories en Premium)
• Priority dans collections : 100-65000.
• Default action : Deny.

FQDN Tags (Standard+)

Préconfigurés MS (similaire aux Service Tags NSG mais L7) :

• WindowsUpdate, WindowsDiagnostics, MicrosoftActiveProtectionService, AppServiceEnvironment, AzureKubernetesService, etc.

Threat Intelligence (Standard+)

• Block / alert sur des IPs/domains malveillants connus (feed MS).
• Modes : Off, Alert only, Alert and deny.

TLS Inspection (Premium uniquement)

• Décrypte HTTPS sortant, inspecte, re-chiffre.
• Nécessite : KV avec un certificat root + Managed Identity du firewall.

Subnet

• Dédié : AzureFirewallSubnet (/26 minimum, pas de NSG dessus).
• Pour Forced Tunneling (Standard+) : AzureFirewallManagementSubnet additionnel.

Vs NSG

Combo classique : NSG sur subnets pour le micro-segmentation interne + Azure Firewall en hub pour le trafic nord-sud.

G. Azure Bastion

RDP / SSH vers tes VMs Azure depuis le portail web, sans Public IP sur les VMs et sans VPN. Sécurise drastiquement l'accès admin.

Architecture

• Service déployé dans un VNet (subnet dédié AzureBastionSubnet, /26 minimum).
• Tu te connectes via le portail Azure → Bastion ouvre une session SSL/HTML5 vers la VM en privé.
• VM accessible via Bastion sur tous les VNets peerés.

SKUs

🚨 Piège exam : pour accommoder >40 users RDP simultanés il faut :

1. Upgrade SKU Basic → Standard (étape first ; sans ça pas de scaling possible)
2. Increase instance count (ex 5 instances × 20 RDP = 100 simultanés)

⚠️ Upgrade Basic → Standard est IRRÉVERSIBLE (pas de downgrade possible). Réfléchir avant.

Calcul rapide : ~20 RDP ou ~40 SSH par instance → si 90 users RDP → besoin 5 instances minimum (5×20=100 RDP).

Sécurité

• VMs cibles n'ont pas besoin de Public IP → réduction surface d'attaque.
• NSG sur la VM bloque RDP/SSH depuis Internet → seul Bastion (depuis AzureBastionSubnet) y accède.
• Auth = Entra ID (avec RBAC) ou local user de la VM.

Subnet

• AzureBastionSubnet (nom obligatoire, /26 minimum).
• Pas de NSG strict requis (Bastion gère sa propre sécurité), mais possible avec règles spécifiques MS.

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

Scenario 1 : E-commerce mono-région avec checkout sécurisé

Contexte business : un retailer FR (~2M visites/mois) a un site Magento sur VMSS, paiement via prestataire externe. Il faut un pare-feu web (le paiement est la cible n°1), gérer le SSL au même endroit, et envoyer /checkout/* vers des VM dédiées plus puissantes. Choix architectural : App Gateway WAF v2 en frontal + un Internal LB (Standard) entre l'app et les bases de lecture. Pas de Front Door : une seule région, pas besoin de CDN. Architecture / pattern :

• AGW WAF v2 public en mode Prevention (OWASP CRS 3.2). Il route /checkout/* vers le pool premium, le reste vers le pool standard.
• SSL ré-encrypté jusqu'au backend (bout en bout, exigé par PCI DSS).
• Sonde de santé sur /health (pas /, qui répond 200 même si la base est tombée).
• Derrière, un ILB Standard répartit les lectures vers les réplicas SQL (port 1433). Trade-offs assumés :
• Gain : WAF L7 + path routing + SSL bout en bout sur un seul point, conforme PCI DSS.
• Perte : AGW WAF v2 + subnet dédié plus coûteux et complexe qu'un simple LB pour une app mono-région. Pièges à éviter :
• AGW doit avoir son propre subnet vide, /27 minimum, sans NSG qui bloque les ports de management Microsoft (65200-65535 en v2).
• Oublier de passer le WAF en Prevention : en Detection il ne fait que logger, il ne bloque rien.
• AGW v2 exige une IP publique Standard (Basic refusée).

📐 Réf. CAF — Load balancing decision tree + WAF (App delivery) : App Gateway WAF_v2 (L7 régional + path routing + SSL e2e) est le choix CAF pour une app web régionale avec WAF. Lien

Scenario 2 : Gaming studio — backend matchmaking UDP

Contexte business : un studio de jeu mobile a ses serveurs de matchmaking en UDP (ports 30000-30100), 50K joueurs en même temps. Il faut un maximum de débit et une latence très faible. Pas de HTTP ni de SSL côté LB. Choix architectural : un Public Standard LB (niveau 4, TCP/UDP, gère des millions de flux), HA Ports si un pare-feu maison tourne en actif-actif, et une règle outbound explicite + NAT Gateway pour gérer le gros volume de SNAT. Architecture / pattern :

• LB Standard avec une IP publique Standard en frontal et un pool VMSS de 50+ serveurs de jeu.
• Règle UDP avec affinité par IP source (2-tuple) : un joueur reste sur le même serveur toute sa partie.
• Sonde de santé en TCP sur le port 30099 (l'UDP n'a pas de sonde native) : l'app expose ce point TCP exprès.
• NAT Gateway sur le subnet pour la télémétrie sortante (vers Application Insights, etc.). Trade-offs assumés :
• Gain : débit L4 massif à faible latence pour l'UDP, SNAT maîtrisé via NAT Gateway.
• Perte : pas de routing L7 ni de WAF au niveau LB, et la sonde UDP doit être simulée en TCP. Pièges à éviter :
• Le Basic LB est retiré depuis le 30 sept 2025 : un vieux script qui ne précise pas le SKU prend Basic par défaut, à migrer avant.
• Le Standard LB bloque le trafic sortant par défaut : sans règle outbound ni NAT Gateway, les VMs ne peuvent même pas résoudre un DNS (panne silencieuse).
• Front Door est inutile ici (pas d'UDP). Pour du DR cross-région : Traffic Manager (basé DNS, compatible UDP car il route l'IP de destination).

📐 Réf. CAF — Load balancing decision (non-HTTP) : pour du TCP/UDP haut débit, le Standard LB (L4) est le choix CAF ; pour le global non-HTTP, Traffic Manager (DNS) ou Cross-Region LB (proxy L4). Lien

Scenario 3 : Application LOB interne (banking, accès on-prem uniquement)

Contexte business : une banque régionale a une app intranet (RH, paie). Elle doit être joignable uniquement depuis le réseau de l'entreprise via ExpressRoute. Il faut du routing niveau 7 + WAF (conformité), sans aucune exposition sur Internet. Choix architectural : un App Gateway interne (IP frontale privée) + Azure Bastion Standard pour administrer les VMs backend (les VMs n'ont jamais d'IP publique). Architecture / pattern :

• AGW v2 WAF avec une IP frontale privée dans son subnet dédié (/27).
• Via ExpressRoute, les postes on-prem atteignent cette IP privée.
• WAF en Prevention même en interne : un attaquant déjà dans le réseau passe aussi par là (défense en profondeur).
• Bastion Standard (2 à 5 instances) dans AzureBastionSubnet /26 pour administrer les VMs sans IP publique, avec audit Entra ID. Trade-offs assumés :
• Gain : zéro exposition Internet (frontend privé + VMs sans IP publique), conforme à l'audit d'isolation.
• Perte : accès limité au réseau d'entreprise (ExpressRoute requis) et Bastion Standard en coût fixe. Pièges à éviter :
• Penser qu'« interne = pas besoin de WAF » : un poste compromis sur le réseau contourne tout le reste.
• Le passage Bastion Basic → Standard est irréversible : prendre Standard dès le départ si plus de 40 sessions RDP simultanées sont prévues.
• AGW interne + DNS : il faut une Private DNS Zone pour résoudre app.corp.local vers l'IP privée de l'AGW, sinon les clients on-prem ne le trouvent pas.

📐 Réf. WAF — Security (private app delivery) + Bastion : App Gateway interne (frontend privé) + WAF + Azure Bastion (zéro IP publique sur les VMs) appliquent la défense en profondeur Well-Architected pour les apps internes. Lien

DEMO — chemins portail

Standard Load Balancer

1. Load balancers > Create > SKU: Standard, Type: Public/Internal
2. Frontend IP : nouvelle Public IP Standard ou IP privée
3. Backend pool : add VMs / VMSS
4. Health probe : TCP/HTTP path
5. LB rule : frontend port → backend port (avec persistence, idle timeout)
6. Outbound : créer outbound rule OU attacher NAT GW au subnet backend

Inbound NAT rule (RDP/SSH par VM via LB)

1. LB > Inbound NAT rules > Add
2. Service Custom, frontend port unique (ex 50001), target VM, target port 3389
3. Tester mstsc <lb-ip>:50001

Application Gateway v2

1. Application Gateways > Create > Tier: Standard v2 ou WAF v2
2. Onglet Configuration :
   • Frontend IP (Public et/ou Private)
   • Backend pool : VMs/VMSS/App Service/IP
   • Routing rule : Listener (HTTP/HTTPS) → Backend pool + HTTP settings
   • HTTP settings : port backend, probe, cookie affinity
3. Subnet dédié dans le VNet (/27 minimum, vide)
4. Pour WAF v2 : WAF policy — choisir mode Detection ou Prevention, OWASP CRS

App Gateway — path-based routing

1. Créer plusieurs backend pools (api-pool, images-pool)
2. Listeners > Add : 1 listener HTTPS port 443
3. Rules > Add path-based rule :
   • /api/* → api-pool
   • /images/* → images-pool
   • default → main-pool

Front Door Standard/Premium

1. Front Door and CDN profiles > Create > Custom create
2. Endpoint : <name>.azurefd.net
3. Origin group : add origins (ex App Service, AGW, Storage static site)
4. Routes : pattern /* → origin group, caching on/off, compression
5. Custom domain : ajouter le domaine + valider via TXT record + bind cert
6. WAF Premium : créer une WAF policy Front Door + attacher à l'endpoint

Traffic Manager

1. Traffic Manager profiles > Create
2. Choisir routing method (Priority, Weighted, Performance, Geographic, etc.)
3. Add endpoints : Azure (App Service, Public IP, Cloud Service) ou External (FQDN)
4. Health monitoring : protocol, port, path, interval
5. Tester avec nslookup <profile>.trafficmanager.net

Azure Firewall

1. Subnet : créer AzureFirewallSubnet (/26) dans le VNet hub
2. Firewalls > Create > SKU: Basic/Standard/Premium
3. Choisir Firewall Policy (créer une nouvelle)
4. Rule collections dans la policy :
   • DNAT : Public IP:8080 → 10.1.0.4:80
   • Network : 10.0.0.0/8 → Internet ports 443 Allow
   • Application : *.windowsupdate.com Allow ou FQDN tag WindowsUpdate
5. UDR sur les subnets spokes : 0.0.0.0/0 → Next hop = Virtual Appliance, IP du firewall

Azure Firewall Premium — TLS Inspection

1. Créer un Key Vault avec certificat root + Managed Identity
2. Firewall Policy > TLS inspection > Enable → choisir le KV + cert
3. Ajouter une Application Rule Collection avec TLS inspection enabled

Azure Bastion

1. Subnet : créer AzureBastionSubnet (/26 exact name, /26 minimum) dans le VNet
2. Bastions > Create > SKU: Developer/Basic/Standard/Premium
3. Public IP Standard (auto)
4. Pour Standard+ : choisir scale units (2-50), file transfer
5. Connexion : VM > Connect > Bastion → user/password ou SSH key (ou Entra ID si Standard+)

Bastion + Entra ID auth (Standard+)

1. VM Linux : installer Entra ID login extension
2. RBAC : assigner Virtual Machine Administrator Login ou Virtual Machine User Login
3. Connect via Bastion → choisir Entra ID