AWS Cloud WAN vs Transit Gateway: Der ehrliche Vergleich 2026 für Engineers

AWS Cloud WAN ist nicht nur „Transit Gateway v2“. Es ist eine grundlegende architektonische Umstellung von einem regional fokussierten, imperativen Routing-Modell zu einem globalen, deklarativen, policy-gesteuerten Framework für Cloud-Networking. Während AWS Transit Gateway (TGW) ein leistungsstarkes und kosteneffektives Tool für regionale Hub-and-Spoke-Topologien bleibt, ist Cloud WAN die strategische Antwort von AWS auf die betrieblichen Schwierigkeiten beim Management großer, regionsübergreifender Netzwerke. Für jede Organisation, die mehr als nur eine Handvoll VPCs über mehrere Kontinente hinweg verwaltet, ist das Verständnis der Kompromisse zwischen diesen beiden Services keine akademische Übung mehr – es ist eine kritische Designentscheidung mit weitreichenden Auswirkungen auf Kosten, Agilität und Sicherheit im Jahr 2026 und darüber hinaus.

Architektur-Grundlagen: Hub-and-Spoke vs. Global Mesh

Ein AWS Transit Gateway ist eine regionale Ressource. Es fungiert als klassischer Hub-and-Spoke-Router, der VPCs, VPNs und Direct Connect Gateways (DXGW) innerhalb einer einzelnen AWS-Region verbindet. Sein mentales Modell ist jedem Network Engineer vertraut: Es verfügt über Attachments und Routentabellen. Sie definieren imperativ, wie der Traffic fließt, indem Sie Attachments bestimmten Routentabellen zuordnen und statische oder propagierte Routen erstellen. Um ein globales Netzwerk aufzubauen, müssen Sie TGWs in verschiedenen Regionen manuell peeren und so ein Full Mesh von Verbindungen bilden, das Sie selbst verwalten müssen. Dieser Prozess ist zwar funktional, erzeugt jedoch einen erheblichen Betriebsaufwand und skaliert schlecht. Jedes Peering ist ein Single Point of Failure, eine Konfigurationslast und ein separater Kostenposten für den Datentransfer.

Cloud WAN abstrahiert diese Komplexität. Das Kern-Primitiv ist das Core Network, ein einziges, globales Objekt, das Ihr gesamtes Netzwerk-Backbone repräsentiert. Innerhalb dieses Core Network stellen Sie Core Network Edges (CNEs) in den gewünschten AWS-Regionen bereit. Diese CNEs sind die regionalen Points of Presence für Ihr globales Netzwerk. VPCs, VPNs und DXGWs werden an ihr lokales CNE angehängt. Entscheidend ist, dass das Routing zwischen CNEs über das AWS Global Backbone automatisch und von AWS verwaltet wird. Sie konfigurieren kein Inter-Region-Peering; Sie deklarieren lediglich, welche Teile Ihres Netzwerks miteinander kommunizieren dürfen, und Cloud WAN übernimmt die zugrunde liegende Pfad- und Routing-Logik. Es verwandelt das Netzwerk von einer Sammlung diskreter, manuell verbundener Hubs in ein einziges, logisches, globales Mesh.

Routing und Segmentierung: TGW Routentabellen vs. Core Network Policy

Dies ist der kritischste Unterschied. Mit Transit Gateway ist das Routing granular und imperativ. Sie könnten ein Dutzend Routentabellen pro TGW haben: eine für Produktions-VPCs, eine für Dev, eine für Shared Services, eine für die Inspektions-VPC, eine weitere für den Egress-Traffic und so weiter. Das Propagieren von Routen von 100 VPCs in die richtigen Tabellen und die Sicherstellung des symmetrischen Routings durch eine Stateful Firewall Appliance wie eine PA-5440 erfordert eine akribische, fehleranfällige Konfiguration. Ein Administrator muss die Auswirkungen jeder statischen Route und Propagations-Einstellung verstehen. Es bietet ultimative Kontrolle, jedoch auf Kosten einer hohen kognitiven Belastung.

Cloud WAN ersetzt dies durch eine Core Network Policy (CNP). Die CNP ist ein einzelnes JSON-Dokument, das die Absicht Ihres Netzwerks deklarativ definiert. Die beiden primären Konstrukte innerhalb der Policy sind Segments und Attachment Policies.

Core Network Segments

Ein Segment ist eine logische Netzwerkpartition, analog zu einer VRF (Virtual Routing and Forwarding) Instanz in einem traditionellen Router wie einem Catalyst 9500-48UXM. Gängige Segmente sind production, development, shared_services und onprem. Standardmäßig sind Segmente vollständig isolierte Routing-Domains. Eine VPC im production-Segment kann nicht zu einer VPC im development-Segment routen, selbst wenn sie sich in derselben Region befinden. Dies bietet eine leistungsstarke, hochrangige Isolation, ohne eine einzige Routentabelle zu berühren.

Attachment Policies und Segment Actions

Eine Attachment Policy ordnet Attachments Segmenten basierend auf Tags zu. Zum Beispiel können Sie eine Regel definieren: „Jedes VPC-Attachment mit dem Tag network-segment: prod wird automatisch dem production-Segment zugeordnet.“ Dies ist Policy-as-Code für das Netzwerk-Onboarding. Wenn eine neue Produktions-VPC mit dem richtigen Tag erstellt wird, platziert Cloud WAN sie automatisch in der richtigen Routing-Domain.

Um die Kommunikation zwischen Segmenten zu ermöglichen, verwenden Sie Segment Actions innerhalb der CNP. Um beispielsweise dem production-Segment zu ermöglichen, das shared_services-Segment zu erreichen, würden Sie eine create-route-Action im production-Segment definieren, die auf das shared_services-Segment zeigt. Sie können auch Blackhole-Routen oder statische Routen zu bestimmten Attachments definieren, wie z.B. einer Security Appliance für die Traffic-Inspektion. Dieses deklarative Modell – zu definieren, *was* verbunden sein soll, nicht *wie* – ist die Essenz der Leistung von Cloud WAN.

Reale Dimensionierung und Kostenanalyse (Preise 2026)

Betrachten wir ein konkretes Szenario: ein Unternehmen mit 50 VPCs in us-east-1 und 50 in eu-west-1. Sie haben in jeder Region einen 10 Gbit/s Direct Connect, der zu ihren Rechenzentren zurückführt. Der gesamte Datenverkehr, der durch das Core Network verarbeitet wird, beträgt 20 TB pro Monat pro Region, wobei 10 TB dieses Traffics zwischen den US- und EU-Regionen fließen.

Kostenmodell 1: Duale Transit Gateways mit Peering

• TGW Instance Hours: 2 TGWs * 0,05 $/Std. * 730 Std./Monat = 73,00 $
• Attachment Hours: 102 Attachments (100 VPCs + 2 DXGWs) * 0,05 $/Attachment-Std. * 730 Std./Monat = 3.723,00 $
• Regional Data Processing: 30 TB (20 TB VPC->VPC in-region + 10 TB, die regionsübergreifend gesendet werden) * 2 Regionen * 0,02 $/GB = 1.228,80 $ (ungefähr, da ein Teil des Datenverkehrs zweimal verarbeitet wird)
• Inter-Region Data Transfer: Dies sind die Hauptkosten. 10 TB Daten, die über TGW-Peering von us-east-1 nach eu-west-1 gesendet werden, verursachen eine Transfergebühr. 10.240 GB * 0,02 $/GB = 204,80 $.
• Geschätzte monatliche Gesamtkosten: ~5.230 $

Kostenmodell 2: Globales Cloud WAN

• Core Network Edge Hours: 2 CNEs (1 pro Region) * 0,299 $/Std. * 730 Std./Monat = 436,54 $
• Attachment Hours: 102 Attachments * 0,05 $/Attachment-Std. * 730 Std./Monat = 3.723,00 $
• Cloud WAN Data Processing: 40 TB insgesamt verarbeitete Daten * 0,03 $/GB = 1.228,80 $ (Hinweis: Cloud WAN hat eine gestaffelte Datenverarbeitungsgebühr, wir verwenden hier einen gemischten Satz für dieses Beispiel).
• Inter-Region Data Transfer: Dies ist ein entscheidender Vorteil. Cloud WAN hat keine separate Gebühr für den „Inter-Region-Peering“-Datentransfer. Der Traffic wird durch die Standard-Datenverarbeitungsgebühr abgedeckt, da er über das von AWS verwaltete Global Backbone fließt.
• Geschätzte monatliche Gesamtkosten: ~5.388 $

Auf den ersten Blick ähneln sich die Kosten. Das Cloud WAN-Modell vereinfacht jedoch die Abrechnung und eliminiert die kostspielige Inter-Region-Datentransfer-Steuer. Mit zunehmender Anzahl von Regionen eskalieren die Kosten und die Komplexität eines Full-Mesh-TGW-Peering-Modells nicht-linear, während das Cloud WAN-Modell besser vorhersagbar skaliert. Der leichte Kostenzuschlag für Cloud WAN erkauft Ihnen eine immense betriebliche Vereinfachung und ein globales, vereinheitlichtes Policy-Modell.

Sicherheits- und Inspektionsmuster

Das Einfügen einer Firewall, wie einer FortiGate 1800F oder einer Palo Alto Networks VM-Series mit PAN-OS 11.2, ist eine Standardanforderung. Mit TGW beinhaltet dies typischerweise eine dedizierte „Inspection VPC“. Sie manipulieren Routentabellen, um den Traffic von einer Spoke-VPC zum TGW, dann zur Inspection VPC ENI, dann zurück zum TGW und schließlich zu seinem Ziel zu zwingen. Dies wird als „Hairpinning“ bezeichnet und erfordert eine sorgfältige Verwaltung mehrerer Routentabellen, um Symmetrie zu gewährleisten.

Cloud WAN vereinfacht dies mit dem Appliance Mode für VPC Attachments. Wenn dieser auf einem Inspection VPC Attachment aktiviert ist, stellt Cloud WAN automatisch sicher, dass Traffic, der zwischen verschiedenen Segmenten (z. B. Prod-zu-Onprem) fließt, für Ingress und Egress in dieselbe Availability Zone in der Inspection VPC geleitet wird. Innerhalb Ihrer Core Network Policy definieren Sie einfach eine statische Route in Ihrem production-Segment für 0.0.0.0/0, die auf das Inspection VPC Attachment zeigt. Diese einzelne Politikänderung lenkt den Traffic zur Inspektion, ohne die komplexe Routentabellenmanipulation, die TGW erfordert.

Häufige Stolperfalle: Zu permissive Segment-Policies

Die deklarative Kraft der Core Network Policy ist ein zweischneidiges Schwert. Ein häufiger Fehler ist die frühzeitige Erstellung breiter, permissiver Sharing-Regeln bei der Bereitstellung. Zum Beispiel könnte ein Netzweradministrator, der schnell Konnektivität ermöglichen möchte, eine Regel erstellen, die alle Routen von allen Segmenten mit jedem anderen Segment teilt. Diese Aktion flacht das Netzwerk effektiv ab, negiert vollständig die Isolationsvorteile der Segmentierung und erzeugt das Problem des „einen großen flachen Netzwerks“ neu, das Segmente eigentlich lösen sollten. Es ist das Cloud WAN-Äquivalent dazu, alle Ihre VPC Attachments in eine einzige TGW-Routentabelle zu legen. Die CNP muss als kritisches Stück Infrastructure-as-Code behandelt werden, das einer strengen Änderungskontrolle, Linting und Auditierung unterliegt.

Wann Cloud WAN NICHT verwendet werden sollte (Der TGW Sweet Spot)

Trotz seiner Vorteile ist Cloud WAN kein universeller Ersatz für TGW. Transit Gateway behauptet sich in mehreren Schlüsselszenarien:

• Single-Region Deployments: Wenn Ihre gesamte Cloud-Infrastruktur in einer AWS-Region existiert und Sie keine Pläne zur Erweiterung haben, ist Cloud WAN übertrieben. Das regionale Hub-and-Spoke-Modell von TGW ist eine perfekte und kostengünstigere Lösung, da Sie die höheren stündlichen Kosten eines Core Network Edge vermeiden.
• Extreme Kostensensibilität: Für kleine Projekte oder Proof-of-Concepts mit minimalem Datenverkehr sind die Basiskosten von TGW-Attachments und -Verarbeitung niedriger als der Einstiegspunkt für ein regionsübergreifendes Cloud WAN. Wenn jeder Dollar genau geprüft wird und die betriebliche Einfachheit eine geringere Priorität hat, ist TGW die bessere Wahl.
• Feingranulare BGP-Kontrolle: Fortgeschrittene Routing-Szenarien, die auf die Manipulation von BGP-Attributen wie AS_PATH Prepending oder Local Preference angewiesen sind, um das Routing zwischen mehreren On-Premise-Verbindungen (z. B. primäre/sekundäre Direct Connects) zu beeinflussen, können direkter in TGW gesteuert werden. Obwohl Cloud WAN BGP unterstützt, abstrahiert sein Policy-Modell einige der Low-Level-Einstellungen, die ein erfahrener Network Engineer an einem Gerät wie einer Juniper SRX5800 oder Cisco ASR möglicherweise vornehmen möchte.

Das Urteil 2026: Vom Regional Hub zum Global Fabric

Transit Gateway demokratisierte das Cloud-Networking und bot das erste skalierbare Hub-and-Spoke-Modell, das nativ in AWS integriert war. Es bleibt eine ausgezeichnete, kostengünstige Wahl für regionale Architekturen. Cloud WAN ist jedoch die klare strategische Richtung für jedes Unternehmen, das auf globaler Ebene agiert. Es tauscht die granulare, imperative Kontrolle von TGW gegen ein deklaratives, policy-gesteuertes Modell ein, das die Verwaltung von regionsübergreifender Konnektivität, Segmentierung und Sicherheitsinspektion erheblich vereinfacht. Durch die Abstraktion der zugrunde liegenden Routing-Komplexität in einer einzigen Core Network Policy ermöglicht Cloud WAN Ingenieuren, das Netzwerk basierend auf der Absicht und nicht auf Implementierungsdetails zu verwalten. Für Organisationen, die ein strategisches Cloud-Backbone für das nächste Jahrzehnt aufbauen, verschiebt sich die Diskussion von „Sollen wir ein Transit Gateway verwenden?“ zu „Ab welchem Punkt rechtfertigt unsere Skalierung eine Migration zu Cloud WAN?“

Bereit, ein globales Netzwerk zu entwerfen, das mit Ihrem Unternehmen skaliert? Die erfahrenen Ingenieure von techleague.io sind spezialisiert auf die Gestaltung und Implementierung robuster, sicherer und kosteneffektiver AWS-Netzwerklösungen. Wir können Ihnen helfen, die Komplexität der Cloud WAN-Policy zu meistern, Ihre TGW-Bereitstellungen zu optimieren und eine zukunftsfähige Cloud-Infrastruktur aufzubauen. Entdecken Sie unsere verwandten Beiträge zu Direct Connect SiteLink vs. DXGW für On-Premise-Konnektivität und unseren Deep Dive in die Bereitstellung von Palo Alto VM-Series Firewalls auf AWS.