Amazon ANS-C01: Réseautage de conteneurs et sans serveur — 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.

Réseau EKS (CNI, réseau des pods)

Le réseau des pods dans Amazon EKS est dominé par le plugin Amazon VPC CNI (amazon-vpc-cni-k8s) qui attribue à chaque pod une adresse IP du VPC et place le trafic des pods directement sur le réseau VPC. Cette conception offre un contrôle de sécurité prévisible au niveau du VPC (groupes de sécurité, NACL) et un routage à faible latence, mais elle exige une planification minutieuse de la capacité en adresses IP et en ENI, car le nombre d’adresses IPv4 secondaires par ENI et le nombre d’ENI par type d’instance sont limités par le matériel. Le daemonset aws-node gère les opérations d’allocation d’IP et d’attachement/détachement ; son ConfigMap est modifié avec kubectl pour ajuster le comportement (par exemple, pour définir

undefined

, ou

undefined

). Les modes de délégation de préfixe et d’ENI pour les pods réduisent l’épuisement des adresses IP par nœud en permettant à un nœud d’allouer des préfixes /28 entiers à une ENI (

undefined

) ou en attribuant une ENI dédiée par pod (utile pour une isolation de haute sécurité).

Des alternatives à l’Amazon VPC CNI telles que Cilium (eBPF) ou Calico peuvent offrir des compromis différents. Cilium peut remplacer kube-proxy et mettre en œuvre une redirection L3/L4 haute performance en utilisant eBPF, activer le chiffrement transparent entre les nœuds (WireGuard ou IPsec), et réduire la pression sur les adresses IP au niveau des nœuds en utilisant des approches d’overlay ou de masquage. Avec Cilium, vous vous intégrez toujours au routage VPC pour le trafic sortant et entrant, mais vous évitez les opérations fréquentes d’attachement/détachement d’ENI ; cela est important lorsque le taux de renouvellement des pods est élevé. Pour des nombres de connexions très élevés et un comportement L7 strict, vous devez également envisager d’ajuster le mode kube-proxy (IPVS) et les paramètres du noyau du nœud : ajustez

undefined

, et

undefined

, et exposez-les via kubelet ou des scripts d’initialisation de daemonset pour éviter l’épuisement des ports éphémères avec des milliers de connexions gRPC concurrentes et de longue durée.

Modes réseau d’ECS et intégration VPC de Lambda

Le réseau des tâches ECS a trois modes principaux : bridge, host, et awsvpc. Le mode awsvpc est le plus comparable au réseau des pods Kubernetes car il attache une ENI à chaque tâche (ou groupe de tâches) et assigne une adresse IP privée et des groupes de sécurité directement à la tâche. Configurez awsvpc en spécifiant

undefined

avec des

undefined

et des

undefined

dans les appels API

undefined

. Fargate impose le mode awsvpc et fournit donc une isolation réseau au niveau de la tâche et s’intègre avec AWS Cloud Map pour la découverte de services. Utilisez awsvpc lorsque vous avez besoin d’un filtrage du trafic par groupe de sécurité pour chaque tâche, ou lorsque vous devez exposer le routage et les métriques VPC standard.

Les fonctions Lambda qui nécessitent un accès au VPC sont attachées au VPC via des ENI dans les subnets et les groupes de sécurité configurés pour la fonction. Ces ENI sont créées et gérées par le plan de contrôle de Lambda, mais le provisionnement des ENI peut ajouter de la latence au démarrage à froid (cold-start) et a historiquement limité la montée en charge rapide, sauf si cela est atténué par la simultanéité provisionnée ou en utilisant des points de terminaison VPC (AWS PrivateLink) et une architecture de subnets soigneusement conçue. Lorsque vous placez de nombreuses fonctions Lambda dans un VPC, assurez-vous que les subnets disposent d’adresses IP disponibles, utilisez une NAT Gateway ou des instances NAT pour le trafic sortant si nécessaire, et préférez les points de terminaison VPC (points de terminaison

undefined

via

undefined

) pour éviter de router le trafic sortant par Internet lorsque c’est possible. Surveillez l’attachement/détachement des ENI à l’aide de CloudWatch Logs et de VPC Flow Logs pour observer le comportement de mise à l’échelle et dépanner les limitations liées à la simultanéité.

App Mesh et la découverte de services

AWS App Mesh utilise des sidecars Envoy comme plan de données et fournit une observabilité L3–L7, la mise en forme du trafic (traffic shaping), les nouvelles tentatives (retries) et les contrôles d’origine/terminaison TLS. Définissez les maillages (meshes), les nœuds virtuels (virtual nodes) et les services virtuels (virtual services) via l’API App Mesh (

undefined

) ou le contrôleur App Mesh pour Kubernetes. App Mesh prend en charge mTLS en configurant le bloc TLS d’un listener de VirtualNode avec une

undefined

et une autorité de certification, et vous pouvez l’intégrer avec AWS Certificate Manager (ACM) ou SDS pour la distribution des certificats. Cependant, notez que les sidecars App Mesh terminent et rechiffrent le trafic par conception ; si une exigence impose que le trafic applicatif reste chiffré de bout en bout entre le client et le pod de l’application (sans déchiffrement dans le proxy réseau), vous devez vous assurer que le TLS n’est terminé qu’au niveau du pod et éviter de le terminer à l’entrée du maillage ou au niveau du load balancer.

La découverte de services se fait couramment avec les Services Kubernetes et CoreDNS pour EKS, avec Cloud Map (

undefined

) pour les environnements multi-plateformes, et avec les zones hébergées privées Route 53 pour la résolution basée sur DNS. AWS Cloud Map s’intègre directement avec ECS et App Mesh, permettant des enregistrements SRV ou A et des vérifications de santé pilotées par API. Pour les environnements dynamiques où les instances se mettent à l’échelle rapidement, combinez des TTL DNS courts et des vérifications de santé Cloud Map pour éviter la résolution d’adresses obsolètes ; si vous avez besoin d’une cohérence immédiate, utilisez une API du plan de contrôle du maillage de services pour récupérer les points de terminaison plutôt que de vous fier à la mise en cache DNS.

Patrons de conception et compromis

Lors de la conception de gRPC à grande échelle sur TLS avec mTLS, vous devez décider où la terminaison TLS s’effectue. La terminaison au niveau de l’équilibreur de charge (ALB) permet de décharger la gestion des certificats sur ACM et simplifie leur rotation, mais elle rompt le chiffrement de bout en bout et ne peut pas fournir le mTLS aux pods backend, à moins que le backend ne rétablisse une connexion TLS en utilisant les informations du certificat client qui ont été transférées. Pour un véritable mTLS de bout en bout où les points de terminaison de l’application authentifient directement les clients, utilisez une passerelle L4 en mode passthrough comme un Network Load Balancer et laissez le pod/l’application gérer le TLS/mTLS. Combinez le type de cible ip du NLB avec l’annotation du AWS Load Balancer Controller service.beta.kubernetes.io/aws-load-balancer-target-type: "ip" pour enregistrer directement les adresses IP des pods ; ce patron est très scalable car le NLB est conçu pour des millions de connexions et prend en charge les sessions TCP/gRPC de longue durée sans terminaison TLS.

Pour l’ingress et le routage basé sur le chemin (path-based routing) avec terminaison HTTPS, l’Application Load Balancer est plus approprié car il prend en charge les règles basées sur l’hôte/le chemin, les redirections et l’intégration avec WAF. Pour préserver les adresses IP des clients lorsque l’ALB effectue la terminaison TLS, fiez-vous aux en-têtes X-Forwarded-For ; les serveurs web backend doivent consommer et journaliser X-Forwarded-For, et vous devriez activer les journaux d’accès de l’ALB pour vérification. Si vous avez besoin de la véritable adresse du socket client au niveau du serveur (pour des logiciels hérités), utilisez un NLB avec le proxy protocol v2 et assurez-vous que les services backend prennent en charge le proxy protocol.

La connectivité des services entre plusieurs comptes AWS et VPCs évolue différemment selon le patron utilisé. Le VPC peering est simple mais sa gestion est en N^2 ; Transit Gateway centralise le routage et est plus scalable pour un grand nombre de VPCs grâce à la ségrégation des tables de routage ; AWS PrivateLink (Interface VPC Endpoints) fournit le modèle d’accès par service le plus granulaire et sensible à l’identité, car vous exposez un service de point de terminaison via un NLB et les consommateurs créent des points de terminaison d’interface dans leurs propres VPCs. Pour les services partagés multi-comptes avec un contrôle d’accès strict et un onboarding scalable, préférez PrivateLink car il isole le routage (aucun changement de table de routage dans les VPCs consommateurs) et utilise les groupes de sécurité pour des contrôles fins.

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

Un piège récurrent est de supposer qu’un même modèle de réseau convient à toutes les charges de travail. Les charges de travail avec des connexions stateful ou de longue durée (gRPC, bases de données) privilégient le passthrough de niveau 4 (NLB) avec une terminaison TLS au niveau du pod ou des modèles hostPort/hostNetwork pour éviter la latence induite par le proxy ; les microservices HTTP qui nécessitent un routage basé sur le chemin, un WAF ou une terminaison WebSocket bénéficient des fonctionnalités d’ALB et d’App Mesh. Une autre erreur est de ne pas tenir compte des limites d’ENI/IP lors de la mise à l’échelle des nœuds EKS ou des tâches ECS en mode awsvpc : consultez toujours le tableau des types d’instances EC2 indiquant les ENI et les IP par ENI, et utilisez la délégation de préfixe ou les overlays Cilium lorsque vous avez besoin d’une haute densité de pods.

La surveillance et le débogage nécessitent plusieurs sources : les VPC Flow Logs et les métriques d’ENI pour voir le trafic sortant/entrant, les métriques CloudWatch pour les AWS Load Balancers (ActiveFlowCount, ProcessedBytes), et la télémétrie au niveau de l’application provenant d’Envoy/App Mesh ou de l’agent AWS X-Ray. Pour Lambda et Fargate, n’oubliez pas que les démarrages à froid liés aux opérations ENI peuvent être atténués par la simultanéité provisionnée ou en réarchitecturant les modèles d’accès pour utiliser les points de terminaison VPC et PrivateLink afin que les fonctions n’aient pas besoin d’un accès sortant étendu.

Problème pratique : Scénario d’utilisation

Nom de l’entreprise : Acme Payments Inc. Défi : Acme Payments exploite un service gRPC sur Amazon EKS qui doit prendre en charge des milliers de connexions TLS simultanées sur le port TCP 443, utiliser le TLS mutuel (mTLS) afin que le certificat client soit validé par le service backend, et permettre au cluster EKS de s’adapter automatiquement via le Cluster Autoscaler et HPA sans interrompre la connectivité ni exiger la terminaison TLS au niveau de l’équilibreur de charge.

Approche numérotée :

Déployer le service avec le TLS au niveau du pod et l’authentification mutuelle implémentés dans l’application ou dans un sidecar qui ne termine pas le TLS de bout en bout pour les clients externes. Stocker les certificats serveur/client dans AWS Secrets Manager et les monter via le CSI secrets store de Kubernetes ou utiliser un mécanisme de distribution de certificats qui fonctionne avec le cycle de vie du pod.
Utiliser l’AWS Load Balancer Controller pour créer un Network Load Balancer en annotant le Service (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”) et définir le type de cible sur IP (service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”), puis créer un écouteur TCP sur le port 443. Cela garantit que le NLB effectue un passthrough de niveau 4 et ne termine pas le TLS.
Configurer le groupe cible du NLB avec le protocole TCP et enregistrer dynamiquement les adresses IP des pods (le Load Balancer Controller appellera CreateTargetGroup et RegisterTargets). S’assurer que les bilans de santé sont définis sur TCP ou sur une sonde de santé personnalisée basée sur TCP à un intervalle court afin que les cibles soient marquées comme saines rapidement lors de l’autoscaling (aws elbv2 create-target-group –protocol TCP –port 443 –target-type ip; aws elbv2 create-listener –protocol TCP –port 443 …).
Ajuster l’Amazon VPC CNI pour prendre en charge une haute densité de pods et réduire le « churn » (rotation) des ENI : activer la délégation de préfixe si elle est prise en charge (définir ENABLE_PREFIX_DELEGATION=true dans le ConfigMap aws-node), configurer WARM_IP_TARGET pour maintenir des adresses de rechange, et surveiller les métriques aws-node (journaux du daemonset kube-system et métriques personnalisées CloudWatch). Si les limites d’IP au niveau du nœud sont une préoccupation, envisagez d’utiliser Cilium avec eBPF pour une plus grande densité de pods et des opérations ENI réduites.
Mettre le cluster à l’échelle en toute sécurité : s’assurer que le Cluster Autoscaler dispose des balises de groupe de nœuds et des autorisations IAM appropriées, définir des PodDisruptionBudgets, et vérifier que les bilans de santé du groupe cible et le drainage des connexions du NLB sont configurés pour éviter de perdre des connexions gRPC de longue durée lors d’une réduction d’échelle (scale-down).
Sécuriser la rotation et la confiance des certificats : automatiser la rotation des certificats avec ACM Private CA ou Secrets Manager et s’assurer que les pods récupèrent les « trust bundles » mis à jour sans nécessiter de reconfiguration du NLB. Utiliser des sondes de préparation (readiness) et de vivacité (liveness) Kubernetes qui reflètent l’état de la poignée de main mTLS.

Justification AWS : Un Network Load Balancer en mode de cible IP préserve le TLS jusqu’au pod (chiffrement de bout en bout véritable) et prend en charge des millions de connexions TCP persistantes, ce qui le rend approprié pour des milliers de sessions gRPC simultanées. L’enregistrement direct des adresses IP des pods évite la complexité de l’enregistrement par hostPort ou par cible d’instance au niveau du nœud et fonctionne de manière transparente avec le Cluster Autoscaler/HPA, car l’AWS Load Balancer Controller enregistrera et désenregistrera les adresses IP des pods à mesure que ceux-ci se mettent à l’échelle. L’ajustement du VPC CNI ou l’adoption d’un plan de données basé sur eBPF prévient l’épuisement des adresses IP et réduit la latence d’attachement/détachement des ENI, ce qui est essentiel pour un autoscaling rapide et les charges de travail à haute connexion. Le stockage et la livraison des artéfacts mTLS via Secrets Manager ou un fournisseur CSI rendent le cycle de vie des certificats gérable sans toucher à l’équilibreur de charge.

← Automatisation · Tous les domaines

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