Amazon ANS-C01: Équilibrage de charge et gestion du trafic — Guide d'étude

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Fait partie du AWS Advanced Networking Specialty ANS-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Concept de base

L’équilibrage de charge dans AWS opère sur deux couches fondamentales : L4 (transport) et L7 (application). Le Network Load Balancer (NLB) fournit une distribution de niveau L4 (TCP/UDP/TLS) et est optimisé pour des performances extrêmes, préservant l’adresse IP source du client et prenant en charge des millions de connexions simultanées avec une très faible latence et une faible rotation des connexions. L’Application Load Balancer (ALB) opère au niveau L7 (HTTP/HTTPS/WebSocket et HTTP/2/gRPC), fournit un routage basé sur l’hôte et le chemin, l’inspection des en-têtes, des vérifications de santé basées sur HTTP et l’adhérence par cookie (stickiness), et effectue la terminaison TLS lorsqu’il est configuré avec des certificats dans ACM. Le Gateway Load Balancer (GWLB) est un équilibreur de charge spécialement conçu pour mettre à l’échelle des appliances virtuelles tierces (pare-feu, IDS/IPS) en utilisant l’encapsulation GENEVE et des points de terminaison Gateway Load Balancer (GWLBe), permettant l’inspection du trafic en ligne sans mise à l’échelle manuelle des appliances.

Les écouteurs (listeners) et les règles d’écouteur sont les points d’entrée L4/L7 qui mappent les protocoles/ports aux groupes de cibles. Un écouteur sur un ALB peut avoir des règles complexes qui inspectent l’hôte, le chemin, les en-têtes, le CIDR de l’IP source, et transfèrent vers différents groupes de cibles ; l’ALB peut également décharger (terminer) le TLS et présenter les en-têtes X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Port aux cibles. Un écouteur NLB est généralement un écouteur TCP/UDP/TLS qui transfère le trafic aux groupes de cibles sans analyser la charge utile (sauf si vous activez la terminaison TLS au niveau du NLB) : en utilisant le passthrough TCP, vous préservez le TLS de bout en bout, de sorte que le backend doit présenter et valider les certificats pour le TLS mutuel (mTLS). Les groupes de cibles (target groups) sont le lien entre un écouteur d’équilibreur de charge et l’ensemble des points de terminaison (instance, IP ou Lambda), et ils exposent des attributs tels que le protocole/port/chemin de vérification de santé, le délai de désenregistrement (drainage des connexions) et les propriétés d’adhérence (stickiness).

Services clés et configuration

Choisissez le bon équilibreur de charge en fonction des caractéristiques du trafic et des exigences de sécurité. Utilisez un ALB lorsque vous avez besoin d’un routage basé sur l’hôte/chemin, de fonctionnalités HTTP/HTTPS comme les WebSockets ou HTTP/2/gRPC avec un routage sensible à l’application, et d’une adhérence basée sur les cookies. Configurez les écouteurs de l’ALB avec

undefined

ou via

undefined

, attachez des certificats depuis ACM, et définissez des règles d’écouteur en utilisant

undefined

avec des conditions (

undefined

). Activez l’adhérence sur les groupes de cibles de l’ALB avec

undefined

en définissant

undefined

pour utiliser des cookies générés par l’équilibreur de charge.

Utilisez un NLB pour les connexions TCP à haut débit et de longue durée, et lorsque la préservation de l’adresse IP source du client est requise au niveau du backend. Créez un NLB avec

undefined

et ajoutez un écouteur TCP avec

undefined

. Pour le passthrough TLS et le mTLS, configurez l’écouteur NLB en tant que TCP afin que le TLS soit terminé par le backend ; définissez le groupe de cibles sur

undefined

lors de l’enregistrement des IP de pods pour Kubernetes. Utilisez

undefined

pour définir

undefined

afin de permettre le drainage des connexions ; pour le NLB, vous pouvez également activer l’affinité par IP source (adhérence du groupe de cibles) le cas échéant.

Le Gateway Load Balancer est configuré avec

undefined

et est soutenu par des groupes de cibles de vos instances d’appliance (ou d’un groupe de mise à l’échelle dans un groupe Auto Scaling), et utilise un point de terminaison Gateway Load Balancer dans les VPC consommateurs pour diriger le trafic vers les appliances du VPC de service. Utilisez ce modèle lorsque vous avez besoin d’une inspection transparente et que vous souhaitez que les appliances se mettent à l’échelle automatiquement avec le trafic ; créez des écouteurs sur le port 6081 (encapsulation GENEVE) et enregistrez les ENI des appliances dans le groupe de cibles du GWLB.

Les paramètres opérationnels que vous devez contrôler par programmation incluent l’équilibrage de charge interzone (cross-zone load balancing), le délai de désenregistrement (drainage des connexions) et le réglage des vérifications de santé. Pour l’équilibrage de charge interzone, définissez les attributs sur l’équilibreur de charge (

undefined

) pour assurer la distribution du trafic entre les AZ plutôt que de biaiser la capacité par AZ. Définissez l’intervalle, le délai d’attente et les seuils de santé/non-santé sur les groupes de cibles pour éviter le basculement intempestif (flapping) lors des événements d’autoscaling.

Patrons de conception et compromis

Pour le TLS de bout en bout et le TLS mutuel (mTLS), où le trafic doit rester chiffré et les certificats clients doivent être présentés au backend, privilégiez le passthrough de couche 4 (L4) en utilisant un NLB avec des écouteurs TCP. Cela maintient la session TLS intacte, permettant aux backends de valider les certificats X.509 du client ; configurez les groupes cibles pour utiliser des cibles par IP afin que les adresses IP des pods Kubernetes puissent être enregistrées directement et que l’AWS Load Balancer Controller puisse gérer le cycle de vie des cibles. Le compromis est la perte des fonctionnalités de couche 7 (L7) de l’ALB, telles que le routage par hôte/chemin, les intégrations avec Web Application Firewall et la persistance de session native par cookie HTTP au niveau de l’équilibreur de charge.

Lorsque vous avez besoin d’un routage basé sur le contenu, d’une terminaison TLS et de fonctionnalités HTTP avancées, utilisez un ALB et terminez la session TLS au niveau de l’ALB (avec des certificats gérés par ACM). Pour conserver l’adresse IP du client pour la journalisation et les règles WAF, lisez l’en-tête X-Forwarded-For que l’ALB renseigne, ou utilisez une couche qui injecte l’IP client d’origine dans les en-têtes. Si vous avez besoin que la pile réseau/OS du backend voie l’adresse IP du client au niveau du socket, utilisez un NLB (ou activez le Proxy Protocol pour transmettre l’IP d’origine), mais notez que le Proxy Protocol doit être activé sur le groupe cible et que votre application ou votre proxy (par exemple, Envoy) doit l’analyser.

La gestion des sessions persistantes (sticky sessions) dans un environnement d’autoscaling nécessite une attention particulière. La persistance de session par cookie de l’ALB peut lier un client à une cible pour une durée déterminée, ce qui peut nuire à une mise à l’échelle équilibrée entre les pods si le trafic de session est intense. Les alternatives incluent l’utilisation d’une persistance de courte durée combinée à l’externalisation de l’état de session vers ElastiCache (Redis) ou DynamoDB, ou l’utilisation d’un proxy sidecar (Envoy) pour gérer l’affinité de session avec un hachage cohérent (consistent hashing). Le drainage des connexions (délai de désenregistrement) est essentiel pour un arrêt en douceur (graceful shutdown) : définissez deregistration_delay.timeout_seconds sur une durée supérieure à la plus longue requête RPC/HTTP pour éviter les terminaisons abruptes et les erreurs client lors de l’arrêt d’un pod. Configurez les hooks preStop de Kubernetes pour coordonner le cycle de vie du pod avec le désenregistrement.

GWLB est le modèle approprié lorsque vous avez besoin d’une inspection en ligne (inline) et évolutive sur de nombreux VPC et que vous souhaitez des contrôles de sécurité centralisés. Combinez GWLB avec des architectures Transit Gateway ou de peering VPC si nécessaire. Le coût et la complexité opérationnelle de la gestion des appliances sont les compromis par rapport à l’utilisation de services gérés comme AWS Network Firewall.

Pièges courants et critères de décision

Une erreur fréquente consiste à terminer la session TLS au niveau de l’ALB sans tenir compte des besoins en aval pour l’authentification du client ou l’adresse IP source d’origine. Si les backends nécessitent le certificat client ou la véritable adresse IP source au niveau de la couche TCP (pour la journalisation ou l’autorisation), terminez la session TLS au niveau du backend via le mode passthrough du NLB ou utilisez le Proxy Protocol et assurez-vous que l’application l’analyse. Un autre piège courant est d’activer les sessions persistantes (sticky sessions) sans stockage de session externe tout en utilisant le Horizontal Pod Autoscaler : lorsque les pods sont mis à l’échelle (scale-out ou scale-in), l’affinité persistante peut créer des points chauds et un gaspillage de capacité ; préférez des backends sans état (stateless) ou externalisez l’état de la session.

Des erreurs opérationnelles surviennent également à cause de vérifications de santé mal configurées et de délais de désenregistrement qui entraînent des pertes de requêtes pendant la mise à l’échelle. Définissez toujours les chemins et les seuils des vérifications de santé pour refléter le temps de démarrage de l’application et utilisez deregistration_delay.timeout_seconds pour permettre aux connexions de longue durée de se drainer. L’équilibrage de charge interzone (cross-zone load balancing) doit être configuré intentionnellement : son activation réduit la latence de queue et répartit la charge de manière uniforme, mais peut augmenter les coûts de transfert de données inter-AZ ; évaluez-le en fonction de la capacité des AZ et des modèles de trafic. Enfin, le GWLB introduit une surcharge de gestion due à l’encapsulation (GENEVE) et aux appliances — automatisez l’enregistrement des appliances à l’aide des API AWS (CreateTargetGroup/RegisterTargets) et instrumentez avec les métriques CloudWatch pour piloter les politiques d’autoscaling.

Problème pratique : Scénario d’utilisation

Entreprise : Acme Telemetry. Défi : Fournir un chiffrement de bout en bout pour un service gRPC (gRPC sur TLS sur le port TCP 443) déployé dans un cluster Amazon EKS, supporter des milliers de connexions simultanées de longue durée, utiliser le Cluster Autoscaler de Kubernetes et le HPA, et exiger le TLS mutuel (mTLS) afin que le certificat client soit validé par le backend (c’est-à-dire que le trafic ne doit être déchiffré par aucun équilibreur de charge intermédiaire).

Approche de mise en œuvre du cas d’utilisation : Provisionner un Network Load Balancer avec un listener TCP sur le port 443 et un groupe cible de type « ip » pointant vers les adresses IP des pods. Créer le NLB avec

undefined

, créer le groupe cible avec

undefined

, enregistrer les cibles via les annotations du AWS Load Balancer Controller pour Kubernetes (service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip”) afin que le contrôleur enregistre automatiquement les adresses IP des pods, et créer le listener avec

undefined

. Définir l’attribut du groupe cible deregistration_delay.timeout_seconds à une valeur appropriée (par exemple 300) en utilisant

undefined

pour permettre un drainage progressif (graceful draining).

Configuration TLS et mTLS du backend : Terminer la session TLS et effectuer le TLS mutuel au niveau de la couche des pods. Déployer des sidecars Envoy ou faire en sorte que les serveurs gRPC acceptent directement le TLS, en stockant les certificats de serveur et les lots d’AC (CA bundles) dans des Secrets Kubernetes et en les montant dans le pod. Configurer les backends pour valider les certificats clients par rapport à votre AC et configurer les vérifications de santé pour utiliser TCP afin d’éviter de terminer la session TLS au niveau de l’équilibreur de charge. S’assurer que les hooks de cycle de vie du HPA et du Cluster Autoscaler se coordonnent avec le désenregistrement du groupe cible en implémentant des hooks preStop qui permettent aux pods de terminer leur drainage avant de s’arrêter.
Scalabilité et contrôles opérationnels : Activer l’équilibrage de charge interzone sur le NLB si nécessaire avec

undefined

pour répartir uniformément les connexions entre les AZ. Surveiller les connexions simultanées et les débits de flux avec les métriques CloudWatch (NetworkPackets, ActiveFlowCount pour le NLB) et définir des politiques d’autoscaling pour l’appliance (si un sidecar est utilisé) et pour les nœuds de travail. Utiliser ModifyTargetGroupAttributes pour le drainage des connexions et ajuster les intervalles des vérifications de santé pour une détection plus rapide des pannes sans instabilité (flapping). Enfin, automatiser la rotation des certificats en utilisant l’intégration entre AWS Secrets Manager et cert-manager de Kubernetes.

Justification AWS : Le NLB en mode TCP préserve la session TLS de bout en bout afin que le backend puisse effectuer la validation mTLS ; son architecture de niveau 4 est conçue pour des millions de flux simultanés et des connexions de longue durée, et l’utilisation du target-type ip permet au AWS Load Balancer Controller d’enregistrer directement les adresses IP des pods, permettant à HPA/Cluster Autoscaler de s’adapter de manière transparente. Le drainage des connexions (deregistration_delay) et les vérifications de santé préviennent la perte de requêtes lors de la terminaison des pods, et l’équilibrage de charge interzone assure une distribution uniforme entre les AZ tout en arbitrant entre le coût de transfert inter-AZ et la performance.

← DNS et Route 53 · Tous les domaines · Sécurité réseau et conformité →

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