Une entreprise de marketing utilise un réseau hybride avec AWS Direct Connect et une surcouche SD-WAN pour relier ses succursales. Plusieurs VPC se connectent à un VPC de transit d'appliance SD-WAN tiers dans le même compte AWS à l'aide d'AWS Site-to-Site VPN. L'entreprise prévoit de connecter davantage de VPC à ce VPC de transit d'appliance SD-WAN, mais elle rencontre des limites de scalabilité, des contraintes de table de routage et des coûts croissants avec la conception actuelle. Un ingénieur réseau doit proposer une solution qui résout ces problèmes et élimine les dépendances tout en nécessitant le MOINS de frais opérationnels. Quelle approche satisfait ces exigences ?

La bonne réponse est de configurer une Transit Gateway (TGW) pour attacher les VPC, puis d'utiliser un attachement TGW Connect pour le VPC de transit de l'appliance SD-WAN. Cette approche tire parti de l'intégration native de TGW Connect avec les hubs virtuels SD-WAN, ce qui permet une mise à l'échelle plus efficace, réduit les contraintes de table de routage et diminue les coûts opérationnels par rapport à de multiples connexions VPN Site-to-Site. TGW Connect utilise des tunnels GRE et BGP pour une connectivité dynamique et évolutive, éliminant la gestion manuelle de nombreuses connexions VPN. Les autres options sont incorrectes car : Configurer un Site-to-Site VPN entre TGW et le VPC de l'appliance SD-WAN résoudrait la mise à l'échelle des VPC, mais ne résoudrait pas les limites de mise à l'échelle du VPN lui-même ni les contraintes de table de routage côté appliance SD-WAN, et n'offrirait pas les avantages de TGW Connect. Le peering de VPC ne résout pas les problèmes d'évolutivité et de gestion des tables de routage pour un grand nombre de VPC, car il nécessite des connexions point à point et n'est pas transitif. La dernière option mélange le peering de VPC (non évolutif) avec TGW Connect, ce qui est contradictoire et ne résout pas le problème fondamental de la connectivité des VPC.