Erweitern einer VPC auf eine lokale Zone, eine Wavelength-Zone oder einen Outpost

Sie können VPC-Ressourcen wie Subnetze an mehreren Standorten weltweit hosten. Diese Standorte bestehen aus Regionen, Availability Zones, Local Zones und Wavelength Zones. Jede Region ist ein separater geografischer Bereich.

• Availability Zones sind mehrere isolierte Standorte innerhalb jeder Region.

• Local Zones bieten Ihnen die Möglichkeit, Ressourcen wie Rechenleistung und Speicher an mehreren Standorten zu platzieren, die näher an Ihren Endbenutzern liegen.

• AWS Outposts bieten native AWS-Services, Infrastruktur und Betriebsmodelle für praktisch jedes Rechenzentrum, jeden Co-Location-Bereich oder jede On-Premises-Einrichtung.

• Mit Wavelength Zones können Developer Anwendungen mit äußerst niedriger Latenz für 5G-Geräte und Endbenutzer erstellen. Wavelength stellt standardmäßige AWS-Datenverarbeitungs- und -Speicherservices am Edge der 5G-Netze von Telekommunikationsanbietern bereit.

AWS betreibt hochmoderne, hoch verfügbare Rechenzentren. In seltenen Fällen kann es aber zu Ausfällen kommen, die die Verfügbarkeit von Instances desselben Standorts beeinträchtigen. Wenn Sie alle Ihre Instances an einem einzigen Standort hosten, der von einem Ausfall dieser Art betroffen ist, ist keine Ihrer Instances verfügbar.

Informationen zur Ermittlung der für Sie am besten geeigneten Bereitstellung finden Sie unter Häufig gestellte Fragen zu AWS Wavelength.

Subnetze in AWS Local Zones

Mit AWS Local Zones können Sie Ressourcen näher an Ihre Endbenutzer platzieren und sich nahtlos mit dem gesamten Serviceangebot der Region AWS mit vertrauten APIs und Toolsets verbinden. Wenn Sie ein Subnetz in einer Local Zone erstellen, erweitern Sie Ihre VPC auf diese Local Zone.

Um eine Local Zone zu verwenden, gehen Sie wie folgt vor:

• Melden Sie sich für die Local Zone an.

• Erstellen Sie ein Subnetz in der Local Zone.

• Starten Sie die Ressourcen im Subnetz der Local Zone, damit Ihre Anwendungen näher an Ihren Benutzern liegen:

Das folgende Diagramm zeigt eine VPC in der Region USA West (Oregon) (us-west-2), die sich über Availability Zones und eine Local Zone erstreckt.

Wenn Sie eine VPC erstellen, können Sie der VPC einen Satz von Amazon bereitgestellten öffentlichen IP-Adressen zuweisen. Sie können auch eine Netzwerkgrenzgruppe für die Adressen festlegen, die die Adressen auf die Gruppe beschränkt. Wenn Sie eine Netzwerkgrenzgruppe festlegen, können die IP-Adressen nicht zwischen Netzwerkgrenzgruppen wechseln. Der Netzwerkverkehr der Local Zone wird direkt ins Internet oder zu Points-of-Presence (PoPs) geleitet, ohne die übergeordnete Region der Local Zone zu durchqueren, und ermöglicht so den Zugang zu Datenverarbeitung mit niedriger Latenz. Die vollständige Liste der lokalen Zonen und ihrer übergeordneten Regionen finden Sie unter Available Local Zones im AWS Benutzerhandbuch für lokale Zonen.

Die folgenden Regeln gelten für Local Zones:

• Die Local-Zone-Subnetze folgen denselben Routingregeln, einschließlich Routing-Tabellen, Sicherheitsgruppen und Netzwerk-ACLs, wie das Availability-Zone-Subnetz.

• Der ausgehende Internetverkehr verlässt eine lokale Zone aus der lokalen Zone.

• Sie müssen öffentliche IP-Adressen für die Verwendung in einer Local Zone bereitstellen. Wenn Sie Adressen zuweisen, können Sie den Ort angeben, von dem aus die IP-Adresse angekündigt wird. Wir bezeichnen dies als Netzwerkgrenzgruppe, und Sie können diesen Parameter festlegen, um die Adresse auf diesen Ort zu beschränken. Nachdem Sie die IP-Adressen bereitgestellt haben, können Sie sie nicht zwischen der Local Zone und der übergeordneten Region verschieben (z. B. von us-west-2-lax-1a nach us-west-2).

• Wenn die lokale Zone IPv6 unterstützt, können Sie von Amazon bereitgestellte IPv6-IP-Adressen anfordern und sie mit der Netzwerkgrenzgruppe für eine neue oder bestehende VPC verknüpfen. Eine Liste der lokalen Zonen, die IPv6 unterstützen, finden Sie unter Überlegungen im AWS Benutzerhandbuch für lokale Zonen

• Sie können keine VPC-Endpunkte in Subnetzen der lokalen Zone erstellen.

Weitere Informationen zum Arbeiten mit Local Zones finden Sie im Benutzerhandbuch zu AWS Local Zones.

Überlegungen für Internet-Gateways

Berücksichtigen Sie folgende Informationen, wenn Sie Internet-Gateways (in der übergeordneten Region) in Local Zones verwenden:

• Sie können Internet-Gateways in Local Zones mit Elastic-IP-Adressen oder automatisch zugewiesenen öffentlichen IP-Adressen von Amazon verwenden. Die von Ihnen verknüpften Elastic-IP-Adressen müssen die Netzwerkgrenzgruppe der Local Zone enthalten. Weitere Informationen finden Sie unter Zuordnen von elastischen IP-Adressen zu Ressourcen in Ihrer VPC.

  Sie können keine Elastic-IP-Adresse zuordnen, die für die Region festgelegt ist.

• Elastic-IP-Adressen, die in Local Zones verwendet werden, haben die gleichen Kontingente wie Elastic IP-Adressen in einer Region. Weitere Informationen finden Sie unter Elastic-IP-Adressen.

• Sie können Internet-Gateways in Routing-Tabellen verwenden, die mit Ressourcen der lokalen Zone verknüpft sind. Weitere Informationen finden Sie unter Routing zu einem Internet-Gateway.

Zugreifen auf Local Zones mit einem Direct Connect Gateway

Betrachten Sie das Szenario, in dem ein On-Premises-Rechenzentrum auf Ressourcen zugreifen soll, die sich in einer lokalen Zone befinden. Sie verwenden ein Virtual Private Gateway für die VPC, die mit der Local Zone verknüpft ist, um eine Verbindung mit einem Direct Connect-Gateway herzustellen. Das Direct Connect-Gateway verbindet sich mit einem AWS Direct Connect-Standort in einer Region. Das On-Premises-Rechenzentrum hat eine AWS Direct Connect-Verbindung zum AWS Direct Connect-Standort.

Anmerkung

Datenverkehr innerhalb der USA, der über Direct Connect an ein Subnetz in einer lokalen Zone gerichtet ist, wird nicht durch die übergeordnete Region der lokalen Zone geleitet. Stattdessen nimmt der Verkehr den kürzesten Weg zur lokalen Zone. Dies verringert die Latenz und trägt dazu bei, dass Ihre Anwendungen schneller reagieren.

Sie konfigurieren die folgenden Ressourcen für diese Konfiguration:

• Ein Virtual Private Gateway für die VPC, das dem Subnetz der lokalen Zone zugeordnet ist. Sie können die VPC für das Subnetz auf der Seite mit den Subnetzdetails in der Amazon Virtual Private Cloud Console anzeigen oder describe-subnets verwenden.

  Informationen zum Erstellen eines Virtual Private Gateway finden Sie unter Erstellen eines Ziel-Gateways im AWS Site-to-Site VPN-Benutzerhandbuch.

• Eine Direct Connect-Verbindung. Für die beste Latenzleistung empfiehlt AWS, den Direct-Connect-Standort zu verwenden, der der Local Zone, auf die Sie Ihr Subnetz erweitern, am nächsten liegt.

  Informationen zum Bestellen einer Verbindung finden Sie unter Querverbindungen im AWS Direct Connect-Benutzerhandbuch.

• Ein Direct Connect-Gateway Informationen zum Erstellen eines Direct Connect-Gateways finden Sie unter Erstellen eines Direct Connect Gateway im AWS Direct Connect-Benutzerhandbuch.

• Eine Virtual Private Gateway-Verbindung, um die VPC mit dem Direct Connect-Gateway zu verbinden. Informationen zum Erstellen einer Virtual Private Gateway-Verbindung finden Sie unter Zuordnen und Aufheben der Zuordnung von Virtual Private Gateways im AWS Direct Connect-Benutzerhandbuch.

• Eine private virtuelle Schnittstelle für die Verbindung vom AWS Direct Connect-Standort mit dem On-Premises-Rechenzentrum. Informationen zum Erstellen eines Direct Connect-Gateways finden Sie unter Erstellen einer privaten virtuellen Schnittstelle für das Direct Connect-Gateway im AWS Direct Connect-Benutzerhandbuch.

Verbinden von Subnetzen der Local Zone mit einem Transit-Gateway

Sie können keinen Transit-Gateway-Anhang für ein Subnetz in einer Local Zone erstellen. Das folgende Diagramm zeigt, wie Sie Ihr Netzwerk so konfigurieren, dass Subnetze in der Local Zone eine Verbindung mit einem Transit-Gateway über die übergeordnete Availability Zone herstellen. Erstellen Sie Subnetze in den Local Zones und Subnetzen in den übergeordneten Availability Zones. Verbinden Sie die Subnetze in den übergeordneten Availability Zones mit dem Transit Gateway und erstellen Sie dann in der Routing-Tabelle für jede VPC eine Route, die den für die andere VPC-CIDR bestimmten Datenverkehr an die Netzwerkschnittstelle für den Transit-Gateway-Anhang weiterleitet.

Anmerkung

Datenverkehr, der für ein Subnetz in einer lokalen Zone bestimmt ist und von einem Transit-Gateway stammt, durchläuft zunächst die übergeordnete Region.

Erstellen Sie die folgenden Ressourcen für dieses Szenario:

• Ein Subnetz in jeder übergeordneten Availability Zone. Weitere Informationen finden Sie unter Erstellen eines Subnetzes.

• Ein Transit-Gateway. Weitere Informationen finden Sie unter Transit Gateways erstellen in Amazon-VPC-Transit-Gateways.

• Ein Transit-Gateway-Anhang für jede VPC, die die übergeordnete Availability Zone verwendet. Weitere Informationen finden Sie unter Transit-Gateways-Anhang an eine VPC erstellen in Amazon-VPC-Transit-Gateways.

• Eine Transit-Gateway-Routing-Tabelle, die der Transit-Gateway-Verbindung zugeordnet ist. Weitere Informationen finden Sie unter Transit-Gateway-Routing-Tabellen in Amazon-VPC-Transit-Gateways.

• Für jede VPC einen Eintrag in der VPC-Routing-Tabelle mit dem anderen VPC-CIDR als Ziel und der ID der Netzwerkschnittstelle für den Transit-Gateway-Anhang als Ziel. Suchen Sie nach der Netzwerkschnittstelle für den Transit-Gateway-Anhang in den Beschreibungen der Netzwerkschnittstellen nach der ID des Transit-Gateway-Anhangs. Weitere Informationen finden Sie unter Routing für ein Transit-Gateway.

Es folgt ein Beispiel für eine Routing-Tabelle für VPC 1.

Ziel	Ziel
VPC 1 CIDR	Lokal
VPC 2 CIDR	vpc1-attachment-network-interface-id

Es folgt ein Beispiel für eine Routing-Tabelle für VPC 2.

Ziel	Ziel
VPC 2 CIDR	Lokal
VPC 1 CIDR	vpc2-attachment-network-interface-id

Es folgt ein Beispiel für die Routing-Tabelle des Transit-Gateways. Die CIDR-Blöcke für jede VPC werden an die Transit-Gateway-Routing-Tabelle übertragen.

CIDR	Attachment	Routing-Typ
VPC 1 CIDR	Anhang für VPC 1	verbreitet
VPC 2 CIDR	Anhang für VPC 2	verbreitet

Subnetze in AWS Wavelength

AWS Wavelength Mit können Entwickler Anwendungen mit ultra-niedriger Latenz für Mobilgeräte und Endbenutzer erstellen. Wavelength stellt standardmäßige AWS-Datenverarbeitungs- und -Speicherservices am Edge der 5G-Netze von Telekommunikationsanbietern bereit. Entwickler können eine Virtual Private Cloud (VPC) auf eine oder mehrere Wavelength-Zonen ausweiten und dann AWS-Ressourcen wie Amazon-EC2-Instances verwenden, um Anwendungen auszuführen, die eine extrem niedrige Latenz und eine Verbindung zu AWS-Services in der Region erfordern.

Um Wavelength Zones verwenden zu können, müssen Sie sich zunächst für die Zone anmelden. Erstellen Sie als Nächstes ein Subnetz in der Wavelength Zone. Sie können Amazon EC2-Instances, Amazon EBS-Volumes und Amazon VPC-Subnetze und Carrier Gateways in Wavelength Zones erstellen. Sie können auch Services nutzen, die EC2, EBS und VPC orchestrieren oder mit diesen zusammenarbeiten, wie Amazon EC2 Auto Scaling, Amazon EKS-Cluster, Amazon ECS-Cluster, Amazon EC2 Systems Manager, Amazon CloudWatch, AWS CloudTrail und AWS CloudFormation. Die Services in Wavelength sind Teil einer VPC, die über eine zuverlässige Verbindung mit hoher Bandbreite mit einer AWS-Region verbunden ist, um einen einfachen Zugang zu Services wie Amazon DynamoDB und Amazon RDS zu ermöglichen.

Die folgenden Regeln gelten für Wavelength Zones:

• Eine VPC erweitert sich zu einer Wavelength Zone, wenn Sie ein Subnetz in der VPC erstellen und es mit der Wavelength Zone verknüpfen.

• Standardmäßig erbt jedes Subnetz, das Sie in einer VPC erstellen, die sich über eine Wavelength Zone erstreckt, die Haupt-Routing-Tabelle der VPC, einschließlich der lokalen Route.

• Wenn Sie eine EC2-Instance in einem Subnetz in einer Wavelength Zone starten, weisen Sie ihr eine Carrier-IP-Adresse zu. Das Carrier-Gateway verwendet die Adresse für den Datenverkehr von der Schnittstelle zum Internet oder zu mobilen Geräten. Das Carrier-Gateway verwendet NAT, um die Adresse zu übersetzen, und sendet dann den Datenverkehr an das Ziel. Der Verkehr vom Telekommunikations-Carrier-Netzwerk läuft über das Carrier-Gateway.

• Sie können das Ziel einer VPC-Routing-Tabelle oder einer Subnetz-Routing-Tabelle in einer Wavelength Zone auf ein Carrier-Gateway festlegen, das eingehenden Datenverkehr von einem Carrier-Netzwerk an einem bestimmten Standort und ausgehenden Datenverkehr zum Carrier-Netzwerk und zum Internet zulässt. Weitere Informationen zu Weiterleitungsoptionen in einer Wavelength Zone finden Sie unter Weiterleitung im AWS Wavelength Entwicklerhandbuch.

• Subnetze in Wavelength-Zonen verfügen über dieselben Netzwerkkomponenten wie Subnetze in Availability Zones, einschließlich IPv4-Adressen, DHCP-Optionssätze und Netzwerk-ACLs.

• Sie können keinen Transit-Gateway-Anhang zu einem Subnetz in einer Wavelength-Zone erstellen. Erstellen Sie stattdessen den Anhang über ein Subnetz in der übergeordneten Availability Zone, und leiten Sie dann den Datenverkehr über das Transit Gateway an die gewünschten Ziele weiter. Ein Beispiel hierfür finden Sie im nächsten Abschnitt.

Überlegungen zu mehreren Wavelength Zones

EC2-Instances, die sich in verschiedenen Wavelength Zones in derselben VPC befinden, dürfen nicht miteinander kommunizieren. Wenn Sie eine Kommunikation von Wavelength Zone zu Wavelength Zone benötigen, empfiehlt AWS, mehrere VPCs zu verwenden – eine für jede Wavelength Zone. Sie können ein Transit-Gateway verwenden, um die VPCs miteinander zu verbinden. Diese Konfiguration ermöglicht die Kommunikation zwischen Instances in den Wavelength Zones.

Der Datenverkehr von Wavelength Zone zu Wavelength Zone läuft über die AWS-Region. Weitere Informationen finden Sie unter AWS Transit Gateway.

Das folgende Diagramm zeigt, wie Sie Ihr Netzwerk so konfigurieren, dass Instances in zwei verschiedenen Wavelength Zones miteinander kommunizieren können. Sie verfügen über zwei Wavelength Zones (Wavelength Zone A und Wavelength Zone B). Sie müssen die folgenden Ressourcen erstellen, um die Kommunikation zu ermöglichen:

• Für jede Wavelength Zone ein Subnetz in einer Availability Zone, das die übergeordnete Availability Zone für die Wavelength Zone ist. In diesem Beispiel erstellen Sie Subnetz 1 und Subnetz 2. Informationen zum Erstellen von Subnetzen finden Sie unter Erstellen eines Subnetzes. Verwenden Sie zum Suchen der übergeordneten Zone describe-availability-zones.

• Ein Transit-Gateway. Das Transit-Gateway verbindet die VPCs. Weitere Informationen zum Erstellen eines Transit Gateways finden Sie unter Erstellen eines Transit-Gateways im Amazon VPC Transit Gateways-Handbuch.

• Für jede VPC eine VPC-Anfügung an den Transit Gateway in der übergeordneten Availability Zone der Wavelength-Zone. Weitere Informationen finden Sie unter Transit-Gateway-Anhang an eine VPC erstellen im Amazon-VPC-Transit-Gateways-Handbuch.

• Einträge für jede VPC in der Routingtabelle des Transit-Gateways. Informationen zum Erstellen von Transit Gateway-Routen finden Sie unter Transit Gateway-Routing-Tabellen im Amazon VPC Transit Gateways-Handbuch.

• Für jede VPC ein Eintrag in der VPC-Routing-Tabelle, der das andere VPC-CIDR als Ziel enthält, und die Gateway-ID als Ziel. Weitere Informationen finden Sie unter Routing für ein Transit-Gateway.

  In dem Beispiel hat die Routingtabelle für VPC 1 den folgenden Eintrag:

  Zielbereich	Ziel
  10.1.0.0/24	tgw-22222222222222222

  Die Routingtabelle für VPC 2 hat den folgenden Eintrag:

  Zielbereich	Ziel
  10.0.0.0/24	tgw-22222222222222222

Subnetze in AWS Outposts

AWS Outposts bietet Ihnen die gleiche AWS-Hardwareinfrastruktur, Services, APIs und Tools zum Erstellen und Ausführen Ihrer Anwendungen On-Premises und in der Cloud. AWS Outposts ist ideal für Workloads geeignet, die einen Zugriff mit niedriger Latenz auf On-Premises-Anwendungen oder -Systeme benötigen, sowie für Workloads, die Daten lokal speichern und verarbeiten müssen. Mehr über AWS Outposts erfahren Sie unter AWS Outposts.

Eine VPC umfasst alle Availability Zones einer AWS-Region. Nachdem Sie Ihren Outpost mit seiner übergeordneten Region verbunden haben, können Sie jede VPC in der Region auf Ihren Outpost ausdehnen, indem Sie ein Subnetz für den Outpost in dieser VPC erstellen.

Es gelten die folgenden Regeln für AWS Outposts:

• Die Subnetze müssen sich an einem Outpost-Standort befinden.

• Sie erstellen ein Subnetz für einen Outpost, indem Sie den Amazon-Ressourcennamen (ARN) des Outposts angeben, wenn Sie das Subnetz erstellen.

• Outposts-Rack – Ein lokales Gateway verarbeitet die Netzwerkkonnektivität zwischen Ihrer VPC und On-Premises-Netzwerken. Weitere Informationen finden Sie unter Lokale Gateways im AWS Outposts-Benutzerhandbuch für das Outposts-Rack.

• Outposts-Server – Eine lokale Netzwerkschnittstelle verarbeitet die Netzwerkkonnektivität zwischen Ihrer VPC und On-Premises-Netzwerken. Weitere Informationen finden Sie unter Lokale Netzwerkschnittstellen im AWS Outposts-Benutzerhandbuch für Outposts-Server.

• Standardmäßig ist jedes Subnetz, das Sie in einer VPC erstellen, einschließlich Subnetze für Ihre Outposts, implizit eine Haupt-Routing-Tabelle für die VPC zugeordnet. Alternativ können Sie eine benutzerdefinierte Routing-Tabelle explizit mit den Subnetzen in Ihrer VPC On-Premises-Netzwerk bestimmt ist, festlegen.