AWS Transit Gateway: High-Scale Multi-Account Design Patterns für 2026

Im Jahr 2026 bleibt das AWS Transit Gateway (TGW) das unangefochtene Rückgrat jeder unternehmensweiten Multi-Account-Architektur. Die "Hub-and-Spoke"-Flitterwochen sind jedoch für Ingenieure, die Erschöpfung durch Peering, Quota-Grenzen und die absolute Notwendigkeit einer zentralisierten Inspektion nicht berücksichtigen, vorbei. Wenn Sie in einem System mit über 50 Accounts immer noch einzelne VPC-Peering-Verbindungen oder manuelle Routenpropagierung verwalten, betreiben Sie keine Architektur; Sie warten nur darauf, dass eine Routing-Schleife oder eine "Quota Exceeded"-Ausnahme Ihre Produktions-Stacks zum Absturz bringt. Das moderne TGW-Design erfordert einen kompromisslosen Fokus auf Resource Access Manager (RAM)-Automatisierung, isolierte Routing-Domains und Gateway Load Balancer (GWLB)-Integration, um die East-West-Sicherheitslücke zu schließen.

Die Multi-Account-Realität 2026: Skalieren oder Scheitern

Die Zeiten eines einzelnen monolithischen AWS-Accounts sind längst vorbei. Unternehmen erreichen heute die Marke von über 500 VPCs in Hunderten von Accounts, die über AWS Organizations verwaltet werden. In diesem Maßstab wird das TGW mehr als nur ein Router; es ist eine Abstraktionsschicht. Durch die Verwendung von AWS Resource Access Manager (RAM) können Sie ein einziges TGW (das sich in einem dedizierten Network Services/Hub-Account befindet) über die gesamte Organisation hinweg teilen. Dies verhindert "Shadow Networking", bei dem Entwickler isolierte VPCs erstellen, die lokale Anforderungen erfüllen, aber gegen die unternehmensweiten Egress-Richtlinien verstoßen.

Die Skalierung auf über 1.000 VPCs führt jedoch zu einem spezifischen Satz von Einschränkungen. Während TGW theoretisch 5.000 Attachments pro Region unterstützt, liegt der eigentliche Engpass bei der TGW-Routing-Tabellen-Grenze (derzeit 20 pro TGW) und den Routen pro TGW-Routing-Tabelle (10.000). Um das Skalierungsniveau von 2026 zu bewältigen, müssen Sie von Flat Routing abrücken und einen VRF-ähnlichen Ansatz innerhalb des TGW mit mehreren Routing-Tabellen (Route Tables) implementieren, die auf Anwendungsschichten zugeschnitten sind (z. B. Prod, Dev, Shared Services, Inspection).

Resource Access Manager (RAM) und die Automatisierungspipeline

Das manuelle Teilen von TGW über die Konsole ist ein Kündigungsgrund. In einer professionellen CI/CD-Umgebung sollte der Hub-Account die TGW-Ressource automatisch mit der gesamten Organizational Unit (OU) teilen. Wenn ein neuer Account über Control Tower oder eine kundenspezifische Account Factory bereitgestellt wird, sollte er automatisch eine "TGW Attachment Request" erhalten.

# Terraform snippet for RAM sharing
resource "aws_ram_resource_share" "tgw_share" {
  name                      = "central-tgw-share"
  allow_external_principals = false
}

resource "aws_ram_principal_association" "org_association" {
  principal          = data.aws_organizations_organization.current.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

resource "aws_ram_resource_association" "tgw_association" {
  resource_arn       = aws_ec2_transit_gateway.main.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

Ein wichtiger Tipp: Deaktivieren Sie immer default_route_table_association und default_route_table_propagation auf dem TGW. Wenn Sie diese aktiviert lassen, würde jedes neue VPC-Attachment automatisch seine lokalen Routen in eine globale Tabelle eintragen und Routen zu jeder anderen VPC empfangen. Dies ist ein Albtraum in Bezug auf den Radius der Auswirkungen. Sie wünschen explizites, intentionsbasiertes Routing.

Die Inspection VPC: Implementierung von GWLB am Edge

Deep Packet Inspection (DPI) für East-West-Traffic (VPC-zu-VPC) und North-South-Traffic (VPC-zu-Internet) ist nicht verhandelbar. Der Goldstandard für 2026 ist das Inspection VPC-Muster unter Verwendung des Gateway Load Balancers (GWLB) und einer Flotte von FortiGate- oder Palo Alto VM-Series-Appliances. Mithilfe von TGW können Sie den Traffic von jeder Spoke-VPC in die Inspection VPC leiten, bevor er sein Ziel erreicht.

Dies wird durch den Appliance Mode erreicht. Stellen Sie sicher, dass appliance_mode_support auf dem TGW-Attachment zur Inspection VPC aktiviert ist. Ohne dies würde das TGW die Flowsymmetrie nicht aufrechterhalten, die Anfrage durch die Firewall einer AZ und die Antwort durch eine andere senden, was dazu führen würde, dass die Stateful Firewall das Paket verwirft. Für einen tieferen Einblick in die Firewall-Integration siehe unseren Guide zu FortiGate GWLB Design Patterns.

Traffic Engineering: Separierung von Prod, Dev und Shared Services

Um den Radius der Auswirkungen zu begrenzen, behandeln Sie TGW Route Tables wie VRFs in der Cisco-Welt. Sie sollten mindestens haben:

• Prod_RT: Enthält Routen für Produktions-VPCs. Propagiert zur Inspection VPC, aber NICHT zur Dev_RT.
• Dev_RT: Enthält Routen für Entwicklungsumgebungen. Isoliert von Prod auf TGW-Ebene.
• Inspection_RT: Die "Landing"-Tabelle für den gesamten Traffic, der gesäubert werden muss. Diese Tabelle hat eine Standardroute (0.0.0.0/0), die auf den GWLB-Endpunkt in der Inspection VPC zeigt.
• Edge_RT: Für Direct Connect (DX) oder VPN-Attachments.

Die Kosten dieser Design-Architektur sind vorhersehbar, aber erheblich. Jedes TGW-Attachment kostet ungefähr 36,50 $/Monat pro Region (basierend auf 0,05 $/Stunde) plus 0,02 $ pro GB verarbeiteter Daten. In einer Umgebung mit 1.000 VPCs zahlen Sie allein für die Attachment-Gebühren 36.500 $/Monat. Wenn Sie 1 PB Daten durch das TGW leiten, kommen weitere 20.000 $ hinzu. Für Anwendungen mit hohem Durchsatz und geringer Latenz sollten Sie für spezifische "High-Talker"-Paare VPC Peering in Betracht ziehen, während TGW als Management-Ebene erhalten bleibt.

Blast Radius Mitigation (Begrenzung des Auswirkungsbereichs): Routenfilterung und Blackholing

Eine einzige falsch konfigurierte Route in einer TGW Route Table kann die laterale Bewegung von Ransomware in Ihrem gesamten Unternehmen erleichtern. Setzen Sie Blackhole Routes strategisch ein. Wenn ein bestimmter CIDR-Bereich niemals über das TGW erreichbar sein sollte (z. B. Ihr On-Premises-Legacy-Management-Subnetz, das eine eigene DX-Verbindung hat), blackholen Sie ihn explizit in den Spoke Route Tables.

Implementieren Sie darüber hinaus Service Control Policies (SCPs), um zu verhindern, dass Entwickler die Routing-Tabellen in ihren lokalen VPCs ändern, um das TGW zu umgehen. Die lokale VPC-Routing-Tabelle muss eine 0.0.0.0/0 oder eine spezifische CIDR aufweisen, die auf die TGW-Schnittstelle für den regionalen Traffic zeigt, damit dieser inspiziert werden kann. Wenn ein Entwickler dies direkt auf ein Internet Gateway (IGW) ändert, hat er Ihren Security Stack umgangen. Verwenden Sie SCPs, um ec2:CreateRoute und ec2:DeleteRoute zu verweigern, wenn die Gateway-ID ein IGW ist, es sei denn, der Account ist explizit whitelisted.

Die Direct Connect Gateway (DXGW) Integration

Die Anbindung Ihres On-Premises-Rechenzentrums an eine Multi-Account-TGW-Umgebung erfordert eine Transit VIF auf Ihrem Direct Connect. Verwenden Sie hierfür keine Private VIFs; sie skalieren nicht und funktionieren nicht mit TGW. Die Transit VIF terminiert auf einem Direct Connect Gateway (DXGW), das dann mit dem TGW assoziiert wird. Dies ermöglicht bis zu 3 TGWs (potenziell in verschiedenen Regionen), dieselbe DX-Verbindung zu teilen.

Im Jahr 2026 sehen wir, dass mehr Unternehmen dedizierte 100-Gbps-Verbindungen wählen. Bei dieser Bandbreite wird die Pro-Flow-Grenze des TGW (ca. 10 Gbps pro VPC Attachment Flow) zum Engpass. Um höhere Geschwindigkeiten zu erzielen, müssen Sie mehrere Flows nutzen oder AWS Cloud WAN in Betracht ziehen, wenn Ihre Präsenz wirklich global über 10+ Regionen verteilt ist, da Cloud WAN das Inter-Region-Peering automatisiert, das Sie mit TGW noch manuell aufbauen müssen.

Skalierung jenseits von 1000 VPCs: TGW Peering vs. Cloud WAN

Sobald Sie die physischen oder logischen Grenzen eines einzelnen TGW überschreiten oder Ihre Latenzanforderungen zwischen Tokio und US-East-1 kritisch werden, müssen Sie sich zwischen TGW Peering und AWS Cloud WAN entscheiden. TGW Peering ist ein statischer, manueller Prozess. Sie erstellen das Peering-Attachment und aktualisieren dann manuell die Routing-Tabellen auf beiden Seiten. Dies ist mühsam und anfällig für "Route Rot" (schleichende Fehler in Routing-Tabellen).

AWS Cloud WAN verwendet einen Network Function Manager und eine Core Network Policy (ein JSON-Dokument), um zu definieren, wie Segmente (wie Prod und Dev) global interagieren. Wenn Sie auf dem Niveau eines Fortune-100-Unternehmens operieren, ist Cloud WAN der Standard für 2026. Für die meisten Unternehmen ist jedoch ein regionales TGW-Hub mit TGW Peering für die 2-3 sekundären Regionen kostengünstiger und einfacher mit Standard-Reachability Analyzer-Tools zu debuggen.

Fazit: Das TechLeague Urteil

Der Aufbau eines Multi-Account-Netzwerks im Jahr 2026 ohne Transit Gateway ist ein Rezept für operativen Bankrott. Das TGW ist jedoch ein "dummer" Router, es sei denn, Sie umhüllen es mit einem strengen Richtlinienrahmen. Verwenden Sie RAM für die Verteilung, mehrere Route Tables für die Isolation und GWLB für die zentrale Inspektion. Alles andere ist nur ein Flat Network mit einem cloud-großen Preisschild. Wenn Ihr Netzwerkteam Schwierigkeiten hat, Sicherheit von Konnektivität in großem Maßstab zu entkoppeln, sehen Sie sich unsere maßgeschneiderten Infrastruktur-Audits unter techleague.io an.

Häufig gestellte Fragen

Warum nicht einfach VPC Peering verwenden, da es für den Datentransfer innerhalb derselben AZ kostenlos ist?

VPC Peering erzeugt ein Komplexitäts-Chaos der Ordnung n^2. Während es Kosten für die Datenverarbeitung spart, macht der Verwaltungsaufwand für die Aktualisierung Hunderter von Routing-Tabellen und Security Groups in Kombination mit dem Fehlen von transitiver Routenführung es bei Scale unmöglich zu verwalten. Verwenden Sie TGW für die Management-Ebene und VPC Peering nur für dedizierte "Elephant Flows" mit hoher Bandbreite zwischen zwei spezifischen VPCs.

Wie gehe ich mit überlappenden CIDRs in einer TGW-Umgebung um?

TGW unterstützt überlappende CIDRs nicht nativ in derselben Route Table. Sie müssen entweder ein Private NAT Gateway in den Spoke-VPCs verwenden, um deren Quell-IP zu übersetzen, bevor sie das TGW erreicht, oder separate TGW Route Tables verwenden und diese über eine "Translation VPC" mit weiteren NAT-Instanzen oder Firewalls mit DNAT/SNAT koppeln.

Unterstützt TGW Multicast?

Ja, TGW unterstützt IGMP Multicast. Sie müssen eine Multicast Domain auf dem TGW erstellen und die spezifischen VPC-Subnetze zuordnen. Dies ist entscheidend für ältere Finanzanwendungen oder bestimmte Medien-Streaming-Protokolle, die nicht für unicast Cloud-Umgebungen modernisiert wurden.

Wie hoch ist der maximale Durchsatz eines einzelnen TGWs?

Während AWS angibt, dass TGW "dynamisch" skaliert, ist jedes VPC-Attachment auf 50 Gbit/s Burst-Durchsatz begrenzt. Entscheidend ist, dass ein einzelner TCP-Flow im Allgemeinen auf 10 Gbit/s begrenzt ist. Wenn Sie 100 Gbit/s zwischen zwei VPCs benötigen, müssen Sie sicherstellen, dass Ihr Traffic auf viele verschiedene 5-Tupel-Flows verteilt ist.

Sollte ich TGW Connect für die SD-WAN-Integration verwenden?

Absolut. TGW Connect-Attachments ermöglichen Ihnen das Ausführen von GRE-Tunneln über das TGW, wodurch BGP-Peering direkt zwischen Ihren SD-WAN-Virtual Appliances (wie Cisco SD-WAN oder Silver Peak) und dem TGW möglich wird. Dies eliminiert die Notwendigkeit zahlreicher IPsec-VPNs und vereinfacht die Routing-Tabelle erheblich.

Wie löst der Appliance Mode das Problem der Flow-Asymmetrie?

Wenn der Appliance Mode für ein Attachment aktiviert ist, stellt das TGW sicher, dass für die Lebensdauer eines Flows dieselbe Netzwerkschnittstelle (und somit dieselbe AZ) für den Rücktraffic ausgewählt wird, die für die ursprüngliche Anfrage verwendet wurde. Dies ist entscheidend für Stateful Firewalls in einer Inspection VPC, die andernfalls Pakete verwerfen würden, wenn sie nur eine Seite des Handshakes sehen würden.