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.
# Zentralisierter Zugang zum Internet
Wenn Sie Anwendungen in Ihrer Umgebung mit mehreren Konten bereitstellen, benötigen viele Apps nur ausgehenden Internetzugang (z. B. das Herunterladen von Bibliotheken, Patches oder Betriebssystemupdates). Dies kann sowohl für IPv4- als auch für IPv6-Verkehr erreicht werden. Bei IPv4 kann dies durch Network Address Translation (NAT) in Form eines NAT-Gateways (empfohlen) oder alternativ durch eine selbstverwaltete NAT-Instance, die auf einer Amazon EC2 EC2-Instance ausgeführt wird, als Mittel für den gesamten ausgehenden Internetzugang erreicht werden. Interne Anwendungen befinden sich in privaten Subnetzen, während sich NAT-Gateways und Amazon EC2 EC2-NAT-Instances in einem öffentlichen Subnetz befinden.
AWS empfiehlt die Verwendung von NAT-Gateways, da diese eine bessere Verfügbarkeit und Bandbreite bieten und weniger Verwaltungsaufwand Ihrerseits erfordern. Weitere Informationen finden Sie unter [Vergleich von NAT-Gateways und NAT-Instances](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html).
Für den IPv6 Datenverkehr kann der ausgehende Datenverkehr so konfiguriert werden, dass jede VPC dezentral über ein Internet-Gateway nur für ausgehenden Verkehr verlassen wird, oder er kann so konfiguriert werden, dass er mithilfe von NAT-Instances oder Proxy-Instances an eine zentrale VPC gesendet wird. Die IPv6 Muster werden unter erörtert. [Zentralisierter Ausgang für IPv6](centralized-egress-for-ipv6.md)
**Topics**
+ [Verwenden des NAT-Gateways für den zentralisierten IPv4 Ausgang](using-nat-gateway-for-centralized-egress.md)
+ [Verwenden des NAT-Gateways mit AWS Network Firewall für den zentralisierten IPv4 Ausgang](using-nat-gateway-with-firewall.md)
+ [Verwenden des NAT-Gateways und des Gateway Load Balancer mit Amazon EC2 EC2-Instances für den zentralisierten Ausgang IPv4](using-nat-gateway-and-gwlb-with-ec2.md)
+ [Zentralisierter Ausgang für IPv6](centralized-egress-for-ipv6.md)
# Verwenden des NAT-Gateways für den zentralisierten IPv4 Ausgang
Das NAT-Gateway ist ein verwalteter Übersetzungsdienst für Netzwerkadressen. Die Bereitstellung eines NAT-Gateways in jeder Spoke-VPC kann unerschwinglich werden, da Sie für jedes bereitgestellte NAT-Gateway eine stündliche Gebühr zahlen (siehe [Amazon VPC-Preise](https://aws.amazon.com/vpc/pricing/)). Die Zentralisierung von NAT-Gateways kann eine praktikable Option zur Kostensenkung sein. Zur Zentralisierung erstellen Sie eine separate Ausgangs-VPC im Netzwerkdienstkonto, stellen NAT-Gateways in der Ausgangs-VPC bereit und leiten den gesamten Ausgangsdatenverkehr von der Spoke VPCs zu den NAT-Gateways in der Ausgangs-VPC mithilfe von Transit Gateway oder CloudWAN weiter, wie in der folgenden Abbildung dargestellt.
**Anmerkung**
Wenn Sie das NAT-Gateway mithilfe von Transit Gateway zentralisieren, zahlen Sie eine zusätzliche Transit-Gateway-Datenverarbeitungsgebühr — verglichen mit dem dezentralen Ansatz, bei dem in jeder VPC ein NAT-Gateway betrieben wird. In einigen Randfällen, in denen Sie riesige Datenmengen über ein NAT-Gateway von einer VPC aus senden, kann es kostengünstiger sein, das NAT lokal in der VPC beizubehalten, um die Transit Gateway Gateway-Datenverarbeitungsgebühren zu vermeiden.
![\[Ein Diagramm, das eine dezentrale NAT-Gateway-Architektur mit hoher Verfügbarkeit darstellt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/decentralized-ha-nat-gateway.png)
![\[Ein Diagramm, das ein zentralisiertes NAT-Gateway mit Transit Gateway darstellt (Übersicht)\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-nat-gateway-tg.png)
![\[Ein Diagramm, das ein zentralisiertes NAT-Gateway mit Transit Gateway darstellt (Routentabellendesign)\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/nat-gateway-tg-rt.png)
In diesem Setup werden Spoke-VPC-Anlagen mit Route Table 1 (RT1) verknüpft und an Route Table 2 (RT2) weitergegeben. Es gibt eine [Blackhole-Route](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html), die verhindert, dass die beiden VPCs miteinander kommunizieren. Wenn Sie die Kommunikation zwischen VPC zulassen möchten, können Sie den `10.0.0.0/8 -> Blackhole` Routeneintrag von entfernen. RT1 Dadurch können sie über das Transit-Gateway kommunizieren. Sie können die Spoke-VPC-Anlagen auch an weitergeben RT1 (oder alternativ können Sie eine Routentabelle und associate/propagate alles daran verwenden), sodass der direkte Verkehr zwischen den VPCs verwendeten Transit Gateway kann.
Sie fügen eine statische Route hinzu, indem Sie den RT1 gesamten Datenverkehr auf die ausgehende VPC weiterleiten. Aufgrund dieser statischen Route sendet Transit Gateway den gesamten Internetverkehr über seine ENIs in der Ausgangs-VPC. Sobald der Verkehr in der Ausgangs-VPC angekommen ist, folgt er den Routen, die in der Subnetz-Routentabelle definiert sind, wo diese Transit Gateway vorhanden sind. ENIs Sie fügen in Subnetz-Routentabellen eine Route hinzu, die den gesamten Datenverkehr auf das jeweilige NAT-Gateway in derselben Availability Zone (AZ) lenkt, um den Verkehr in der Cross-Availability Zone (AZ) zu minimieren. In der Tabelle der NAT-Gateway-Subnetz-Routings ist das Internet-Gateway (IGW) als nächsten Hop angegeben. Damit der Rückverkehr zurückfließen kann, müssen Sie einen Eintrag in der Tabelle mit der statischen Routingtabelle für das Routing des NAT-Gateways hinzufügen, der den gesamten an Spoke VPC gebundenen Verkehr als nächsten Hop auf Transit Gateway verweist.
## Hohe Verfügbarkeit
Für eine hohe Verfügbarkeit sollten Sie mehr als ein NAT-Gateway verwenden (eines in jeder Availability Zone). Wenn ein NAT-Gateway nicht verfügbar ist, wird der Verkehr in der Availability Zone, die das betroffene NAT-Gateway durchquert, möglicherweise unterbrochen. Wenn eine Availability Zone nicht verfügbar ist, fallen der Transit Gateway-Endpunkt zusammen mit dem NAT-Gateway in dieser Availability Zone aus, und der gesamte Datenverkehr fließt über die Transit Gateway- und NAT-Gateway-Endpunkte in der anderen Availability Zone.
## Sicherheit
Sie können sich auf Sicherheitsgruppen auf den Quell-Instances, Blackhole-Routen in den Transit Gateway Gateway-Routentabellen und die Netzwerk-ACL des Subnetzes verlassen, in dem sich das NAT-Gateway befindet. Beispielsweise können Kunden öffentliche Subnetze ACLs auf dem NAT Gateway verwenden, um Quell- oder Ziel-IP-Adressen zuzulassen oder zu blockieren. Alternativ können Sie NAT Gateway mit AWS Network Firewall für den zentralisierten Ausgang verwenden, wie im nächsten Abschnitt beschrieben, um diese Anforderung zu erfüllen.
## Skalierbarkeit
Ein einzelnes NAT-Gateway kann bis zu 55.000 gleichzeitige Verbindungen pro zugewiesener IP-Adresse zu jedem eindeutigen Ziel unterstützen. Sie können eine Kontingentanpassung beantragen, um bis zu acht zugewiesene IP-Adressen zuzulassen, sodass 440.000 gleichzeitige Verbindungen zu einer einzigen Ziel-IP und einem einzigen Zielport möglich sind. Das NAT-Gateway bietet eine Bandbreite von 5 Gbit/s und skaliert automatisch auf 100 Gbit/s. Transit Gateway fungiert im Allgemeinen nicht als Load Balancer und verteilt Ihren Datenverkehr nicht gleichmäßig auf die NAT-Gateways in den verschiedenen Availability Zones. Der Verkehr über das Transit Gateway bleibt, wenn möglich, innerhalb einer Availability Zone. Wenn sich die Amazon EC2 EC2-Instance, die den Verkehr initiiert, in Availability Zone 1 befindet, fließt der Datenverkehr aus der elastic network interface von Transit Gateway in derselben Availability Zone 1 in der Ausgangs-VPC und fließt auf der Grundlage der Subnetz-Routentabelle, in der sich die Elastic Network-Schnittstelle befindet, zum nächsten Hop. Eine vollständige Liste der Regeln finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) in der Amazon Virtual Private Cloud Cloud-Dokumentation.
Weitere Informationen finden Sie im Blogbeitrag [Creating a single internet exit point from multiple VPCs Using AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/).
# Verwenden des NAT-Gateways mit AWS Network Firewall für den zentralisierten IPv4 Ausgang
Wenn Sie Ihren ausgehenden Datenverkehr überprüfen und filtern möchten, können Sie die AWS-Netzwerk-Firewall mit NAT-Gateway in Ihre zentralisierte Ausgangsarchitektur integrieren. AWS Network Firewall ist ein verwalteter Service, der es einfach macht, wichtige Netzwerkschutzmaßnahmen für all Ihre Benutzer bereitzustellen. VPCs Es bietet Kontrolle und Transparenz für den Netzwerkverkehr der Schichten 3-7 für Ihre gesamte VPC. Sie können den URL/domain Namen, die IP-Adresse und den Inhalt des ausgehenden Datenverkehrs filtern, um möglichen Datenverlust zu verhindern, Compliance-Anforderungen zu erfüllen und bekannte Malware-Kommunikation zu blockieren. AWS Network Firewall unterstützt Tausende von Regeln, mit denen Netzwerkverkehr herausgefiltert werden kann, der für bekanntermaßen schlechte IP-Adressen oder schädliche Domainnamen bestimmt ist. Sie können Suricata-IPS-Regeln auch als Teil des AWS Network Firewall Dienstes verwenden, indem Sie Open-Source-Regelsätze importieren oder Ihre eigenen IPS-Regeln (Intrusion Prevention System) mithilfe der Suricata-Regelsyntax erstellen. AWS Network Firewall ermöglicht es Ihnen auch, kompatible Regeln von AWS-Partnern zu importieren.
In der zentralisierten Ausgangsarchitektur mit Inspektion ist der AWS Network Firewall Endpunkt ein Standard-Routing-Tabellenziel in der Subnetz-Routentabelle für Transit-Gateway-Anlagen für die Ausgangs-VPC. Der Datenverkehr zwischen Spoke VPCs und dem Internet wird AWS Network Firewall wie in der folgenden Abbildung dargestellt überprüft.
![\[Ein Diagramm, das den zentralen Ausgang mit AWS Network Firewall einem NAT-Gateway darstellt (Routing-Tabellen-Design)\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-rt.png)
Für ein zentralisiertes Bereitstellungsmodell mit Transit Gateway empfiehlt AWS die Bereitstellung von AWS Network Firewall Endpunkten in mehreren Availability Zones. In jeder Availability Zone, in der der Kunde Workloads ausführt, sollte es einen Firewall-Endpunkt geben, wie im vorherigen Diagramm dargestellt. Es hat sich bewährt, dass das Firewall-Subnetz keinen anderen Datenverkehr enthalten sollte, da AWS Network Firewall es nicht in der Lage ist, den Verkehr von Quellen oder Zielen innerhalb eines Firewall-Subnetzes zu untersuchen.
Ähnlich wie bei der vorherigen Konfiguration sind Spoke-VPC-Anlagen mit Route Table 1 (RT1) verknüpft und werden an Route Table 2 (RT2) weitergegeben. Eine Blackhole-Route wird ausdrücklich hinzugefügt, um zu verhindern, dass die beiden VPCs miteinander kommunizieren.
Verwenden Sie weiterhin eine Standardroute, um den gesamten RT1 Datenverkehr auf die ausgehende VPC weiterzuleiten. Transit Gateway leitet alle Verkehrsflüsse an eine der beiden Availability Zones in der Egress-VPC weiter. Sobald der Verkehr eines der Transit Gateway ENIs in der Ausgangs-VPC erreicht, treffen Sie auf eine Standardroute, die den Verkehr an einen der AWS Network Firewall Endpunkte in der jeweiligen Availability Zone weiterleitet. AWS Network Firewall untersucht dann den Datenverkehr anhand der von Ihnen festgelegten Regeln, bevor der Verkehr über eine Standardroute an das NAT-Gateway weitergeleitet wird.
In diesem Fall ist der Transit Gateway Gateway-Appliance-Modus nicht erforderlich, da Sie keinen Datenverkehr zwischen Anhängen senden.
**Anmerkung**
AWS Network Firewall führt keine Netzwerkadressübersetzung für Sie durch. Diese Funktion würde vom NAT-Gateway nach der Überprüfung des Datenverkehrs durch die ausgeführt AWS Network Firewall. Ingress-Routing ist in diesem Fall nicht erforderlich, da der Rückverkehr standardmäßig an das NATGW IPs weitergeleitet wird.
Da Sie ein Transit Gateway verwenden, können wir hier die Firewall vor dem NAT-Gateway platzieren. In diesem Modell kann die Firewall die Quell-IP hinter dem Transit Gateway erkennen.
Wenn Sie dies in einer einzelnen VPC getan haben, können wir die VPC-Routing-Verbesserungen verwenden, mit denen Sie den Verkehr zwischen Subnetzen in derselben VPC überprüfen können. Einzelheiten finden Sie im Blogbeitrag [Deployment Models for AWS Network Firewall with VPC Routing Enhancements](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/).
## Skalierbarkeit
AWS Network Firewall kann die Firewall-Kapazität je nach Verkehrslast automatisch nach oben oder unten skalieren, um eine konstante, vorhersehbare Leistung aufrechtzuerhalten und so die Kosten zu minimieren. AWS Network Firewall ist für die Unterstützung von Zehntausenden von Firewallregeln konzipiert und kann einen Durchsatz von bis zu 100 Gbit/s pro Availability Zone skalieren.
## Wesentliche Überlegungen
+ Jeder Firewall-Endpunkt kann etwa 100 Gbit/s Datenverkehr verarbeiten. Wenn Sie einen höheren Burst- oder Dauerdurchsatz benötigen, wenden Sie sich an den [AWS-Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html).
+ Wenn Sie sich dafür entscheiden, in Ihrem AWS-Konto zusammen mit der Network Firewall ein NAT-Gateway zu erstellen, werden die standardmäßigen [Gebühren](https://aws.amazon.com/network-firewall/pricing/) für die NAT-Gateway-Verarbeitung und die Nutzung pro Stunde erlassen, je nachdem, wie die Verarbeitung pro GB und die Nutzungsstunden für Ihre Firewall berechnet werden. one-to-one
+ Sie können auch verteilte Firewall-Endpunkte AWS Firewall Manager ohne Transit Gateway in Betracht ziehen.
+ Testen Sie Firewallregeln, bevor Sie sie in die Produktionsumgebung überführen, ähnlich wie bei einer Netzwerkzugriffskontrollliste, da die Reihenfolge wichtig ist.
+ Für eine genauere Prüfung sind erweiterte Suricata-Regeln erforderlich. Die Netzwerk-Firewall unterstützt die Überprüfung des verschlüsselten Datenverkehrs sowohl für eingehenden als auch für ausgehenden Datenverkehr.
+ Die `HOME_NET` Regelgruppenvariable definierte den Quell-IP-Bereich, der für die Verarbeitung in der Stateful Engine in Frage kommt. Bei einem zentralisierten Ansatz müssen Sie alle zusätzlichen VPC hinzufügen, die an das Transit Gateway CIDRs angeschlossen sind, damit sie verarbeitet werden können. Weitere Informationen zur `HOME_NET` Regelgruppenvariablen finden Sie in der [Dokumentation zur Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html).
+ Erwägen Sie die Bereitstellung von Transit Gateway und ausgehender VPC in einem separaten Netzwerkdienstkonto, um den Zugriff auf der Grundlage der Delegierung von Aufgaben zu trennen. Beispielsweise können nur Netzwerkadministratoren auf das Network Services-Konto zugreifen.
+ Um die Bereitstellung und Verwaltung von AWS Network Firewall zu vereinfachen, AWS Firewall Manager kann dieses Modell verwendet werden. Mit Firewall Manager können Sie Ihre verschiedenen Firewalls zentral verwalten, indem der Schutz, den Sie am zentralen Ort erstellt haben, automatisch auf mehrere Konten angewendet wird. Firewall Manager unterstützt sowohl verteilte als auch zentralisierte Bereitstellungsmodelle für Network Firewall. Weitere Informationen finden Sie im Blogbeitrag [How to deploy AWS Network Firewall by using AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/).
# Verwenden des NAT-Gateways und des Gateway Load Balancer mit Amazon EC2 EC2-Instances für den zentralisierten Ausgang IPv4
Die Verwendung einer softwarebasierten virtuellen Appliance (auf Amazon EC2) von AWS Marketplace und AWS Partner Network als Ausgangspunkt ähnelt dem NAT-Gateway-Setup. Diese Option kann verwendet werden, wenn Sie die erweiterten Layer-7- und Deep-Packet-Inspection-Funktionen der verschiedenen Anbieter nutzen möchten. rewall/Intrusion Prevention/Detection System (IPS/IDS
In der folgenden Abbildung stellen Sie zusätzlich zum NAT-Gateway virtuelle Appliances mithilfe von EC2-Instances hinter einem Gateway Load Balancer (GWLB) bereit. In diesem Setup werden GWLB, Gateway Load Balancer Endpoint (GWLBE), virtuelle Appliances und NAT-Gateways in einer zentralen VPC bereitgestellt, die über eine VPC-Verbindung mit dem Transit Gateway verbunden ist. Die Spokes VPCs sind auch über einen VPC-Anhang mit dem Transit Gateway verbunden. Da GWLBEs es sich um ein routingfähiges Ziel handelt, können Sie den Datenverkehr, der zu und vom Transit Gateway fließt, zur Flotte virtueller Appliances weiterleiten, die als Ziele hinter einem GWLB konfiguriert sind. GWLB fungiert als bump-in-the-wire und leitet den gesamten Layer-3-Verkehr transparent über virtuelle Appliances von Drittanbietern weiter und ist somit für Quelle und Ziel des Datenverkehrs unsichtbar. Daher ermöglicht Ihnen diese Architektur, Ihren gesamten ausgehenden Verkehr, der über Transit Gateway fließt, zentral zu überprüfen.
Weitere Informationen darüber, wie der Datenverkehr durch dieses Setup von den Anwendungen in das VPCs Internet und zurück fließt, finden Sie unter [Centralized Inspection Architecture with AWS Gateway Load Balancer und AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/).
Sie können den Appliance-Modus auf dem Transit Gateway aktivieren, um die Flusssymetrie durch virtuelle Appliances aufrechtzuerhalten. Das bedeutet, dass der bidirektionale Verkehr während der gesamten Lebensdauer des Datenflusses über dieselbe Appliance und die Availability Zone geleitet wird. Diese Einstellung ist besonders wichtig für Stateful-Firewalls, die Deep Packet Inspection durchführen. Durch die Aktivierung des Appliance-Modus sind keine komplexen Behelfslösungen mehr erforderlich, wie z. B. die Übersetzung von Quellnetzadressen (Source Network Address Translation, SNAT), um den Datenverkehr zur korrekten Appliance zurückzukehren, um die Symmetrie aufrechtzuerhalten. Einzelheiten finden Sie unter [Bewährte Methoden für die Bereitstellung von Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/).
Es ist auch möglich, GWLB-Endpunkte verteilt ohne Transit Gateway bereitzustellen, um die Ausgangsinspektion zu ermöglichen. Weitere Informationen zu diesem Architekturmuster finden Sie im Blogbeitrag [Introducing AWS Gateway Load Balancer: Unterstützte Architekturmuster](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/).
![\[Ein Diagramm, das den zentralisierten Ausgang mit Gateway Load Balancer und EC2-Instance darstellt (Routentabellendesign)\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-gwlb-and-ec2.png)
## Hohe Verfügbarkeit
AWS empfiehlt für eine höhere Verfügbarkeit den Einsatz von Gateway Load Balancers und virtuellen Appliances in mehreren Availability Zones.
Gateway Load Balancer kann Integritätsprüfungen durchführen, um Ausfälle virtueller Appliances zu erkennen. Im Falle einer fehlerhaften Appliance leitet GWLB die neuen Datenflüsse an fehlerfreie Appliances weiter. Bestehende Datenflüsse werden unabhängig vom Status des Ziels immer an dasselbe Ziel weitergeleitet. Auf diese Weise können Verbindungen verloren gehen und Fehler bei der Integritätsprüfung aufgrund von CPU-Spitzen auf Appliances ausgeglichen werden. Weitere Informationen finden Sie in Abschnitt 4: Grundlegendes zu Ausfallszenarien für Appliances und Availability Zones im Blogbeitrag [Bewährte Methoden für die Bereitstellung von Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/). Gateway Load Balancer kann Auto Scaling-Gruppen als Ziele verwenden. Dieser Vorteil macht die Verwaltung der Verfügbarkeit und Skalierbarkeit der Appliance-Flotten überflüssig.
## Vorteile
Gateway Load Balancer und Gateway Load Balancer werden mit Strom versorgt AWS PrivateLink, was den sicheren Austausch von Datenverkehr über VPC-Grenzen hinweg ermöglicht, ohne dass das öffentliche Internet durchquert werden muss.
Gateway Load Balancer ist ein verwalteter Service, der die undifferenzierte Schwerstarbeit bei der Verwaltung, Bereitstellung und Skalierung virtueller Sicherheitsanwendungen überflüssig macht, sodass Sie sich auf die wichtigen Dinge konzentrieren können. Gateway Load Balancer kann den Firewall-Stapel als Endpunktdienst bereitstellen, den Kunden über den abonnieren können. [AWS Marketplace](https://aws.amazon.com/marketplace) Dies wird als Firewall as a Service (FWaaS) bezeichnet. Es ermöglicht eine vereinfachte Bereitstellung und macht es überflüssig, sich bei der Verteilung des Datenverkehrs auf mehrere Amazon EC2-Instances auf BGP und ECMP zu verlassen.
## Wesentliche Überlegungen
+ Die Appliances müssen das [Geneve](https://datatracker.ietf.org/doc/html/rfc8926) Encapsulation Protocol unterstützen, um in GWLB integriert werden zu können.
+ Einige Appliances von Drittanbietern können SNAT und Overlay-Routing ([Two-Arm-Modus](https://networkgeekstuff.com/networking/basic-load-balancer-scenarios-explained/)) unterstützen, sodass aus Kostengründen keine NAT-Gateways erstellt werden müssen. Wenden Sie sich jedoch an einen AWS-Partner Ihrer Wahl, bevor Sie diesen Modus verwenden, da dies vom Support und der Implementierung des Anbieters abhängt.
+ Notieren Sie sich das [GWLB-Leerlauf-Timeout](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#idle-timeout). Dies kann zu Verbindungs-Timeouts auf Clients führen. Sie können Ihre Timeouts auf Client-, Server-, Firewall- und Betriebssystemebene anpassen, um dies zu vermeiden. Weitere Informationen finden Sie in *Abschnitt 1: Optimieren von TCP-Keep-Alive- oder Timeout-Werten zur Unterstützung langlebiger TCP-Flüsse im Blogbeitrag* [Bewährte Methoden für die Bereitstellung von Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/).
+ GWLBE werden von betrieben, daher fallen Gebühren an. AWS PrivateLink AWS PrivateLink Weitere Informationen finden Sie auf der Seite mit den [AWS PrivateLink Preisen](https://aws.amazon.com/privatelink/pricing/). Wenn Sie das zentralisierte Modell mit Transit Gateway verwenden, fallen die TGW-Datenverarbeitungsgebühren an.
+ Erwägen Sie die Bereitstellung von Transit Gateway und ausgehender VPC in einem separaten Netzwerkdienstkonto, um den Zugriff auf der Grundlage der Delegierung von Aufgaben zu trennen, z. B. können nur Netzwerkadministratoren auf das Netzwerkdienstkonto zugreifen.
# Zentralisierter Ausgang für IPv6
Um IPv6 ausgehenden Datenverkehr in Dual-Stack-Bereitstellungen mit zentralisiertem IPv4 Ausgang zu unterstützen, muss eines von zwei Mustern ausgewählt werden:
+ Zentralisierter Ausgang mit dezentralisiertem IPv4 Ausgang IPv6
+ Zentralisierter Ausgang und IPv4 zentralisierter Ausgang IPv6
Im ersten Muster, das in der folgenden Abbildung dargestellt ist, werden Internet-Gateways nur für ausgehenden Datenverkehr in jeder Spoke-VPC bereitgestellt. Internet-Gateways nur für ausgehenden Datenverkehr sind horizontal skalierte, redundante und hochverfügbare Gateways, die ausgehende Kommunikation von Instances innerhalb Ihrer VPC aus ermöglichen. IPv6 Sie verhindern, dass das Internet Verbindungen zu Ihren Instances aufbaut. IPv6 Internet-Gateways, die nur für ausgehende Verbindungen genutzt werden, sind kostenlos. In diesem Bereitstellungsmodell fließt der IPv6 Datenverkehr von den Internet-Gateways für ausgehenden Datenverkehr in jeder VPC und der IPv4 Datenverkehr über die bereitgestellten zentralisierten NAT-Gateways.
![\[Ein Diagramm, das den zentralen Ausgang und den dezentralen IPV4 , nur ausgehenden Ausgang darstellt. IPv6\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-egress-and-decentralized-outbound-ipv6.png)
Im zweiten Muster, das in den folgenden Diagrammen dargestellt ist, wird ausgehender IPv6 Datenverkehr von Ihren Instances an eine zentrale VPC gesendet. Dies kann durch die Verwendung von IPv6 -to- IPv6 Network Prefix Translation (NPTv6) mit NAT66 Instances und NAT-Gateways oder durch die Verwendung von Proxy-Instances und Network Load Balancer erreicht werden. Dieses Muster ist anwendbar, wenn eine zentrale Verkehrsinspektion für ausgehenden Datenverkehr erforderlich ist und sie nicht in jeder Spoke-VPC durchgeführt werden kann.
![\[Ein Diagramm, das den zentralisierten IPv6 Ausgang mithilfe von NAT-Gateways und -Instanzen darstellt. NAT66\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv6-egress-using-nat-gateways.png)
![\[Ein Diagramm, das zentralisierte Instanzen IPv4 und ausgehende Verbindungen mithilfe von IPv6 Proxyinstanzen und Network Load Balancer darstellt.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-and-ipv6-egress.png)
Das [IPv6 OnAWS-Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/advanced-dual-stack-and-ipv6-only-network-designs.html) beschreibt die zentralisierten IPv6 Ausgangsmuster. Die IPv6 Ausgangsmuster werden im Blog [Zentralisierter ausgehender Internetverkehr für Dual-Stack-Verbindungen ausführlicher behandelt IPv4 und](https://aws.amazon.com/blogs/networking-and-content-delivery/centralizing-outbound-internet-traffic-for-dual-stack-ipv4-and-ipv6-vpcs/) zusammen mit speziellen Überlegungen IPv6 VPCs, Musterlösungen und Diagrammen vorgestellt.