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.
# Netzwerk
Eine Outpost-Bereitstellung hängt von einer stabilen Verbindung zu ihrem zentralen AZ ab, damit Verwaltung, Überwachung und Servicebetriebe ordnungsgemäß funktionieren. Sie sollten Ihr lokales Netzwerk so einrichten, dass redundante Netzwerkverbindungen für jedes Outpost-Rack und eine zuverlässige Konnektivität zu den Ankerpunkten in der Cloud bereitgestellt werden. AWS Berücksichtigen Sie auch die Netzwerkpfade zwischen den Anwendungs-Workloads, die auf dem Outpost ausgeführt werden, und den anderen lokalen und Cloud-Systemen, mit denen sie kommunizieren. Wie werden Sie diesen Datenverkehr in Ihrem Netzwerk weiterleiten?
**Topics**
+ [Netzwerkanschluss](network-attachment.md)
+ [Anker-Konnektivität](anchor-connectivity.md)
+ [Routing von Anwendungen und Arbeitslasten](applicationworkload-routing.md)
# Netzwerkanschluss
Jedes AWS Outposts Rack ist mit redundanten top-of-rack Switches konfiguriert, die als Outpost Networking Devices () ONDs bezeichnet werden. Die Rechen- und Speicherserver in jedem Rack sind mit beiden ONDs verbunden. Sie sollten jedes OND mit einem separaten Switch, einem sogenannten Customer Networking Device (CND), in Ihrem Rechenzentrum verbinden, um verschiedene physische und logische Pfade für jedes Outpost-Rack bereitzustellen. ONDs Stellen Sie mithilfe von Glasfaserkabeln und optischen Transceivern eine Verbindung zu Ihrem CNDs über eine oder mehrere physische Verbindungen her. Die [physischen Verbindungen](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity) sind in [LAG-Links (Logical Link Aggregation Group)](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation) konfiguriert.
![\[Diagramm, das Multi-Rack-Outpost mit redundanten Netzwerkanhängen zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
Die OND-zu-CND-Verbindungen werden immer in einer LAG konfiguriert — auch wenn es sich bei der physischen Verbindung um ein einzelnes Glasfaserkabel handelt. Wenn Sie die Links als LAG-Gruppen konfigurieren, können Sie die Verbindungsbandbreite erhöhen, indem Sie der logischen Gruppe zusätzliche physische Verbindungen hinzufügen. Die LAG-Verbindungen sind als IEEE 802.1q-Ethernet-Trunks konfiguriert, um getrennte Netzwerke zwischen dem Outpost und dem lokalen Netzwerk zu ermöglichen.
Jeder Outpost verfügt über mindestens zwei logisch getrennte Netzwerke, die mit dem Kundennetzwerk oder über das Kundennetzwerk kommunizieren müssen:
+ **Service Link-Netzwerk** — weist den Outpost-Servern die Service-Link-IP-Adressen zu und erleichtert die Kommunikation mit dem lokalen Netzwerk, sodass sich die Server wieder mit den Outpost-Ankerpunkten in der Region verbinden können. Wenn Sie mehrere Rack-Implementierungen in einem einzigen logischen Outposts haben, müssen Sie jedem Rack einen Service Link /26 CIDR zuweisen.
+ **Lokales Gateway-Netzwerk** — ermöglicht die Kommunikation zwischen den VPC-Subnetzen auf dem Outpost und dem lokalen Netzwerk über das Outpost Local Gateway (LGW).
[Diese getrennten Netzwerke sind über eine Reihe von IP-Verbindungen über die LAG-Links mit dem lokalen Netzwerk verbunden. point-to-point ](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) Jeder OND-zu-CND-LAG-Link ist mit VLAN IDs, point-to-point (/30 oder /31) IP-Subnetzen und eBGP-Peering für jedes getrennte Netzwerk (Service Link und LGW) konfiguriert. Sie sollten die LAG-Links mit ihren point-to-point VLANs und Subnetzen als segmentierte Layer-2-Verbindungen mit Routing betrachten. Die gerouteten IP-Verbindungen bieten redundante logische Pfade, die die Kommunikation zwischen den getrennten Netzwerken im Outpost und dem lokalen Netzwerk erleichtern.
![\[Diagramm, das Service Link Peering zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[Diagramm mit lokalem Gateway-Peering\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
Sie sollten die Layer-2-LAG-Links (und ihre VLANs) auf den direkt angeschlossenen CND-Switches beenden und die IP-Schnittstellen und das BGP-Peering auf den CND-Switches konfigurieren. Sie sollten die LAG VLANs zwischen Ihren Switches im Rechenzentrum nicht überbrücken. Weitere Informationen finden Sie unter [Konnektivität auf Netzwerkebene](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) im *AWS Outposts Benutzerhandbuch*.
In einem logischen Outpost mit mehreren Racks ONDs sind sie redundant miteinander verbunden, um eine hochverfügbare Netzwerkkonnektivität zwischen den Racks und den Workloads auf den Servern zu gewährleisten. AWS ist für die Netzwerkverfügbarkeit innerhalb des Outpost verantwortlich.
## Empfohlene Vorgehensweisen für hochverfügbare Netzwerkanschlüsse ohne ACE
+ Connect jedes Outpost Networking Device (OND) in einem Outpost-Rack mit einem separaten Customer Networking Device (CND) im Rechenzentrum.
+ Trennen Sie die Layer-2-Links VLANs, Layer-3-IP-Subnetze und das BGP-Peering auf den direkt angeschlossenen Customer Networking Device (CND) -Switches. Stellen Sie keine Brücke zwischen OND und CND zwischen dem lokalen Netzwerk oder zwischen dem lokalen Netzwerk her VLANs . CNDs
+ Fügen Sie Links zu den Link Aggregation Groups (LAGs) hinzu, um die verfügbare Bandbreite zwischen dem Outpost und dem Rechenzentrum zu erhöhen. Verlassen Sie sich nicht auf die Gesamtbandbreite der verschiedenen Pfade durch beide. ONDs
+ Nutzen Sie die verschiedenen Pfade durch die Redundanz ONDs , um eine stabile Konnektivität zwischen den Outpost-Netzwerken und dem lokalen Netzwerk zu gewährleisten.
+ Um eine optimale Redundanz zu erreichen und eine unterbrechungsfreie OND-Wartung zu ermöglichen, empfehlen wir Kunden, BGP-Werbung und -Richtlinien wie folgt zu konfigurieren:
+ Die Netzwerkausrüstung des Kunden sollte BGP-Werbung von Outpost erhalten, ohne die BGP-Attribute zu ändern, und BGP aktivieren, falls eine Wartung erforderlich ist. multipath/load-balancing to achieve optimal inbound traffic flows (from customer towards Outpost). AS-Path prepending is used for Outpost BGP prefixes to shift traffic away from a particular OND/uplink Das Kundennetzwerk sollte Routen von Outpost mit AS-Path-Länge 1 gegenüber Routen mit AS-Path-Länge 4 bevorzugen, d. h. auf AS-Path-Prepending reagieren.
+ Das Kundennetzwerk sollte in Outpost für gleiche BGP-Präfixe mit denselben Attributen werben. ONDs Standardmäßig verteilt das Outpost-Netzwerk den ausgehenden Datenverkehr (zum Kunden hin) auf alle Uplinks. Routing-Richtlinien werden auf der Outpost-Seite verwendet, um den Datenverkehr von einem bestimmten OND wegzuleiten, falls Wartungsarbeiten erforderlich sind. Für diese Verkehrsverlagerung und für die unterbrechungsfreie Durchführung von Wartungsarbeiten ONDs sind auf allen Seiten gleiche BGP-Präfixe von Kundenseite erforderlich. Wenn das Netzwerk des Kunden gewartet werden muss, empfehlen wir die Verwendung von AS-Path Prepending, um den Datenverkehr vorübergehend von einem bestimmten Uplink oder Gerät abzuleiten.
## Empfohlene Vorgehensweisen für hochverfügbare Netzwerkanschlüsse mit ACE
Für eine Multi-Rack-Bereitstellung mit vier oder mehr Computer-Racks müssen Sie das Aggregation, Core, Edge (ACE) -Rack verwenden, das als Netzwerkaggregationspunkt fungiert, um die Anzahl der Glasfaserverbindungen zu Ihren lokalen Netzwerkgeräten zu reduzieren. Das ACE-Rack stellt die Konnektivität zum Rack ONDs in jedem Outposts bereit und ist somit für AWS die Zuweisung und Konfiguration der VLAN-Schnittstelle zwischen den ONDs ACE-Netzwerkgeräten zuständig.
Isolierte Netzwerkschichten für Service Link- und Local Gateway-Netzwerke sind weiterhin erforderlich, unabhängig davon, ob ein ACE-Rack verwendet wird oder nicht, das auf VLAN-IP-Subnetze point-to-point (/30 oder /31) und eine eBGP-Peering-Konfiguration für jedes getrennte Netzwerk abzielt. Die vorgeschlagenen Architekturen sollten einer der beiden folgenden Architekturen folgen:
![\[Netzwerkgeräte für zwei Kunden\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ Bei dieser Architektur sollte der Kunde über zwei Netzwerkgeräte (CND) verfügen, um die ACE-Netzwerkgeräte miteinander zu verbinden und so Redundanz zu gewährleisten.
+ Für jede physische Verbindung müssen Sie eine LAG aktivieren (um die verfügbare Bandbreite zwischen dem Outpost und dem Rechenzentrum zu erhöhen), auch wenn es sich um einen einzelnen physischen Port handelt. Dieser Port wird zwei Netzwerksegmente mit 2 point-to-point VLANs (/30 oder /31) und eBGP-Konfigurationen zwischen und übertragen. ACEs CNDs
+ In einem stabilen Zustand erfolgt der Lastenausgleich nach dem to/from the customer network from the ACE layer, 25% traffic distribution across the ACE to customer. In order to allow this behavior, the eBGP peering’s between ACEs and CNDs must have BGP multipath/load ECMP-Muster-Balancing (Equal-Cost Multipath), wobei der Lastenausgleich aktiviert ist und die Kundenpräfixe mit derselben BGP-Metrik auf den 4 eBGP-Peering-Verbindungen angekündigt werden.
+ Um eine optimale Redundanz zu erreichen und eine unterbrechungsfreie OND-Wartung zu ermöglichen, empfehlen wir unseren Kunden, die folgenden Empfehlungen zu befolgen:
+ Das Netzwerkgerät des Kunden sollte für alle Geräte in Outpost gleiche BGP-Präfixe mit denselben Attributen bewerben. ONDs
+ Das Netzwerkgerät des Kunden sollte BGP-Werbung von Outpost erhalten, ohne die BGP-Attribute zu ändern und um BGP-Multipath/Load-Balancing zu aktivieren.
![\[Netzwerkgeräte für vier Kunden\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
Bei dieser Architektur verfügt der Kunde über vier Netzwerkgeräte (CND), um die ACE-Netzwerkgeräte miteinander zu verbinden, wodurch Redundanz und dieselbe Netzwerklogik, einschließlich eBGP und ECMP VLANs, wie sie für eine 2-CND-Architektur gelten, gewährleistet werden.
# Anker-Konnektivität
Ein [Outpost-Servicelink](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) stellt eine Verbindung zu öffentlichen oder privaten Ankern (nicht zu beiden) in einer bestimmten Availability Zone (AZ) in der übergeordneten Region des Outposts her. Outpost-Server initiieren ausgehende Service Link-VPN-Verbindungen von ihren Service Link-IP-Adressen zu den Ankerpunkten in der Anker-AZ. Diese Verbindungen verwenden UDP- und TCP-Port 443. AWS ist verantwortlich für die Verfügbarkeit der Ankerpunkte in der Region.
Sie müssen sicherstellen, dass die IP-Adressen der Outpost-Servicelinks über Ihr Netzwerk eine Verbindung zu den Ankerpunkten im Anker-AZ herstellen können. Die Service Link-IP-Adressen müssen nicht mit anderen Hosts in Ihrem lokalen Netzwerk kommunizieren.
Öffentliche Ankerpunkte befinden sich in den [öffentlichen IP-Bereichen](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) der Region (in den CIDR-Blöcken des EC2 Dienstes) und können über das Internet oder öffentliche virtuelle Schnittstellen [AWS Direct Connect](https://aws.amazon.com/directconnect/)(DX) aufgerufen werden (). VIFs Die Verwendung öffentlicher Ankerpunkte ermöglicht eine flexiblere Pfadauswahl, da der Service Link-Verkehr über jeden verfügbaren Pfad geleitet werden kann, der die Ankerpunkte im öffentlichen Internet erfolgreich erreichen kann.
Private Ankerpunkte ermöglichen es Ihnen, Ihre IP-Adressbereiche für die Ankerkonnektivität zu verwenden. Private Ankerpunkte werden in einem [privaten Subnetz innerhalb einer dedizierten VPC](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity) unter Verwendung von vom Kunden zugewiesenen IP-Adressen erstellt. Die VPC wird in dem Land erstellt AWS-Konto , dem die Outpost-Ressource gehört, und Sie sind dafür verantwortlich, dass die VPC verfügbar und ordnungsgemäß konfiguriert ist. Verwenden Sie eine Security Control Policy (SCP) in AWSOrigamiServiceGateway Organizations, um zu verhindern, dass Benutzer diese Virtual Private Cloud (VPC) löschen. Auf private Ankerpunkte muss über [Direct](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/) Connect Private zugegriffen werden. VIFs
Sie sollten redundante Netzwerkpfade zwischen dem Outpost und den Ankerpunkten in der Region bereitstellen, wobei die Verbindungen auf separaten Geräten an mehr als einem Standort enden. Dynamisches Routing sollte so konfiguriert werden, dass der Verkehr automatisch auf alternative Pfade umgeleitet wird, wenn Verbindungen oder Netzwerkgeräte ausfallen. Sie sollten ausreichend Netzwerkkapazität bereitstellen, um sicherzustellen, dass der Ausfall eines WAN-Pfads die verbleibenden Pfade nicht überlastet.
Das folgende Diagramm zeigt drei Outposts mit redundanten Netzwerkpfaden zu ihrem Anker, die AZs über AWS Direct Connect öffentliche Internetverbindungen verfügen. Outpost A und Outpost B sind in verschiedenen Availability Zones in derselben Region verankert. Außenposten A ist mit privaten Ankerpunkten in AZ 1 der Region 1 verbunden. Außenposten B ist mit öffentlichen Ankerpunkten in AZ 2 der Region 1 verbunden. Außenposten C ist mit öffentlichen Ankern in AZ 1 der Region 2 verbunden.
![\[Diagramm, das die hochverfügbare Ankerkonnektivität mit AWS Direct Connect und den öffentlichen Internetzugang zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
Outpost A verfügt über drei redundante Netzwerkpfade, um seinen privaten Ankerpunkt zu erreichen. Zwei Pfade sind über redundante Direct Connect-Schaltungen an einem einzigen Direct Connect-Standort verfügbar. Der dritte Pfad ist über einen Direct Connect-Stromkreis an einem zweiten Direct Connect-Standort verfügbar. Dieses Design hält den Service Link-Verkehr von Outpost A in privaten Netzwerken aufrecht und bietet Pfadredundanz, die den Ausfall eines der Direct Connect-Leitungen oder eines gesamten Direct Connect-Standorts ermöglicht.
Outpost B verfügt über vier redundante Netzwerkpfade, um seinen öffentlichen Ankerpunkt zu erreichen. Drei Pfade sind öffentlich verfügbar, die auf den von Outpost A genutzten Direct Connect-Leitungen und Standorten VIFs bereitgestellt werden. Der vierte Pfad ist über das Kunden-WAN und das öffentliche Internet verfügbar. Der Service Link-Verkehr von Outpost B kann über jeden verfügbaren Pfad geleitet werden, der die Ankerpunkte im öffentlichen Internet erfolgreich erreichen kann. Die Verwendung der Direct Connect-Pfade kann für eine konsistentere Latenz und eine höhere Bandbreitenverfügbarkeit sorgen, während der öffentliche Internetpfad für Disaster Recovery (DR) oder Bandbreitenerweiterungen verwendet werden kann.
Outpost C verfügt über zwei redundante Netzwerkpfade, um seinen öffentlichen Ankerpunkt zu erreichen. Outpost C wird in einem anderen Rechenzentrum als Outpost A und B bereitgestellt. Das Rechenzentrum von Outpost C verfügt nicht über eigene Leitungen, die mit dem Kunden-WAN verbunden sind. Stattdessen verfügt das Rechenzentrum über redundante Internetverbindungen, die von zwei verschiedenen Internetdienstanbietern () bereitgestellt werden. ISPs Der Service Link-Verkehr von Outpost C kann über eines der ISP-Netzwerke geleitet werden, um die Ankerpunkte im öffentlichen Internet zu erreichen. Dieses Design ermöglicht Flexibilität bei der Weiterleitung des Service Link-Verkehrs über jede verfügbare öffentliche Internetverbindung. Der end-to-end Pfad hängt jedoch von öffentlichen Netzwerken von Drittanbietern ab, in denen Bandbreitenverfügbarkeit und Netzwerklatenz schwanken.
Der Netzwerkpfad zwischen einem Outpost und seinen Service Link-Ankerpunkten muss der folgenden Bandbreitenspezifikation entsprechen:
+ 500 Mbit/s — 1 Gbit/s verfügbare Bandbreite pro Outpost-Rack (z. B. 3 Racks: 1,5 — 3 Gbit/s verfügbare Bandbreite)
## Empfohlene Verfahren für hochverfügbare Anker-Konnektivität
+ Stellen Sie redundante Netzwerkpfade zwischen jedem Außenposten und seinen Ankerpunkten in der Region bereit.
+ Verwenden Sie Direct Connect (DX) -Pfade, um Latenz und Bandbreitenverfügbarkeit zu kontrollieren.
+ Stellen Sie sicher, dass der TCP- und UDP-Port 443 von den Outpost Service Link CIDR-Blöcken zu den [EC2 IP-Adressbereichen](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) in der übergeordneten Region geöffnet ist (ausgehend). Stellen Sie sicher, dass die Ports auf allen Netzwerkpfaden geöffnet sind.
+ Behalten Sie den Überblick über die EC2 Amazon-IP-Adressbereiche in Ihrer Firewall, wenn Sie eine Teilmenge der CIDR-Bereiche für die Region verwenden.
+ Stellen Sie sicher, dass jeder Pfad die Anforderungen an Bandbreitenverfügbarkeit und Latenz erfüllt.
+ Verwenden Sie dynamisches Routing, um die Verkehrsumleitung bei Netzwerkausfällen zu automatisieren.
+ Testen Sie das Routing des Service Link-Datenverkehrs über jeden geplanten Netzwerkpfad, um sicherzustellen, dass der Pfad erwartungsgemäß funktioniert.
# Routing von Anwendungen und Arbeitslasten
Für Anwendungs-Workloads gibt es zwei Wege aus dem Outpost heraus:
+ Der Service-Link-Pfad: Bedenken Sie, dass der Anwendungsdatenverkehr mit dem Traffic auf der Kontrollebene von Outposts konkurrieren wird. Außerdem ist die [MTU auf 1300 Byte](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links) begrenzt.
+ Der lokale Gateway-Pfad (LGW): Bedenken Sie, dass das lokale Netzwerk des Kunden den Zugriff sowohl auf lokale als auch auf interne Anwendungen ermöglicht. AWS-Region
Sie konfigurieren die Routing-Tabellen des Outpost-Subnetzes, um zu steuern, welcher Pfad zum Erreichen der Zielnetzwerke verwendet werden soll. Routen, die auf das LGW verweisen, leiten den Verkehr vom lokalen Gateway zum lokalen Netzwerk weiter. Routen, die auf die Dienste und Ressourcen in der Region verweisen, wie Internet Gateway, NAT Gateway, Virtual Private Gateway und TGW, verwenden [Service Link](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html), um diese Ziele zu erreichen. Wenn Sie eine VPC-Peering-Verbindung mit mehreren VPCs auf demselben Outpost haben, VPCs verbleibt der Verkehr zwischen den Outpost und verwendet nicht den Service-Link zurück zur Region. Informationen zum VPC-Peering finden Sie unter [Connect VPCs using VPC Peering](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) im *Amazon* VPC-Benutzerhandbuch.
![\[Diagramm, das eine Visualisierung des Outpost-Servicelinks und der LGW-Netzwerkpfade zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
Bei der Planung des Anwendungsroutings sollten Sie darauf achten, sowohl den normalen Betrieb als auch die eingeschränkte Routing- und Serviceverfügbarkeit bei Netzwerkausfällen zu berücksichtigen. Der Service Link-Pfad ist nicht verfügbar, wenn ein Outpost von der Region getrennt wird.
Sie sollten verschiedene Pfade bereitstellen und dynamisches Routing zwischen dem Outpost LGW und Ihren kritischen lokalen Anwendungen, Systemen und Benutzern konfigurieren. Redundante Netzwerkpfade ermöglichen es dem Netzwerk, den Datenverkehr um Ausfälle herum weiterzuleiten und sicherzustellen, dass lokale Ressourcen bei teilweisen Netzwerkausfällen mit den Workloads kommunizieren können, die auf dem Outpost ausgeführt werden.
Outpost-VPC-Routenkonfigurationen sind statisch. Sie konfigurieren Subnetz-Routing-Tabellen über die AWS-Managementkonsole CLI und andere Infrastructure as Code (IaC) -Tools. Sie können die Subnetz-Routing-Tabellen jedoch während eines Verbindungsabbruchs nicht ändern. APIs Sie müssen die Konnektivität zwischen dem Outpost und der Region wiederherstellen, um die Routing-Tabellen zu aktualisieren. Verwenden Sie für den normalen Betrieb dieselben Routen, die Sie bei Verbindungsabbrüchen verwenden möchten.
Ressourcen auf dem Outpost können das Internet über den Service Link und ein Internet Gateway (IGW) in der Region oder über den Local Gateway (LGW) -Pfad erreichen. Durch die Weiterleitung des Internetverkehrs über den LGW-Pfad und das lokale Netzwerk können Sie vorhandene lokale Interneteingangs- und -ausgangspunkte verwenden. Dies kann im Vergleich zur Verwendung des Service Link-Pfads zu einem IGW in der Region zu einer geringeren Latenz und höheren MTUs und niedrigeren AWS Datenausgangsgebühren führen.
Wenn Ihre Anwendung lokal ausgeführt werden muss und über das öffentliche Internet zugänglich sein muss, sollten Sie den Anwendungsdatenverkehr über Ihre lokalen Internetverbindungen an das LGW weiterleiten, um die Ressourcen auf dem Outpost zu erreichen.
Sie können zwar Subnetze in einem Outpost wie öffentliche Subnetze in der Region konfigurieren, dies kann jedoch für die meisten Anwendungsfälle unerwünscht sein. Eingehender Internetverkehr wird über den Service Link zu den Ressourcen, die auf dem Outpost laufen, aufgenommen AWS-Region und über diesen weitergeleitet.
Der Antwortverkehr wird wiederum über die Service-Verbindung und wieder über die Internetverbindungen von weitergeleitet. AWS-Region Dieses Verkehrsmuster kann die Latenz erhöhen und es fallen Gebühren für ausgehende Daten an, wenn der Verkehr die Region auf dem Weg zum Außenposten verlässt und wenn der Rückverkehr durch die Region zurückkehrt und ins Internet gelangt. Wenn Ihre Anwendung in der Region ausgeführt werden kann, ist die Region der beste Ort, um sie auszuführen.
Der Verkehr zwischen VPC-Ressourcen (in derselben VPC) folgt immer der lokalen VPC-CIDR-Route und wird von den impliziten VPC-Routern zwischen Subnetzen weitergeleitet.
Beispielsweise wird der Verkehr zwischen einer EC2 Instance, die auf dem Outpost läuft, und einem VPC-Endpunkt in der Region immer über den Service Link geleitet.
![\[Diagramm, das das lokale VPC-Routing über die impliziten Router zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## Empfohlene Verfahren für das Routing von Anwendungen/Workloads
+ Verwenden Sie nach Möglichkeit den Local Gateway (LGW) -Pfad anstelle des Service Link-Pfads.
+ Leiten Sie den Internetverkehr über den LGW-Pfad weiter.
+ Konfigurieren Sie die Outpost-Subnetz-Routingtabellen mit einer Reihe von Standardrouten. Diese werden sowohl für den normalen Betrieb als auch bei Verbindungsabbrüchen verwendet.
+ Stellen Sie redundante Netzwerkpfade zwischen dem Outpost LGW und wichtigen lokalen Anwendungsressourcen bereit. Verwenden Sie dynamisches Routing, um die Verkehrsumleitung bei Netzwerkausfällen vor Ort zu automatisieren.