AWS TGW vs Azure vWAN vs GCP NCC : La guerre des backbones multi-cloud 2026

Le choix d'un backbone réseau multi-cloud en 2026 est moins une question de fidélité à une marque que d'adéquation architecturale et de TCO (coût total de possession). AWS Transit Gateway (TGW), Azure Virtual WAN (vWAN) et Google Cloud Network Connectivity Center (NCC) offrent tous des capacités de type hub-and-spoke et mesh, mais leurs architectures sous-jacentes, leurs modèles de tarification et leurs points d'intégration diffèrent considérablement. Cette analyse se concentre sur les capacités techniques brutes et les implications économiques pour les grandes entreprises.

Philosophies architecturales et limites de scale

AWS TGW, en particulier lorsqu'il est augmenté par Cloud WAN pour une connectivité mesh globale, offre une approche fondamentalement orientée objet. Chaque TGW est une construction régionale, supportant jusqu'à 5000 attachments (VPC/VPN/Direct Connect Gateway). Cloud WAN orchestre plusieurs TGW en un réseau global, gérant les politiques de routage et la segmentation à travers les régions et les comptes. Les limites de scale par défaut du TGW sont critiques : 5000 routes par table de routage, 100 TGW attachments et 20 tables de routage TGW par TGW sont des goulots d'étranglement courants pour les très grands déploiements. Le peering interrégional entre TGW s'appuie sur les capacités de VPC peering interrégional, désormais largement remplacé par Transit Gateway Inter-Region Peering, offrant une bande passante plus élevée et une latence plus faible que les VPN traditionnels.

Azure Virtual WAN est un service géré par Microsoft agissant comme un hub pour divers types de connectivité (VPN, ExpressRoute, VNet peering). Il utilise une architecture globale gérée de manière centralisée. Les hubs Standard supportent jusqu'à 2000 connexions VNet. Chaque ExpressRoute Gateway au sein d'un hub vWAN peut supporter jusqu'à 10 Gbps et les VPN Gateways jusqu'à 10 Gbps (en fonction de l'unité de scale). Un différenciateur clé est le concept de 'Secure Hub' intégré à Azure Firewall Manager, permettant l'application centralisée de politiques de sécurité (IDP/IPS, filtrage URL) pour tout le trafic transitant par le hub, y compris VNet-to-VNet et on-premises-to-VNet. L'intention de routage d'Azure permet un contrôle granulaire sur les flux de trafic entrants et sortants au sein du hub, une fonctionnalité nécessitant souvent la manipulation de BGP community ou des associations de tables de routage complexes dans AWS.

GCP Network Connectivity Center (NCC) est conceptuellement similaire à un fabric global, se concentrant sur la connexion des sites on-premises, des VPC et même d'autres cloud providers (via Cross-Cloud Interconnect). Les hubs NCC gèrent de manière centralisée les spokes (réseaux VPC, tunnels VPN, Partner Interconnect, Cross-Cloud Interconnect) à l'échelle mondiale. Contrairement à TGW ou vWAN, NCC se présente comme une entité globale unique, simplifiant le déploiement multi-régional. Il supporte jusqu'à 1000 spokes par hub. La conception met l'accent sur la simplicité pour connecter diverses workloads et emplacements à un réseau unifié. Cross-Cloud Interconnect, une offre relativement nouvelle, connecte directement GCP à AWS, offrant une latence et un débit prévisibles, une capacité non nativement disponible au même degré entre les backbones natifs d'AWS et d'Azure sans circuit direct ou overlay fournisseur.

Routage, segmentation et intégration BGP

AWS TGW s'appuie fortement sur les tables de routage attachées à des VPC spécifiques et des Direct Connect Gateways. La segmentation est réalisée en attribuant des attachments à différentes tables de routage TGW et en configurant des règles de propagation et d'association. Le routage inter-compte est géré via TGW Resource Share. BGP est fondamental pour les attachments VPN et DX Gateway, TGW annonçant ses routes et apprenant les routes de vos routers on-premises. Chaque TGW peut fonctionner comme un peer de routage dynamique. Cloud WAN étend cela avec une propagation automatique des routes et un routage basé sur des politiques à travers les régions définies dans une politique réseau globale. Le routage entre des tables de routage TGW arbitraires nécessite des routes statiques explicites ou un routage basé sur des politiques au sein de Cloud WAN.

Les hubs Azure vWAN exposent des tables de routage qui peuvent être associées à diverses connexions. Les Routing Intent et Routing Policies permettent aux administrateurs de dicter la manière dont le trafic circule, par exemple, en forçant le trafic destiné à Internet à traverser le firewall d'un Secure Hub ou en acheminant le trafic VNet-to-VNet directement. BGP est largement utilisé pour les connexions ExpressRoute et VPN Gateway vers le hub vWAN. Les circuits ExpressRoute peerent généralement avec le Microsoft enterprise edge (MSEE), qui injecte ensuite les routes dans le hub vWAN. Pour les environnements hybrides, vWAN simplifie l'agrégation et l'annonce de routes, réduisant considérablement la complexité BGP observée avec les modèles hub-and-spoke traditionnels d'Azure utilisant des UDR.

GCP NCC utilise une capacité de routage global similaire au réseau global de Google Cloud. Les spokes attachés à un hub NCC échangent automatiquement les routes. Chaque spoke obtient une table de routage, et les routes sont propagées. BGP est utilisé pour les attachments VPN et Interconnect. Pour Cross-Cloud Interconnect, les sessions BGP sont établies directement avec le fournisseur de services cloud pair (par exemple, AWS Direct Connect Gateway) à l'emplacement d'interconnexion, permettant l'échange de routes entre les environnements cloud. La force de NCC réside dans sa publication et son apprentissage de routes global et unifié, éliminant le besoin de configuration explicite de routage interrégional ou de configurations complexes de routage transitif généralement requises pour d'autres connectivités multi-régionales.

Débit, latence et performances inter-régions

Le débit maximal d'AWS TGW par attachment est typiquement de 50 Gbps, avec une agrégation allant jusqu'à 100 Gbps par TGW à travers plusieurs attachments pour le trafic inter-VPC. Le peering TGW Inter-Region offre une bande passante significativement plus élevée que le VPN, dépassant souvent 5 Gbps par connexion de peer mais pouvant atteindre 50 Gbps selon la demande et la capacité régionale, avec une latence comparable au VPC peering brut entre les régions. Pour les sites on-premises, les connexions Direct Connect jusqu'à 100 Gbps peuvent se terminer sur un Direct Connect Gateway, qui se connecte ensuite à un TGW. Les performances sont excellentes à condition que le TGW ne soit pas surchargé par le volume de VPC et de routes.

La capacité de débit du hub Azure vWAN est dynamique ; les VPN gateways peuvent atteindre 10 Gbps et les ExpressRoute gateways jusqu'à 20 Gbps (plusieurs ExpressRoutes peuvent se terminer). Le débit agrégé du hub vWAN entre les VNets est souvent cité autour de 100 Gbps pour les grands hubs. Le trafic VNet-to-VNet interrégional via vWAN utilise le backbone global de Microsoft, offrant une connectivité haute-vitesse et faible latence au sein du réseau Azure. Les Secure Hubs avec Azure Firewall peuvent introduire de la latence en fonction du SKU du firewall et de la charge d'inspection. Les performances entre les régions sont généralement robustes grâce au réseau global Microsoft hautement optimisé.

GCP NCC utilise le réseau privé global très performant de Google. Le trafic VPC-to-VPC et la connectivité on-premises (VPN/Interconnect) bénéficient du backbone faible latence et haute bande passante de Google. Cross-Cloud Interconnect peut atteindre jusqu'à 10 Gbps par lien vers AWS, avec plusieurs liens pour une capacité plus élevée. La latence entre les régions Google Cloud est constamment parmi les plus faibles de l'industrie, ce qui se traduit directement par les caractéristiques de performance de NCC. C'est un avantage significatif pour les applications sensibles à la latence s'étendant sur plusieurs régions cloud ou nécessitant une communication multi-cloud transparente.

Intégration d'appliances SD-WAN et services de sécurité

L'intégration de SD-WAN dans AWS TGW implique généralement l'établissement de VPN IPsec depuis des appliances SD-WAN de branch ou des appliances virtuelles (par exemple, FortiGate-VM, Palo Alto Networks VM-Series, Cisco Catalyst 8000V) dans des spokes directement vers le TGW. AWS Network Manager fournit un tableau de bord centralisé pour surveiller les réseaux globaux, y compris les TGW, Cloud WAN et les sites on-premises connectés via VPN ou Direct Connect. Bien qu'il n'héberge pas nativement des capacités de sécurité, TGW peut diriger le trafic vers des 'inspection VPCs' contenant des firewalls virtuels pour l'application centralisée des politiques de sécurité. Cela nécessite une manipulation explicite des routes et implique souvent des configurations de firewall ECMP ou Active/Standby, comme Transit Gateway VPN ECMP pour un routage symétrique.

Azure vWAN offre des capacités SD-WAN intégrées. De nombreux fournisseurs SD-WAN leaders (par exemple, Fortinet, Versa, VMware, Cisco Viptela) ont intégré leurs solutions avec vWAN, simplifiant la connectivité des agences. Une appliance virtuelle gérée peut être déployée directement dans un hub vWAN, simplifiant le déploiement et réduisant la charge opérationnelle par rapport à un VNet séparé. La fonctionnalité Secure Hub avec Azure Firewall Manager (l'utilisation de FortiGate-VM ou Palo Alto VM-Series au lieu d'Azure Firewall est également possible, mais nécessite un VNet séparé) est un argument de vente majeur pour la sécurité centralisée appliquée. Cette intégration directe simplifie le processus de direction de tout le trafic des agences, des VNet et d'Internet via un point d'inspection de sécurité commun.

L'intégration de GCP NCC avec SD-WAN est en évolution. Pour l'instant, elle suit largement le modèle VPN-to-spoke, où les appliances SD-WAN établissent des VPN IPsec vers un VPN gateway dans un spoke de VPC, qui est ensuite attaché à NCC. Bien que des fournisseurs majeurs comme Fortinet et Palo Alto proposent des appliances virtuelles robustes pour GCP, NCC n'a pas (encore) la même intégration profonde que le Secure Hub de vWAN ou le support SD-WAN natif. Cependant, NCC facilite la connexion des déploiements SD-WAN on-premises aux services Google Cloud et à d'autres environnements cloud via ses divers types de spokes, centralisant la gestion de ces connexions sans dicter la solution SD-WAN elle-même. La prochaine intégration de Private Service Connect avec NCC promet une simplification supplémentaire pour l'accès aux services SaaS et partenaires.

Modèles de coûts : Egress et Attachments

Fonctionnalité	AWS Transit Gateway (TGW)	Azure Virtual WAN (vWAN)	GCP Network Connectivity Center (NCC)
Coût horaire par Hub	0,05 $/heure par TGW + 0,05 $/heure par connexion de peering interrégional	Hub Standard : 0,25 $/heure. Secure Hub : 0,35 $/heure + coûts Azure Firewall.	0,025 $/heure par unité de hub (régional, 1000 spokes)
Coût par Attachment	0,05 $/Go traité en entrée/sortie (coût du traitement des données)	Pas de frais directs par attachment. Les frais pour VPN/ExpressRoute gateway s'appliquent.	Heure d'unité Spoke : 0,0025 $/heure par spoke. Données traitées : 0,02 $/Go pour toutes les données transitant par NCC.
Transfert de données interrégional	0,02 $/Go - 0,09 $/Go (selon les régions)	Varie selon la paire de régions, typiquement 0,02 $/Go - 0,08 $/Go	0,02 $/Go - 0,12 $/Go (varie selon les régions, spécifique pour Cross-Cloud)
Exemple : 50 VPC/VNet/Spokes (env.)	~50 VPC * 0,05 $/Go (données traitées) + TGW horaire. Total ~0,05 * 24 * 30 = 36 $/mois (TGW seul). Données à 100To/mois : 100 * 1024 * 0,05 = 5120 $.	Hub Standard ~0,25 * 24 * 30 = 180 $/mois. Pas de frais directs de spoke. Données via ExpressRoute/VPN.	Unité de Hub NCC ~0,025 * 24 * 30 = 18 $/mois. 50 Unités de Spoke ~50 * 0,0025 * 24 * 30 = 90 $/mois. Données à 100To/mois : 100 * 1024 * 0,02 = 2048 $.
Exemple : 500 VPC/VNet/Spokes (env.)	~500 VPC * 0,05 $/Go (données traitées) + TGW horaire. Plusieurs TGW probablement nécessaires dans les grandes régions en raison des limites. Données à 500To/mois : 500 * 1024 * 0,05 = 25600 $.	Hub Standard ~0,25 * 24 * 30 = 180 $/mois. Le Routing Intent peut ajouter des frais. Frais de données.	Unité de Hub NCC ~0,025 * 24 * 30 = 18 $/mois. 500 Unités de Spoke ~500 * 0,0025 * 24 * 30 = 900 $/mois. Données à 500To/mois : 500 * 1024 * 0,02 = 10240 $.

Les modèles de coûts sont significativement différents. AWS TGW facture par Go de données 'traitées' (entrantes ou sortantes vers tout attachment). Cela signifie que le trafic est-ouest au sein d'un TGW entraîne des frais. Azure vWAN facture principalement à l'heure pour le hub lui-même et pour tout ExpressRoute ou VPN Gateways déployé en son sein. Des frais d'egress de données s'appliquent au trafic quittant Azure pour Internet, mais le trafic VNet-to-VNet au sein d'un hub vWAN n'entraîne pas de frais supplémentaires par Go pour le service vWAN lui-même (les frais de VNet peering standard s'appliquent toujours s'il n'utilise pas vWAN pour VNet to VNet). GCP NCC facture un faible coût horaire pour l'unité de hub et un coût horaire par 'spoke unit'. Comme TGW, il facture les données traitées (transitées) via NCC. Cependant, pour les données intra-NCC, GCP facture un taux par Go inférieur à celui de TGW de 0,05 $/Go, ce qui peut être significatif à grande échelle.

Pour un scénario avec 500 VPC/VNet/Spokes et 500To/mois de trafic interne agrégé, AWS pourrait rapidement devenir le plus cher en raison de ses frais de traitement de données de 0,05 $/Go. Le traitement de données de GCP à 0,02 $/Go dans NCC est plus compétitif. Le modèle d'Azure, qui abstrait largement les frais de données VNet-to-VNet internes au hub, peut être très attrayant pour les organisations ayant des flux de données internes massifs. Cependant, cela est largement vrai pour le trafic restant dans le périmètre régional du hub vWAN. Le trafic multi-régional Azure vWAN entraînera des frais de transfert de données interrégionaux, similaires à AWS et GCP.

Observabilité et dépannage

AWS fournit des métriques CloudWatch pour TGW (par exemple, BytesIn/Out, Packet Drop). Les Flow Logs pour les TGW attachments permettent une visibilité granulaire du trafic, permettant l'intégration avec des services comme VPC Flow Logs vers S3, CloudWatch Logs, ou des SIEM tiers. AWS Network Manager donne une vue topologique et l'état de connectivité pour TGW et les connexions associées. La résolution des problèmes de routage implique souvent l'inspection des tables de routage TGW, des paramètres de propagation et des associations d'attachments, ainsi que de l'état des sessions BGP pour VPN/DX.

Azure vWAN offre une surveillance complète via Azure Monitor, fournissant des métriques pour l'utilisation du hub, le débit du gateway et l'état des connexions VPN/ExpressRoute. Les composants de Network Watcher tels que NSG Flow Logs (pour les Secure Hubs) et le connection monitor aident à visualiser les modèles de trafic et à diagnostiquer les problèmes de connectivité. La nature globale de la console de gestion de vWAN simplifie le dépannage interrégional, offrant un panneau de verre unique pour toutes les connexions et routes du hub. Les logs Azure Firewall au sein d'un Secure Hub offrent une inspection approfondie du trafic et la journalisation des événements de sécurité.

GCP NCC s'intègre également à Cloud Monitoring pour les métriques et à Cloud Logging pour les logs d'audit et de flux. Les VPC Flow Logs pour les spokes fournissent des enregistrements détaillés du trafic. Google Cloud Network Intelligence Center fournit des vues topologiques, une surveillance des performances et des insights sur la santé du réseau à travers les spokes attachés. Compte tenu de l'accent mis par GCP sur l'observabilité, le dépannage de NCC utilise généralement les outils familiers de Cloud Console et la suite Stackdriver. La surveillance des sessions BGP pour les Interconnects est robuste, fournissant un statut détaillé et des routes annoncées.

Extraits de configuration et exemple réel

Attachment AWS TGW à un VPC avec propagation de routes :

resource "aws_ec2_transit_gateway_vpc_attachment" "example" {
  vpc_id                        = aws_vpc.example.id
  transit_gateway_id            = aws_ec2_transit_gateway.example.id
  subnet_ids                    = [
    aws_subnet.example_az1.id,
    aws_subnet.example_az2.id,
  ]
  tags = {
    Name = "Example-VPC-Attachment"
  }
}

resource "aws_ec2_transit_gateway_route_table_association" "example" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.example.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.example.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "example" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.example.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.example.id
}

Cet extrait Terraform démontre comment attacher un VPC à un AWS TGW, puis associer et propager ses routes à une table de routage TGW spécifique, ce qui est fondamental pour la segmentation et la connectivité. Pour les déploiements à grande échelle, les politiques Cloud WAN gèrent ces associations et propagations de manière dynamique à travers plusieurs TGW.

Verdict

AWS TGW (avec Cloud WAN) est le meilleur choix lorsque :

• Vous êtes une organisation native d'AWS avec plus de 90 % de votre infrastructure dans AWS.
• Vous avez besoin d'un contrôle précis sur la propagation et l'association du routage dans un environnement AWS multi-comptes et multi-régions complexe.
• Vous devez intégrer des Direct Connects existants et un grand nombre de VPN, en particulier avec des exigences spécifiques en matière de BGP community.
• Votre flux de données est-ouest interne est modéré, car les frais de traitement de données de 0,05 $/Go peuvent rapidement s'accumuler à des volumes élevés.

Azure Virtual WAN est le meilleur choix lorsque :

• Vous avez un environnement hybride centré sur Microsoft, utilisant fortement ExpressRoute et les services Azure.
• L'application centralisée de la sécurité via les Secure Hubs et Azure Firewall Manager est une exigence critique pour la conformité réglementaire et une gestion simplifiée.
• Vous déployez un overlay SD-WAN global et préférez une intégration et une gestion approfondies avec le backbone cloud.
• Votre trafic VNet-to-VNet au sein d'une région est excessivement élevé, car la tarification basée sur le hub peut être plus prévisible que le traitement par Go pour ce type de trafic.

GCP Network Connectivity Center (NCC) est le meilleur choix lorsque :

• Vous privilégiez GCP pour la majorité de votre empreinte cloud, mais avez également besoin d'une connectivité efficace et performante vers AWS ou d'autres clouds via Cross-Cloud Interconnect.
• La simplicité dans la gestion du réseau global est une priorité absolue, offrant une seule construction globale plutôt que des TGW régionaux ou des peerings interrégionaux explicites.
• Votre organisation valorise le backbone global hautement optimisé de Google pour une connectivité faible latence et haute bande passante entre les régions.
• L'efficacité des coûts pour les volumes élevés de transfert de données internes est cruciale, étant donné les frais de traitement de données inférieurs de NCC (0,02 $/Go) par rapport à AWS TGW pour le trafic interne.

Lectures complémentaires

• Firewall AWS Network vs Palo Alto VM-Series 2025
• Stratégies Azure ExpressRoute pour les entreprises mondiales 2025
• GCP Cloud VPN vs Interconnect : Analyse approfondie des performances
• Intégration Fortinet SD-WAN Multi-Cloud