Retour aux articles • CLOUD • Mis à jour en 2026 • 4 min de lecture

Azure Load Balancer : L4 vs L7 (App Gateway)

Comparatif architectural entre Azure Load Balancer (Couche 4 TCP/UDP) et Azure Application Gateway (Couche 7 HTTP/HTTPS), supervision Log Analytics et évolutions 2026.

#cloud #paas #logs analytics #load balancer #azure
Azure Load Balancer : L4 vs L7 (App Gateway)
Documentation officielle Azure : learn.microsoft.com/azure/load-balancer & application-gateway
Modules Azure Verified (AVM) : github.com/Azure/terraform-azurerm-avm-res-network-loadbalancer • Architecture : L4 Standard LB & L7 WAF_v2 / AGC

Load Balancer

Un LoadBalancer (LB) est un endpoint unique pour les clients (consomamteurs du service). Il distribue les flux entrants arrivant sur l’ip frontal et repartie la charge à ses back-end.

Ces flux dépendent des règles d’équilibrage de charge et des sondes d’intégrité configurées. Les instances de pool de back-ends peuvent être des machines virtuelles Azure ou des instances d’un groupe de machines virtuelles identiques.

Chaque cloud provider propose des load balancer as a service. Ici nous allons nous intéréssé des Load Balancer d’Azure. il en existe plusieurs.

Comparatif architectural Azure Load Balancing : Azure Standard Load Balancer (Couche 4 TCP/UDP) vs Azure Application Gateway WAF v2 (Couche 7 HTTP/HTTPS)

Load Balancer 4

Les Load Balancer Azure de niveau 4, couche 4 du modèle OSI (Open Systems Interconnection), sont disponibles sous deux format (SKU). L’un en basic sans SLA et l’autre en standart avec un SLA de 99.99%.

Le LB 4 prend la décision de routage en fonction des adresses IP et des ports TCP ou UDP. Il a une vue paquet du trafic échangé entre le client et un serveur, ce qui signifie qu’il prend des décisions paquet par paquet.

Load Balancer 7

Les load balancer de niveau 7 appellé Application gateway sont des load balancer avec affinité de session. Contrairement au niveau LB 4 les paquets sont réassemblés puis le LB peut prendre une décision de routage en fonction des informations qu’il peut trouver dans les requêtes ou les réponses de l’application. Bien que cela est plus complexe le temps de traitement est de l’ordre de la milliseconde

Superviser son LB4 PaaS

On pouvait déjà superviser ses AppsGW (Azure Application Gateway) en derversant ses logs dans Logs Analytics. Mais récement cette fonctionnalité est aussi disponible sur les Load Balancer SKU Standard.

LoadBalancer2LogsAnalytics.png

Configuration via portail

On peut facilement activer la fonctionnalité en allant sur l’objet en question :

capt1.png

Puis en choisisant la destination de notre BD, ici on choisira LogsAnalytics

capt2.png

Configuration via Terraform

On peut aussi le faire avec Terrform. Ci dessous un exemple de code gracieusement fournit par Alexandre COMET :

Query Logs analytics

Ci-dessous un exemple de métrique :

AzureMetrics
| where $__timeFilter(TimeGenerated) and Resource == "My-LB" and MetricName == "VipAvailability"
| project TimeGenerated, Count
| order by TimeGenerated asc
Animation exécution CLI dans le terminal

Grafana et logs

Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome

MàJ 2026 Matrice de choix L4 vs L7 et nouveautés Azure

Cinq ans après la rédaction initiale de ce billet, l’écosystème d’équilibrage de charge Azure a fortement évolué avec le retrait définitif du SKU Basic et l’arrivée d’Application Gateway for Containers (ALB).

1. Synthèse L4 (Azure Load Balancer) vs L7 (Application Gateway / Front Door)

CritèreAzure Load Balancer (Couche 4)Azure Application Gateway v2 / ALB (Couche 7)
Couche OSI & ProtocolesCouche 4 (TCP, UDP, HA Ports tous flux)Couche 7 (HTTP/1.1, HTTP/2, HTTP/3 QUIC, WebSocket, gRPC)
Décision de routage5-tuple (IP src, Port src, IP dst, Port dst, Proto)Hostname, URI path, headers HTTP, cookies, réécriture d’URL
Terminaison TLS / mTLSNon (Passthrough pur de bout en bout)Oui (TLS offloading, mTLS, politiques cryptographiques centralisées)
Sécurité embarquéeNSG + Azure DDoS ProtectionWAF intégré (OWASP Core Rule Set, bot protection, rate limiting)
Latence & DébitUltra-faible (< 100 µs, millions de pps en datapath matériel)~1 à 3 ms (reconstruction du flux TCP + inspection HTTP/WAF)

2. Ce qui change en 2026

  • Fin de vie du SKU Basic : le SKU Standard (SLA 99.99%, redondance inter-zones ZRS par défaut, outbound rules explicites) est désormais obligatoire en production.
  • Application Gateway for Containers (AGC) : remplace avantageusement l’ancien contrôleur AGIC sur AKS en s’appuyant sur l’API standard Kubernetes Gateway API avec une réconciliation quasi instantanée des pods back-ends.
  • Diagnostic Logs en mode Resource-Specific : dans Log Analytics, privilégiez désormais les tables dédiées (ALBHealthProbeStatus, AGWAccessLogs, AGWFirewallLogs) plutôt que l’ancienne table générique AzureDiagnostics, plus coûteuse et limitée en colonnes.

Hardening Multi-Cloud des Load Balancers (CLI & Compléments Officiels)

En complément du code Terraform ci-dessus, voici les commandes Azure CLI (az) permettant de durcir un Azure Standard Load Balancer et son Azure Application Gateway WAF_v2 selon le Microsoft Cloud Security Benchmark [1] [2] :

# 1. Créer une politique WAF v2 en mode Prevention avec OWASP CRS 3.2
az network application-gateway waf-policy create \
  --name prod-waf-policy-strict \
  --resource-group rg-prod-network \
  --type OWASP \
  --version 3.2

az network application-gateway waf-policy policy-setting update \
  --policy-name prod-waf-policy-strict \
  --resource-group rg-prod-network \
  --mode Prevention \
  --state Enabled

# 2. Forcer la politique TLS minimale TLSv1_2 (AzSecPack) sur l'Application Gateway
az network application-gateway ssl-policy set \
  --gateway-name prod-appgw \
  --resource-group rg-prod-network \
  --policy-type Predefined \
  --policy-name AppGwSslPolicy20220101S

Sources