AWS TGW vs. Azure vWAN vs. GCP NCC: Der Multi-Cloud Backbone Krieg 2026

Die Wahl eines Multi-Cloud-Netzwerk-Backbones im Jahr 2026 hängt weniger von Markenloyalität ab, sondern vielmehr von der architektonischen Eignung und den Gesamtbetriebskosten (TCO). AWS Transit Gateway (TGW), Azure Virtual WAN (vWAN) und Google Cloud Network Connectivity Center (NCC) bieten alle Hub-and-Spoke- und Mesh-ähnliche Funktionen, unterscheiden sich jedoch erheblich in ihren zugrunde liegenden Architekturen, Preismodellen und Integrationspunkten. Diese Analyse konzentriert sich auf die reinen technischen Fähigkeiten und wirtschaftlichen Auswirkungen für große Unternehmen.

Architekturphilosophien und Skalierungslimits

AWS TGW, insbesondere wenn es durch Cloud WAN für globale Mesh-Konnektivität erweitert wird, bietet einen grundlegend objektorientierten Ansatz. Jedes TGW ist ein regionales Konstrukt und unterstützt bis zu 5000 Attachments (VPC/VPN/Direct Connect Gateway). Cloud WAN orchestriert mehrere TGWs zu einem globalen Netzwerk und verwaltet Routing-Policies und Segmentierung über Regionen und Accounts hinweg. Die Standard-TGW-Skalierungslimits sind kritisch: 5000 Routen pro Route Table, 100 TGW Attachments und 20 TGW Route Tables pro TGW sind häufige Engpässe für sehr große Implementierungen. Inter-Region Peering zwischen TGWs basiert auf Inter-Region VPC Peering-Fähigkeiten, die heute weitgehend durch Transit Gateway Inter-Region Peering abgelöst wurden und eine höhere Bandbreite und geringere Latenz als herkömmliche VPNs bieten.

Azure Virtual WAN ist ein von Microsoft verwalteter Service, der als Hub für verschiedene Konnektivitätstypen (VPN, ExpressRoute, VNet Peering) fungiert. Es nutzt eine globale, zentral verwaltete Architektur. Standard-Hubs unterstützen bis zu 2000 VNet-Verbindungen. Jedes ExpressRoute Gateway innerhalb eines vWAN Hubs kann bis zu 10 Gbit/s und VPN Gateways bis zu 10 Gbit/s (abhängig von der Skalierungseinheit) unterstützen. Ein wesentliches Unterscheidungsmerkmal ist das Konzept eines 'Secure Hubs', der mit dem Azure Firewall Manager integriert ist und die zentrale Durchsetzung von Security Policies (IDP/IPS, URL-Filtering) für den gesamten Datenverkehr ermöglicht, der den Hub durchläuft, einschließlich VNet-to-VNet und On-Premises-to-VNet. Azures Routing Intent ermöglicht eine granulare Kontrolle über Ingress- und Egress-Datenflüsse innerhalb des Hubs, eine Funktion, die in AWS oft BGP Community-Manipulationen oder komplexe Route Table Associations erfordert.

GCP Network Connectivity Center (NCC) ist konzeptionell einem globalen Fabric ähnlich und konzentriert sich auf die Verbindung von On-Premises-Standorten, VPCs und sogar anderen Cloud-Providern (über Cross-Cloud Interconnect). NCC-Hubs verwalten Spoke (VPC Networks, VPN Tunnels, Partner Interconnect, Cross-Cloud Interconnect) global. Im Gegensatz zu TGW oder vWAN präsentiert sich NCC als eine einzige globale Entität, was die Multi-Region-Bereitstellung vereinfacht. Es unterstützt bis zu 1000 Spokes pro Hub. Das Design betont die Einfachheit bei der Verbindung unterschiedlicher Workloads und Standorte zu einem einheitlichen Netzwerk. Cross-Cloud Interconnect, ein relativ neueres Angebot, verbindet GCP direkt mit AWS und bietet vorhersehbare Latenz und Durchsatz, eine Funktion, die nativ nicht im gleichen Maße zwischen AWS und Azures nativem Backbone ohne eine direkte Leitung oder ein Vendor Overlay verfügbar ist.

Routing, Segmentierung und BGP-Integration

AWS TGW basiert stark auf Route Tables, die an bestimmte VPCs und Direct Connect Gateways angehängt sind. Die Segmentierung wird durch die Zuweisung von Attachments zu verschiedenen TGW Route Tables und die Konfiguration von Propagations- und Assoziationsregeln erreicht. Cross-Account-Routing wird über TGW Resource Share verwaltet. BGP ist grundlegend für VPN- und DX Gateway-Attachments, wobei TGW seine Routen annonciert und Routen von Ihren On-Premises-Routern lernt. Jedes TGW kann als dynamischer Routing-Peer fungieren. Cloud WAN erweitert dies um automatische Routen-Propagation und Policy-basiertes Routing über Regionen hinweg, die in einer globalen Netzwerk-Policy definiert sind. Das Routing zwischen beliebigen TGW Route Tables erfordert explizite statische Routen oder Policy-basiertes Routing innerhalb von Cloud WAN.

Azure vWAN-Hubs stellen Routing Tables bereit, die mit verschiedenen Verbindungen assoziiert werden können. Routing Intent und Routing Policies ermöglichen Administratoren, den Datenfluss vorzuschreiben, z.B. indem sie Internet-gebundenen Datenverkehr über die Firewall eines Secure Hubs erzwingen oder VNet-to-VNet-Datenverkehr direkt routen. BGP wird ausgiebig für ExpressRoute- und VPN Gateway-Verbindungen zum vWAN-Hub verwendet. ExpressRoute-Verbindungen peeren typischerweise mit dem Microsoft Enterprise Edge (MSEE), der dann Routen in den vWAN-Hub injiziert. Für Hybrid-Umgebungen vereinfacht vWAN die Routenaggregation und -annoncierung erheblich, wodurch die mit traditionellen Azure Hub-and-Spoke-Modellen (mit UDRs) verbundene BGP-Komplexität reduziert wird.

GCP NCC verwendet eine globale Routing-Funktionalität, die dem gesamten Google Cloud-Netzwerk ähnelt. Spokes, die an einen NCC-Hub angehängt sind, tauschen Routen automatisch aus. Jeder Spoke erhält eine Route Table, und Routen werden propagiert. BGP wird für VPN- und Interconnect-Attachments verwendet. Für Cross-Cloud Interconnect werden BGP-Sessions direkt mit dem Peer Cloud Provider (z.B. AWS Direct Connect Gateway) am Interconnect-Standort aufgebaut, was den Routenaustausch zwischen Cloud-Umgebungen ermöglicht. Die Stärke von NCC liegt in seiner einheitlichen globalen Routen-Annoncierung und -Erfassung, wodurch die Notwendigkeit einer expliziten Inter-Regional-Routing-Konfiguration oder komplexer Transit-Routing-Setups entfällt, die normalerweise für andere Multi-Region-Konnektivität erforderlich sind.

Durchsatz, Latenz und Inter-Region Performance

Der maximale Durchsatz eines AWS TGW pro Attachment beträgt typischerweise 50 Gbit/s, mit einer Aggregation von bis zu 100 Gbit/s pro TGW über mehrere Attachments für den Intra-VPC-Verkehr. Inter-Region TGW Peering bietet eine deutlich höhere Bandbreite als VPN, oft über 5 Gbit/s pro Peer-Verbindung, kann aber je nach Nachfrage und regionaler Kapazität auf bis zu 50 Gbit/s skaliert werden, mit einer Latenz, die mit dem direkten VPC Peering zwischen Regionen vergleichbar ist. Für On-Premises-Verbindungen können Direct Connect-Verbindungen bis zu 100 Gbit/s an einem Direct Connect Gateway terminiert werden, das dann an ein TGW angehängt wird. Die Performance ist hervorragend, sofern das TGW nicht durch die Menge der VPCs und Routen überlastet wird.

Die Durchsatzkapazität eines Azure vWAN Hubs ist dynamisch; VPN Gateways skalieren bis zu 10 Gbit/s und ExpressRoute Gateways bis zu 20 Gbit/s (mehrere ExpressRoutes können terminiert werden). Der aggregierte vWAN-Hub-Durchsatz zwischen VNets wird für große Hubs oft mit rund 100 Gbit/s angegeben. Der Inter-Region VNet-to-VNet-Verkehr durch vWAN nutzt das globale Microsoft-Backbone und liefert eine Hochgeschwindigkeits-, Low-Latency-Konnektivität innerhalb des Azure-Netzwerks. Secure Hubs mit Azure Firewall können je nach Firewall SKU und Inspektionslast Latenz einführen. Die Performance zwischen Regionen ist aufgrund des hochoptimierten globalen Microsoft-Netzwerks im Allgemeinen stark.

GCP NCC nutzt das hochperformante globale private Netzwerk von Google. VPC-to-VPC-Verkehr und On-Premises-Konnektivität (VPN/Interconnect) profitieren vom Low-Latency-, High-Bandwidth-Backbone von Google. Cross-Cloud Interconnect kann bis zu 10 Gbit/s pro Link zu AWS erreichen, mit mehreren Links für höhere Kapazität. Die Latenz zwischen Google Cloud-Regionen gehört durchweg zu den niedrigsten in der Branche, was sich direkt auf die Performance-Eigenschaften von NCC überträgt. Dies ist ein erheblicher Vorteil für latenzempfindliche Anwendungen, die über mehrere Cloud-Regionen verteilt sind oder eine nahtlose Multi-Cloud-Kommunikation erfordern.

SD-WAN Appliance Integration und Security Services

Die Integration von SD-WAN in AWS TGW beinhaltet typischerweise den Aufbau von IPsec-VPNs von SD-WAN Branch-Geräten oder Virtual Appliances (z.B. FortiGate-VM, Palo Alto Networks VM-Series, Cisco Catalyst 8000V) in Spokes direkt zum TGW. AWS Network Manager bietet ein zentrales Dashboard zur Überwachung globaler Netzwerke, einschließlich TGWs, Cloud WAN und On-Premises-Standorten, die über VPN oder Direct Connect verbunden sind. Obwohl es keine nativen Sicherheitsfunktionen hostet, kann TGW den Datenverkehr zu 'Inspection VPCs' leiten, die virtuelle Firewalls für die zentrale Durchsetzung von Security Policies enthalten. Dies erfordert eine explizite Routenmanipulation und beinhaltet oft ECMP- oder Active/Standby-Firewall-Konfigurationen, wie z.B. Transit Gateway VPN ECMP für symmetrisches Routing.

Azure vWAN bietet integrierte SD-WAN-Funktionen. Viele führende SD-WAN-Anbieter (z.B. Fortinet, Versa, VMware, Cisco Viptela) haben ihre Lösungen in vWAN integriert, was die Anbindung von Filialen vereinfacht. Eine verwaltete Virtual Appliance kann direkt in einem vWAN Hub bereitgestellt werden, was die Bereitstellung vereinfacht und den operativen Aufwand im Vergleich zu einem separaten VNet reduziert. Die Secure Hub-Funktion mit Azure Firewall Manager (wobei FortiGate-VM oder Palo Alto VM-Series anstelle von Azure Firewall verwendet werden können, dies erfordert jedoch ein separates VNet) ist ein wichtiges Verkaufsargument für die erzwungene zentrale Sicherheit. Diese direkte Integration rationalisiert den Prozess, den gesamten Branch-, VNet- und Internet-Traffic durch einen gemeinsamen Security Inspection Point zu leiten.

Die Integrationsgeschichte von GCP NCC mit SD-WAN entwickelt sich. Vorerst folgt sie weitgehend dem VPN-to-Spoke-Modell, bei dem SD-WAN-Appliances IPsec-VPNs zu einem VPN Gateway in einem VPC Spoke aufbauen, der dann an NCC angehängt wird. Während große Anbieter wie Fortinet und Palo Alto robuste Virtual Appliances für GCP anbieten, verfügt NCC (noch) nicht über die gleiche tiefe Integration wie der Secure Hub von vWAN oder die native SD-WAN-Unterstützung. NCC erleichtert jedoch die Verbindung von On-Premises-SD-WAN-Implementierungen mit Google Cloud Services und anderen Cloud-Umgebungen über seine verschiedenen Spoke-Typen, wodurch die Verwaltung dieser Verbindungen zentralisiert wird, ohne die SD-WAN-Lösung selbst vorzuschreiben. Die kommende Private Service Connect-Integration mit NCC verspricht eine weitere Vereinfachung für den Zugriff auf SaaS- und Partner-Services.

Kostenmodelle: Egress und Attachments

Funktion	AWS Transit Gateway (TGW)	Azure Virtual WAN (vWAN)	GCP Network Connectivity Center (NCC)
Stundensatz pro Hub	$0.05/Stunde pro TGW + $0.05/Stunde pro Inter-Region Peering Connection	Standard Hub: $0.25/Stunde. Secure Hub: $0.35/Stunde + Azure Firewall-Kosten.	$0.025/Stunde pro Hub-Einheit (regional, 1000 Spokes)
Kosten pro Attachment	$0.05/GB verarbeitet Inbound/Outbound (Data Processed Charge)	Keine direkte Gebühr pro Attachment. VPN/ExpressRoute Gateway-Gebühren fallen an.	Spoke Unit Stunde: $0.0025/Stunde pro Spoke. Daten verarbeitet: $0.02/GB für alle Daten, die NCC durchlaufen.
Inter-Region Datentransfer	$0.02/GB - $0.09/GB (je nach Region)	Variiert je nach Regionspaar, typischerweise $0.02/GB - $0.08/GB	$0.02/GB - $0.12/GB (variiert je nach Region, spezifisch für Cross-Cloud)
Beispiel: 50 VPCs/VNets/Spokes (ca.)	~50 VPCs * $0.05/GB (Daten verarbeitet) + TGW pro Stunde. Gesamt ~0.05 * 24 * 30 = $36/Monat (nur TGW). Daten bei 100TB/Monat: 100 * 1024 * 0.05 = $5120.	Standard Hub ~0.25 * 24 * 30 = $180/Monat. Keine direkten Spoke-Gebühren. Daten über ExpressRoute/VPN.	NCC Hub Unit ~0.025 * 24 * 30 = $18/Monat. 50 Spoke Units ~50 * 0.0025 * 24 * 30 = $90/Monat. Daten bei 100TB/Monat: 100 * 1024 * 0.02 = $2048.
Beispiel: 500 VPCs/VNets/Spokes (ca.)	~500 VPCs * $0.05/GB (Daten verarbeitet) + TGW pro Stunde. Mehrere TGWs wahrscheinlich in großen Regionen aufgrund von Limits erforderlich. Daten bei 500TB/Monat: 500 * 1024 * 0.05 = $25600.	Standard Hub ~0.25 * 24 * 30 = $180/Monat. Routing Intent kann Gebühren hinzufügen. Daten-Gebühren.	NCC Hub Unit ~0.025 * 24 * 30 = $18/Monat. 500 Spoke Units ~500 * 0.0025 * 24 * 30 = $900/Monat. Daten bei 500TB/Monat: 500 * 1024 * 0.02 = $10240.

Die Kostenmodelle unterscheiden sich erheblich. AWS TGW berechnet pro GB Daten, die 'verarbeitet' werden (inbound oder outbound zu jedem Attachment). Das bedeutet, dass East-West-Traffic innerhalb eines TGW eine Gebühr verursacht. Azure vWAN berechnet hauptsächlich stundenweise für den Hub selbst und für alle darin bereitgestellten ExpressRoute- oder VPN Gateways. Daten-Egress-Gebühren fallen für den Datenverkehr an, der Azure ins Internet verlässt, aber VNet-to-VNet-Traffic innerhalb eines vWAN Hubs verursacht keine zusätzlichen Pro-GB-Gebühren für den vWAN-Service selbst (Standard-VNet Peering-Gebühren fallen weiterhin an, wenn vWAN nicht für VNet-to-VNet verwendet wird). GCP NCC berechnet eine geringe Stundengebühr für die Hub-Einheit und eine Stundengebühr pro 'Spoke-Einheit'. Wie TGW berechnet es auch für durch NCC verarbeitete (transferierte) Daten. Für intra-NCC-Daten berechnet GCP jedoch einen niedrigeren Pro-GB-Satz im Vergleich zu TGWs pauschal $0.05/GB, was bei großem Umfang erheblich sein kann.

Für ein Szenario mit 500 VPCs/VNets/Spokes und 500 TB/Monat aggregiertem internen Datenverkehr könnte AWS aufgrund seiner Gebühr von $0.05/GB für die Datenverarbeitung schnell am teuersten werden. GCPs $0.02/GB für die Datenverarbeitung in NCC ist wettbewerbsfähiger. Azures Modell, das VNet-to-VNet-Datengebühren innerhalb des Hubs weitgehend abstrahiert, kann für Organisationen mit massiven internen Datenflüssen sehr attraktiv sein. Dies gilt jedoch weitgehend für Datenverkehr, der innerhalb des regionalen Bereichs des vWAN Hubs bleibt. Multi-Region Azure vWAN-Traffic verursacht Inter-Region-Datentransfergebühren, ähnlich wie bei AWS und GCP.

Observability und Troubleshooting

AWS bietet CloudWatch Metrics für TGW (z.B. BytesIn/Out, Packet Drop). Flow Logs für TGW Attachments ermöglichen eine granulare Datenverkehrstransparenz und die Integration mit Services wie VPC Flow Logs zu S3, CloudWatch Logs oder Third-Party SIEMs. AWS Network Manager bietet eine topologische Ansicht und den Konnektivitätsstatus für TGW und zugehörige Verbindungen. Die Fehlerbehebung bei Routing-Problemen beinhaltet oft die Überprüfung von TGW Route Tables, Propagation Settings und Attachment Associations sowie den BGP-Sitzungsstatus für VPN/DX.

Azure vWAN bietet umfassendes Monitoring über Azure Monitor, das Metriken für Hub-Auslastung, Gateway-Durchsatz und VPN/ExpressRoute-Verbindungsstatus liefert. Network Watcher-Komponenten wie NSG Flow Logs (für Secure Hubs) und Connection Monitor helfen, Traffic-Muster zu visualisieren und Konnektivitätsprobleme zu diagnostizieren. Die globale Natur der vWAN-Verwaltungskonsole vereinfacht die Regionsübergreifende Fehlerbehebung und bietet ein Single Pane of Glass für alle Hub-Verbindungen und -Routen. Azure Firewall Logs innerhalb eines Secure Hubs bieten Deep Traffic Inspection und Security Event Logging.

GCP NCC integriert sich ebenfalls mit Cloud Monitoring für Metriken und Cloud Logging für Audit- und Flow-Logs. VPC Flow Logs für Spokes liefern detaillierte Traffic-Aufzeichnungen. Das Google Cloud Network Intelligence Center bietet Topologieansichten, Performance Monitoring und Einblicke in den Netzwerkzustand über alle verbundenen Spokes hinweg. Angesichts des starken Fokus von GCP auf Observability nutzt die Fehlerbehebung bei NCC typischerweise vertraute Cloud Console Tools und die Stackdriver Suite. Die BGP Session Monitoring für Interconnects ist robust und bietet detaillierte Status- und annoncierte Routen.

Konfigurationsausschnitte und Real-World-Beispiel

AWS TGW Attachment an VPC mit Routen-Propagation:

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
}

Dieser Terraform-Snippet zeigt das Anhängen einer VPC an ein AWS TGW und die anschließende Assoziierung und Propagation seiner Routen zu einer spezifischen TGW Route Table, was für Segmentierung und Konnektivität grundlegend ist. Für große Implementierungen verwalten Cloud WAN Policies diese Assoziationen und Propagations dynamisch über mehrere TGWs.

Fazit

AWS TGW (mit Cloud WAN) gewinnt, wenn:

• Sie eine AWS-native Organisation sind und 90%+ Ihrer Infrastruktur in AWS haben.
• Sie eine feingranulare Kontrolle über Routing Propagation und Association in einer komplexen Multi-Account-, Multi-Region-AWS-Umgebung benötigen.
• Sie bestehende Direct Connects und eine große Anzahl von VPNs integrieren müssen, insbesondere mit spezifischen BGP Community-Anforderungen.
• Ihr interner East-West-Datenfluss moderat ist, da die Gebühr von $0.05/GB für die Datenverarbeitung bei hohem Volumen schnell eskalieren kann.

Azure Virtual WAN gewinnt, wenn:

• Sie eine Microsoft-zentrierte Hybrid-Umgebung haben und ExpressRoute und Azure Services stark nutzen.
• Die zentrale Durchsetzung von Security Policies über Secure Hubs und Azure Firewall Manager eine kritische Anforderung für Compliance und vereinfachte Verwaltung ist.
• Sie ein globales SD-WAN Overlay bereitstellen und eine tiefe Integration und Verwaltung mit dem Cloud-Backbone bevorzugen.
• Ihr VNet-to-VNet-Traffic innerhalb einer Region extrem hoch ist, da die Hub-basierte Preisgestaltung für diesen Traffic-Typ besser vorhersehbar sein kann als eine Pro-GB-Verarbeitung.

GCP Network Connectivity Center (NCC) gewinnt, wenn:

• Sie hauptsächlich GCP für den Großteil Ihrer Cloud-Präsenz nutzen, aber auch eine effiziente, hochperformante Konnektivität zu AWS oder anderen Clouds über Cross-Cloud Interconnect benötigen.
• Einfachheit im globalen Netzwerkmanagement oberste Priorität hat und eine einzige globale Konstruktion anstelle von regionalen TGWs oder expliziten Inter-Region Peerings geboten wird.
• Ihre Organisation Googles hochoptimiertes globales Backbone für Low-Latency, High-Bandwidth-Konnektivität über Regionen hinweg schätzt.
• Kosteneffizienz bei hohen internen Datentransfervolumen entscheidend ist, angesichts der geringeren Datenverarbeitungsgebühren von NCC ($0.02/GB) im Vergleich zu AWS TGW für internen Datenverkehr.

Weiterführende Lektüre

• AWS Network Firewall vs. Palo Alto VM-Series 2025
• Azure ExpressRoute Strategien für globale Unternehmen 2025
• GCP Cloud VPN vs. Interconnect Performance Deep Dive
• Fortinet SD-WAN Multi-Cloud Integration