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.
Eine Amazon Virtual Private Cloud (VPC-) Verbindung zu einem Transit-Gateway ermöglicht es Ihnen, den Verkehr zu und von einem oder mehreren VPC-Subnetzen weiterzuleiten. Wenn Sie einem Transit Gateway eine VPC anhängen, müssen Sie ein Subnetz aus jeder Availability Zone angeben, die das Transit Gateway für die Weiterleitung des Datenverkehrs verwenden soll. Die Angabe eines Subnetzes aus einer Availability Zone ermöglicht es, Datenverkehr an Ressourcen in jedem Subnetz in dieser Availability Zone zu leiten.
Einschränkungen
-
Wenn Sie eine VPC an ein Transit Gateway anhängen, können keine Ressourcen in Availability Zones ohne Transit-Gateway-Anhang das Transit Gateway nicht erreichen. Wenn in einer Subnetz-Routing-Tabelle eine Route zum Transit Gateway vorhanden ist, wird Datenverkehr nur dann zum Transit Gateway weitergeleitet, wenn das Transit Gateway eine Anhang in einem Subnetz in dieser Availability Zone besitzt.
-
Ein Transit-Gateway unterstützt keine DNS-Auflösung für benutzerdefinierte DNS-Namen von angehängten VPCs Einrichtungen, die private gehostete Zonen in Amazon Route 53 verwenden. Informationen zur Konfiguration der Namensauflösung für privat gehostete Zonen für alle, die an ein Transit-Gateway VPCs angeschlossen sind, finden Sie unter Zentralisierte DNS-Verwaltung der Hybrid Cloud mit Amazon Route 53 und AWS Transit Gateway
. -
Ein Transit-Gateway unterstützt kein Routing zwischen und VPCs identisch CIDRs. Wenn Sie eine VPC an ein Transit Gateway anschließen und ihr CIDR mit dem CIDR einer anderen VPC identisch ist, die bereits an das Transit Gateway angeschlossen ist, werden die Routen für die neu angeschlossene VPC nicht an die Transit-Gateway-Routing-Tabelle weitergegeben.
-
Sie können keinen Anhang für ein VPC-Subnetz erstellen, das sich in einer Local Zone befindet. Jedoch können Sie Ihr Netzwerk so konfigurieren, dass Subnetze in der Local Zone eine Verbindung mit einem Transit-Gateway über die übergeordnete Availability Zone herstellen. Weitere Informationen finden Sie unter Verbinden von Subnetzen der Local Zone mit einem Transit Gateway.
-
Sie können keinen IPv6 Transit-Gateway-Anhang erstellen, der nur Subnetze verwendet. Subnetze für Transit-Gateway-Anhänge müssen auch Adressen unterstützen. IPv4
-
Ein Transit-Gateway muss mindestens einen VPC-Anhang haben, bevor dieses Transit-Gateway zu einer Routing-Tabelle hinzugefügt werden kann.
Lebenszyklus von VPC-Anhängen
Eine VPC-Anhang durchläuft verschiedene Phasen, die mit der Einleitung der Anforderung beginnen. In jeder Phase kann es Aktionen geben, die Sie einleiten können. Am Ende Ihres Lebenszyklus bleibt der VPC-Anhang in der Amazon Virtual Private Cloud Console und in der API- oder Befehlszeilenausgabe eine Zeit lang sichtbar.
Das folgende Diagramm zeigt die Phasen, die eine Anhang in einer einzelnen Kontokonfiguration oder eine kontoübergreifende Konfiguration durchlaufen kann, bei der Auto accept shared attachments (Gemeinsame Anhänge automatisch akzeptieren) werden aktiviert ist.
-
Ausstehend: Eine Anfrage für einen VPC-Anfügung wurde initiiert und befindet sich im Bereitstellungsprozess. In dieser Phase kann eine Anfügung fehlschlagen oder nach
availableverschoben werden. -
Fehlgeschlagen: Eine Anfrage für einen VPC-Anfügung schlägt fehl. In dieser Phase kann die VPC-Anfügung nach
failedverschoben werden. -
Fehlgeschlagen: Die Anforderung für die VPC-Anfügungen ist fehlgeschlagen. In dieser Phase kann er nicht gelöscht werden. Der fehlgeschlagene VPC-Anhang bleibt 2 Stunden lang sichtbar und ist dann nicht mehr sichtbar.
-
Verfügbar: Die VPC-Anfügung ist verfügbar und der Datenverkehr kann zwischen der VPC und dem Transit-Gateway fließen. In dieser Phase kann eine Anfügung fehlschlagen oder nach
modifyingbzw.deletingverschoben werden. -
Löschen: Eine VPC-Anfügung , die gerade gelöscht wird. In dieser Phase kann eine Anfügung fehlschlagen oder nach
deletedverschoben werden. -
Gelöscht: Eine
available-VPC-Anfügung wurde gelöscht. In dieser Phase kann der VPC-Anhang nicht geändert werden. Der VPC-Anhang bleibt 2 Stunden lang sichtbar und ist dann nicht mehr sichtbar. -
Ändern: Es wurde eine Anfrage zum Ändern der Eigenschaften der VPC-Anfügung gestellt. In dieser Phase kann eine Anfügung fehlschlagen oder nach
availablebzw.rolling backverschoben werden. -
Wiederherstellen: Die VPC-Anfügungsanforderung kann nicht abgeschlossen werden, und das System macht alle vorgenommenen Änderungen rückgängig. In dieser Phase kann eine Anfügung fehlschlagen oder nach
availableverschoben werden.
Das folgende Diagramm zeigt die Phasen, die eine Anfügung in einer kontoübergreifenden Konfiguration durchlaufen kann, bei der Auto accept shared attachments (Gemeinsame Anfügungen automatisch akzeptieren) deaktiviert ist.
-
Ausstehende Annahme: Die VPC-Anfügungsanfrage wartet auf Annahme. In dieser Phase kann die Anfügung nach
pending,rejectingoderdeletingverschoben werden. -
Ablehnen: Eine VPC-Anfügung, die gerade abgelehnt wird. In dieser Phase kann eine Anfügung fehlschlagen oder nach
rejectedverschoben werden. -
Abgelehnt: Eine
pending acceptance-VPC-Anfügung wurde abgelehnt. In dieser Phase kann der VPC-Anhang nicht geändert werden. Der VPC-Anhang bleibt 2 Stunden lang sichtbar und ist dann nicht mehr sichtbar. -
Ausstehend: Die VPC-Anfügung wurde angenommen und befindet sich im Bereitstellungsprozess. In dieser Phase kann eine Anfügung fehlschlagen oder nach
availableverschoben werden. -
Fehlgeschlagen: Eine Anfrage für einen VPC-Anfügung schlägt fehl. In dieser Phase kann die VPC-Anfügung nach
failedverschoben werden. -
Fehlgeschlagen: Die Anforderung für die VPC-Anfügungen ist fehlgeschlagen. In dieser Phase kann er nicht gelöscht werden. Der fehlgeschlagene VPC-Anhang bleibt 2 Stunden lang sichtbar und ist dann nicht mehr sichtbar.
-
Verfügbar: Die VPC-Anfügung ist verfügbar und der Datenverkehr kann zwischen der VPC und dem Transit-Gateway fließen. In dieser Phase kann eine Anfügung fehlschlagen oder nach
modifyingbzw.deletingverschoben werden. -
Löschen: Eine VPC-Anfügung , die gerade gelöscht wird. In dieser Phase kann eine Anfügung fehlschlagen oder nach
deletedverschoben werden. -
Gelöscht: Ein
available- oderpending acceptance-VPC-Anhang wurde gelöscht. In dieser Phase kann der VPC-Anhang nicht geändert werden. Der VPC-Anhang bleibt 2 Stunden sichtbar und ist dann nicht mehr sichtbar. -
Ändern: Es wurde eine Anfrage zum Ändern der Eigenschaften der VPC-Anfügung gestellt. In dieser Phase kann eine Anfügung fehlschlagen oder nach
availablebzw.rolling backverschoben werden. -
Wiederherstellen: Die VPC-Anfügungsanforderung kann nicht abgeschlossen werden, und das System macht alle vorgenommenen Änderungen rückgängig. In dieser Phase kann eine Anfügung fehlschlagen oder nach
availableverschoben werden.
Appliance-Modus
Wenn Sie planen, eine statusbehaftete Netzwerk-Appliance in Ihrer VPC zu konfigurieren, können Sie die Appliance-Modus-Unterstützung für den VPC-Anhang aktivieren, in dem sich die Appliance befindet, wenn Sie einen Anhang erstellen. Dadurch wird sichergestellt, dass AWS Transit Gateway während der gesamten Lebensdauer des Datenverkehrs zwischen einer Quelle und einem Ziel dieselbe Availability Zone für diesen VPC-Anhang verwendet. Es ermöglicht einem Transit-Gateway auch, Datenverkehr an eine beliebige Availability Zone in der VPC zu senden, sofern in dieser Zone eine Subnetzverbindung besteht. Der Appliance-Modus wird zwar nur für VPC-Anlagen unterstützt, der Netzwerkfluss kann jedoch von jedem anderen Transit-Gateway-Anhangstyp stammen, einschließlich VPC-, VPN- und Connect-Anhängen. Der Appliance-Modus funktioniert auch für Netzwerkflüsse mit unterschiedlichen Quellen und Zielen. AWS-Regionen Netzwerkflüsse können möglicherweise zwischen verschiedenen Availability Zones neu verteilt werden, wenn Sie den Appliance-Modus zunächst nicht aktivieren, aber später die Anhangskonfiguration bearbeiten, um ihn zu aktivieren. Sie können den Appliance-Modus entweder über die Konsole, die Befehlszeile oder die API aktivieren oder deaktivieren.
Der Appliance-Modus in AWS Transit Gateway optimiert das Traffic-Routing, indem er bei der Bestimmung des Pfads durch eine VPC im Appliance-Modus die Quell- und Ziel-Availability Zones berücksichtigt. Dieser Ansatz verbessert die Effizienz und reduziert die Latenz. Im Folgenden finden Sie Beispielszenarien.
Szenario 1: Routing des Datenverkehrs in der Intra-Availability Zone über eine Appliance-VPC
Wenn der Verkehr von einer Quell-Availability Zone in us-east-1a zu einer Ziel-Availability Zone in us-east-1a fließt, mit Appliance-Modus-Anhängen sowohl in us-east-1a als auch us-east-1b, wählt AWS Transit Gateway eine Netzwerkschnittstelle von us-east-1a innerhalb der Appliance-VPC. Diese Availability Zone wird für die gesamte Dauer des Datenverkehrs zwischen Quelle und Ziel beibehalten.
Szenario 2: Datenverkehrs-Routing zwischen den Availability Zones über eine Appliance-VPC
Für Datenverkehr, der von einer Quell-Availability Zone in us-east-1a zu einer Ziel-Availability Zone in us-east-1b fließt, mit VPC-Anhängen im Appliance-Modus sowohl in us-east-1a als auch us-east-1b, verwendet AWS Transit Gateway einen Flow-Hash-Algorithmus, um entweder us-east-1a oder us-east-1b in der Appliance-VPC auszuwählen. Die gewählte Availability Zone wird während der gesamten Lebensdauer des Datenflusses konsistent verwendet.
Szenario 3: Weiterleitung des Datenverkehrs über eine Appliance-VPC ohne Availability Zone-Daten
Wenn der Verkehr von der Quell-Availability Zone in us-east-1a zu einem Ziel ohne Availability Zone-Informationen stammt — z. B. internetgebundener Verkehr — mit VPC-Anhängen im Appliance-Modus sowohl in us-east-1a als auch us-east-1b, wählt Transit Gateway innerhalb der Appliance-VPC eine Netzwerkschnittstelle von us-east-1a. AWS
Szenario 4: Weiterleitung des Datenverkehrs durch eine Availability Zone, die sich entweder von der Quelle oder dem Ziel unterscheidet
Wenn der Verkehr von einer Quell-Availability Zone in us-east-1a zu einer Ziel-Availability Zone us-east-1b mit VPC-Anhängen im Appliance-Modus in verschiedenen Availability Zones von der Quelle oder dem Ziel fließt — die Appliance-Modi VPCs befinden sich beispielsweise in us-east-1c und us-east-1d — verwendet AWS Transit Gateway einen Flow-Hash-Algorithmus, um entweder us-east-1c oder us-east-1d in der Appliance-VPC auszuwählen. Die gewählte Availability Zone wird während der gesamten Lebensdauer des Flows konsistent verwendet.
Anmerkung
Der Appliance-Modus wird nur für VPC-Anhänge unterstützt.
Referenzierung von Sicherheitsgruppen
Sie können diese Funktion verwenden, um die Verwaltung von Sicherheitsgruppen und die Steuerung des instance-to-instance Datenverkehrs zu vereinfachen VPCs , der an dasselbe Transit-Gateway angeschlossen ist. Sie können nur in Regeln für eingehenden Datenverkehr Querverweise auf Sicherheitsgruppen erstellen. Sicherheitsregeln für ausgehende Nachrichten unterstützen keine Verweise auf Sicherheitsgruppen. Mit der Aktivierung oder Verwendung der Sicherheitsgruppenreferenzierung sind keine zusätzlichen Kosten verbunden.
Die Unterstützung von Verweisen auf Sicherheitsgruppen kann sowohl für Transit-Gateways als auch für Transit-Gateway-VPC-Anlagen konfiguriert werden und funktioniert nur, wenn sie sowohl für ein Transit-Gateway als auch für dessen VPC-Anlagen aktiviert wurde.
Einschränkungen
Die folgenden Einschränkungen gelten, wenn Sie die Sicherheitsgruppenreferenzierung mit einem VPC-Anhang verwenden.
Die Referenzierung von Sicherheitsgruppen wird für Transit-Gateway-Peering-Verbindungen nicht unterstützt. Beide VPCs müssen an dasselbe Transit-Gateway angeschlossen sein.
Die Referenzierung von Sicherheitsgruppen wird für VPC-Anlagen in der Availability Zone use1-az3 nicht unterstützt.
Die Referenzierung von Sicherheitsgruppen wird für Endpoints nicht unterstützt. PrivateLink Wir empfehlen die Verwendung von IP-CIDR-basierten Sicherheitsregeln als Alternative.
Die Referenzierung von Sicherheitsgruppen funktioniert für Elastic File System (EFS), solange für die EFS-Schnittstellen in der VPC eine Sicherheitsgruppenregel „Allow All Egress“ konfiguriert ist.
Für Local Zone-Konnektivität über ein Transit-Gateway werden nur die folgenden Local Zones unterstützt: us-east-1-atl-2a, us-east-1-dfw-2a, us-east-1-iah-2a, us-west-2-lax-1a, us-west-2-lax-1b, us-east-1-mia-2a, us-east-1-chi-2a und us-west-2-phx-2a.
-
Wir empfehlen, diese Funktion auf VPC-Anhangsebene für VPCs Subnetze in nicht unterstützten Local Zones, AWS Outposts und AWS Wavelength Zones zu deaktivieren, da dies zu Dienstunterbrechungen führen kann.
-
Wenn Sie über eine Inspektions-VPC verfügen, funktioniert die Referenzierung von Sicherheitsgruppen über das Transit-Gateway nicht über den AWS Gateway Load Balancer oder eine AWS Network Firewall hinweg.
