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.

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

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

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

Contexte business : retailer FR (~2M visites/mois) — site web Magento sur VMSS, paiement via PSP externe. Besoin de filtrage WAF (carte = cible #1), SSL termination centralisée, routing /checkout/* vers un pool VM dédié (instances plus grosses, isolation perf). Choix techniques : App Gateway WAF v2 en frontal + Internal LB (Standard) entre tier app et tier DB read-replicas. Pas besoin de Front Door (single region, pas de CDN critique). Architecture / pattern :

• AGW WAF v2 public (Prevention mode, OWASP CRS 3.2) → path-based routing /checkout/* → pool premium, reste → pool standard
• HTTP settings : re-encrypt SSL end-to-end vers backend (PCI DSS)
• Health probe custom /health (pas / qui retourne 200 même si DB down)
• ILB Standard derrière pour load balance les lectures vers SQL replicas (port 1433) Pièges à éviter :
• AGW subnet dédié /27 minimum vide — pas de NSG bloquant les ports MS de management (65200-65535 v2)
• Oublier d'activer WAF en Prevention (rester en Detection = log only, aucune protection réelle)
• Public IP Standard obligatoire pour AGW v2 (Basic refusé)

Scenario 2 : SaaS B2B multi-tenant (40+ domaines clients)

Contexte business : éditeur SaaS RH — chaque client a son sous-domaine (client1.app.com, client2.app.com…). 1 codebase, isolation logique par tenant. Veut centraliser TLS + WAF + scaling auto. Choix techniques : App Gateway WAF v2 avec multi-site hosting (jusqu'à 100+ sites sur 1 AGW), 1 listener HTTPS multi-site par host header, WAF policy custom par site sensible. Architecture / pattern :

• 1 listener Multi-site HTTPS port 443 avec SNI → matche le host header
• 1 routing rule par client (ou wildcard *.app.com + rewrite rule pour extraire le tenant)
• WAF policy globale OWASP CRS 3.2 + WAF policies spécifiques sur les sites VIP (mode Prevention strict)
• Autoscaling v2 : min 2 / max 20 instances → encaisse les pics paie de fin de mois Pièges à éviter :
• Limite 40 sites WAF par AGW (au-delà : 2e AGW, pas un seul géant) — au-delà → Front Door
• Certificats : monter via KV reference + Managed Identity AGW (pas upload manuel renouvelable à la main)
• v1 Standard/WAF en retraite 28 avril 2026 → si legacy, migrer v2 maintenant

Scenario 3 : Gaming studio — backend matchmaking UDP

Contexte business : studio mobile gaming — serveurs matchmaking proprio (UDP 30000-30100), 50K joueurs concurrents, besoin throughput max + latence ultra-faible. Pas de HTTP, pas de SSL côté LB. Choix techniques : Public Standard LB (L4 TCP/UDP, millions de flux), HA Ports pour NVA active-active si firewall maison, outbound rule explicite + NAT Gateway pour SNAT massif. Architecture / pattern :

• LB Standard avec frontend Public IP Standard + backend pool VMSS (50+ VMs game servers)
• Load balancing rule UDP avec Source IP affinity (2-tuple) : un joueur reste sur le même serveur pendant sa session
• Health probe TCP custom port 30099 (UDP n'a pas de probe natif) — l'app expose un endpoint TCP de health
• NAT Gateway sur le subnet pour outbound télémétrie (vers Application Insights, etc.) Pièges à éviter :
• Basic LB retiré 30 sept 2025 : si vieux script utilise Standard_LB SKU = Basic implicite → migration obligatoire avant
• Standard LB bloque outbound par défaut : sans outbound rule ni NAT GW les VMs ne peuvent pas faire de DNS → silent fail
• Front Door inutile ici (UDP non supporté). Pour DR cross-region : Traffic Manager (DNS-based, supporte UDP en routant l'IP de destination)

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

Contexte business : banque régionale — app intranet (ressources humaines, paie). Accès uniquement depuis le réseau corporate via ExpressRoute. Besoin de routing L7 + WAF (compliance) sans aucune exposition publique. Choix techniques : App Gateway interne (Frontend IP privé) + Azure Bastion Standard pour accès admin VMs backend (jamais de Public IP sur les VMs). Architecture / pattern :

• AGW v2 WAF avec Frontend Private IP dans subnet dédié (/27)
• ExpressRoute → on-prem clients atteignent l'IP privée AGW
• WAF en Prevention même en interne (defense in depth — un attaquant insider passe par là)
• Bastion Standard (host scaling 2-5 instances) dans AzureBastionSubnet /26 pour admin VMs sans IP publique, audit Entra ID Pièges à éviter :
• Croire que "interne = pas besoin de WAF" → un poste compromis sur le LAN bypass tout
• Upgrade Bastion Basic → Standard irréversible : choisir Standard d'emblée si >40 sessions RDP simultanées prévues
• AGW interne + DNS : besoin d'une Private DNS Zone pour résoudre app.corp.local vers l'IP privée AGW (sinon clients on-prem ne trouvent pas)

Sources :

• Azure Architecture Center — Load Balancing
• App Gateway multi-site hosting
• Application Gateway v2 features