Microsoft AZ-104: Équilibrage de charge Azure et Gestion du trafic — Guide d'étude

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Administrator Associate AZ-104 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Azure propose un portefeuille de services à plusieurs niveaux pour distribuer et protéger le trafic : Azure Load Balancer (Couche 4, TCP/UDP), Application Gateway (Couche 7, HTTP/S), Azure Front Door (périphérie mondiale de Couche 7), Azure Traffic Manager (basé sur le DNS) et Azure CDN (mise en cache en périphérie). Chacun cible un segment spécifique du chemin de la requête, allant de la prise de décision DNS mondiale et des POPs de périphérie au routage HTTP régional et au trafic privé est-ouest. La maîtrise consiste à sélectionner le bon service pour le protocole et l’audience, à les composer correctement, et à configurer des sondes de santé et des règles qui assurent un basculement fiable.

Azure Load Balancer (L4) : SKUs, composants, NAT/sortie et IP flottante

Standard Load Balancer est l’équilibreur de charge L4 de qualité production. Il est conscient des zones/redondant entre les zones, prend en charge les ports HA, des diagnostics/métriques avancés, est sécurisé par défaut (pas de trafic entrant sauf si vous définissez des règles), des règles de sortie configurables, et une mise à l’échelle importante du backend. Basic est une SKU héritée avec une échelle/des fonctionnalités limitées et sans redondance de zone ; elle est en voie de retrait et ne doit pas être choisie pour les nouvelles charges de travail.

Les composants principaux définissent comment le trafic circule :

IP frontale : La VIP exposée aux clients. Les LBs externes utilisent une IP publique ou un préfixe d’IP publique ; les LBs internes utilisent une IP statique privée d’un sous-réseau. Le SKU Standard prend en charge plusieurs frontends et des IP publiques redondantes entre les zones.
Pool backend : Des NICs, des configurations IP sur les NICs, ou des instances de VM scale set dans la même région/VNet. Un seul pool peut servir plusieurs règles. Le SKU Standard prend en charge les backends interzones au sein d’une région.
Sondes de santé : Déterminent quelles instances backend sont saines. Les sondes TCP effectuent une poignée de main (handshake) ; les sondes HTTP/HTTPS font un GET sur un chemin et considèrent 200–399 comme un succès. Vous contrôlez le protocole, le port, le chemin (pour HTTP/S), l’intervalle et le seuil de défaillance (échecs consécutifs avant de marquer l’instance comme défaillante).
Règles d’équilibrage de charge : Lient un frontend (IP/port/protocole) à un pool backend et à une sonde de santé. Les paramètres de la règle incluent le port backend, le protocole (TCP/UDP), la persistance de session, le délai d’inactivité (idle timeout) et l’IP flottante (Floating IP ou Direct Server Return).

Les règles NAT entrantes sont des traductions par VM qui transfèrent un port frontal spécifique vers une seule NIC/port backend (par exemple, pour exposer RDP ou SSH à une seule VM sans équilibrage de charge). Elles n’utilisent pas la sonde de santé et ne sont pas un mécanisme de mise à l’échelle horizontale (scale-out).

Les règles de sortie définissent le comportement SNAT pour les backends du Standard Load Balancer qui initient des connexions vers Internet via les frontends publics du LB. Elles vous permettent de contrôler quel(s) frontend(s) fournissent les ports SNAT et combien de ports par instance backend sont alloués, aidant à éviter l’épuisement des ports SNAT en cas de forte simultanéité sortante. Si une NAT Gateway est attachée au sous-réseau, elle remplace le SNAT du LB ; préférez NAT Gateway pour une connectivité sortante cohérente et évolutive.

L’IP flottante (Floating IP ou Direct Server Return) est une option de règle utilisée lorsque l’IP/port de destination doit être préservé de bout en bout. Elle est requise pour les scénarios en cluster tels que les écouteurs de groupe de disponibilité SQL Server Always On. Pour un SQL AG, utilisez un Standard Load Balancer interne avec une sonde TCP (pas HTTP) vers le port de sonde du cluster et activez l’IP flottante sur la règle du LB ; ne sondez pas le port 1433 avec HTTP, car SQL n’est pas une charge de travail HTTP.

Le choix entre équilibreurs de charge internes et externes dépend de l’audience et de la frontière de sécurité. Utilisez un LB interne lorsque vous exposez une VIP privée à l’intérieur d’un VNet ou via une connectivité privée (VPN/ExpressRoute) pour des applications métier, des bases de données et des NVAs. Utilisez un LB externe pour les services L4 accessibles depuis Internet. Pour les LBs internes, assignez un frontend privé statique dans le sous-réseau cible ; pour les LBs externes, liez une IP publique Standard et utilisez éventuellement plusieurs frontends.

Cross-region Load Balancer fournit un équilibrage de charge de Couche 4 mondial et anycast entre les régions. Vous déployez des Standard Public Load Balancers dans chaque région (niveau régional) et placez leurs frontends publics dans le backend d’un unique Load Balancer mondial (niveau mondial). Le LB mondial utilise des sondes de santé vers chaque LB régional et dirige les clients vers la région saine la plus proche (en termes de latence) avec une symétrie de flux basée sur un hachage à 5 tuples. Il est uniquement TCP/UDP — sans terminaison TLS — et complète les passerelles L7 régionales.

Application Gateway (L7) et Azure Front Door (L7 global)

Application Gateway est un proxy inverse régional de couche 7 avec WAF. Il termine les connexions HTTP/HTTPS, inspecte les en-têtes et les chemins, et route le trafic vers des backends privés ou publics.

Principaux composants d’Application Gateway :

Écouteurs (Listeners) : Lient une adresse IP/port/nom d’hôte frontend et des paramètres SSL pour accepter le trafic. Le SNI permet d’héberger plusieurs sites TLS sur une seule adresse IP. Utilisez des écouteurs de base pour un site unique, des écouteurs multisites pour le routage basé sur l’hôte, et des hôtes génériques (wildcard) pour une couverture étendue.
Règles de routage et paramètres HTTP : Les règles associent les écouteurs aux pools backend et spécifient les paramètres HTTP appliqués aux backends (protocole, port, remplacement de l’en-tête d’hôte, affinité basée sur les cookies, drainage des connexions, délai d’attente des requêtes). Vous pouvez rediriger, réécrire les en-têtes ou router en fonction des segments du chemin d’URL.
Pools backend : Les cibles peuvent être des adresses IP de cartes réseau (NIC), des FQDN, des App Services ou des VM scale sets. Des sondes d’intégrité (health probes) personnalisées vérifient des chemins/hôtes spécifiques et respectent les codes de statut de succès.
WAF : Protection basée sur le Core Rule Set de l’OWASP en mode détection ou prévention, avec des règles personnalisées, des listes d’exclusion et une association par route dans la v2. La mise à l’échelle automatique (autoscaling) et la redondance de zone sont prises en charge dans la v2.

Modèles L7 avancés :

Routage basé sur le chemin d’URL : Routez /api/* vers des microservices et /images/* vers une origine statique ou un CDN, permettant une distribution (fanout) vers les microservices derrière une seule VIP.
Hébergement multisite : Hébergez contoso.com et fabrikam.com sur une seule passerelle en utilisant des écouteurs SNI et des règles basées sur l’en-tête d’hôte. Utile pour la consolidation avec une isolation forte via des stratégies WAF par site.
Terminaison SSL : Déchargez le chiffrement TLS sur la passerelle pour une gestion centralisée des certificats et l’inspection WAF. Utilisez le chiffrement TLS de bout en bout (ré-encryption) lorsque les backends nécessitent un chiffrement ou la validation du certificat client.

Azure Front Door fournit un équilibrage de charge HTTP/HTTPS global et une accélération en périphérie (edge) avec anycast, split TCP et une optimisation de la connexion du POP à l’origine. C’est la meilleure solution pour les applications exposées sur Internet nécessitant un routage global, un WAF en périphérie et une mise en cache optionnelle en périphérie.

Équilibrage de charge global : Route les utilisateurs vers l’origine saine ayant la plus faible latence en utilisant des sondes d’intégrité depuis plusieurs POP. Les groupes d’origines prennent en charge le basculement basé sur la priorité et la latence, avec une affinité de session si nécessaire.
WAF : Règles gérées avec protection contre les bots, règles personnalisées, filtres géo/IP, limitation de débit (rate limiting) et association par route.
Mise en cache : Avec Front Door Standard/Premium, la mise en cache en périphérie est intégrée ; définissez le comportement de mise en cache par chemin, contrôlez la mise en cache des chaînes de requête (query-string) et les TTL, et déchargez le contenu statique globalement.
Sondes d’intégrité : Sondes par groupe d’origines (HTTP/HTTPS) avec chemin, intervalle et protocole configurables depuis divers POP. Les décisions de routage combinent l’état de santé et la latence.

Utilisez Application Gateway pour les besoins L7 régionaux (backends privés, trafic est-ouest, réécritures complexes) et Front Door pour le L7 global, la sécurité en périphérie et l’accélération. Ils sont souvent composés : Front Door en périphérie, des Application Gateways par région, et des équilibreurs de charge internes derrière les passerelles pour les services L4.

Traffic Manager (basé sur le DNS) et Azure CDN

Traffic Manager est un service de distribution de trafic global basé sur le DNS. Il ne sert pas de proxy pour le trafic ; à la place, il retourne le nom DNS/l’IP d’un point de terminaison en fonction d’une stratégie et de son état de santé, laissant les clients se connecter directement. L’état de santé est vérifié depuis des sondes distribuées vers des points de terminaison HTTP/HTTPS/TCP ; des TTL bas réduisent la latence de basculement mais augmentent le volume de requêtes DNS.

Priorité : Basculement actif/passif. Placez le point de terminaison principal en premier ; Traffic Manager le dessert sauf s’il est défaillant, puis bascule vers la priorité suivante.
Pondéré : Distribue le trafic selon des poids pour prendre en charge des basculements progressifs ou des tests A/B.
Performance : Choisit le point de terminaison avec la plus faible latence réseau entre la région de l’utilisateur et le point de terminaison.
Géographique : Route le trafic en fonction de la localisation géographique de l’utilisateur pour la souveraineté des données ou la localisation du contenu.
Multivalue : Retourne plusieurs points de terminaison sains pour le même service afin de permettre un basculement simple côté client. Vous pouvez imbriquer des profils pour des stratégies hybrides (par ex., géographique au niveau supérieur, puis pondéré au sein d’une zone géographique). Utilisez Traffic Manager pour les protocoles non-HTTP, les services qui ne bénéficient pas d’un proxy en périphérie, ou lorsque vous avez besoin d’un contrôle au niveau DNS sur des points de terminaison hétérogènes (Azure, sur site, tiers).

Azure CDN décharge le contenu statique et pouvant être mis en cache vers des POP en périphérie pour réduire la charge sur l’origine et la latence.

Profils : Conteneurs pour un ou plusieurs points de terminaison liés à un fournisseur/niveau (par exemple, les familles Microsoft, Akamai ou Verizon). Les profils aident à séparer les environnements ou les centres de coûts.
Points de terminaison : Définissent les détails de l’origine (nom d’hôte, en-tête d’hôte d’origine, protocole/port) et le nom d’hôte de périphérie. Vous pouvez avoir plusieurs points de terminaison par profil pour différentes applications ou types de contenu.
Règles de mise en cache : Les règles par défaut et personnalisées contrôlent les TTL, le comportement basé sur le chemin, la gestion des chaînes de requête (transférer, ignorer ou mettre en cache chaque requête unique) et la compression. Utilisez les règles pour forcer la mise en cache des ressources avec des TTL d’origine courts, ou pour contourner la mise en cache pour les API dynamiques.
Domaines personnalisés : Associez des noms d’hôtes conviviaux avec un TLS géré par le CDN. Validez la propriété du domaine via un CNAME et activez HTTPS avec des certificats gérés. Combinez avec le filtrage géographique ou le moteur de règles si nécessaire.

Choix de conception, intégration inter-régionale et comportement des sondes d’intégrité

Le choix entre des équilibreurs de charge internes et externes est déterminé par l’audience et l’exposition des routes. Si les consommateurs se trouvent uniquement à l’intérieur de réseaux privés, utilisez des équilibreurs de charge (LB) internes pour éviter l’exposition publique et simplifier le contrôle des NSG. Pour les utilisateurs Internet ou les partenaires, utilisez des frontends publics. Pour la connectivité sortante à grande échelle, préférez NAT Gateway au SNAT de l’équilibreur de charge ; réservez les règles de trafic sortant aux cas où le frontend de l’équilibreur de charge doit fournir le SNAT.

Le Cross-region Load Balancer s’intègre avec les Standard Public Load Balancers régionaux pour obtenir une résilience de couche 4 (Layer 4) active-active et globale pour les services TCP/UDP. Placez les frontends publics des LB régionaux dans le pool de backends du LB global. Les sondes d’intégrité au niveau global reflètent la disponibilité régionale ; le routage dirige vers la région saine avec la plus faible latence et bascule automatiquement si une région entière (ou son LB régional) devient défaillante. Combinez cette solution avec Front Door lorsque vous avez besoin des deux types de support de protocole (par exemple, des services TCP via le Cross-region LB et HTTP/S via Front Door) sous des VIP distinctes.

Les sondes d’intégrité sont la source de vérité pour le basculement :

Sondes TCP : Fonctionnent pour tout service TCP. Un établissement de liaison en trois temps (3-way handshake) réussi marque le succès. Convient pour SQL, SMTP ou des protocoles TCP personnalisés.
Sondes HTTP/HTTPS : Valident l’intégrité au niveau de l’application en demandant un chemin et en attendant un code de retour 200–399. Elles permettent la personnalisation de l’hôte/chemin et peuvent discriminer les défaillances partielles de l’application. Les sondes HTTPS vérifient la négociation TLS mais pas la validité du certificat au-delà du handshake ; utilisez les en-têtes d’hôte corrects pour les applications hébergées virtuellement.
Seuils d’anomalie : Azure Load Balancer marque un backend comme étant hors service après N échecs consécutifs de la sonde (configurable ; les intervalles par défaut sont courts pour accélérer le basculement). Application Gateway et Front Door sondent depuis plusieurs points d’observation et considèrent une origine comme étant hors service lorsque suffisamment d’échecs consécutifs s’accumulent sur l’ensemble de leurs sondes. La récupération nécessite des succès consécutifs. Ajustez l’intervalle et le seuil pour équilibrer la sensibilité et le flapping ; assurez-vous que les sondes atteignent un point de terminaison léger et conscient des dépendances.

Scénario de problème pratique

Adobe doit exposer globalement un SaaS multi-région composé de frontends web, de microservices et d’un groupe de disponibilité SQL Server Always On, avec une sécurité stricte, un basculement rapide et une faible latence pour les utilisateurs du monde entier. Ils exposent également un service d’ingestion de télémétrie hérité basé sur TCP.

Placer Azure Front Door Standard en périphérie avec une politique WAF et des routes pour www.adobe.com et api.adobe.com. Les origines sont des Application Gateways dans les régions East US et West Europe, regroupées avec un routage basé sur la latence et un basculement par priorité.

Pourquoi : Front Door fournit un anycast global, un WAF en périphérie et une mise en cache optionnelle pour accélérer et protéger le trafic HTTP/S Internet ; il choisit automatiquement la région saine la plus proche.

Déployer Application Gateway v2 avec WAF dans chaque région. Configurer des écouteurs multi-sites avec SNI pour les deux noms d’hôte, un routage basé sur le chemin de l’URL vers les microservices, et des sondes d’intégrité personnalisées vers /healthz sur chaque service. Activer le SSL de bout en bout avec un remplacement de l’hôte backend par les FQDN des services.

Pourquoi : Application Gateway offre un routage L7 régional, une inspection WAF proche de l’application, une distribution basée sur le chemin (fanout) et des politiques par route ; il se connecte de manière sécurisée aux backends privés et gère les réécritures/redirections d’en-têtes.

Déployer un Standard Load Balancer interne dans chaque région pour l’écouteur du groupe de disponibilité SQL (AG). Configurer un frontend privé statique, une sonde d’intégrité TCP vers le port de sonde du cluster de basculement Windows, et une règle d’équilibrage de charge avec Floating IP activé vers le port de l’écouteur.

Pourquoi : L’écouteur SQL nécessite une couche L4 avec retour direct du serveur (DSR). Le Floating IP préserve la sémantique de la destination, et une sonde TCP reflète précisément la propriété du groupe de disponibilité. Cela correspond à l’exigence connue selon laquelle le sondage HTTP sur le port 1433 n’est pas valide.

Soutenir les ressources statiques web avec des règles de mise en cache Azure Front Door pour /static/* avec un TTL long et une revalidation, et également mettre en place un profil et un point de terminaison Azure CDN pour les téléchargements de médias volumineux sur downloads.adobe.com avec une mise en cache spécifique au chemin et une variation de la chaîne de requête.

Pourquoi : La mise en cache de Front Door réduit la latence pour le contenu statique web principal en ligne avec le routage en périphérie, tandis qu’un point de terminaison CDN dédié optimise la livraison d’objets volumineux et l’indépendance de la politique de cache pour les téléchargements.

Publier l’ingestion de télémétrie TCP héritée via un Standard Public Load Balancer régional dans chaque région, puis les placer derrière un Cross-region Load Balancer comme VIP publique unique. Configurer des sondes globales pour chaque LB régional et utiliser le routage par latence.

Pourquoi : Le service est TCP, pas HTTP ; le Cross-region Load Balancer offre une solution L4 active-active globale avec basculement automatique et sélection de la région à plus faible latence.

Ajouter Azure Traffic Manager avec une politique de Priorité uniquement pour un point de terminaison SFTP d’un partenaire externe hébergé en dehors d’Azure, en listant le point de terminaison principal du partenaire et un point de terminaison de secours hébergé sur Azure.

Pourquoi : Traffic Manager est basé sur le DNS et peut inclure des points de terminaison externes ; il offre un basculement actif/passif simple pour les cibles non-HTTP et tierces où le proxying n’est pas souhaité.

Pour la connectivité sortante depuis les sous-réseaux des applications, attacher une NAT Gateway et supprimer la dépendance au SNAT de l’équilibreur de charge. Surveiller les résultats des sondes et les métriques de LB/App Gateway/Front Door dans Azure Monitor et ajuster les intervalles des sondes/seuils d’anomalie pour éliminer le flapping.

Pourquoi : NAT Gateway assure une mise à l’échelle fiable de la connectivité sortante sans l’épuisement des ports SNAT ; un réglage précis des sondes d’intégrité permet un comportement de basculement plus rapide et stable à travers les couches.

← Réseaux virtuels Azure · Tous les domaines · Stockage Azure →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →