Amazon ANS-C01: Transit Gateway et topologie 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.
Concepts fondamentaux
AWS Transit Gateway (TGW) est un hub de transit réseau régional qui centralise le routage entre les Amazon VPC, les VPN, les passerelles Direct Connect et d’autres Transit Gateways. Au plus simple, un TGW agit comme un plan de routage : vous créez des attachements (par exemple avec l’appel d’API EC2 CreateTransitGatewayVpcAttachment pour les VPC, CreateTransitGatewayAttachment pour les appliances, ou CreateTransitGatewayPeeringAttachment pour le peering) puis vous contrôlez comment ces attachements échangent des routes en les associant et en propageant leurs routes dans une ou plusieurs tables de routage Transit Gateway. Les tables de routage sur un TGW fournissent les primitives d’isolation et de segmentation qui permettent au TGW d’agir comme plusieurs routeurs virtuels (VRF). Pour chaque attachement, vous décidez à quelle table de routage TGW il est associé (en utilisant AssociateTransitGatewayRouteTable) et quels attachements propagent leurs routes dans quelles tables (via les paramètres de propagation de la table de routage). Le TGW transfère les paquets en se basant sur la correspondance du plus long préfixe (longest-prefix match) à travers toutes les tables de routage auxquelles l’attachement source est associé. Une conception minutieuse des limites d’association/propagation est donc la manière dont vous mettez en œuvre des topologies hub-and-spoke, des hubs segmentés ou des maillages partiels.
Le peering de Transit Gateway crée un chemin chiffré et privé inter-régions ou inter-comptes entre des TGW qui dépend toujours de la configuration des tables de routage pour permettre le flux de trafic. Vous créez le peering avec CreateTransitGatewayPeeringAttachment du côté du demandeur, puis AcceptTransitGatewayPeeringAttachment du côté de l’accepteur ; après cela, vous devez ajouter des routes aux tables de routage TGW appropriées pour que l’attachement de peering soit utilisé. Le peering n’est pas transitif : le trafic ne circulera pas de TGW-A à TGW-C via TGW-B, à moins qu’un peering explicite et des mappages de tables de routage ne le permettent. TGW prend également en charge les attachements Connect pour une connectivité haute performance vers des appliances SD-WAN ou tierces, créés avec l’API CreateTransitGatewayConnect, ce qui permet l’encapsulation (GRE, VXLAN) et le transfert à haut débit vers des appareils spécialisés.
Services clés et configuration
Configurez les attachements VPC en utilisant CreateTransitGatewayVpcAttachment et assurez-vous de définir les options d’attachement dont vous avez besoin : par exemple, activez ApplianceModeSupport sur les attachements VPC qui transfèrent du trafic vers des appliances réseau afin que le TGW conserve la destination d’origine lors de l’envoi du trafic à l’appliance. Après avoir créé les attachements, utilisez CreateTransitGatewayRouteTable pour créer des tables de routage TGW supplémentaires au-delà de celle par défaut, puis appelez AssociateTransitGatewayRouteTable et activez la propagation pour les attachements choisis afin que leurs préfixes apparaissent dans la table de routage. Pour les cas d’usage multicast, créez un domaine de multicast avec CreateTransitGatewayMulticastDomain, puis utilisez AssociateTransitGatewayMulticastDomain pour les attachements qui participeront, et utilisez RegisterTransitGatewayMulticastGroupMembers et RegisterTransitGatewayMulticastGroupSources pour établir l’appartenance au groupe et les sources. Les domaines de multicast sont distincts des tables de routage unicast et sont nécessaires pour la livraison de groupe de type IGMP à travers les VPC et les appliances.
Pour la visibilité de la topologie globale et l’application des politiques, utilisez AWS Transit Gateway Network Manager (qui fait partie d’AWS Network Manager). Créez un réseau global (Global Network) dans Network Manager (via la console ou networkmanager:CreateGlobalNetwork) et enregistrez les Transit Gateways pour obtenir une vue nord/sud à travers les régions et les connexions sur site. Network Manager fournit une surveillance automatisée des performances, des visualisations cœur-périphérie et des analyses de routage ; il peut ingérer les métriques CloudWatch et les journaux de flux VPC (VPC flow logs) et les corréler avec les attachements TGW et les liens VPN/Direct Connect. L’intégration avec AWS Resource Access Manager (RAM) vous permet de partager un TGW géré de manière centralisée avec d’autres comptes AWS en utilisant CreateResourceShare et les attachements de principaux appropriés ; n’oubliez pas de définir l’option TGW AutoAcceptSharedAttachments ou de gérer les acceptations de manière programmatique.
Modèles de conception et compromis
Une topologie en étoile (hub-and-spoke) mise en œuvre avec un unique Transit Gateway est le modèle le plus courant pour les architectures multi-VPC et multi-comptes, car elle centralise la connectivité, simplifie la distribution des routes et permet de consolider les services partagés, les appliances de sécurité et la connectivité sur site (on-prem). Utilisez une ou plusieurs tables de routage TGW pour assurer la segmentation entre les unités commerciales : associez les spokes à une table de routage spécifique au spoke et propagez les préfixes des services partagés uniquement dans les tables qui doivent y avoir accès. Le compromis est que cette centralisation peut devenir un point d’étranglement unique (chokepoint) pour le trafic et un rayon d’impact (blast radius) unique en cas de mauvaise configuration ; les flux est-ouest importants transitant par le TGW peuvent nécessiter une ingénierie de trafic minutieuse, le déploiement d’attachements Connect pour les appliances à haut débit, ou le placement de TGW régionaux pour maintenir le trafic local.
Un maillage complet (peering entre TGW ou nombreuses liaisons de peering VPC) fournit une connectivité directe et réduit la dépendance à un hub central pour certains modèles de trafic, mais il introduit une complexité opérationnelle à mesure que le nombre de liaisons augmente et complique l’application des politiques de sécurité sur de nombreux domaines administratifs. Le peering de Transit Gateway (CreateTransitGatewayPeeringAttachment + AcceptTransitGatewayPeeringAttachment) permet une connectivité backbone inter-régions avec chiffrement sur le réseau mondial d’AWS et s’avère utile lorsque vous souhaitez une isolation régionale tout en bénéficiant de certains services partagés. Cependant, vous devez gérer explicitement les mappages des tables de routage et accepter que le peering n’est pas transitif. Vous pouvez combiner les modèles : un TGW en étoile (hub-and-spoke) par région et un peering entre les hubs pour le trafic inter-régions équilibre souvent la mise à l’échelle, la latence et les domaines de défaillance.
Lors de l’intégration de réseaux sur site (on-premises), attachez le Direct Connect Gateway au TGW en utilisant les fonctionnalités d’association de Direct Connect (configurez une interface virtuelle privée sur Direct Connect et créez une association avec le TGW via la console ou l’API Direct Connect). Évaluez s’il faut utiliser des VPN basés sur les routes (BGP sur IPSec) pour le routage dynamique ou des routes statiques pour les flux étroitement contrôlés. Pour les cas d’usage d’inspection basée sur des appliances et de terminaison TLS mutuelle, évitez de terminer le TLS sur une appliance centrale si un chiffrement de bout en bout est requis entre les clients et les backends ; effectuez plutôt la terminaison TLS au niveau de la couche applicative (par exemple, au niveau des pods dans EKS) et utilisez le routage TGW pour diriger le trafic vers un ALB ou un Network Load Balancer qui préserve les IP clientes avec le Proxy Protocol ou utilise les en-têtes X-Forwarded-For de l’ALB.
Pièges courants et critères de décision
Une erreur opérationnelle courante est de supposer que TGW fournit une segmentation implicite ; ce n’est pas le cas. Vous devez créer et associer explicitement des tables de routage et activer la propagation pour contrôler quels attachements peuvent atteindre quels préfixes. Un autre piège fréquent est la mauvaise configuration des groupes de sécurité et des NACL : TGW ne gère que le routage, donc tous les groupes de sécurité et NACL des VPC s’appliquent toujours et doivent être alignés avec la connectivité de bout en bout souhaitée. Attendez-vous à ce que les groupes de sécurité avec état (stateful) soient évalués au niveau de l’instance ou de l’équilibreur de charge ; si vous avez besoin de préserver l’IP du client lors de la terminaison TLS au niveau de l’ALB, activez le X-Forwarded-For de l’ALB et, pour les Network Load Balancers, préservez l’IP source en utilisant le type de cible IP et le proxy-protocol si nécessaire.
Les décisions de mise à l’échelle dépendent souvent du volume de trafic et des limites administratives. La centralisation de nombreux flux à haut débit via un seul TGW peut compliquer les performances et la reprise après sinistre ; utilisez les attachements Transit Gateway Connect pour les liens d’appliances à large bande passante, envisagez plusieurs TGW avec peering pour l’isolation, et utilisez Network Manager pour surveiller et déclencher des alarmes en cas de saturation. Vérifiez toujours les limites souples (soft limits) pour le nombre d’attachements, de tables de routage et de domaines multicast, et demandez des augmentations si nécessaire plutôt que de vous fier aux quotas par défaut.
Problème pratique : Scénario d’utilisation
Entreprise : Atlas Financial Services. Défi : Atlas doit connecter dix VPC d’unités commerciales dans us-east-1 à un VPC central de services partagés, appliquer un accès réseau de moindre privilège entre les unités et les services partagés, pouvoir s’adapter à des dizaines d’unités commerciales supplémentaires au fil du temps, et fournir une comptabilité du trafic par unité commerciale pour dépanner les pics qui saturent occasionnellement leur liaison Direct Connect.
Approche (numérotée) :
- Provisionner un Transit Gateway régional avec
undefined
et créer une table de routage Transit Gateway dédiée pour chaque unité commerciale plus une pour les services partagés en utilisant
undefined
; cela permet une segmentation par unité sans l’explosion de peerings VPC. 2. Attacher chaque VPC d’unité commerciale via
undefined
et
undefined
à la table de routage par unité ; attacher le VPC des services partagés et l’associer uniquement à la table de routage des services partagés. 3. Activer la propagation de manière sélective : faire en sorte que chaque attachement d’unité commerciale propage ses routes dans sa propre table de routage et que l’attachement des services partagés propage ses préfixes dans une table de services partagés distincte ; puis ajouter des routes statiques dans la table de routage de chaque unité qui pointent vers l’attachement des services partagés pour les préfixes autorisés, appliquant ainsi le moindre privilège en ne propageant pas les préfixes des unités dans la table des services partagés. 4. Partager le TGW avec d’autres comptes AWS en utilisant AWS RAM (
undefined
) afin que l’intégration d’une nouvelle unité commerciale se résume à un attachement VPC et une association de table de routage, minimisant ainsi la charge administrative. 5. Pour la comptabilité du trafic et le dépannage, activez les Flow Logs sur le TGW et les VPC associés, et intégrez le TGW à AWS Network Manager (
undefined
et enregistrez le TGW) pour visualiser la topologie et surveiller la bande passante. Corrélez les flow logs du TGW et les métriques CloudWatch pour identifier quel attachement cause la saturation de Direct Connect. 6. Si la capacité de Direct Connect est saturée pendant des pics prévisibles, créez une Direct Connect Gateway et utilisez une association Direct Connect avec le TGW ; mettez en œuvre le marquage (tagging) des routes par unité commerciale et, si nécessaire, configurez des politiques de routage (communautés BGP on-prem ou filtres de route) au niveau de la Direct Connect Gateway pour limiter ou façonner le trafic par unité.
Justification AWS : L’utilisation d’un TGW avec des tables de routage par unité fournit une segmentation forte et s’adapte de manière linéaire à mesure que de nouvelles unités sont ajoutées, sans la complexité du peer-to-peer. Le partage du TGW avec AWS RAM minimise la gestion entre comptes. La propagation sélective et les entrées de routes statiques appliquent le moindre privilège au niveau du plan de routage, tandis que les groupes de sécurité et les NACL appliquent l’accès au niveau de l’instance. Les Flow Logs combinés à Network Manager fournissent la visibilité nécessaire pour identifier précisément quel attachement ou quelle unité commerciale sature Direct Connect, afin qu’Atlas puisse appliquer des contrôles de quota ou demander des augmentations de capacité ciblées sur l’unité en cause.
← Connectivité hybride : VPN et Direct Connect · Tous les domaines · DNS et Route 53 →
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 →