Amazon ANS-C01: Automatisation, IaC et opérations 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.
Concept de base
L’Infrastructure as Code pour le réseau sur AWS transforme la topologie réseau, la politique de sécurité et le routage en modèles déclaratifs et en opérations de cycle de vie déterministes. Les modèles CloudFormation (AWS::EC2::VPC, AWS::EC2::Subnet, AWS::EC2::RouteTable, AWS::EC2::TransitGateway, AWS::EC2::TransitGatewayAttachment, AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::EC2::VPCEndpoint, AWS::EC2::NetworkAcl, AWS::EC2::SecurityGroup) encodent l’état désiré, tandis que les API CloudFormation — les opérations CreateStack, UpdateStack, DeleteStack, DescribeStacks et ChangeSet — appliquent les changements de manière atomique. Utilisez des piles imbriquées et des modèles modulaires pour isoler les domaines réseau (services partagés, VPC d’application par compte, zones d’entrée/sortie) et des StackSets pour propager des piles réseau cohérentes à travers AWS Organizations. La détection de dérive (DetectStackDrift) et les ensembles de modifications (change sets) fournissent des garde-fous pour que l’automatisation puisse détecter et exiger une revue humaine pour les changements réseau hors bande.
L’automatisation doit également couvrir les parties du réseau que CloudFormation ne peut pas exprimer nativement ou qui nécessitent des hooks de cycle de vie : le partage de ressources entre comptes, les intégrations sur site (on-prem) et la configuration à l’exécution sur les hôtes. Les ressources personnalisées CloudFormation (basées sur Lambda) ou les modules CloudFormation peuvent appeler des API telles que CreateResourceShare (AWS RAM) pour partager un Transit Gateway ou un sous-réseau, ou appeler Systems Manager (SSM) SendCommand pour injecter des certificats ou des politiques de routage dans les instances. Pour Kubernetes dans EKS, l’AWS Load Balancer Controller est installé via Helm et géré par le biais d’annotations de Service ; CloudFormation peut provisionner le rôle IAM, le fournisseur OIDC et les objets HelmRelease via AWS::EKS::Cluster et des ressources personnalisées, mais le mappage à l’exécution des adresses IP des pods vers les groupes cibles du NLB est géré par le contrôleur.
Services et configuration clés
Il existe des services et API AWS principaux que vous utiliserez de manière répétée lors de l’automatisation des opérations réseau : CloudFormation (CreateStack, UpdateStack, DetectStackDrift), AWS Resource Access Manager (CreateResourceShare, AssociateResourceShare), AWS Transit Gateway (CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute), Elastic Load Balancing V2 (CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes), AWS Lambda (CreateFunction, AddPermission, Invoke), Systems Manager (PutParameter, SendCommand, CreateDocument), et AWS Config (PutEvaluations, StartConfigurationRecorder). Ces services forment une pile d’automatisation typique pour un réseautage sécurisé et auditable.
Lors de la conception des modèles et de l’automatisation, prêtez attention aux attributs de ressource spécifiques et aux annotations du contrôleur. Pour les équilibreurs de charge, choisissez le type et les attributs corrects : un NLB avec des écouteurs TCP préserve l’adresse IP source et prend en charge le Proxy Protocol v2 via CreateLoadBalancer/ModifyTargetGroupAttributes et en définissant “proxy_protocol_v2.enabled” sur les groupes cibles ; un ALB (Application Load Balancer) termine la connexion TLS et insère les en-têtes X-Forwarded-For pour les adresses IP des clients, et prend en charge gRPC/HTTP2 lorsqu’il est configuré avec des écouteurs HTTPS. Pour EKS, vous utilisez des annotations telles que service.beta.kubernetes.io/aws-load-balancer-type: “nlb” ou les annotations Ingress/Service de l’AWS Load Balancer Controller pour contrôler le passthrough TLS par rapport à sa terminaison et pour définir le type de cible (target type) sur ip pour un ciblage direct des pods. Pour le partage entre comptes et les réseaux multi-comptes, vous utiliserez AWS RAM pour partager des Transit Gateways, et des CloudFormation StackSets combinés à des rôles d’administrateur délégué pour créer des attachements et des accès dans les comptes consommateurs.
Patrons de conception et compromis
Deux modèles courants et contrastés sont le hub-and-spoke avec Transit Gateway et le VPC partagé via AWS RAM. Le modèle hub-and-spoke avec un Transit Gateway centralise le routage, l’inspection et la connectivité inter-VPC ; il est scalable car les attachements et les tables de routage permettent la segmentation, et vous pouvez partager le TGW en utilisant RAM afin que différents comptes puissent créer des attachements sans transférer la pleine propriété. Le compromis réside dans la propagation des routes et les limites des tables de routage : les tables de routage et les limites d’attachement du Transit Gateway nécessitent une planification et peuvent introduire des points uniques où la politique doit être appliquée (utilisez plusieurs tables de routage et AWS Network Firewall pour isoler le trafic). Le VPC partagé (partage de VPC avec AWS RAM) place les sous-réseaux dans un compte hôte et permet aux comptes consommateurs de lancer des ressources dans ces sous-réseaux, ce qui simplifie les contrôles de sécurité centraux pour la connectivité mais réduit l’autonomie au niveau du compte et complique l’isolation réseau par unité commerciale, car la propriété des groupes de sécurité et les limites IAM doivent être gérées avec soin.
Pour l’entrée de trafic (ingress) et la terminaison TLS, vous devez équilibrer le besoin de chiffrement de bout en bout avec la mise à l’échelle et la préservation de l’IP client. Si vous avez besoin d’une terminaison TLS au niveau de l’équilibreur de charge (pour WAF, la centralisation des certificats et le routage HTTP), l’ALB est l’outil approprié ; il ajoute l’en-tête X-Forwarded-For pour que la journalisation applicative puisse capturer les adresses IP des clients, et l’ALB prend en charge le routage basé sur le chemin et l’hôte vers plusieurs groupes cibles. Si vous avez besoin d’un véritable TLS de bout en bout ou de mTLS où l’équilibreur de charge ne doit pas déchiffrer le trafic, utilisez un NLB en mode TCP pour laisser passer le TLS jusqu’aux points de terminaison backend (pod ou instance) et configurez le type de cible (target type) sur ip et externalTrafficPolicy: Local sur Kubernetes pour préserver l’adresse IP source. Pour des milliers de connexions gRPC bidirectionnelles simultanées avec mTLS, un NLB transférant le TLS brut vers les ports des pods, combiné à des pods terminant le mTLS, offre une scalabilité et un véritable chiffrement de bout en bout, tout en utilisant les annotations de l’AWS Load Balancer Controller pour créer les écouteurs et les groupes cibles NLB appropriés.
Pièges courants et critères de décision
Un écueil fréquent est de confondre l’emplacement de la terminaison TLS avec les exigences relatives à l’adresse IP du client : un ALB fournit l’en-tête X-Forwarded-For lorsqu’il termine la connexion TLS, mais il ne préserve pas l’adresse IP source jusqu’à la cible comme le fait un NLB. Si vous avez besoin à la fois des fonctionnalités d’un ALB (routage par hôte/chemin, WAF) et de l’adresse IP source originale au niveau du backend, envisagez d’utiliser un ALB pour la terminaison HTTP et de transférer le trafic vers des proxys inverses ou des sidecars qui reconstruisent les adresses IP sources à partir de l’en-tête X-Forwarded-For, ou d’utiliser une architecture où un NLB laisse passer le trafic TLS vers des services qui effectuent le mTLS et délèguent le routage HTTP à des proxys au sein du cluster. Un autre écueil est la mauvaise configuration des autorisations inter-comptes : lors du partage d’une Transit Gateway ou d’une autre ressource réseau avec RAM, assurez-vous d’utiliser un partage de ressource explicite ainsi que le rôle IAM et le principal RAM corrects ; ne pas le faire entraîne des erreurs opaques de type « permission denied ».
Concernant l’automatisation de la conformité, ne stockez pas les clés privées ou les matériaux de l’autorité de certification (CA) non chiffrés en texte clair. Utilisez SSM Parameter Store SecureString avec une clé KMS dont la politique de clé minimale n’autorise que les rôles et les principaux qui nécessitent un accès. Utilisez les règles gérées d’AWS Config (par exemple, vpc-flow-logs-enabled, restricted-common-ports, security-group-rule-check) et, lorsque les règles gérées ne couvrent pas vos critères, implémentez des règles Config basées sur Lambda qui appellent PutEvaluations. La remédiation doit être automatisée via des documents SSM Automation ou Systems Manager Run Command que l’action de remédiation de Config peut invoquer, mais prévoyez toujours un chemin d’alerte et d’approbation pour les changements à haut risque.
Problème pratique : Scénario d’utilisation
Entreprise : ApexTelemetrics — défi : fournir un service gRPC hébergé sur EKS et accessible mondialement, qui exige un véritable TLS mutuel de bout en bout (le client et le serveur s’authentifient avec mTLS), supporte des milliers de connexions simultanées et de longue durée sur le port TCP 443, doit mettre à l’échelle automatiquement les pods (autoscaling), et garantir que la distribution et la rotation des certificats sont automatisées et auditables.
Approche :
- Provisionner le réseau et le load balancer avec CloudFormation : créer un NLB via AWS::ElasticLoadBalancingV2::LoadBalancer configuré avec un listener TCP sur le port 443 et des groupes cibles avec targetType défini sur « ip » et des vérifications de santé sur TCP. Utiliser CloudFormation CreateStack/UpdateStack et des piles imbriquées modulaires pour le VPC, les subnets et le NLB. Utiliser les annotations de l’AWS Load Balancer Controller sur le Service EKS (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”, service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”) afin que chaque Service crée le groupe cible du NLB directement vers les pods.
- Assurer le passthrough TLS et la terminaison mTLS au niveau des pods : configurer le Service EKS pour transférer le trafic TCP 443 directement aux ports des pods ; implémenter un proxy sidecar ou envoy à l’intérieur de chaque pod qui effectue la terminaison mTLS avec le client et impose l’authentification mutuelle. Définir externalTrafficPolicy: Local sur le Service pour que l’adresse IP source soit préservée si nécessaire, et utiliser l’autoscaling au niveau des pods (Horizontal Pod Autoscaler) avec le Cluster Autoscaler pour mettre à l’échelle les nœuds et les pods ensemble.
- Automatiser le cycle de vie et la distribution des certificats : stocker les clés privées du certificat de l’autorité de certification (CA) et du serveur dans SSM Parameter Store SecureString, chiffrées par une clé KMS. Créer une ressource personnalisée basée sur AWS Lambda dans CloudFormation pour créer des paramètres SSM lors de la création de la pile (CreateFunction avec le rôle IAM approprié, puis une ressource personnalisée CloudFormation pour appeler PutParameter). Utiliser SSM Run Command ou un DaemonSet immuable qui récupère les secrets de SSM via un rôle IAM lié au pod (via IRSA) pour injecter les certificats dans le sidecar. Pour la rotation, planifier des fonctions Lambda (CreateFunction + règle EventBridge) pour générer de nouveaux certificats, appeler PutParameter, et utiliser SSM ou des Jobs Kubernetes pour effectuer des redémarrages progressifs (rolling restarts).
- Conformité et audit : activer les règles AWS Config (règles gérées telles que vpc-flow-logs-enabled et règles personnalisées basées sur Lambda utilisant PutEvaluations) pour vérifier que les listeners du NLB sont en TCP et qu’aucun ALB ne termine la connexion TLS pour ce service. Configurer la remédiation de Config pour invoquer des documents SSM Automation si une mauvaise configuration est détectée et envoyer les résultats (findings) à AWS Security Hub et CloudWatch Events. Justification AWS : Le NLB en mode TCP fournit le véritable passthrough TLS requis pour le mTLS de bout en bout et peut monter en charge pour gérer des milliers de connexions simultanées avec une faible empreinte CPU par connexion au niveau du load balancer. Le ciblage des pods via targetType=ip supprime un saut réseau supplémentaire et maintient la réactivité de l’autoscaling. Le stockage et la rotation des clés dans SSM Parameter Store, sécurisés par KMS, offrent une gestion centralisée et auditable des secrets avec des contrôles IAM. De plus, l’utilisation de CloudFormation avec des ressources personnalisées Lambda et EventBridge garantit que l’ensemble du cycle de vie est codifié, reproductible et observable.
← Performance et surveillance du réseau · Tous les domaines · Réseautage de conteneurs et sans serveur →
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 →