Beispiele für Routing-Optionen - Amazon Virtual Private Cloud

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.

Beispiele für Routing-Optionen

In den folgenden Themen wird das Routing für bestimmte Gateways oder Verbindungen in Ihrer VPC erläutert.

Routing zu einem Internet-Gateway

Sie können ein Subnetz zu einem öffentlichen Subnetz machen, indem Sie eine Route in der Subnetz-Routing-Tabelle zu einem Internet-Gateway hinzufügen. Erstellen Sie dazu ein Internet-Gateway und fügen Sie es an Ihre VPC an. Fügen Sie dann eine Route mit dem Zielbereich 0.0.0.0/0 für IPv4-Datenverkehr oder ::/0 für IPv6-Datenverkehr und der Internet-Gateway-ID (igw-xxxxxxxxxxxxxxxxx) als Ziel hinzu.

Ziel Ziel
0.0.0.0/0 igw-id
::/0 igw-id

Weitere Informationen finden Sie unter Herstellen einer Internetverbindung über ein Internet-Gateway.

Routing zu einem NAT-Gerät

Damit Instances in einem privaten Subnetz eine Verbindung zum Internet herstellen können, können Sie ein NAT-Gateway erstellen oder eine NAT-Instance in einem öffentlichen Subnetz starten. Fügen Sie dann eine Route für die Routing-Tabelle des privaten Subnetzes hinzu, die IPv4-Internetverkehr (0.0.0.0/0) an das NAT-Gerät weiterleitet.

Ziel Ziel
0.0.0.0/0 nat-gateway-id

Sie können auch spezifischere Routen zu anderen Zielen erstellen, um unnötige Datenverarbeitungsgebühren für die Verwendung eines NAT-Gateways zu vermeiden oder bestimmte Datenverkehrsdaten privat zu leiten. Im folgenden Beispiel wird der Amazon-S3-Datenverkehr (pl-xxxxxxxx, eine Präfixliste, die die IP-Adressbereiche für Amazon S3 in einer bestimmten Region enthält) an einen Gateway-VPC-Endpunkt und der 10.25.0.0/16-Datenverkehr an eine VPC-Peering-Verbindung weitergeleitet. Diese IP-Adressbereiche sind spezifischer als 0.0.0.0/0. Wenn Instances Datenverkehr an Amazon S3 oder an die Peer-VPC senden, wird der Datenverkehr an den Gateway-VPC-Endpunkt oder die VPC-Peering-Verbindung gesendet. Der gesamte andere Datenverkehr wird an das NAT-Gateway gesendet.

Ziel Ziel
0.0.0.0/0 nat-gateway-id
pl-xxxxxxxx vpce-id
10.25.0.0/16 pcx-id

Weitere Informationen finden Sie unter NAT-Geräte.

Routing zu einem Virtual Private Gateway

Sie können eine AWS Site-to-Site VPN Verbindung verwenden, um Instances in Ihrer VPC die Kommunikation mit Ihrem eigenen Netzwerk zu ermöglichen. Erstellen Sie dazu ein Virtual Private Gateway und fügen Sie es an Ihre VPC an. Fügen Sie dann eine Route in der Subnetz-Routing-Tabelle mit dem Zielbereich Ihres Netzwerks und einem Ziel des Virtual Private Gateways () hi (vgw-xxxxxxxxxxxxxxxxx).

Ziel Ziel
10.0.0.0/16 vgw-id

Sie können dann Ihre Site-to-Site VPN-Verbindung erstellen und konfigurieren. Weitere Informationen finden Sie unter Was ist AWS Site-to-Site VPN? und Routing-Tabellen und VPN-Routenpriorität im AWS Site-to-Site VPN -Benutzerhandbuch.

Eine Site-to-Site VPN-Verbindung auf einem Virtual Private Gateway unterstützt keinen IPv6-Datenverkehr. Wir unterstützen jedoch IPv6-Datenverkehr zu einer AWS Direct Connect -Verbindung über ein Virtual Private Gateway. Weitere Informationen finden Sie im AWS Direct Connect -Benutzerhandbuch.

Routing zu einem AWS Outposts lokalen Gateway

In diesem Abschnitt werden Routingtabellenkonfigurationen für das Routing zu einem AWS Outposts lokalen Gateway beschrieben.

Datenverkehr zwischen Outpost-Subnetzen und Ihrem On-Premises-Netzwerk ermöglichen

Subnetze, die sich in VPCs befinden, mit denen verknüpft sind, AWS Outposts können einen zusätzlichen Zieltyp haben, nämlich ein lokales Gateway. Betrachten Sie den Fall, in dem der lokale Gateway-Routenverkehr mit der Zieladresse 192.168.10.0/24 an das Kundennetzwerk gesendet werden soll. Fügen Sie dazu die folgende Route mit dem Zielnetzwerk und einem Ziel des lokalen Gateways () hi (lgw-xxxx).

Ziel Ziel
192.168.10.0/24 lgw-id

Datenverkehr zwischen Subnetzen in derselben VPC über Outposts hinweg ermöglichen

Sie können die Kommunikation zwischen Subnetzen, die sich in derselben VPC befinden, über verschiedene Outposts hinweg mithilfe von lokalen Outpost-Gateways und Ihrem On-Premises-Netzwerk herstellen.

Mit diesem Feature können Sie für Ihre On-Premise-Anwendungen, die in Outposts-Racks ausgeführt werden, ähnliche Architekturen wie Multi-Availability Zone (AZ)-Architekturen erstellen. Stellen Sie dazu Verbindungen zwischen Outposts-Racks her, die sich in verschiedenen AZs befinden.

Datenverkehr zwischen Subnetzen in derselben VPC über Outposts hinweg mithilfe von lokalen Gateways

Um dieses Feature zu aktivieren, fügen Sie Ihrer Routing-Tabelle des Outpost-Rack-Subnetzes eine Route hinzu, die spezifischer ist als die lokale Route in dieser Routing-Tabelle und den Zieltyp eines lokalen Gateways aufweist. Das Ziel der Route muss mit dem gesamten IPv4-Block des Subnetzes in Ihrer VPC übereinstimmen, das sich in einem anderen Outpost befindet. Wiederholen Sie diese Konfiguration für alle Outpost-Subnetze, die kommunizieren müssen.

Wichtig
  • Zur Nutzung dieses Features müssen Sie das direkte VPC-Routing verwenden. Sie können Ihre eigenen kundeneigenen IP-Adressen nicht verwenden.

  • Ihr On-Premises-Netzwerk, an das die lokalen Gateways der Outposts angeschlossen sind, muss über das erforderliche Routing verfügen, damit die Subnetze aufeinander zugreifen können.

  • Wenn Sie Sicherheitsgruppen für Ressourcen in den Subnetzen verwenden möchten, müssen Sie Regeln verwenden, die IP-Adressbereiche als Quelle oder Ziel in den Outpost-Subnetzen enthalten. Sie können keine Sicherheitsgruppen-IDs verwenden.

  • Bestehende Outposts-Racks erfordern möglicherweise ein Update, um die Unterstützung der Intra-VPC-Kommunikation über mehrere Outposts hinweg zu ermöglichen. Wenn dieses Feature bei Ihnen nicht funktioniert, wenden Sie sich an den  AWS -Support.

Beispiel

Für eine VPC mit einem CIDR von 10.0.0.0/16, einem Subnetz Outpost 1 mit einem CIDR von 10.0.1.0/24 und einem Subnetz Outpost 2 mit einem CIDR von 10.0.2.0/24 würde der Eintrag für die Routing-Tabelle des Subnetzes Outpost 1 wie folgt lauten:

Bestimmungsort Ziel
10.0.0.0/16 Local
10.0.2.0/24 lgw-1-id

Der Eintrag für die Routing-Tabelle des Subnetzes Outpost 2 würde wie folgt lauten:

Bestimmungsort Ziel
10.0.0.0/16 Local
10.0.1.0/24 lgw-2-id

Routing an eine VPC-Peering-Verbindung

Eine VPC-Peering-Verbindung ist eine Netzwerkverbindung zwischen zwei VPCs. Diese ermöglicht die Weiterleitung des Datenverkehrs zwischen den VPCs mithilfe von privaten IPv4-Adressen. Instances in jeder der VPCs können so miteinander kommunizieren, als befänden sie sich im selben Netzwerk.

Um das Routing von Datenverkehr zwischen VPCs in einer VPC-Peering-Verbindung zu aktivieren, müssen Sie eine Route zu einer oder mehreren Ihrer Subnetz-Routing-Tabellen hinzufügen, die auf die VPC-Peering-Verbindung verweist. Auf diese Weise können Sie auf den CIDR-Block der anderen VPC in der Peering-Verbindung ganz oder teilweise zugreifen. Ebenso muss der Eigentümer der anderen VPC seiner Subnetz-Routing-Tabelle eine Route hinzufügen, damit der Datenverkehr zu Ihrer VPC zurückgeleitet wird.

Angenommen Sie haben eine VPC-Peering-Verbindung (pcx-11223344556677889) zwischen zwei VPCs mit den folgenden Informationen:

  • VPC A: CIDR-Block ist 10.0.0.0/16

  • VPC B: CIDR-Block ist 172.31.0.0/16

Damit Datenverkehr zwischen den VPCs sowie Zugriff auf den gesamten IPv4-CIDR-Block beider VPCs möglich ist, wird die Routing-Tabelle von VPC A wie folgt konfiguriert.

Ziel Ziel
10.0.0.0/16 Local
172.31.0.0/16 pcx-11223344556677889

Die Routing-Tabelle von VPC B wird folgendermaßen konfiguriert.

Ziel Ziel
172.31.0.0/16 Local
10.0.0.0/16 pcx-11223344556677889

Ihre VPC-Peering-Verbindung kann auch IPv6-Kommunikation zwischen Instances innerhalb der VPCs unterstützen, sofern IPv6-Kommunikation für die VPCs und Instances aktiviert ist. Damit IPv6-Datenverkehr zwischen VPCs geleitet werden kann, müssen Sie der Routing-Tabelle eine Route hinzufügen, die auf die VPC-Peering-Verbindung verweist, um ganz oder teilweise auf den IPv6-CIDR-Block der Peer-VPC zuzugreifen.

Ausgehend von derselben, oben genannten VPC-Peering-Verbindung (pcx-11223344556677889) nehmen wir an, dass die VPCs folgende Informationen haben:

  • VPC A: IPv6-CIDR-Block ist 2001:db8:1234:1a00::/56

  • VPC B: IPv6-CIDR-Block ist 2001:db8:5678:2b00::/56

Um IPv6-Kommunikation über die VPC-Peering-Verbindung zu ermöglichen, fügen Sie der Subnetz-Routing-Tabelle für VPC A folgende Route hinzu:

Ziel Ziel
10.0.0.0/16 Local
172.31.0.0/16 pcx-11223344556677889
2001:db8:5678:2b00::/56 pcx-11223344556677889

Fügen Sie der Routing-Tabelle für VPC B die folgende Route hinzu:

Ziel Ziel
172.31.0.0/16 Local
10.0.0.0/16 pcx-11223344556677889
2001:db8:1234:1a00::/56 pcx-11223344556677889

Weitere Informationen zu VPC-Peering-Verbindungen erhalten Sie im Amazon VPC Peering-Handbuch.

Routing zu einem Gateway-VPC-Endpunkt

Ein Gateway-VPC-Endpunkt ermöglicht es Ihnen, eine private Verbindung zwischen Ihrer VPC und einem anderen AWS Service herzustellen. Wenn Sie einen Gateway-Endpunkt erstellen, geben Sie die Subnetz-Routing-Tabellen in Ihrer VPC an, die vom Gateway-Endpunkt verwendet werden. Den Routing-Tabellen wird automatisch eine Route mit der Präfixlisten-ID des Services (pl-xxxxxxxx) als Zielbereich und der Endpunkt-ID (vpce-xxxxxxxxxxxxxxxxx) als Ziel hinzugefügt. Sie können die Endpunktroute nicht explizit löschen oder ändern. Es ist jedoch möglich, die von dem Endpunkt verwendeten Routing-Tabellen zu ändern.

Weitere Informationen zur Weiterleitung für Endpunkte sowie zu den Auswirkungen auf Routen zu AWS -Services finden Sie unter Routing für Gateway-Endpunkte.

Routing zu einem Egress-Only-Internet-Gateway

Sie können ein Egress-Only-Internet-Gateway für Ihre VPC erstellen, um es Instances in einem privaten Subnetz zu ermöglichen, ausgehenden Datenverkehr an das Internet zu senden, ohne dass vom Internet aus eine Verbindung zu den Instances möglich ist. Ein Egress-Only-Internet-Gateway steht nur für den IPv6-Datenverkehr zur Verfügung. Um Routing für ein Egress-Only-Internet-Gateway zu konfigurieren, müssen Sie eine Route in der Routing-Tabelle des privaten Subnetzes hinzufügen, das IPv6-Internetdatenverkehr (::/0) an das Egress-Only-Internet-Gateway leitet.

Ziel Ziel
::/0 eigw-id

Weitere Informationen finden Sie unter Aktivieren von ausgehendem IPv6-Datenverkehr mit einem Internet-Gateway, das nur ausgehenden Verkehr zulässt.

Routing für ein Transit-Gateway

Wenn Sie einem Transit-Gateway eine VPC anfügen, müssen Sie der Subnetz-Routing-Tabelle eine Route hinzufügen, damit der Datenverkehr über das Transit-Gateway weitergeleitet wird.

Betrachten Sie das folgende Szenario, in dem drei VPCs einem Transit-Gateway angefügt sind. In diesem Szenario sind alle Anfügungen der standardmäßigen Transit Gateway-Routing-Tabelle zugeordnet und werden auf die standardmäßige Transit Gateway-Routing-Tabelle übertragen. Daher können alle Anfügungen Pakete untereinander weiterleiten und das Transit-Gateway dient als einfacher Layer 3-IP-Hub.

Angenommen Sie haben 2 VPCs mit den folgenden Informationen:

  • VPC A: 10.1.0.0/16, Anfügungs-ID tgw-attach-11111111111111111

  • VPC B: 10.2.0.0/16, Anfügungs-ID tgw-attach-22222222222222222

Damit Datenverkehr zwischen den VPCs sowie der Zugriff auf das Transit-Gateway möglich ist, wird die Routing-Tabelle von VPC A wie folgt konfiguriert.

Ziel Ziel
10.1.0.0/16 Lokal
10.0.0.0/8 tgw-id

Folgendes ist ein Beispiel für die Transit-Gateway-Routing-Tabellen-Einträge für die VPC-Anfügungen.

Ziel Ziel
10.1.0.0/16 tgw-attach-11111111111111111
10.2.0.0/16 tgw-attach-22222222222222222

Weitere Informationen zu Transit-Gateway-Routing-Tabellen finden Sie unter Weiterleitung in Amazon VPC Transit Gateways.

Routing für eine Middlebox-Appliance

Sie können Middlebox-Appliances zu den Routing-Pfaden für Ihre VPC hinzufügen. Folgende Anwendungsfälle sind möglich:

  • Fangen Sie Datenverkehr ab, der über ein Internet-Gateway oder ein Virtual Private Gateway in Ihre VPC gelangt, indem Sie ihn an eine Middlebox-Appliance in Ihrer VPC leiten. Sie können den Middlebox-Routing-Assistenten verwenden, um AWS automatisch die entsprechenden Routing-Tabellen für Ihr Gateway, Ihre Middlebox und Ihr Zielsubnetz konfigurieren zu lassen. Weitere Informationen finden Sie unter Middlebox-Routing-Assistent.

  • Direkte Datenverkehr zwischen zwei Subnetzen zu einer Middlebox-Appliance. Sie können dies tun, indem Sie eine Route für eine Subnetz-Routing-Tabelle erstellen, die mit dem Subnetz-CIDR des anderen Subnetzes übereinstimmt und einen Gateway-Load-Balancer-Endpunkt, NAT-Gateway, Network-Firewall-Endpunkt oder die Netzwerkschnittstelle einer Appliance als Ziel angibt. Um den gesamten Datenverkehr vom Subnetz zu einem anderen Subnetz umzuleiten, ersetzen Sie alternativ das Ziel der lokalen Route durch einen Gateway-Load-Balancer-Endpunkt, ein NAT-Gateway oder eine Netzwerkschnittstelle.

Sie können die Appliance entsprechend Ihren Anforderungen konfigurieren. Sie können beispielsweise eine Sicherheits-Appliance konfigurieren, die den gesamten Datenverkehr untersucht, oder eine WAN-Beschleunigungs-Appliance. Die Appliance wird als Amazon EC2-Instance in einem Subnetz in Ihrer VPC bereitgestellt und durch eine Elastic Network-Schnittstelle (Netzwerkschnittstelle) in Ihrem Subnetz dargestellt.

Wenn Sie die Routing-Weitergabe für die Routing-Tabelle des Ziel-Subnetzes aktivieren, beachten Sie die Routing-Priorität. Wir priorisieren die spezifischste Route. Wenn die Routen übereinstimmen, geben wir statischen Routen den Vorrang vor verbreiteten Routen. Überprüfen Sie Ihre Routen, um sicherzustellen, dass der Verkehr korrekt weitergeleitet wird und dass es keine unbeabsichtigten Folgen hat, wenn Sie Route Propagation aktivieren oder deaktivieren (Route Propagation ist beispielsweise für eine AWS Direct Connect Verbindung erforderlich, die Jumbo Frames unterstützt).

Um eingehenden VPC-Datenverkehr an eine Appliance weiterzuleiten, ordnen Sie eine Routing-Tabelle dem Internet-Gateway oder dem Virtual Private Gateway zu und geben die Netzwerkschnittstelle Ihrer Appliance als Ziel für den VPC-Datenverkehr an. Weitere Informationen finden Sie unter Gateway-Routing-Tabellen. Sie können auch ausgehenden Datenverkehr aus dem Subnetz an eine Middlebox-Appliance in einem anderen Subnetz weiterleiten.

Beispiele für Middlebox-Routing finden Sie unter Middlebox-Szenarien.

Überlegungen zu Appliances

Sie können eine Drittanbieter-Appliance aus AWS Marketplace auswählen oder eine eigene Appliance konfigurieren. Beachten Sie beim Erstellen oder Konfigurieren einer Appliance Folgendes:

  • Die Appliance muss in einem separaten Subnetz für den Quell- oder Zielbereichsdatenverkehr konfiguriert sein.

  • Sie müssen die Quell-/Zielprüfung in der Appliance deaktivieren. Weitere Informationen finden Sie unter Ändern der Quell- oder Zielüberprüfung im Amazon EC2 EC2-Benutzerhandbuch.

  • Sie können keinen Datenverkehr zwischen Hosts im selben Subnetz über eine Appliance weiterleiten.

  • Die Appliance muss keine Netzwerkadressübersetzung (Network Address Translation, NAT) durchführen.

  • Sie können Ihren Routing-Tabellen eine Route hinzufügen, die spezifischer als die lokale Route ist. Sie können spezifischere Routen verwenden, um Datenverkehr zwischen Subnetzen innerhalb einer VPC (Ost-West-Verkehr) zu einer Middlebox-Appliance umzuleiten. Das Ziel der Route muss mit dem gesamten IPv4- oder IPv6-CIDR-Block eines Subnetzes in Ihrer VPC übereinstimmen.

  • Um IPv6-Datenverkehr abzufangen, müssen Sie sicherstellen, dass VPC, Subnetz und Appliance IPv6 unterstützen. Virtual Private Gateways unterstützen keinen IPv6-Datenverkehr.

Routing des Datenverkehrs zwischen einem Gateway und einer Appliance

Um eingehenden VPC-Datenverkehr an eine Appliance weiterzuleiten, ordnen Sie eine Routing-Tabelle dem Internet-Gateway oder dem Virtual Private Gateway zu und geben die Netzwerkschnittstelle Ihrer Appliance als Ziel für den VPC-Datenverkehr an. Im folgenden Beispiel verfügt die VPC über ein Internet-Gateway, eine Appliance und ein Subnetz mit Instances. Der Datenverkehr aus dem Internet wird über eine Appliance geleitet.

Weiterleiten von eingehendem Datenverkehr über eine Appliance

Ordnen Sie diese Routing-Tabelle Ihrem Internet-Gateway oder Ihrem Virtual Private Gateway zu. Der erste Eintrag ist die lokale Route. Der zweite Eintrag sendet IPv4-Datenverkehr, der für das Subnetz bestimmt ist, an die Netzwerkschnittstelle der Appliance. Diese Route ist spezifischer als die lokale Route.

Bestimmungsort Ziel
VPC-CIDR Local
Subnetz-CIDR Appliance-Netzwerkschnittstellen-ID

Alternativ können Sie das Ziel für die lokale Route durch die Netzwerkschnittstelle der Appliance ersetzen. Sie können dies tun, um sicherzustellen, dass der gesamte Datenverkehr automatisch an die Appliance geleitet wird, einschließlich des Datenverkehrs, der für Subnetze bestimmt ist, die Sie der VPC in Zukunft hinzufügen.

Bestimmungsort Ziel
VPC-CIDR Appliance-Netzwerkschnittstellen-ID

Um Datenverkehr von Ihrem Subnetz an eine Appliance in einem anderen Subnetz weiterzuleiten, fügen Sie der Subnetz-Routing-Tabelle eine Route hinzu, die Datenverkehr an die Netzwerkschnittstelle der Appliance weiterleitet. Der Zielbereich muss weniger spezifisch sein als der Zielbereich für die lokale Route. Geben Sie beispielsweise für den für das Internet bestimmten Datenverkehr 0.0.0.0/0 (alle IPv4-Adressen) als Zielbereich an.

Ziel Ziel
VPC-CIDR Local
0.0.0.0/0 Appliance-Netzwerkschnittstellen-ID

Fügen Sie dann in der Routing-Tabelle, die dem Subnetz der Appliance zugeordnet ist, eine Route hinzu, die den Datenverkehr zurück an das Internet-Gateway oder Virtual Private Gateway sendet.

Bestimmungsort Ziel
VPC-CIDR Local
0.0.0.0/0 igw-id

Routing-Intersubnetzdatenverkehr an eine Appliance

Sie können Datenverkehr, der für ein bestimmtes Subnetz bestimmt ist, an die Netzwerkschnittstelle einer Appliance weiterleiten. Im folgenden Beispiel enthält die VPC zwei Subnetze und eine Appliance. Der Verkehr zwischen den Subnetzen wird über eine Appliance geleitet.

Routing des Datenverkehrs zwischen Subnetzen über eine Appliance
Sicherheitsgruppen

Wenn Sie Datenverkehr zwischen Instances in verschiedenen Subnetzen über eine Middlebox-Appliance leiten, müssen die Sicherheitsgruppen für beide Instances den Datenverkehr zwischen den Instances zulassen. Die Sicherheitsgruppe für jede Instance muss die private IP-Adresse der anderen Instance oder den CIDR-Bereich des Subnetzes, das die andere Instance enthält, als Quelle referenzieren. Wenn Sie die Sicherheitsgruppe der anderen Instance als Quelle referenzieren, wird dadurch kein Datenverkehr zwischen den Instances möglich.

Routing

Im Folgenden finden Sie eine Routing-Tabelle für Subnetz A. Dieser erste Eintrag befähigt Instances in dieser VPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten Datenverkehr vom Subnetz A zum Subnetz B an die Netzwerkschnittstelle der Appliance weiter.

Bestimmungsort Ziel
VPC-CIDR Local
Subnetz-B-CIDR Appliance-Netzwerkschnittstellen-ID

Im Folgenden finden Sie eine Routing-Tabelle für Subnetz B. Dieser erste Eintrag befähigt Instances in dieser VPC, miteinander zu kommunizieren. Der zweite Eintrag leitet den gesamten Datenverkehr vom Subnetz B zum Subnetz A an die Netzwerkschnittstelle der Appliance weiter.

Bestimmungsort Ziel
VPC-CIDR Local
Subnetz-A-CIDR Appliance-Netzwerkschnittstellen-ID

Alternativ können Sie das Ziel für die lokale Route durch die Netzwerkschnittstelle der Appliance ersetzen. Sie können dies tun, um sicherzustellen, dass der gesamte Datenverkehr automatisch an die Appliance geleitet wird, einschließlich des Datenverkehrs, der für Subnetze bestimmt ist, die Sie der VPC in Zukunft hinzufügen.

Bestimmungsort Ziel
VPC-CIDR Appliance-Netzwerkschnittstellen-ID

Routing unter Verwendung einer Präfixliste

Wenn Sie in Ihren AWS Ressourcen häufig auf denselben Satz von CIDR-Blöcken verweisen, können Sie eine vom Kunden verwaltete Präfixliste erstellen, um sie zu gruppieren. Anschließend können Sie die Präfixliste als Ziel in Ihrem Routing-Tabelleneintrag angeben. Sie können später Einträge für die Präfixliste hinzufügen oder entfernen, ohne die Routing-Tabellen aktualisieren zu müssen.

Beispielsweise verfügen Sie über ein Transit-Gateway mit mehreren VPC-Anhängen. Die VPCs müssen in der Lage sein, mit zwei bestimmten VPC-Anhängen zu kommunizieren, die die folgenden CIDR-Blöcke haben:

  • 10.0.0.0/16

  • 10.2.0.0/16

Sie erstellen eine Präfixliste mit beiden Einträgen. In den Subnetz-Routing-Tabellen erstellen Sie eine Route und geben die Präfixliste als Destination und das Transit-Gateway als Ziel an.

Ziel Ziel
172.31.0.0/16 Local
pl-123abc123abc123ab tgw-id

Die maximale Anzahl von Einträgen für die Präfixlisten entspricht der Anzahl von Einträgen in der Routing-Tabelle.

Routing zu einem Gateway Load Balancer-Endpunkt

Ein Gateway Load Balancer ermöglicht es Ihnen, den Datenverkehr an eine Flotte virtueller Appliances wie Firewalls zu verteilen. Sie können den Load Balancer als Service konfigurieren, indem Sie eine VPC-Endpunktdienstkonfiguration erstellen. Sie erstellen dann in Ihrer VPC einen Gateway Load Balancer-Endpunkt, um Ihre VPC mit dem Service zu verbinden.

Um Ihren Datenverkehr an den Gateway Load Balancer weiterzuleiten (z. B. zur Sicherheitsinspektion), geben Sie den Gateway Load Balancer-Endpunkt als Ziel in Ihren Routingtabellen an.

Ein Beispiel für Sicherheitsgeräte hinter einem Gateway Load Balancer finden Sie unter Überprüfen des Datenverkehrs mithilfe von Appliances in einer Sicherheits-VPC.

Um den Gateway Load Balancer-Endpunkt in der Routingtabelle anzugeben, verwenden Sie die ID des VPC-Endpunkts. Um beispielsweise Datenverkehr für 10.0.1.0/24 an einen Gateway-Load-Balancer-Endpunkt weiterzuleiten, fügen Sie die folgende Route hinzu.

Bestimmungsort Ziel
10.0.1.0/24 vpc-endpoint-id

Weitere Informationen finden Sie unter Gateway Load Balancer.