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.
Amazon VPC-Anhänge in AWS Transit-Gateway
Ein Amazon Virtual Private Cloud (VPC-) Anhang 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 angegebenen Subnetze dienen als Eingangs- und Ausgangspunkte für den Transit-Gateway-Verkehr. Der Datenverkehr kann Ressourcen in anderen Subnetzen innerhalb derselben Availability Zone nur erreichen, wenn in den Routing-Tabellen der Transit-Gateway-Anschlusssubnetze entsprechende Routen konfiguriert sind, die auf die Ziel-Subnetze verweisen.
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.
Anmerkung
In Availability Zones, die Transit-Gateway-Anlagen haben, wird der Verkehr nur von den spezifischen Subnetzen, die dem Anhang zugeordnet sind, an das Transit-Gateway weitergeleitet. Wenn eine Subnetz-Routentabelle eine Route zum Transit-Gateway enthält, wird der Verkehr nur dann an das Transit-Gateway weitergeleitet, wenn das Transit-Gateway einen Anhang in einem Subnetz in derselben Availability Zone hat und die Routing-Tabelle des Anhang-Subnetzes die entsprechenden Routen zum geplanten Ziel des Datenverkehrs innerhalb der VPC enthält.
-
Ein Transit Gateway unterstützt keine DNS-Auflösung für benutzerdefinierte DNS-Namen von angefügten VPCs, die mit privaten gehosteten Zonen in Amazon Route 53 eingerichtet wurden. Informationen zur Konfiguration der Namensauflösung für private gehostete Zonen für alle VPCs, die an ein Transit-Gateway 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 VPCs mit identischen CIDRs oder wenn sich ein CIDR in einem Bereich mit einem CIDR in einer angeschlossenen VPC überschneidet. Wenn Sie eine VPC an ein Transit-Gateway anhängen und ihr CIDR mit dem CIDR einer anderen VPC, die bereits mit dem Transit-Gateway verbunden ist, identisch ist oder sich mit diesem überschneidet, 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 Transit-Gateway-Anhang mithilfe von Subnetzen erstellen. IPv6-only Subnetze für Transit-Gateway-Anhänge müssen auch IPv4-Adressen unterstützen.
-
Ein Transit-Gateway muss mindestens einen VPC-Anhang haben, bevor dieses Transit-Gateway zu einer Routing-Tabelle hinzugefügt werden kann.
Anforderungen an die Routing-Tabelle für VPC-Anlagen
Für die korrekte Funktion von Transit-Gateway-VPC-Anhängen sind bestimmte Routing-Tabellenkonfigurationen erforderlich:
-
Subnetz-Routentabellen für Anlagen: Die Subnetze, die dem Transit-Gateway-Anhang zugeordnet sind, müssen Routing-Tabelleneinträge für alle Ziele innerhalb der VPC enthalten, die über das Transit-Gateway erreichbar sein müssen. Dazu gehören Routen zu anderen Subnetzen, Internet-Gateways, NAT-Gateways und VPC-Endpunkten.
-
Ziel-Subnetz-Routentabellen: Subnetze, die Ressourcen enthalten, die über das Transit-Gateway kommunizieren müssen, müssen über Routen verfügen, die für den Rückverkehr zu externen Zielen auf das Transit-Gateway verweisen.
-
Lokaler VPC-Verkehr: Der Transit-Gateway-Anschluss ermöglicht nicht automatisch die Kommunikation zwischen Subnetzen innerhalb derselben VPC. Es gelten die Standard-VPC-Routing-Regeln, und die lokale Route (VPC-CIDR) muss in den Routing-Tabellen für die VPC-Kommunikation vorhanden sein.
Anmerkung
Wenn Routen in Subnetzen ohne Anlagen innerhalb derselben Availability Zone konfiguriert sind, wird der Verkehrsfluss nicht aktiviert. Nur die spezifischen Subnetze, die dem Transit-Gateway-Anhang zugeordnet sind, können als entry/exit Punkte für den Transit-Gateway-Verkehr dienen.
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.
-
Pending-acceptance: Die VPC-Anhangsanforderung wartet auf ihre 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 eine statusbehaftete Netzwerk-Appliance in Ihrer VPC konfigurieren möchten, können Sie beim Erstellen eines Anhangs die Unterstützung für den Appliance-Modus für den VPC-Anhang aktivieren, in dem sich die Appliance befindet. 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 jede Availability Zone in der VPC zu senden, sofern in dieser Zone eine Subnetzzuordnung 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-Anlagen. Der Appliance-Modus funktioniert auch für Netzwerkflüsse, die Quellen und Ziele auf unterschiedlichen Ebenen haben. AWS-Regionen Netzwerkflüsse können möglicherweise auf verschiedene Availability Zones verteilt werden, wenn Sie den Appliance-Modus zunächst nicht aktivieren, aber später die Anlagenkonfiguration bearbeiten, um ihn zu aktivieren. Sie können den Appliance-Modus entweder über die Konsole, die Befehlszeile oder die API aktivieren oder deaktivieren.
Wichtig
Der Appliance-Modus wird nur für VPC-Anhänge unterstützt.
Voraussetzungen für das AZ-aware Routing: Die Routenweitergabe muss für die Transit-Gateway-Routing-Tabelle aktiviert sein, die dem VPC-Anhang im Appliance-Modus zugeordnet ist. Ohne Propagierung kann das Transit-Gateway die Quell- und Ziel-Availability Zones nicht ermitteln. Der gesamte Datenverkehr — einschließlich der in Szenario 1 beschriebenen Availability-Zone Datenflüsse — wird auf die Flow-Hash-basierte Availability Zone-Auswahl zurückgeführt. Dies bedeutet, dass der Datenverkehr innerhalb derselben Availability Zone möglicherweise an eine andere Availability Zone in der Appliance-VPC weitergeleitet wird, wodurch die Isolierung der Availability Zone unterbrochen wird.
Der Appliance-Modus im AWS Transit Gateway optimiert das Traffic-Routing, indem die Quell- und Ziel-Availability Zones bei der Bestimmung des Pfads durch eine VPC im Appliance-Modus berücksichtigt werden. Dieser Ansatz erhöht die Effizienz und reduziert die Latenz. Das Verhalten variiert je nach der spezifischen Konfiguration und den Verkehrsmustern.
In den folgenden Szenarien wird davon ausgegangen, dass die Routenweitergabe für die Transit-Gateway-Routentabelle aktiviert ist, die dem VPC-Anhang im Appliance-Modus zugeordnet ist. Ohne Propagierung kann das Transit-Gateway die Quell- und Ziel-Availability Zones nicht ermitteln, und in allen Szenarien wird standardmäßig eine Flow-Hash-basierte Availability Zone-Auswahl verwendet (das in Szenario 2 beschriebene Verhalten).
Szenario 1: Routing des Intra-Availability Zonenverkehrs über Appliance-VPC
Wenn der Datenverkehr von der Quell-Availability Zone us-east-1a zur Ziel-Availability Zone us-east-1a fließt und VPC-Anhänge im Appliance-Modus sowohl in us-east-1a als auch in us-east-1b enthalten sind, wählt Transit Gateway eine Netzwerkschnittstelle aus us-east-1a innerhalb der Appliance-VPC aus. Diese Availability Zone wird für die gesamte Dauer des Datenverkehrs zwischen Quelle und Ziel beibehalten.
Szenario 2: Routing des Inter-Availability Zonenverkehrs über Appliance-VPC
Für den Datenverkehr, der von der Quellverfügbarkeitszone us-east-1a zur Zielverfügbarkeitszone us-east-1b fließt, wobei VPC-Anlagen im Appliance-Modus sowohl in us-east-1a als auch in us-east-1b enthalten sind, verwendet 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 Flows konsistent verwendet.
Szenario 3: Routing des Datenverkehrs durch eine Appliance-VPC ohne Availability Zone-Daten
Wenn der Datenverkehr von der Quell-Availability Zone us-east-1a zu einem Ziel ohne Availability Zone-Informationen (z. B. internetgebundener Verkehr) stammt und VPC-Anhänge im Appliance-Modus sowohl in us-east-1a als auch in us-east-1b enthalten sind, wählt Transit Gateway eine Netzwerkschnittstelle von us-east-1a innerhalb der Appliance-VPC aus.
Szenario 4: Routing des Datenverkehrs durch eine Appliance-VPC in einer Availability Zone, die sich von der Quelle oder dem Ziel unterscheidet
Wenn der Datenverkehr von der Quell-Availability Zone us-east-1a zur Ziel-Availability Zone us-east-1b fließt und VPC-Anlagen im Appliance-Modus in verschiedenen Availability Zones, z. B. us-east-1c und us-east-1d, verwendet 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.
Referenzierung von Sicherheitsgruppen
Sie können diese Funktion verwenden, um die Verwaltung von Sicherheitsgruppen und die Steuerung des Datenverkehrs von Instanz zu Instanz über VPCs, die an dasselbe Transit-Gateway angeschlossen sind, zu vereinfachen. Sie können Sicherheitsgruppen nur in Regeln für eingehenden Datenverkehr miteinander vergleichen. Sicherheitsregeln für ausgehende Nachrichten unterstützen keine Referenzierung von Sicherheitsgruppen. Mit der Aktivierung oder Verwendung der Sicherheitsgruppenreferenzierung fallen keine zusätzlichen Kosten an.
Die Unterstützung von Sicherheitsgruppenreferenzen kann sowohl für Transit-Gateways als auch für Transit-Gateway-VPC-Anhänge konfiguriert werden und funktioniert nur, wenn sie sowohl für ein Transit-Gateway als auch für dessen VPC-Anhänge aktiviert wurde.
Einschränkungen
Die folgenden Einschränkungen gelten, wenn die Referenzierung von Sicherheitsgruppen mit einem VPC-Anhang verwendet wird.
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 Verfügbarkeitszone use1-az3 nicht unterstützt.
Die Referenzierung von Sicherheitsgruppen wird für Endpoints nicht unterstützt. PrivateLink Wir empfehlen, CIDR-based IP-Sicherheitsregeln als Alternative zu verwenden.
Die Referenzierung von Sicherheitsgruppen funktioniert für Elastic File System (EFS), solange für die EFS-Schnittstellen in der VPC eine Sicherheitsgruppenregel „Alle ausgehenden Ausgänge zulassen“ konfiguriert ist.
AWS Outposts, AWS Wavelength Zones und einige AWS lokale Zonen unterstützen keine Referenzierung von Sicherheitsgruppen. Um Dienstunterbrechungen zu vermeiden, deaktivieren Sie die Sicherheitsgruppenreferenzierung auf VPC-Anhangsebene für VPCs mit Subnetzen an diesen Standorten.
Nicht unterstützt AWS Local Zones
Die folgenden AWS lokalen Zonen unterstützen diese Funktion nicht:
us-east-1-bos-1a,,us-east-1-bue-1a,us-east-1-lim-1aus-east-1-mci-1a,us-east-1-msp-1a,us-east-1-phl-1a,us-east-1-scl-1a,us-west-2-den-1a,us-west-2-hnl-1a,us-west-2-las-1a,us-west-2-sea-1a,ap-south-1-ccu-1a,ap-south-1-del-1a,ap-southeast-1-mnl-1a,ap-southeast-2-per-1a,eu-north-1-cph-1aeu-north-1-hel-1a,eu-central-1-ham-1a.eu-central-1-waw-1aaf-south-1-los-1ame-south-1-mct-1a-
Wenn Sie über eine Inspektion-VPC verfügen, funktioniert die Referenzierung von Sicherheitsgruppen über das Transit-Gateway nicht über den AWS Gateway Load Balancer oder eine AWS Netzwerk-Firewall hinweg.
IPv6-Support
Wenn Sie einen VPC-Anhang erstellen oder ändern, können Sie die IPv6-Unterstützung aktivieren oder deaktivieren. Der Standardwert ist disable.
Die Aktivierung der IPv6-Unterstützung bewirkt Folgendes:
-
Weist der Transit-Gateway-Netzwerkschnittstelle im Anhangsubnetz eine IPv6-Adresse zu. Das Transit-Gateway verwendet diese Adresse, um IPv6-Verkehr über den Anhang zu senden und zu empfangen.
-
Leitet IPv6-VPC-CIDRs an die Routentabelle des Transit-Gateways weiter, wenn die Routenweitergabe konfiguriert ist.
Wenn Sie die IPv6-Unterstützung deaktivieren, gelten weiterhin die folgenden Verhaltensweisen:
-
Sie können weiterhin statische IPv6-Routen erstellen, die auf den Anhang abzielen.
-
IPv6-Verkehr kann immer noch von der VPC in das Transit-Gateway gelangen, wenn die VPC-Routing-Tabelle eine IPv6-Route enthält, die auf das Transit-Gateway verweist, und Netzwerk-ACLs und Sicherheitsgruppen den Verkehr zulassen.
Diese Einstellung steuert nur die Netzwerkschnittstellenadressierung und die Routenverbreitung — sie filtert keine Pakete.
