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.
In den folgenden Themen wird das Routing für bestimmte Gateways oder Verbindungen in Ihrer VPC erläutert.
Inhalt
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 und fügen Sie dann eine Route mit dem Ziel 0.0.0.0/0
für IPv4 Traffic oder ::/0
für IPv6 Traffic und einem Ziel der Internet-Gateway-ID (igw-xxxxxxxxxxxxxxxxx
) hinzu.
Bestimmungsort | Ziel |
---|---|
0.0.0.0/0 | igw-id |
::/0 | igw-id |
Weitere Informationen finden Sie unter Aktivieren Sie den Internetzugang für eine VPC mithilfe eines Internet-Gateways.
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 Routentabelle des privaten Subnetzes hinzu, die den IPv4 Internetverkehr (0.0.0.0/0
) an das NAT-Gerät weiterleitet.
Bestimmungsort | 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 |
Anschließend können Sie 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 virtuellen privaten Gateway unterstützt keinen IPv6 Datenverkehr. Wir unterstützen jedoch IPv6 Datenverkehr, der über ein virtuelles privates Gateway zu einer AWS Direct Connect Verbindung geleitet wird. 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.
Inhalt
Datenverkehr zwischen Outpost-Subnetzen und Ihrem On-Premises-Netzwerk ermöglichen
Subnetze, die mit VPCs verknüpft sind, AWS Outposts können den zusätzlichen Zieltyp eines lokalen Gateways haben. 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.
Sie können diese Funktion verwenden, um Architekturen zu erstellen, die Multi-Availability Zone (AZ) -Architekturen für Ihre lokalen Anwendungen, die auf Outposts-Racks ausgeführt werden, ähneln, indem Sie Konnektivität zwischen Outposts-Racks herstellen, die an unterschiedlichen Racks verankert sind. AZs

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 die Sicherheitsgruppe nicht verwenden. IDs
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 , mit der Sie den Verkehr zwischen ihnen mithilfe privater IPv4 Adressen weiterleiten können. Instances in jeder der VPCs können so miteinander kommunizieren, als befänden sie sich im selben Netzwerk.
Um das Routing des Datenverkehrs zwischen VPCs einer VPC-Peering-Verbindung zu ermöglichen, müssen Sie einer oder mehreren Ihrer Subnetz-Routing-Tabellen eine Route 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.
Sie haben beispielsweise 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
Um den Verkehr zwischen den zu ermöglichen VPCs und den Zugriff auf den gesamten IPv4 CIDR-Block einer der beiden VPCs zu ermöglichen, ist die VPC A-Routentabelle wie folgt konfiguriert.
Bestimmungsort | 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 die IPv6 Kommunikation zwischen Instances in der unterstützen VPCs, sofern die Instances VPCs und für IPv6 die Kommunikation aktiviert sind. Um das Routing des IPv6 Datenverkehrs zwischen diesen zu ermöglichen VPCs, müssen Sie Ihrer Routentabelle eine Route hinzufügen, die auf die VPC-Peering-Verbindung verweist, um auf den gesamten oder einen Teil des IPv6 CIDR-Blocks der Peer-VPC zuzugreifen.
Wenn Sie beispielsweise dieselbe VPC-Peering-Verbindung (pcx-11223344556677889
) wie oben verwenden, gehen Sie davon aus, dass sie über die folgenden Informationen VPCs verfügen:
-
VPC A: IPv6 CIDR-Block ist
2001:db8:1234:1a00::/56
-
VPC B: IPv6 CIDR-Block ist
2001:db8:5678:2b00::/56
Um die IPv6 Kommunikation über die VPC-Peering-Verbindung zu aktivieren, fügen Sie der Subnetz-Routentabelle für VPC A die folgende Route hinzu.
Bestimmungsort | 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-
) als Zielbereich und der Endpunkt-ID (xxxxxxxx
vpce-
) 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.xxxxxxxxxxxxxxxxx
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 Internet-Gateway nur für ausgehenden Datenverkehr wird nur für den Datenverkehr verwendet. IPv6 Um das Routing für ein Internet-Gateway nur für ausgehenden Datenverkehr zu konfigurieren, fügen Sie in der Routing-Tabelle des privaten Subnetzes eine Route hinzu, die den IPv6 Internetverkehr () ::/0
an das Internet-Gateway weiterleitet, das nur für ausgehenden Datenverkehr bestimmt ist.
Bestimmungsort | Ziel |
---|---|
::/0 | eigw-id |
Weitere Informationen finden Sie unter Aktivieren Sie ausgehenden IPv6 Datenverkehr über ein Internet-Gateway nur für ausgehenden Datenverkehr.
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.
Stellen Sie sich das folgende Szenario vor, in dem Sie drei VPCs Geräte haben, die an ein Transit-Gateway angeschlossen 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.
Sie haben beispielsweise zwei 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
Um den Verkehr zwischen dem zu ermöglichen VPCs und den Zugriff auf das Transit-Gateway zu ermöglichen, ist die VPC A-Routentabelle wie folgt konfiguriert.
Bestimmungsort | 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 EC2 Amazon-Instance in einem Subnetz in Ihrer VPC bereitgestellt und durch eine elastic network interface (Netzwerkschnittstelle) in Ihrem Subnetz repräsentiert.
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 die Route-Propagierung 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.
Inhalt
Überlegungen zu Appliances
Sie können eine Drittanbieter-Appliance aus AWS Marketplace
-
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 EC2 Amazon-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 dem IPv6 CIDR-Block eines Subnetzes in Ihrer VPC übereinstimmen.
-
Um den IPv6 Datenverkehr abzufangen, stellen Sie sicher, dass Ihre VPC, Ihr Subnetz und Ihre Appliance dies unterstützen. IPv6
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.

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 den für das Subnetz bestimmten IPv4 Datenverkehr an die Netzwerkschnittstelle der Appliance. Diese Route ist spezifischer als die lokale Route.
Bestimmungsort | Ziel |
---|---|
VPC CIDR |
Local |
Subnet CIDR |
Appliance network interface 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 network interface 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 Datenverkehr, der für das Internet bestimmt ist, 0.0.0.0/0
(alle IPv4 Adressen) als Ziel an.
Bestimmungsort | Ziel |
---|---|
VPC CIDR |
Local |
0.0.0.0/0 | Appliance network interface 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.

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 |
Subnet B CIDR |
Appliance network interface 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 |
Subnet A CIDR |
Appliance network interface 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 network interface 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. Sie VPCs müssen in der Lage sein, mit zwei spezifischen 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 einen Gateway Load Balancer erstellen, einen Gateway Load Balancer-Endpunktdienst konfigurieren und dann einen Gateway Load Balancer-Endpunkt in Ihrer VPC erstellen, um ihn 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 Konfigurieren des Routings und der Inspektion des Middlebox-Datenverkehrs in einer 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.