AWS Cloud WAN vs Transit Gateway : La comparaison honnête de 2026 pour les ingénieurs

AWS Cloud WAN n'est pas simplement « Transit Gateway v2 ». C'est un changement architectural fondamental, passant d'un modèle de routage impératif et régional à un cadre global, déclaratif et piloté par des politiques pour le cloud networking. Bien qu'AWS Transit Gateway (TGW) reste un outil puissant et rentable pour les topologies hub-and-spoke régionales, Cloud WAN est la réponse stratégique d'AWS à la difficulté opérationnelle de gérer des réseaux multi-régions à grande échelle. Pour toute organisation gérant plus de quelques VPC sur plusieurs continents, comprendre les compromis entre ces deux services n'est plus un exercice académique — c'est une décision de conception critique avec des implications durables pour les coûts, l'agilité et la sécurité en 2026 et au-delà.

Primitives architecturales : Hub-and-Spoke vs. Global Mesh

Un AWS Transit Gateway est une ressource régionale. Il fonctionne comme un routeur hub-and-spoke classique, connectant des VPC, des VPN et des Direct Connect Gateways (DXGW) au sein d'une seule région AWS. Son modèle mental est familier à tout ingénieur réseau : il a des attachments et des tables de routage. Vous définissez de manière impérative comment le trafic circule en associant des attachments à des tables de routage spécifiques et en créant des routes statiques ou propagées. Pour construire un réseau global, vous devez manuellement "peer" les TGW dans différentes régions, formant un full mesh de connexions que vous êtes responsable de gérer. Ce processus, bien que fonctionnel, génère une surcharge opérationnelle significative et ne scale pas bien. Chaque peering est un point de défaillance, un fardeau de configuration et une ligne de coût de transfert de données distincte.

Cloud WAN abstrait cette complexité. Sa primitive principale est le Core Network, un objet global unique qui représente l'ensemble de votre backbone réseau. Au sein de ce Core Network, vous déployez des Core Network Edges (CNE) dans les régions AWS souhaitées. Ces CNE sont les points de présence régionaux de votre réseau global. Les VPC, les VPN et les DXGW s'attachent à leur CNE local. Il est crucial de noter que le routage entre les CNE sur le backbone global d'AWS est automatique et géré par AWS. Vous ne configurez pas le peering inter-régions ; vous déclarez simplement quelles parties de votre réseau peuvent communiquer entre elles, et Cloud WAN gère la logique de routage sous-jacente. Il transforme le réseau d'une collection de hubs discrets et connectés manuellement en un réseau global unique, logique et maillé.

Routage et segmentation : Tables de routage TGW vs. Core Network Policy

C'est la différence la plus critique. Avec Transit Gateway, le routage est granulaire et impératif. Vous pourriez avoir une douzaine de tables de routage par TGW : une pour les VPC de production, une pour le développement, une pour les shared services, une pour le VPC d'inspection, une autre pour le trafic d'egress, et ainsi de suite. Propager les routes de 100 VPC dans les tables correctes et assurer un routage symétrique via un appliance de firewall full-stateful comme un PA-5440 nécessite une configuration méticuleuse et sujette aux erreurs. Un administrateur doit comprendre les implications de chaque route statique et de chaque paramètre de propagation. Cela offre un contrôle ultime, mais au prix d'une charge cognitive élevée.

Cloud WAN remplace cela par une Core Network Policy (CNP). La CNP est un document JSON unique qui définit l'intention de votre réseau de manière déclarative. Les deux principales constructions au sein de la politique sont les Segments et les Attachment Policies.

Core Network Segments

Un Segment est une partition réseau logique, analogue à une instance VRF (Virtual Routing and Forwarding) dans un routeur traditionnel comme un Catalyst 9500-48UXM. Les segments courants incluent production, development, shared_services et onprem. Par défaut, les segments sont des domaines de routage complètement isolés. Un VPC dans le segment production ne peut pas router vers un VPC dans le segment development, même s'ils sont dans la même région. Cela offre une isolation puissante et de haut niveau sans toucher à une seule table de routage.

Attachment Policies et Segment Actions

Une Attachment Policy mappe les attachments aux segments en fonction des tags. Par exemple, vous pouvez définir une règle : « Tout attachement de VPC avec le tag network-segment: prod est automatiquement mappé au segment production. » C'est du policy-as-code pour l'onboarding réseau. Lorsqu'un nouveau VPC de production est créé avec le bon tag, Cloud WAN le place automatiquement dans le bon domaine de routage.

Pour activer la communication entre les segments, vous utilisez les Segment Actions au sein du CNP. Par exemple, pour permettre au segment production d'atteindre le segment shared_services, vous définiriez une action create-route dans le segment production qui pointe vers le segment shared_services. Vous pouvez également définir des routes blackhole ou des routes statiques vers des attachments spécifiques, comme un appliance de sécurité pour l'inspection du trafic. Ce modèle déclaratif — définir *ce qui* doit être connecté, et non *comment* — est l'essence de la puissance de Cloud WAN.

Dimensionnement réel et analyse des coûts (tarification 2026)

Modélisons un scénario tangible : une entreprise avec 50 VPC dans us-east-1 et 50 dans eu-west-1. Ils ont un Direct Connect de 10 Gbps dans chaque région, se connectant à leurs datacenters. Le volume total de données traitées via le Core Network est de 20 To par mois par région, dont 10 To de ce trafic circulent entre les régions US et EU.

Modèle de coût 1 : Deux Transit Gateways avec Peering

• Heures d'instance TGW : 2 TGW * 0,05 $/heure * 730 heures/mois = 73,00 $
• Heures d'attachment : 102 attachments (100 VPC + 2 DXGW) * 0,05 $/attachment-heure * 730 heures/mois = 3 723,00 $
• Traitement des données régionales : 30 To (20 To VPC->VPC in-region + 10 To à envoyer cross-region) * 2 régions * 0,02 $/Go = 1 228,80 $ (environ, car une partie du trafic est traitée deux fois)
• Transfert de données inter-régions : C'est le coût majeur. 10 To de données envoyées via le TGW peering de us-east-1 vers eu-west-1 entraînent des frais de transfert. 10 240 Go * 0,02 $/Go = 204,80 $.
• Total mensuel estimé : ~5 230 $

Modèle de coût 2 : Cloud WAN global

• Heures de Core Network Edge : 2 CNE (1 par région) * 0,299 $/heure * 730 heures/mois = 436,54 $
• Heures d'attachment : 102 attachments * 0,05 $/attachment-heure * 730 heures/mois = 3 723,00 $
• Traitement des données Cloud WAN : 40 To de données totales traitées * 0,03 $/Go = 1 228,80 $ (Remarque : Cloud WAN a des frais de traitement de données par paliers, nous utilisons un taux moyen pour cet exemple).
• Transfert de données inter-régions : C'est un avantage essentiel. Cloud WAN n'a pas de frais distincts de transfert de données pour le « peering inter-régions ». Le trafic est couvert par les frais de traitement de données standard, car il transite par le AWS Global Backbone géré par le service.
• Total mensuel estimé : ~5 388 $

À première vue, les coûts semblent similaires. Cependant, le modèle Cloud WAN simplifie la facturation et supprime la taxe punitive sur le transfert de données inter-régions. À mesure que le nombre de régions augmente, le coût et la complexité d'un modèle de TGW peering en full-mesh augmentent de manière non linéaire, tandis que le modèle Cloud WAN scale de manière plus prévisible. Le léger surcoût de Cloud WAN vous offre une immense simplicité opérationnelle et un modèle de politique global et unifié.

Modèles de sécurité et d'inspection

L'insertion d'un firewall, comme un FortiGate 1800F ou un Palo Alto Networks VM-Series exécutant PAN-OS 11.2, est une exigence standard. Avec TGW, cela implique généralement un « inspection VPC » dédié. Vous manipulez les tables de routage pour forcer le trafic d'un VPC spoke vers le TGW, puis vers l'ENI de l'inspection VPC, puis de nouveau vers le TGW, et enfin vers sa destination. C'est ce qu'on appelle le « hairpinning » et cela nécessite une gestion minutieuse de plusieurs tables de routage pour assurer la symétrie.

Cloud WAN simplifie cela avec le Appliance Mode pour les attachements VPC. Lorsqu'il est activé sur l'attachement de l'inspection VPC, Cloud WAN assure automatiquement que le trafic circulant entre différents segments (par exemple, prod-to-onprem) est dirigé vers la même Availability Zone dans l'inspection VPC pour l'ingress et l'egress. Dans votre Core Network Policy, vous définissez simplement une route statique dans votre segment production pour 0.0.0.0/0 qui pointe vers l'attachement de l'inspection VPC. Ce simple changement de politique dirige le trafic pour inspection sans la manipulation complexe de la table de routage requise par TGW.

Piège courant : Politiques de segment trop permissives

Le pouvoir déclaratif de la Core Network Policy est une arme à double tranchant. Une erreur courante consiste à créer des règles de partage larges et permissives au début d'un déploiement. Par exemple, un administrateur réseau essayant d'activer rapidement la connectivité pourrait créer une règle qui partage toutes les routes de tous les segments avec tous les autres segments. Cette action aplatit efficacement le réseau, annulant complètement les avantages d'isolation de la segmentation et recréant le problème du « one big flat network » que les segments étaient censés résoudre. C'est l'équivalent dans Cloud WAN de placer tous vos attachements VPC dans une seule table de routage TGW. Le CNP doit être traité comme une pièce d'infrastructure-as-code critique, soumise à un contrôle de changement rigoureux, à un linting et à des audits.

Quand NE PAS utiliser Cloud WAN (Le Sweet Spot de TGW)

Malgré ses avantages, Cloud WAN n'est pas un remplacement universel pour TGW. Transit Gateway conserve son utilité dans plusieurs scénarios clés :

• Déploiements à région unique : Si l'ensemble de votre infrastructure cloud se trouve dans une seule région AWS et que vous n'avez pas l'intention de vous étendre, Cloud WAN est excessif. Le modèle régional hub-and-spoke de TGW est parfaitement adapté et plus rentable, car vous évitez le coût horaire plus élevé d'un Core Network Edge.
• Sensibilité extrême aux coûts : Pour les projets à petite échelle ou les proofs-of-concept avec un trafic minimal, le coût de base des attachements TGW et du traitement est inférieur au point d'entrée d'un Cloud WAN multi-régions. Si chaque dollar est scruté et que la simplicité opérationnelle est une priorité moindre, TGW est préférable.
• Contrôle BGP granulaire : Les scénarios de routage avancés qui reposent sur la manipulation d'attributs BGP tels que AS_PATH prepending ou local preference pour influencer le cheminement entre plusieurs connexions on-premise (par exemple, Direct Connects primaire/backup) peuvent être contrôlés plus directement dans TGW. Bien que Cloud WAN prenne en charge BGP, son modèle de politique abstrait certains des paramètres de bas niveau qu'un ingénieur réseau expérimenté pourrait vouloir ajuster sur un équipement comme un Juniper SRX5800 ou un Cisco ASR.

Le verdict de 2026 : Du hub régional au "fabric" global

Transit Gateway a démocratisé le cloud networking, offrant le premier modèle hub-and-spoke scalable natif d'AWS. Il reste un excellent choix, rentable, pour les architectures régionales. Cependant, Cloud WAN est clairement la direction stratégique pour toute entreprise opérant à l'échelle mondiale. Il échange le contrôle granulaire et impératif de TGW contre un modèle déclaratif et piloté par des politiques qui simplifie considérablement la gestion de la connectivité multi-régions, de la segmentation et de l'inspection de sécurité. En abstrayant la complexité de routage sous-jacente en une seule Core Network Policy, Cloud WAN permet aux ingénieurs de gérer le réseau en fonction de l'intention, et non des détails d'implémentation. Pour les organisations qui construisent un backbone cloud stratégique pour la prochaine décennie, la question passe de « Devons-nous utiliser un Transit Gateway ? » à « À quel moment notre échelle justifie-t-elle une migration vers Cloud WAN ? »

Prêt à concevoir un réseau global qui scale avec votre entreprise ? Les ingénieurs experts de techleague.io sont spécialisés dans la conception et la mise en œuvre de solutions de networking AWS robustes, sécurisées et rentables. Nous pouvons vous aider à naviguer dans les complexités de la politique Cloud WAN, à optimiser vos déploiements TGW et à construire une infrastructure cloud prête pour l'avenir. Explorez nos articles connexes sur Direct Connect SiteLink vs. DXGW pour la connectivité On-Premise et notre analyse approfondie du déploiement des firewalls Palo Alto VM-Series sur AWS.