So funktionieren Amazon VPC Transit Gateways - Amazon VPC
Beispiel für ein ArchitekturdiagrammRessourcen-AnhängeMehrpfad-Routing zu gleichen Kosten Availability ZonesRoutingBeispiele für Transit-Gateway-Szenarien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

So funktionieren Amazon VPC Transit Gateways

In AWS Transit Gateway fungiert ein Transit-Gateway als regionaler virtueller Router für den Verkehr zwischen Ihren virtuellen privaten Clouds (VPCs) und lokalen Netzwerken. Ein Transit Gateway wird basierend auf dem Volumen an Netzwerkdatenverkehr elastisch skaliert. Die Weiterleitung über ein Transit Gateway erfolgt auf Schicht 3, wo Pakete basierend auf ihren Ziel-IP-Adressen an einen bestimmten Next-Hop-Anhang gesendet werden.

Beispiel für ein Architekturdiagramm

Das folgende Diagramm zeigt ein Transit-Gateway mit drei VPC Anhängen. Die Routentabelle für jede dieser Routen VPCs umfasst die lokale Route und Routen, die den für die anderen beiden bestimmten Verkehr VPCs an das Transit-Gateway weiterleiten.

VPCKonnektivitätsoptionen

Im Folgenden finden Sie ein Beispiel für eine Standard-Transit-Gateway-Routing-Tabelle für die im vorherigen Diagramm gezeigten Anhänge. Die CIDR Blöcke für jeden Block VPC werden in die Routentabelle übertragen. Daher kann jeder Anhang Pakete an die beiden anderen Anhänge weiterleiten.

Bestimmungsort Ziel Routing-Typ
VPC A CIDR Attachment for VPC A verbreitet
VPC B CIDR Attachment for VPC B verbreitet
VPC C CIDR Attachment for VPC C verbreitet

Ressourcen-Anhänge

Ein Transit-Gateway-Anhang ist sowohl eine Quelle als auch ein Ziel für Pakete. Sie können die folgenden Ressourcen an Ihr Transit-Gateway anhängen:

  • Einer oder mehrereVPCs. AWS Transit Gateway stellt eine elastic network interface innerhalb von VPC Subnetzen bereit, die dann vom Transit-Gateway verwendet wird, um den Verkehr zu und von den ausgewählten Subnetzen weiterzuleiten. Sie müssen mindestens ein Subnetz für jede Availability Zone haben, das es dann ermöglicht, Datenverkehr an Ressourcen in jedem Subnetz dieser Zone weiterzuleiten. Während der Anhangserstellung können Ressourcen innerhalb einer bestimmten Availability Zone nur dann ein Transit Gateway erreichen, wenn ein Subnetz innerhalb derselben Zone aktiviert ist. Wenn eine Subnetz-Routing-Tabelle eine Route zum Transit Gateway enthält, wird der Datenverkehr nur dann an das Transit Gateway weitergeleitet, wenn das Transit Gateway einen Anhang im Subnetz derselben Availability Zone hat.

  • Eine oder mehrere Verbindungen VPN

  • Ein oder mehrere AWS Direct Connect Gateways

  • Eine oder mehrere Transit-Gateway-Connect-Anhänge

  • Eine oder mehrere Transit-Gateway-Peering-Verbindungen

Mehrpfad-Routing zu gleichen Kosten

AWS Transit Gateway unterstützt Equal Cost Multipath (ECMP) Routing für die meisten Anlagen. Für einen VPN Anhang können Sie die ECMP Unterstützung mithilfe der Konsole aktivieren oder deaktivieren, wenn Sie ein Transit-Gateway erstellen oder ändern. Für alle anderen Arten von Anhängen gelten die folgenden ECMP Einschränkungen:

  • VPC- unterstützt VPC nicht, ECMP da sich CIDR Blöcke nicht überlappen können. Sie können beispielsweise nicht eine Verbindung VPC mit einer CIDR Version 10.1.0.0/16 und eine zweite, die dieselbe VPC CIDR verwendet, mit einem Transit-Gateway verbinden und dann Routing einrichten, um den Datenverkehr zwischen ihnen zu verteilen.

  • VPN- Wenn die VPNECMPSupport-Option deaktiviert ist, verwendet ein Transit-Gateway interne Metriken, um den bevorzugten Pfad zu ermitteln, falls gleiche Präfixe auf mehreren Pfaden vorhanden sind. Weitere Informationen zur Aktivierung oder Deaktivierung eines VPN Anhangs ECMP finden Sie unter. Transit-Gateways in Amazon VPC Transit Gateways

  • AWS Transit Gateway Connect — Automatische Unterstützung für das AWS Transit Gateway Connect von AnhängenECMP.

  • AWS Direct Connect AWS Direct Connect Gateway — Gateway-Anhänge werden automatisch ECMP für mehrere Direct Connect Gateway-Anhänge unterstützt, wenn Netzwerkpräfix, Präfixlänge und AS_ exakt identisch PATH sind.

  • Transit-Gateway-Peering — Transit-Gateway-Peering wird nicht unterstützt, ECMP da es weder dynamisches Routing unterstützt noch Sie dieselbe statische Route für zwei verschiedene Ziele konfigurieren können.

Anmerkung

  • BGPMultipath AS-Path Relax wird nicht unterstützt, sodass Sie es nicht ECMP über verschiedene autonome Systemnummern () hinweg verwenden können. ASNs

  • ECMPwird zwischen verschiedenen Anhangstypen nicht unterstützt. Beispielsweise können Sie die Option „ECMPZwischen a“ VPN und „VPCAnlage“ nicht aktivieren. Stattdessen werden Transit-Gateway-Routen ausgewertet und der Datenverkehr entsprechend der ausgewerteten Route weitergeleitet. Weitere Informationen finden Sie unter Reihenfolge der Routenauswertung.

  • Ein einziges Direct Connect-Gateway unterstützt ECMP mehrere virtuelle Transitschnittstellen. Daher empfehlen wir, nur ein einziges Direct Connect-Gateway einzurichten und zu verwenden und nicht mehrere Gateways einzurichten und zu verwenden, um die Vorteile ECMP zu nutzen. Weitere Informationen zu Direct Connect-Gateways und öffentlichen virtuellen Schnittstellen finden Sie unter Wie richte ich eine aktive/aktive oder aktive/passive Direct Connect-Verbindung von einer öffentlichen virtuellen Schnittstelle AWS aus ein? .

Availability Zones

Wenn Sie eine Verbindung VPC zu einem Transit-Gateway herstellen, müssen Sie eine oder mehrere Availability Zones aktivieren, die vom Transit-Gateway verwendet werden, um den Verkehr zu Ressourcen in den VPC Subnetzen weiterzuleiten. Zur Aktivierung der einzelnen Availability Zones geben Sie genau ein Subnetz an. Das Transit Gateway platziert unter Verwendung einer IP-Adresse aus dem Subnetz eine Netzwerkschnittstelle in diesem Subnetz. Nachdem Sie eine Availability Zone aktiviert haben, kann der Verkehr an alle Subnetze in der Availability Zone weitergeleitet werdenVPC, nicht nur an das angegebene Subnetz oder die Availability Zone. Allerdings können nur Ressourcen in Availability Zones mit Transit-Gateway-Anhang das Transit Gateway erreichen.

Wenn der Verkehr aus einer Availability Zone stammt, in der sich der Zielanhang nicht befindet, leitet AWS Transit Gateway diesen Datenverkehr intern an eine zufällige Availability Zone weiter, in der der Anhang vorhanden ist. Für diese Art von Verkehr in der gesamten Availability Zone fallen keine zusätzlichen Transit-Gateway-Gebühren an.

Zur Sicherstellung der Verfügbarkeit sollten Sie mehrere Availability Zones aktivieren.

Verwenden des Applicance-Modus-Supports

Wenn Sie vorhaben, eine Netzwerk-Appliance mit Status in Ihrem zu konfigurierenVPC, können Sie die Unterstützung im Appliance-Modus für den VPC Anhang aktivieren, in dem sich das Gerät befindet. Dadurch wird sichergestellt, dass das Transit-Gateway während der gesamten Lebensdauer des Datenverkehrs zwischen Quelle und Ziel dieselbe Availability Zone für diesen VPC Anhang verwendet. Außerdem kann das Transit-Gateway Datenverkehr an eine beliebige Availability Zone in der sendenVPC, sofern in dieser Zone eine Subnetzverbindung besteht. Weitere Informationen finden Sie unter Beispiel: Appliance in einem Shared Services VPC.

Routing

Ihr Transit-Gateway-Routing IPv4 und IPv6 Pakete zwischen Anhängen mithilfe von Transit-Gateway-Routentabellen. Sie können diese Routentabellen so konfigurieren, dass sie Routen aus den Routentabellen für die angeschlossenen GatewaysVPCs, VPN Verbindungen und Direct Connect weiterleiten. Sie können den Transit-Gateway-Routing-Tabellen auch statische Routen hinzufügen. Wenn ein Paket von einem Anhang ankommt, wird es anhand der Route, die seiner Ziel-IP-Adresse entspricht, an einen anderen Anhang weitergeleitet.

Für Transit-Gateway-Peering-Anhänge werden nur statische Routen unterstützt.

Routing-Tabellen

Ihr Transit Gateway verfügt automatisch über eine Standard-Routing-Tabelle. Diese Routing-Tabelle wird standardmäßig als Standard-Zuordnungs-Routing-Tabelle und standardmäßige Route-Propagierung-Tabelle verwendet. Bei Deaktivierung der Route-Propagierung und Zuordnung der Routing-Tabelle erstellt AWS keine Standard-Routing-Tabelle für das Transit Gateway.

Sie können zusätzliche Routing-Tabellen für Ihr Transit Gateway erstellen. Auf diese Weise können Sie Teilmengen von Anhängen isolieren. Jeder Anhang kann einer Routing-Tabelle zugeordnet sein. Ein Anhang kann ihre Routen an eine oder mehrere Routing-Tabelle propagieren.

Sie können eine Blackhole-Route in Ihrer Transit-Gateway-Routing-Tabelle erstellen, die den Datenverkehr unterbricht, der der Route entspricht.

Wenn Sie eine Verbindung VPC zu einem Transit-Gateway herstellen, müssen Sie Ihrer Subnetz-Routentabelle eine Route hinzufügen, damit der Verkehr über das Transit-Gateway geleitet werden kann. Weitere Informationen finden Sie unter Routing für ein Transit Gateway im VPCAmazon-Benutzerhandbuch.

Routing-Tabellenzuordnung

Ein Transit-Gateway-Anhang kann einer einzigen Routing-Tabelle zugeordnet werden. Jede Routing-Tabelle kann keiner, aber auch mehreren Anhängen zugeordnet werden und Pakete an Anhänge oder andere Routing-Tabellen weiterleiten.

Routing-Propagierung

Jeder Anhang bietet Routen, die in einer oder mehreren Transit-Gateway-Routing-Tabellen installiert werden können. Wenn ein Anhang auf eine Transit-Gateway-Routing-Tabelle übertragen wird, werden diese Routen in der Routing-Tabelle installiert. Sie können nicht nach angekündigten Routen filtern.

Bei einem VPC Anhang VPC werden die CIDR Blöcke von an die Routentabelle des Transit-Gateways weitergegeben.

Wenn dynamisches Routing mit einer VPN Anlage oder einer Direct Connect-Gateway-Anlage verwendet wird, können Sie die vom lokalen Router gelernten Routen BGP an jede der Transit-Gateway-Routentabellen weitergeben.

Wenn dynamisches Routing mit einer VPN Anlage verwendet wird, werden die Routen in der Routentabelle, die dem VPN Anhang zugeordnet sind, dem Kunden-Gateway über angekündigt. BGP

Bei einem Connect-Anhang werden Routen in der Routentabelle, die dem Connect-Anhang zugeordnet ist, den virtuellen Appliances von Drittanbietern, z. B. SD-Appliances, angekündigt, die in einem VPC BGP Durchgang ausgeführt werden. WAN

Bei einem Direct Connect-Gateway-Anhang steuern zulässige Präfixe, von welchen Routen aus das Kundennetzwerk angekündigt wird. AWS

Wenn eine statische Route und eine propagierte Route das gleiche Ziel haben, hat die statische Route die höhere Priorität, sodass die propagierte Route nicht in der Routing-Tabelle enthalten ist. Wenn Sie die statische Route entfernen, wird die überlappende propagierte Route in die Routing-Tabelle aufgenommen.

Routen für Peering-Anhänge

Sie können für zwei Transit Gateways Peering durchführen und den Verkehr zwischen ihnen weiterleiten. Dazu erstellen Sie einen Peering-Anhang auf Ihrem Transit Gateway und geben das Peer-Transit-Gateway an, mit dem die Peering-Verbindung erstellt werden soll. Anschließend erstellen Sie eine statische Route in der Transit-Gateway-Routing-Tabelle, um Datenverkehr an den Transit-Gateway-Peering-Anhang weiterzuleiten. Datenverkehr, der an das Peer-Transit-Gateway weitergeleitet wird, kann dann an das Peer-Transit-Gateway VPC und die VPN Anlagen für das Peer-Transit-Gateway weitergeleitet werden.

Weitere Informationen finden Sie unter Beispiel: Per Peering verbundene Transit Gateways.

Reihenfolge der Routenauswertung

Transit-Gateway-Routen werden in der folgenden Reihenfolge ausgewertet:

  • die spezifischste Route für die Zieladresse.

  • Für Routen mit demselben AnhangstypCIDR, aber von unterschiedlichen Anhangstypen, lautet die Routenpriorität wie folgt:

    • Statische Routen (z. B. Site-to-Site VPN statische Routen)

    • Präfixlisten referenzierter Routen

    • VPC-propagierte Routen

    • Vom Direct Connect-Gateway weitergeleitete Routen

    • Von Transit Gateway Connect weitergeleitete Routen

    • Site-to-Site VPNüber private Direct Connect-Weiterleitungen

    • Site-to-Site VPN-propagierte Routen

    • Von Transit Gateway per Peering-Übertragung übertragene Routen (Cloud) WAN

Einige Anlagen unterstützen die Routenankündigung über. BGP Bei Routen mit demselben CIDR Anhangstyp und mit demselben Anhangstyp wird die Routenpriorität durch folgende BGP Attribute gesteuert:

  • Kürzere AS-Pfadlänge

  • Niedrigerer MED Wert

  • BGPBGPE-Over-IP-Routen werden bevorzugt, wenn der Anhang dies unterstützt

    Wichtig

    AWS Ich kann keine konsistente Reihenfolge der Routenpriorisierung für BGP Routen mit demselben CIDR Anhangstyp und denselben BGP Attributen wie oben aufgeführt garantieren.

AWS Transit Gateway zeigt nur eine bevorzugte Route an. Eine Backup-Route wird nur dann in der Transit Gateway Gateway-Routentabelle angezeigt, wenn diese Route nicht mehr angekündigt wird — zum Beispiel, wenn Sie dieselben Routen über das Direct Connect-Gateway und darüber hinaus ankündigen. Site-to-Site VPN AWS Transit Gateway zeigt nur die Routen an, die von der Direct Connect-Gateway-Route empfangen wurden, was die bevorzugte Route ist. Die Site-to-SiteVPN, die Backup-Route, wird nur angezeigt, wenn das Direct Connect-Gateway nicht mehr angekündigt wird.

VPCUnterschiede in der Routentabelle und beim Transit Gateway

Die Auswertung von Routentabellen unterscheidet sich je nachdem, ob Sie eine VPC Routentabelle oder eine Transit-Gateway-Routentabelle verwenden.

Das folgende Beispiel zeigt eine VPC Routentabelle. Die VPC lokale Route hat die höchste Priorität, gefolgt von den Routen, die am spezifischsten sind. Wenn eine statische und eine propagierte Route dasselbe Ziel haben, hat die statische Route eine höhere Priorität.

Zielbereich Ziel Priorität
10.0.0.0/16

Lokal

 1
192.168.0.0/16 pcx-12345 2
172.31.0.0/16 vgw-12345 (statisch) oder

tgw-12345 (statisch)

 2
172.31.0.0/16 vgw-12345 (propagiert) 3
0.0.0.0/0 igw-12345 4

Das folgende Beispiel zeigt eine Routentabelle für ein Transit-Gateway. Wenn Sie den AWS Direct Connect Gateway-Anhang dem VPN Anhang vorziehen, verwenden Sie eine BGP VPN Verbindung und geben Sie die Routen in der Transit-Gateway-Routentabelle weiter.

Bestimmungsort Anhang (Ziel) Ressourcentyp Routing-Typ Priorität
10.0.0.0/16 tgw-attach-123 | vpc-1234 VPC Statisch oder propagiert 1
192.168.0.0/16 tgw-attach-789 | vpn-5678 VPN Um eine statische IP-Adresse zu verwenden, tippen Sie auf 2
172.31.0.0/16 tgw-attach-456 | dxgw_id AWS Direct Connect Gateway Propagiert 3
172.31.0.0/16 tgw-attach-789 | -123 tgw-connect-peer Verbinden Propagiert 4
172.31.0.0/16 tgw-attach-789 | vpn-5678 VPN Verbreitet 5

Beispiele für Transit-Gateway-Szenarien

Die folgenden Szenarien sind gängige Anwendungsfälle für Transit-Gateways. Ihre Transit Gateways sind nicht auf diese Anwendungsfälle beschränkt.

Beispiele

    Sie können Ihr Transit-Gateway als zentralen Router konfigurieren, der alle Ihre VPCs AWS Direct Connect, und Site-to-Site VPN Verbindungen verbindet. In diesem Szenario sind alle Anhänge der standardmäßigen Transit-Gateway-Routing-Tabelle zugeordnet und propagieren an die standardmäßige Transit-Gateway-Routing-Tabelle. Daher können alle Anhänge Pakete untereinander weiterleiten, wobei das Transit Gateway dient als einfacher Layer-3-IP-Router dient.

    Übersicht

    Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. In diesem Szenario gibt es drei VPC Anlagen und einen Site-to-Site VPN Anhang zum Transit-Gateway. Pakete aus den Subnetzen in VPC A, VPC B und VPC C, die für ein Subnetz in einem anderen VPC oder für die erste VPN Verbindung bestimmt sind, werden über das Transit-Gateway geleitet.

    Ein Transit-Gateway mit drei VPC Anhängen und einer Anlage. VPN

    Ressourcen

    Erstellen Sie die folgenden Ressourcen für dieses Szenario:

    Routing

    Jedes VPC hat eine Routentabelle und es gibt eine Routentabelle für das Transit-Gateway.

    VPCRoutentabellen

    Jede VPC hat eine Routentabelle mit 2 Einträgen. Der erste Eintrag ist der Standardeintrag für lokales IPv4 Routing in derVPC. Dieser Eintrag ermöglicht es den Instanzen in diesem EintragVPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Transit-Gateway weiter. Die folgende Tabelle zeigt die VPC A-Routen.

    Bestimmungsort Ziel

    10.1.0.0/16

    Lokal

    0.0.0.0/0

    tgw-id
    Routing-Tabelle für Transit Gateway

    Folgendes ist ein Beispiel für eine Standard-Routing-Tabelle für die Anhänge aus der vorherigen Grafik. Die Routing-Verbreitung ist aktiviert.

    Zielbereich Ziel Routing-Typ

    10.1.0.0/16

    Attachment for VPC A

    verbreitet

    10.2.0.0/16

    Attachment for VPC B

    verbreitet

    10.3.0.0/16

    Attachment for VPC C

    verbreitet

    10.99.99.0/24

    		 Attachment for VPN connection

    verbreitet
    BGPTabelle mit Kunden-Gateways

    Die BGP Kunden-Gateway-Tabelle enthält Folgendes VPCCIDRs.

    • 10.1.0.0/16

    • 10.2.0.0/16

    • 10.3.0.0/16

    Sie können Ihr Transit-Gateway als mehrere isolierte Router konfigurieren. Dies gleicht der Verwendung mehrerer Transit-Gateways, bietet aber mehr Flexibilität, falls sich die Routen und Anfügungen ändern. In diesem Szenario verfügt jeder isolierte Router über eine einzige Routing-Tabelle. Alle Anfügungen, die diesem isolierten Router zugeordnet sind, verbreiten mit seiner Routing-Tabelle und werden ihr zugeordnet. Die Anfügungen, die einem isolierten Router zugeordnet sind, können Pakete untereinander weiterleiten. Sie können aber keine Pakete an Anfügungen eines anderen isolierten Routers leiten oder Pakete von ihnen empfangen.

    Übersicht

    Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Pakete von VPC A, VPC B und VPC C werden zum Transit-Gateway weitergeleitet. Pakete aus den Subnetzen in VPC A, VPC B und VPC C, die das Internet als Ziel haben, werden zuerst durch das Transit-Gateway und dann zur Site-to-Site VPN Verbindung weitergeleitet (sofern sich das Ziel innerhalb dieses Netzwerks befindet). Pakete von einem SubnetzVPC, die ein Ziel in einem anderen Subnetz habenVPC, z. B. von 10.1.0.0 bis 10.2.0.0, werden über das Transit-Gateway weitergeleitet, wo sie blockiert werden, weil es in der Routentabelle des Transit-Gateways keine Route für sie gibt.

    Ein Transit-Gateway mit drei VPC Anhängen und einer Anlage. VPN

    Ressourcen

    Erstellen Sie die folgenden Ressourcen für dieses Szenario:

    Wenn die VPN Verbindung hergestellt ist, wird die BGP Sitzung eingerichtet und sie VPC CIDRs werden an die Routentabelle des Transit-Gateways VPN CIDR weitergegeben und der BGP Kunden-Gateway-Tabelle hinzugefügt.

    Routing

    Jedes VPC hat eine Routing-Tabelle, und das Transit-Gateway hat zwei Routing-Tabellen — eine für die VPCs und eine für die Verbindung. VPN

    VPCA-, VPC B- und VPC C-Routentabellen

    Jede VPC hat eine Routentabelle mit 2 Einträgen. Der erste Eintrag ist der Standardeintrag für lokales IPv4 Routing in derVPC. Dieser Eintrag ermöglicht es den Instanzen in diesem VPC Bereich, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Transit-Gateway weiter. Die folgende Tabelle zeigt die VPC A-Routen.

    Bestimmungsort Ziel

    10.1.0.0/16

    Lokal
    0.0.0.0/0

    tgw-id
    Transit-Gateway-Routing-Tabellen

    In diesem Szenario wird eine Routentabelle für die VPCs und eine Routentabelle für die VPN Verbindung verwendet.

    Die VPC Anlagen sind der folgenden Routentabelle zugeordnet, die eine weitergeleitete Route für die VPN Anlage enthält.

    Bestimmungsort Ziel Routing-Typ
    10.99.99.0/24 Attachment for VPN connection

    verbreitet

    Die VPN Anlage ist der folgenden Routentabelle zugeordnet, die für jede Anlage weitergegebene Routen enthält. VPC

    Bestimmungsort Ziel Routing-Typ

    10.1.0.0/16

    Attachment for VPC A

    verbreitet

    10.2.0.0/16

    Attachment for VPC B

    verbreitet

    10.3.0.0/16

    Attachment for VPC C

    verbreitet

    Weitere Informationen zum Übertragen von Routen in einer Transit-Gateway-Routing-Tabelle finden Sie unter Route-Propagierung zu einer Transit-Gateway-Routentabelle mithilfe von Amazon VPC Transit Gateways aktivieren.

    Kunden-Gateway-Tabelle BGP

    Die BGP Kunden-Gateway-Tabelle enthält Folgendes VPCCIDRs.

    • 10.1.0.0/16

    • 10.2.0.0/16

    • 10.3.0.0/16

    Sie können Ihr Transit-Gateway als mehrere isolierte Router konfigurieren, die einen freigegebenen Service verwenden. Dies gleicht der Verwendung mehrerer Transit-Gateways, bietet aber mehr Flexibilität, falls sich die Routen und Anfügungen ändern. In diesem Szenario verfügt jeder isolierte Router über eine einzige Routing-Tabelle. Alle Anfügungen, die diesem isolierten Router zugeordnet sind, verbreiten mit seiner Routing-Tabelle und werden ihr zugeordnet. Die Anfügungen, die einem isolierten Router zugeordnet sind, können Pakete untereinander weiterleiten. Sie können aber keine Pakete an Anfügungen eines anderen isolierten Routers leiten oder Pakete von ihnen empfangen. Anfügungen können Pakete an freigegebene Services weiterleiten oder sie davon empfangen. Sie können dieses Szenario verwenden, wenn Sie Gruppen haben, die isoliert sein müssen, aber einen freigegebenen Service verwenden, z. B. ein Produktionssystem.

    Übersicht

    Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Pakete aus den Subnetzen in VPC A, VPC B und VPC C, die das Internet als Ziel haben, werden zuerst über das Transit-Gateway und dann zum Kunden-Gateway für Site-to-Site VPN weitergeleitet. Pakete aus Subnetzen in VPC A, VPC B oder VPC C, die das Ziel eines Subnetzes in VPC A, VPC B oder VPC C haben, werden durch das Transit-Gateway geleitet, wo sie blockiert werden, weil es in der Routentabelle des Transit-Gateways keine Route für sie gibt. Pakete von VPC A, VPC B und VPC C, die VPC D als Ziel haben, werden durch das Transit-Gateway und dann nach D weitergeleitet. VPC

    Ein Transit-Gateway mit vier VPC Anhängen und einem VPN Anhang.

    Ressourcen

    Erstellen Sie die folgenden Ressourcen für dieses Szenario:

    Wenn die VPN Verbindung hergestellt ist, wird die BGP Sitzung eingerichtet und sie VPC CIDRs werden an die Routentabelle des Transit-Gateways VPN CIDR weitergegeben und der BGP Kunden-Gateway-Tabelle hinzugefügt.

    • Jede isolierte Tabelle VPC wird der isolierten Routentabelle zugeordnet und in die gemeinsam genutzte Routentabelle übertragen.

    • Jeder gemeinsame Dienst VPC ist der gemeinsamen Routentabelle zugeordnet und wird an beide Routentabellen weitergegeben.

    Routing

    Jedes VPC hat eine Routing-Tabelle, und das Transit-Gateway hat zwei Routing-Tabellen — eine für die VPCs und eine für die VPN Verbindung und die gemeinsamen Dienste. VPC

    VPCA-, VPC B-, VPC C- und VPC D-Routing-Tabellen

    Jede VPC hat eine Routentabelle mit zwei Einträgen. Der erste Eintrag ist der Standardeintrag für lokales Routing in derVPC. Dieser Eintrag ermöglicht es den Instanzen in diesem EintragVPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Transit-Gateway weiter.

    Bestimmungsort Ziel
    10.1.0.0/16 Lokal
    0.0.0.0/0 transit gateway ID
    Transit-Gateway-Routing-Tabellen

    In diesem Szenario wird eine Routentabelle für die VPCs und eine Routentabelle für die VPN Verbindung verwendet.

    Die Anlagen VPC A, B und C sind der folgenden Routentabelle zugeordnet, die eine weitergeleitete Route für die VPN Anlage und eine weitergegebene Route für die Anlage für D enthält. VPC

    Bestimmungsort Ziel Routing-Typ
    10.99.99.0/24 Attachment for VPN connection verbreitet
    10.4.0.0/16 Attachment for VPC D verbreitet

    Die VPN Anlagen für Anlagen und Shared Services VPC (VPCD) sind der folgenden Routentabelle zugeordnet, die Einträge enthält, die auf die VPC einzelnen Anlagen verweisen. Dies ermöglicht die Kommunikation VPCs zwischen der VPN Verbindung und den Shared ServicesVPC.

    Bestimmungsort Ziel Routing-Typ
    10.1.0.0/16 Attachment for VPC A verbreitet
    10.2.0.0/16 Attachment for VPC B verbreitet
    10.3.0.0/16 Attachment for VPC C verbreitet

    Weitere Informationen finden Sie unter Route-Propagierung zu einer Transit-Gateway-Routentabelle mithilfe von Amazon VPC Transit Gateways aktivieren.

    BGPKunden-Gateway-Tabelle

    Die BGP Kunden-Gateway-Tabelle enthält die CIDRs für alle vierVPCs.

    Sie können eine Transit Gateway-Peering-Verbindung zwischen Transit Gateways erstellen. Anschließend können Sie den Datenverkehr zwischen den Anlagen für jedes Transit Gateway weiterleiten. In diesem Szenario werden VPN Anlagen den Standardroutentabellen des Transit-Gateways zugeordnet und an die Standardroutentabellen des Transit-Gateways weitergegeben. VPC Jede Transit-Gateway-Routing-Tabelle verfügt über eine statische Route, die auf den Peering-Anhang des Transit Gateways verweist.

    Übersicht

    Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Transit-Gateway 1 hat zwei VPC Anlagen und Transit-Gateway 2 hat einen Site-to-Site VPN Anhang. Pakete aus den Subnetzen in VPC A und VPC B, die das Internet als Ziel haben, werden zuerst über Transit-Gateway 1, dann über Transit-Gateway 2 und dann zur VPN Verbindung weitergeleitet.

    Zwei Peer-Transit-Gateways, eines mit zwei VPC Anhängen und das andere mit einem Anhang. VPN

    Ressourcen

    Erstellen Sie die folgenden Ressourcen für dieses Szenario:

    Wenn Sie die VPC Anlagen erstellen, werden sie jeweils an die CIDRs Routentabelle für Transit-Gateway 1 VPC weitergegeben. Wenn die VPN Verbindung hergestellt ist, werden die folgenden Aktionen ausgeführt:

    • Die BGP Sitzung ist eingerichtet

    • Das wird Site-to-Site VPN CIDR in die Routentabelle für Transit-Gateway 2 übertragen

    • Sie VPC CIDRs werden der BGP Kunden-Gateway-Tabelle hinzugefügt

    Routing

    Jedes VPC hat eine Routentabelle und jedes Transit-Gateway hat eine Routentabelle.

    VPCA- und VPC B-Routentabellen

    Jede VPC hat eine Routentabelle mit 2 Einträgen. Der erste Eintrag ist der Standardeintrag für lokales IPv4 Routing in derVPC. Dieser Standardeintrag ermöglicht es den darin enthaltenen RessourcenVPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Transit-Gateway weiter. Die folgende Tabelle zeigt die VPC A-Routen.

    Bestimmungsort Ziel

    10.0.0.0/16

    Lokal

    0.0.0.0/0

    tgw-1-id
    Transit-Gateway-Routing-Tabellen

    Im Folgenden finden Sie ein Beispiel für die Standard-Routing-Tabelle für Transit Gateway 1 mit aktivierter Routen-Propagierung.

    Zielbereich Ziel Routing-Typ

    10.0.0.0/16

    Attachment ID for VPC A

    verbreitet

    10.2.0.0/16

    Attachment ID for VPC B

    verbreitet

    0.0.0.0/0

    		 Attachment ID for peering connection

    statisch

    Im Folgenden finden Sie ein Beispiel für die Standard-Routing-Tabelle für Transit Gateway 2 mit aktivierter Routen-Propagierung.

    Zielbereich Ziel Routing-Typ

    172.31.0.0/24

    		 Attachment ID for VPN connection

    propagiert

    10.0.0.0/16

    Attachment ID for peering connection

    statisch

    10.2.0.0/16

    		 Attachment ID for peering connection statisch
    BGPTabelle mit Kunden-Gateways

    Die BGP Kunden-Gateway-Tabelle enthält Folgendes VPCCIDRs.

    • 10.0.0.0/16

    • 10.2.0.0/16

    Sie können ein Transit-Gateway so konfigurieren, VPC dass ausgehender Internetverkehr von einem Gateway VPC ohne Internet-Gateway an ein NAT Gateway und ein Internet-Gateway weitergeleitet wird.

    Übersicht

    Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Sie haben Anwendungen in VPC A und VPC B, die nur ausgehenden Internetzugang benötigen. Sie konfigurieren VPC C mit einem öffentlichen NAT Gateway und einem Internet-Gateway sowie einem privaten Subnetz für den VPC Anhang. Verbinden Sie alle VPCs mit einem Transit-Gateway. Konfigurieren Sie das Routing so, dass ausgehender Internetverkehr von VPC A und VPC B das Transit-Gateway nach VPC C durchquert. Das NAT Gateway in VPC C leitet den Verkehr an das Internet-Gateway weiter.

    Ein Transit-Gateway mit drei VPC Anhängen.

    Ressourcen

    Erstellen Sie die folgenden Ressourcen für dieses Szenario:

    • Drei VPCs mit IP-Adressbereichen, die sich nicht überschneiden. Weitere Informationen finden Sie unter Create a VPC im VPCAmazon-Benutzerhandbuch.

    • VPCA und VPC B haben jeweils private Subnetze mit EC2 Instances.

    • VPCC hat Folgendes:

      • Ein Internet-Gateway ist an das angeschlossenVPC. Weitere Informationen finden Sie unter Erstellen und Anhängen eines Internet-Gateways im VPCAmazon-Benutzerhandbuch.

      • Ein öffentliches Subnetz mit einem NAT Gateway. Weitere Informationen finden Sie unter Ein NAT Gateway erstellen im VPCAmazon-Benutzerhandbuch.

      • Ein privates Subnetz für den Transit-Gateway-Anhang. Das private Subnetz sollte sich in derselben Availability Zone wie das öffentliche Subnetz befinden.

    • Ein Transit-Gateway Weitere Informationen finden Sie unter Erstellen Sie ein Transit-Gateway mit Amazon VPC Transit Gateways.

    • Drei VPC Anlagen auf dem Transit-Gateway. Die CIDR Blöcke für jeden Block werden in die Routentabelle des Transit-Gateways VPC übertragen. Weitere Informationen finden Sie unter Einen VPC Anhang mit Amazon VPC Transit Gateways erstellen. Für VPC C müssen Sie den Anhang mithilfe des privaten Subnetzes erstellen. Wenn Sie den Anhang mithilfe des öffentlichen Subnetzes erstellen, wird der Instance-Datenverkehr an das Internet-Gateway weitergeleitet, aber das Internet-Gateway lehnt den Datenverkehr ab, da die Instances keine öffentlichen IP-Adressen haben. Wenn Sie den Anhang im privaten Subnetz platzieren, wird der Datenverkehr an das Gateway weitergeleitet, und das NAT NAT Gateway sendet den Datenverkehr an das Internet-Gateway, wobei es seine Elastic IP-Adresse als Quell-IP-Adresse verwendet.

    Routing

    Für beide gibt es Routing-Tabellen VPC und für das Transit-Gateway eine Routing-Tabelle.

    Routentabelle für VPC A

    Es folgt ein Beispiel für eine Routing-Tabelle. Der erste Eintrag ermöglicht es den Instanzen in derVPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Transit-Gateway weiter.

    Bestimmungsort Ziel

    VPC A CIDR

    Lokal

    0.0.0.0/0

    transit-gateway-id
    Routentabelle für B VPC

    Es folgt ein Beispiel für eine Routing-Tabelle. Der erste Eintrag ermöglicht es den Instanzen in derVPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Transit-Gateway weiter.

    Bestimmungsort Ziel

    VPC B CIDR

    Lokal

    0.0.0.0/0

    transit-gateway-id
    Routing-Tabellen für C VPC

    Konfigurieren Sie das Subnetz mit dem NAT Gateway als öffentliches Subnetz, indem Sie dem Internet-Gateway eine Route hinzufügen. Das andere Subnetz bleibt ein privates Subnetz.

    Im Folgenden finden Sie ein Beispiel einer Routing-Tabelle für das öffentliche Subnetz. Der erste Eintrag ermöglicht es den Instanzen in derVPC, miteinander zu kommunizieren. Der zweite und dritte Eintrag leiten den Verkehr für VPC A und VPC B an das Transit-Gateway weiter. Der verbleibende Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Internet-Gateway weiter.

    Bestimmungsort Ziel
    VPC C CIDR Lokal
    VPC A CIDR transit-gateway-id
    VPC B CIDR transit-gateway-id
    0.0.0.0/0 internet-gateway-id

    Das Folgende ist ein Beispiel einer Routing-Tabelle für das private Subnetz. Der erste Eintrag ermöglicht es den Instanzen in derVPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das NAT Gateway weiter.

    Bestimmungsort Ziel
    VPC C CIDR Lokal
    0.0.0.0/0 nat-gateway-id
    Routing-Tabelle für Transit Gateway

    Es folgt ein Beispiel für die Routing-Tabelle des Transit-Gateways. Die CIDR Blöcke für jeden Block werden an die VPC Routentabelle des Transit-Gateways weitergegeben. Die statische Route sendet ausgehenden Internetverkehr an VPC C. Sie können optional die VPC Interkommunikation verhindern, indem Sie für jede Route eine Blackhole-Route hinzufügen. VPC CIDR

    CIDR Attachment Routing-Typ

    VPC A CIDR

    Attachment for VPC A

    verbreitet

    VPC B CIDR

    Attachment for VPC B

    verbreitet

    VPC C CIDR

    Attachment for VPC C

    verbreitet
    0.0.0.0/0

    Attachment for VPC C

    		 statisch

    Sie können eine Appliance (z. B. eine Sicherheits-Appliance) in einem Shared Services konfigurierenVPC. Der gesamte Datenverkehr, der zwischen Transit-Gateway-Anhängen weitergeleitet wird, wird zunächst von der Appliance in den Shared Services VPC überprüft. Wenn der Appliance-Modus aktiviert ist, wählt ein Transit-Gateway mithilfe eines Flow-Hash-Algorithmus eine einzelne Netzwerkschnittstelle in der Appliance VPC aus, an die der Datenverkehr für die gesamte Lebensdauer des Datenflusses gesendet wird. Das Transit Gateway verwendet dieselbe Netzwerkschnittstelle für den Rückverkehr. Dadurch wird sichergestellt, dass der bidirektionale Verkehr symmetrisch weitergeleitet wird — er wird während der gesamten Lebensdauer des Flusses durch dieselbe Availability Zone im VPC Anhang geleitet. Wenn Sie mehrere Transit Gateways in Ihrer Architektur haben, behält jedes Transit Gateway seine eigene Sitzungsaffinität bei und jedes Transit Gateway kann eine andere Netzwerkschnittstelle auswählen.

    Sie müssen genau ein Transit-Gateway mit der Appliance verbinden, um sicherzustellen, dass der Datenfluss stabil bleibt. VPC Wenn Sie mehrere Transit-Gateways mit einer einzigen Appliance verbinden, ist VPC dies keine Garantie für einen reibungslosen Datenfluss, da die Transit-Gateways keine Informationen zum Flow-Status untereinander austauschen.

    Wichtig

    • Der Verkehr im Appliance-Modus wird korrekt weitergeleitet, solange der Quell- und der Zieldatenverkehr von derselben Transit-Gateway-Anlage an eine zentrale Stelle VPC (InspektionVPC) weitergeleitet werden. Der Verkehr kann sinken, wenn sich Quelle und Ziel auf zwei verschiedenen Transit-Gateway-Anhängen befinden. Der Verkehr kann sinken, wenn das zentrale VPC System den Verkehr von einem anderen Gateway empfängt — z. B. von einem Internet-Gateway — und diesen Verkehr dann nach der Überprüfung an den Transit-Gateway-Anhang weiterleitet.

    • Die Aktivierung des Appliance-Modus für einen vorhandenen Anhang kann sich auf die aktuelle Route dieses Anhangs auswirken, da der Anhang jede Availability Zone passieren kann. Wenn der Appliance-Modus nicht aktiviert ist, wird der Datenverkehr in der ursprünglichen Availability Zone belassen.

    Übersicht

    Die folgende Abbildung zeigt die Hauptkomponenten der Konfiguration für dieses Szenario. Das Transit-Gateway hat drei VPC Anhänge. VPCC ist ein Shared ServiceVPC. Der Verkehr zwischen VPC A und VPC B wird zum Transit-Gateway und dann zur Überprüfung an eine Sicherheits-Appliance in VPC C weitergeleitet, bevor er zum endgültigen Ziel weitergeleitet wird. Da die Appliance ist eine zustandsbehaftete Appliance ist, wird sowohl der Anforderungs- als auch der Antwortdatenverkehr überprüft. Für hohe Verfügbarkeit gibt es in jeder Availability Zone in C eine Appliance. VPC

    Eine Appliance in einem Shared Services VPC

    Sie erstellen die folgenden Ressourcen für dieses Szenario:

    • DreiVPCs. Informationen zum Erstellen von finden Sie unter Erstellen eines VPC im Amazon Virtual Private Cloud Cloud-Benutzerhandbuch. VPC

    • Ein Transit Gateway. Weitere Informationen finden Sie unter Erstellen Sie ein Transit-Gateway mit Amazon VPC Transit Gateways.

    • Drei VPC Anlagen — einer für jeden derVPCs. Weitere Informationen finden Sie unter Einen VPC Anhang mit Amazon VPC Transit Gateways erstellen.

      Geben Sie für jeden VPC Anhang ein Subnetz in jeder Availability Zone an. Für die gemeinsamen Dienste sind dies die SubnetzeVPC, zu denen der Verkehr VPC vom Transit-Gateway geleitet wird. Im vorangehenden Beispiel sind dies Subnetze A und C.

      Aktivieren Sie für den VPC Anhang für VPC C die Unterstützung im Appliance-Modus, sodass der Antwortdatenverkehr an dieselbe Availability Zone in VPC C weitergeleitet wird wie der Quelldatenverkehr.

      Die VPC Amazon-Konsole unterstützt den Appliance-Modus. Sie können auch Amazon VPCAPI, an, the verwenden AWS SDK, AWS CLI um den Appliance-Modus zu aktivieren, oder AWS CloudFormation. Fügen Sie beispielsweise --options ApplianceModeSupport=enable den Befehl create-transit-gateway-vpc-attachment oder modify-transit-gateway-vpc-attachment hinzu.

    Anmerkung

    Der Datenfluss im Appliance-Modus wird nur für Quell- und Zieldatenverkehr garantiert, der seinen Ursprung in der Inspektion hat. VPC

    Statusbehaftete Appliances und Appliance-Modus

    Wenn sich Ihre VPC Anhänge über mehrere Availability Zones erstrecken und Sie möchten, dass der Datenverkehr zwischen Quell- und Zielhosts zur Zustandsprüfung über dieselbe Appliance geleitet wird, aktivieren Sie die Unterstützung im Appliance-Modus für den VPC Anhang, in dem sich die Appliance befindet.

    Weitere Informationen finden Sie im Blog unter Zentralisierte AWS Inspektionsarchitektur.

    Verhalten bei nicht aktiviertem Appliance-Modus

    Wenn der Appliance-Modus nicht aktiviert ist, versucht ein Transit-Gateway, den Datenverkehr zwischen VPC Anhängen in der ursprünglichen Availability Zone weiterzuleiten, bis er sein Ziel erreicht. Der Datenverkehr durchquert Availability Zones zwischen Anhängen nur, wenn ein Availability Zone-Fehler auftritt oder wenn einem VPC Anhang in dieser Availability Zone keine Subnetze zugeordnet sind.

    Das folgende Diagramm zeigt einen Datenverkehrsfluss, wenn die Unterstützung des Appliance-Modus nicht aktiviert ist. Der Antwortdatenverkehr, der aus Availability Zone 2 in VPC B stammt, wird vom Transit-Gateway an dieselbe Availability Zone in VPC C weitergeleitet. Der Datenverkehr wird daher unterbrochen, da die Appliance in Availability Zone 2 die ursprüngliche Anfrage von der Quelle in A nicht kennt. VPC

    Antwortdatenverkehr zu einer Appliance unterbrochen

    Routing

    Jede VPC hat eine oder mehrere Routing-Tabellen und das Transit-Gateway hat zwei Routing-Tabellen.

    VPCRoutentabellen

    VPCA und VPC B

    VPCsA und B haben Routentabellen mit 2 Einträgen. Der erste Eintrag ist der Standardeintrag für lokales IPv4 Routing in derVPC. Dieser Standardeintrag ermöglicht es den darin enthaltenen RessourcenVPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten anderen IPv4 Subnetzverkehr an das Transit-Gateway weiter. Im Folgenden finden Sie die Routentabelle für A. VPC

    Bestimmungsort Ziel

    10.0.0.0/16

    Lokal

    0.0.0.0/0

    tgw-id

    VPCC

    Die Shared Services VPC (VPCC) haben unterschiedliche Routing-Tabellen für jedes Subnetz. Subnetz A wird vom Transit-Gateway verwendet (Sie geben dieses Subnetz an, wenn Sie den VPC Anhang erstellen). Die Routing-Tabelle für Subnetz A leitet den gesamten Datenverkehr an die Appliance im Subnetz B.

    Zielbereich Ziel

    192.168.0.0/16

    Lokal

    0.0.0.0/0

    appliance-eni-id

    Die Routing-Tabelle für Subnetz B (die die Appliance enthält) leitet den Datenverkehr zurück zum Transit Gateway.

    Zielbereich Ziel

    192.168.0.0/16

    Lokal

    0.0.0.0/0

    tgw-id
    Transit-Gateway-Routing-Tabellen

    Dieses Transit-Gateway verwendet eine Routentabelle für VPC A und VPC B und eine Routentabelle für die gemeinsamen Dienste VPC (VPCC).

    Die Anlagen VPC A und VPC B sind der folgenden Routentabelle zugeordnet. Die Routentabelle leitet den gesamten Verkehr an VPC C weiter.

    Bestimmungsort Ziel Routing-Typ

    0.0.0.0/0

    Attachment ID for VPC C

    statisch

    Der VPC C-Anhang ist der folgenden Routentabelle zugeordnet. Er leitet den Verkehr nach VPC A und VPC B weiter.

    Bestimmungsort Ziel Routing-Typ

    10.0.0.0/16

    Attachment ID for VPC A

    verbreitet

    10.1.0.0/16

    Attachment ID for VPC B

    		 verbreitet