Amazon ANS-C01: Performance et surveillance du réseau — Guide d'étude
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.
Mise en réseau améliorée et fabric à faible latence
La mise en réseau améliorée (Enhanced networking) dans AWS est l’ensemble des fonctionnalités au niveau de l’OS et de l’hyperviseur qui augmentent considérablement le nombre de paquets par seconde, réduisent la latence et la charge CPU, et exposent un débit plus élevé par interface virtuelle. Les technologies principales sont l’Elastic Network Adapter (ENA), qui fournit une mise en réseau haute performance basée sur SR-IOV pour la plupart des familles d’instances EC2 modernes, et l’Elastic Fabric Adapter (EFA), qui est un périphérique de type RDMA avec contournement de l’OS (OS-bypass) conçu pour les charges de travail HPC et MPI/libfabric étroitement couplées. Pour activer ENA, vous confirmez que le type d’instance prend en charge ENA et que l’AMI Linux dispose du pilote ENA ; par programmation, vous pouvez l’activer ou l’interroger avec des appels API EC2 tels que RunInstances avec InterfaceType=efa si nécessaire, ou ModifyInstanceAttribute pour le support ena. EFA est attaché en créant une interface réseau avec InterfaceType=efa (aws ec2 create-network-interface –interface-type efa) ou en lançant des instances avec une interface réseau compatible EFA ; l’instance doit exécuter un noyau pris en charge et le module de noyau libfabric/efa, et être généralement placée dans un groupe de placement de type cluster pour obtenir la latence intra-hôte la plus faible et la bande passante bisectionnelle la plus élevée.
Les groupes de placement (placement groups) affectent les performances en contrôlant le positionnement des instances au sein de la fabric réseau sous-jacente. Un groupe de placement de type cluster regroupe les instances sur un seul rack ou dans un domaine réseau à faible latence pour permettre une bande passante est-ouest maximale et une latence constante — ceci est requis pour de nombreux cas d’utilisation d’EFA. Un groupe de placement de type spread impose une répartition au niveau de l’hôte pour éviter les défaillances corrélées, mais n’améliore pas la latence. Pour les scénarios à haut débit en rafales, la famille d’instances et le nombre de vCPU définissent les quotas de bande passante réseau de base ; par exemple, certaines tailles d’instances annoncent jusqu’à 25 Gbit/s ou 100 Gbit/s, mais le traitement des paquets et les piles TCP peuvent devenir des goulots d’étranglement sans ENA/EFA. Lors de la conception d’architectures pour des milliers de connexions TCP simultanées (gRPC sur TLS, par exemple), choisissez des types d’instances avec une capacité de connexion simultanée élevée, activez ENA, et préférez NLB / target-type=ip pour l’adressage direct des pods lors de l’exécution dans EKS afin d’éviter les goulots d’étranglement des ports de nœud (node port).
Services clés et configuration pour l’observabilité et l’application des politiques
La surveillance de la santé du réseau et le diagnostic des goulots d’étranglement reposent sur une combinaison de VPC Flow Logs, de métriques CloudWatch, de Traffic Mirroring et des analyseurs Reachability/Access. Les VPC Flow Logs fournissent des métadonnées par flux (IP source/destination, ports, paquets, octets, action) que vous pouvez envoyer vers CloudWatch Logs ou S3 et interroger avec CloudWatch Logs Insights pour trouver les préfixes à fort volume ou les principaux communicateurs (« top talkers »). Pour l’inspection en direct au niveau des paquets, Traffic Mirroring vous permet de créer une cible de miroir (mirror target) et un filtre, puis de créer des sessions (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session) pour copier le trafic des ENIs vers une appliance d’inspection s’exécutant sur EC2 ou vers des partenaires AWS Network Packet Broker.
CloudWatch expose les métriques pertinentes pour différentes couches : les métriques d’instance EC2 telles que NetworkIn/NetworkOut et NetworkPacketsIn/NetworkPacketsOut, les métriques de l’Application Load Balancer sous AWS/ApplicationELB comme RequestCount, ActiveConnectionCount et ClientTLSNegotiationErrorCount, les métriques du Network Load Balancer sous AWS/NetworkELB telles que ProcessedBytes et NewFlowCount, et les métriques AWS/DirectConnect pour l’interface virtuelle BytesIn/BytesOut. Utilisez les alarmes CloudWatch et Contributor Insights sur les journaux de flux pour détecter les flux saturants. Pour la validation des chemins et de la configuration, Reachability Analyzer (via les API EC2 StartNetworkInsightsAnalysis / CreateNetworkInsightsPath) vous permet de modéliser et de tester les chemins de paquets de bout en bout à travers les tables de routage, les NACL, les groupes de sécurité et les attachements VPN/Direct Connect, tandis que Network Access Analyzer aide à détecter les chemins d’accès réseau non intentionnels à travers vos VPC et AWS Organizations.
Patrons de conception et compromis pour l’équilibrage de charge et l’accès sécurisé
Lorsque vous avez besoin d’un véritable chiffrement TLS de bout en bout avec TLS mutuel (mTLS) au niveau du backend tout en prenant en charge des milliers de connexions gRPC, un Network Load Balancer en mode TCP est le patron de conception privilégié. Un NLB préserve l’adresse IP source du client par défaut et peut être créé par l’AWS Load Balancer Controller pour les services EKS à l’aide d’annotations telles que
undefined
et target-type=ip pour envoyer le trafic directement aux adresses IP des pods. L’utilisation du mode TCP passthrough sur le port 443 signifie que le pod backend termine la connexion TLS mutuelle (vérification des certificats client et serveur), de sorte que le trafic n’est jamais déchiffré au niveau de l’équilibreur de charge, préservant ainsi l’authentification bidirectionnelle. Ce patron de conception permet une excellente mise à l’échelle du nombre de connexions, car le NLB est conçu pour des millions de connexions simultanées avec une faible surcharge par connexion.
Pour les architectures qui nécessitent la terminaison TLS au niveau de l’équilibreur de charge et le routage basé sur le chemin (path-based routing) vers plusieurs groupes cibles, l’Application Load Balancer est le choix approprié car il prend en charge HTTP/2 et gRPC, le routage basé sur le chemin et les règles basées sur l’hôte. Pour garantir une journalisation précise de l’adresse IP du client lorsque l’ALB termine la connexion TLS, assurez-vous que l’application backend analyse les en-têtes X-Forwarded-For (l’ALB les injecte automatiquement) ou utilisez le protocole PROXY avec un NLB si vous avez besoin de préserver l’adresse IP source au niveau de la couche TCP. Si vous utilisez Global Accelerator pour fournir des adresses IP frontales anycast statiques et que vous souhaitez empêcher les clients de contourner l’accélérateur pour atteindre directement l’URL de l’ALB, verrouillez le groupe de sécurité de l’ALB pour qu’il n’accepte le trafic entrant que depuis les adresses IP statiques de l’accélérateur (les deux adresses statiques attribuées à l’accélérateur), afin de refuser tout accès direct depuis Internet.
Pour les services partagés multi-comptes avec des contrôles stricts par unité commerciale et des besoins de mise à l’échelle, AWS PrivateLink (VPC Endpoint Services s’appuyant sur des NLB internes) est souvent le patron de conception le plus sécurisé et le plus évolutif. Le VPC des services partagés publie des services via des points de terminaison Network Load Balancer (
undefined
avec des groupes cibles) et les expose en tant que VPC Endpoint Service. Les comptes consommateurs créent des points de terminaison d’interface dans leurs VPC qui se connectent au NLB du fournisseur ; le fournisseur contrôle l’accès via des politiques de point de terminaison et des groupes de sécurité, et le trafic ne traverse jamais un plan de routage centralisé. Transit Gateway est approprié lorsque vous avez besoin d’une visibilité complète du routage et d’une connectivité transitive, mais il centralise le routage et offre un contrôle d’accès par service moins granulaire que PrivateLink.
Pièges courants et critères de décision
Une erreur fréquente est de supposer que la bande passante annoncée d’une instance est illimitée ; les familles et tailles d’instances définissent des limites réseau strictes, et la mise à l’échelle doit envisager une répartition sur plusieurs ENI et un placement dans des groupes de placement de type cluster pour des performances constantes. Un autre écueil est de se fier uniquement à CloudWatch NetworkIn/NetworkOut sans corréler les VPC Flow Logs pour attribuer le trafic à un VPC, un sous-réseau ou une unité commerciale spécifique ; les Flow Logs et le Traffic Mirroring sont nécessaires pour isoler quelle interface virtuelle ou application cause la saturation de Direct Connect. Évitez également de terminer le TLS au niveau de l’ALB lorsque le TLS mutuel est requis de bout en bout. Si la politique exige que le backend voie le certificat client, choisissez le passthrough TLS avec un NLB ou effectuez un pontage TLS (TLS bridging) avec une validation de certificat appropriée, mais soyez explicite sur l’endroit où la confiance est établie.
Lors du diagnostic de saturation intermittente sur des liaisons physiques partagées comme Direct Connect, corrélez les métriques à travers les différentes couches : les métriques AWS/DirectConnect pour les interfaces virtuelles, les VPC Flow Logs pour les décomptes d’octets par sous-réseau/ENI, et les métriques EC2 Network* pour le comportement au niveau de l’instance. Utilisez Reachability Analyzer pour valider si un routage asymétrique ou une propagation d’itinéraire erronée cause des problèmes sur le chemin de retour, et utilisez Traffic Mirroring pour capturer des vidages de paquets (packet dumps) pour une inspection approfondie du protocole.
Problème pratique : Scénario d’utilisation
AcmeIoT est confronté à un problème où des distributeurs automatiques du monde entier doivent se connecter via gRPC avec TLS mutuel à un backend hébergé sur EKS. Le nombre de connexions doit se chiffrer en milliers, le service doit rester chiffré de bout en bout, et les pods du backend doivent se mettre à l’échelle dynamiquement avec le Cluster Autoscaler et HPA.
Créez un AWS LoadBalancer de type Network Load Balancer pour le service Kubernetes, en utilisant l’AWS Load Balancer Controller et des annotations pour spécifier le NLB et le
target-type=ip(service.beta.kubernetes.io/aws-load-balancer-type: "nlb"etservice.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"). Configurez un écouteur TCP (listener) sur le port 443 pour que le NLB effectue un passthrough TCP pur ; ne configurez pas de certificats TLS sur le NLB.Implémentez la terminaison et la validation du TLS mutuel dans les pods de l’application. Chaque pod doit présenter un certificat de serveur et valider les certificats clients, en utilisant un processus de rotation de certificats à courte durée de vie intégré avec AWS Secrets Manager ou SSM Parameter Store. Assurez-vous que les adresses IP des pods sont joignables en utilisant
target-type ipet que les bilans de santé (health checks) sont des bilans TCP ou gRPC configurés sur le groupe cible (target group).Assurez une haute capacité de connexion en choisissant des instances avec le support ENA et une bande passante réseau suffisante, activez ENA (confirmez avec le pilote ENA dans l’AMI et utilisez
aws ec2 modify-instance-attributepour activerena-supportsi nécessaire), et déployez les pods sur plusieurs nœuds avec le Cluster Autoscaler qui met à l’échelle les nœuds en fonction des requêtes des pods. Utilisez des groupes de placement (placement groups) pour les clusters fortement couplés nécessitant une latence constante et déployez un nombre suffisant de nœuds à travers les AZ.Surveillez et validez en utilisant CloudWatch et VPC Flow Logs. Créez des métriques et des alarmes CloudWatch pour
ActiveFlowCount/NewFlowCountdu NLB etNetworkIn/Outdes instances EC2 de travail EKS. Utilisez les VPC Flow Logs pour identifier les principaux émetteurs de trafic (top-talkers) et Reachability Analyzer (StartNetworkInsightsAnalysis/CreateNetworkInsightsPath) pour valider les chemins de routage pendant les événements d’autoscaling. Si vous avez besoin d’un débogage au niveau des paquets, créez des sessions de Traffic Mirroring vers une instance d’inspection.
Justification AWS : un Network Load Balancer en mode TCP préserve l’adresse IP source, supporte un nombre massif de connexions simultanées et permet le TLS de bout en bout car il ne termine pas la connexion TLS. Le target-type ip avec l’AWS Load Balancer Controller s’intègre avec la sémantique d’autoscaling d’EKS, de sorte que les nouvelles adresses IP des pods sont enregistrées dynamiquement comme cibles. ENA et un dimensionnement d’instance approprié fournissent la capacité réseau brute pour gérer des milliers de connexions TLS simultanées sans épuiser le CPU de l’hôte, et la combinaison de CloudWatch, VPC Flow Logs, Reachability Analyzer et Traffic Mirroring fournit l’observabilité requise pour détecter et corriger les problèmes de saturation ou de routage.
← Distribution de contenu et réseautage en périphérie · Tous les domaines · Automatisation →
Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Réussissez votre examen →