Amazon ANS-C01: Conception de VPC et réseautage avancé — 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.
Modèles de conception et compromis
Pour un service central partagé consommé par de nombreuses unités commerciales sur plusieurs comptes, PrivateLink et les services de point de terminaison constituent le modèle le plus sécurisé et le plus évolutif lorsque vous avez besoin d’un contrôle et d’une isolation par connexion. Hébergez le service derrière un Network Load Balancer dans le VPC des services partagés, créez un service de point de terminaison de VPC (
undefined
) et faites en sorte que les comptes consommateurs créent des points de terminaison d’interface que vous approuvez. Cela évite un maillage complet et empêche le routage transitif, et les groupes de sécurité sur les points de terminaison d’interface vous permettent de restreindre les consommateurs qui peuvent se connecter. Le compromis est un coût par point de terminaison et une certaine surcharge de gestion pour accepter et auditer les connexions des points de terminaison.
Transit Gateway est idéal lorsque vous avez de nombreux VPC qui nécessitent une connectivité étendue, une inspection centralisée et un endroit unique pour annoncer les préfixes sur site via Direct Connect (
undefined
,
undefined
). Utilisez la segmentation des tables de routage et les contrôles de propagation pour éviter les mouvements latéraux accidentels ; Transit Gateway prend en charge la priorisation des routes et les associations de tables de routage afin que vous puissiez isoler le trafic de production des réseaux de confiance inférieure. Le compromis est que Transit Gateway centralise le trafic et peut entraîner des coûts pour le trafic inter-VPC qui serait autrement local ; il modifie également les domaines de défaillance et nécessite une planification CIDR minutieuse pour éviter le chevauchement d’adresses.
Pour les architectures hybrides avec une réutilisation limitée des blocs CIDR, envisagez de combiner Direct Connect avec Transit Gateway et Direct Connect Gateway (
undefined
) pour réduire le nombre d’interfaces virtuelles. Si vous avez besoin d’une isolation de la bande passante par unité commerciale sur la liaison physique partagée, placez plusieurs interfaces virtuelles privées et surveillez les métriques CloudWatch par VIF (noms de métriques comme
undefined
) et utilisez des alarmes CloudWatch au niveau de la VIF. Pour identifier les gros consommateurs, activez les VPC Flow Logs (
undefined
) vers S3 ou CloudWatch Logs et analysez-les avec Athena ou CloudWatch Logs Insights ; pour la capture de paquets par VM, utilisez Traffic Mirroring (
undefined
) pour de courtes fenêtres.
L’adoption d’IPv6 et les conceptions à double pile (dual-stack) réduisent la dépendance à l’égard du NAT, diminuent les coûts de débit du NAT Gateway et simplifient l’adressage côté client. Utilisez l’appel d’API
undefined
pour attribuer un préfixe IPv6 fourni par Amazon et créer des sous-réseaux avec des blocs CIDR IPv6. Sachez que certains services et appliances tierces peuvent ne pas être prêts pour IPv6 ; utilisez le mode dual-stack sur les équilibreurs de charge (
undefined
avec
undefined
) pour prendre en charge les clients IPv4 et IPv6 pendant que les systèmes backend restent en IPv4.
Pièges courants et critères de décision
Négliger la consommation d’adresses IP par les pods Kubernetes est une source fréquente d’interruption de service. Tenez compte des limites d’ENI et d’adresses IP secondaires par type d’instance et utilisez les paramètres du CNI du VPC comme
undefined
ou la délégation de préfixe pour améliorer la disponibilité des adresses IP. Ne pas préserver les adresses IP des clients au niveau L7 est une autre lacune courante : si le TLS doit être terminé au niveau de l’équilibreur de charge, vous devez vous assurer que l’application lit l’en-tête
undefined
et que les contrôles de sécurité de l’ALB restreignent l’accès direct afin que les en-têtes puissent être considérés comme fiables. Supposer que le VPC peering peut évoluer indéfiniment conduit souvent à des maillages ingérables ; préférez Transit Gateway pour les expositions de service de type plusieurs-à-plusieurs (many-to-many) et PrivateLink pour celles de type un-à-plusieurs (one-to-many) lorsque vous avez besoin d’une sécurité granulaire et d’une isolation du trafic.
Les politiques de sécurité doivent utiliser les groupes de sécurité et les ACL réseau en combinaison avec des contrôles au niveau de l’espace de noms (namespace). Pour une application stricte de l’accès via Global Accelerator au lieu des URL directes de l’ALB, appuyez-vous sur une combinaison d’ensembles d’adresses IP AWS WAF qui sont remplis avec les plages d’adresses IP de Global Accelerator (automatisé via le fichier
undefined
publié) ou concevez l’ALB comme étant interne et placez devant lui un NLB que Global Accelerator cible, puis n’exposez que la porte d’entrée de Global Accelerator. Automatisez toujours les mises à jour de tous les contrôles basés sur les adresses IP et validez en utilisant
undefined
et une ingestion régulière du fichier
undefined
.
Problème pratique : Scénario d’utilisation
Entreprise : Equinox Payments. Défi : Equinox exploite un service gRPC basé sur EKS nécessitant du mTLS de bout en bout pour des milliers de connexions simultanées, un autoscaling via Cluster Autoscaler et HPA, et la préservation des adresses IP des clients pour la journalisation. Approche : 1) Déployez le service derrière un Network Load Balancer configuré avec un écouteur TCP sur le port 443 via le contrôleur AWS Load Balancer en utilisant l’annotation
undefined
afin que les adresses IP des pods soient enregistrées comme cibles ; 2) terminez le TLS au niveau des pods (pas du NLB) et implémentez le TLS mutuel dans l’application (validation des certificats serveur et client), avec des secrets Kubernetes pour les certificats et des sondes de préparation (readiness probes) pour piloter l’enregistrement des cibles ; 3) utilisez le type de cible
undefined
pour préserver les adresses IP sources des clients, activez le protocole proxy uniquement si nécessaire pour les appliances intermédiaires, et comptez sur la journalisation côté pod pour capturer l’adresse IP du client à partir de la connexion TCP ; 4) configurez les vérifications de santé comme des sondes de préparation TCP ou compatibles gRPC, et assurez-vous que les politiques du Cluster Autoscaler et les types d’instances de nœuds disposent d’une capacité suffisante en ENI et en adresses IP ; 5) implémentez CloudWatch Container Insights et les VPC Flow Logs (
undefined
) pour surveiller le nombre de connexions et la télémétrie au niveau du VPC. Justification AWS : Le NLB avec des écouteurs TCP préserve les sessions chiffrées et les adresses IP sources tout en s’adaptant à des millions de connexions ; le type de cible
undefined
permet aux pods de recevoir directement l’adresse IP source sans NAT ; la terminaison du mTLS au niveau des pods satisfait le chiffrement de bout en bout et l’authentification bidirectionnelle ; l’autoscaling fonctionne car l’état de préparation des pods affecte directement l’enregistrement des cibles et le NLB s’adapte de manière transparente à la charge de connexion.
Tous les domaines · Connectivité hybride : VPN et Direct Connect →
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 →