

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.

# VPC-zu-VPC-Konnektivität
<a name="vpc-to-vpc-connectivity"></a>

Kunden können zwei verschiedene VPC-Konnektivitätsmuster verwenden, um Multi-VPC-Umgebungen einzurichten: *Viele-zu-Many oder *Hub-and-Spoke-Umgebungen**. Bei diesem many-to-many Ansatz wird der Verkehr zwischen jeder VPC individuell zwischen jeder VPC verwaltet. In dem hub-and-spoke Modell fließt der gesamte Datenverkehr zwischen VPC über eine zentrale Ressource, die den Verkehr auf der Grundlage festgelegter Regeln weiterleitet. 

# VPC-Peering
<a name="vpc-peering"></a>

Die erste Möglichkeit, zwei zu verbinden, VPCs ist die Verwendung von VPC-Peering. In diesem Setup ermöglicht eine Verbindung die vollständige bidirektionale Konnektivität zwischen den. VPCs Diese Peering-Verbindung wird verwendet, um den Verkehr zwischen den weiterzuleiten. VPCs VPCs in verschiedenen Konten und AWS-Regionen können auch miteinander verbunden werden. Jegliche Datenübertragung über eine VPC-Peering-Verbindung, die innerhalb einer Availability Zone bleibt, ist kostenlos. Alle Datenübertragungen über eine VPC-Peering-Verbindung, die Availability Zones durchquert, werden zu den standardmäßigen regionalen Datenübertragungstarifen berechnet. Bei regionenübergreifendem VPCs Peering fallen die standardmäßigen Gebühren für die Datenübertragung zwischen den Regionen an.

 VPC-Peering ist point-to-point Konnektivität und unterstützt kein [transitives](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#transitive-peering) Routing. Wenn Sie beispielsweise eine [VPC-Peering-Verbindung zwischen VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) A und VPC B sowie zwischen VPC A und VPC C haben, kann eine Instance in VPC B nicht über VPC A zu VPC C gelangen. Um Pakete zwischen VPC B und VPC C weiterzuleiten, müssen Sie eine direkte VPC-Peering-Verbindung herstellen. 

Im großen Maßstab, wenn Sie Dutzende oder Hunderte von Peering-Verbindungen haben VPCs, kann die Verbindung dieser Verbindungen mit Peering zu einem Netz von Hunderten oder Tausenden von Peering-Verbindungen führen. Eine große Anzahl von Verbindungen kann schwierig zu verwalten und zu skalieren sein. Wenn Sie beispielsweise 100 haben VPCs und ein vollständiges Mesh-Peering zwischen ihnen einrichten möchten, werden 4.950 Peering-Verbindungen [`n(n-1)/2`] benötigt, wobei `n` die Gesamtzahl von. VPCs Es gibt ein [maximales Limit](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html) von 125 aktiven Peering-Verbindungen pro VPC.

![\[Ein Diagramm, das die Netzwerkeinrichtung mithilfe von VPC-Peering darstellt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/network-setup-vpc-peering.png)


Wenn Sie VPC-Peering verwenden, muss zu jeder VPC eine lokale Konnektivität (VPN und/oder Direct Connect) hergestellt werden. Ressourcen in einer VPC können mithilfe der Hybridkonnektivität einer Peer-VPC nicht lokal erreicht werden, wie in der vorherigen Abbildung dargestellt. 

 VPC-Peering eignet sich am besten, wenn Ressourcen in einer VPC mit Ressourcen in einer anderen VPC kommunizieren müssen, die Umgebung beider VPC kontrolliert und gesichert VPCs wird und die Anzahl der VPCs zu verbindenden Ressourcen weniger als 10 beträgt (um die individuelle Verwaltung jeder Verbindung zu ermöglichen). VPC-Peering bietet im Vergleich zu anderen Optionen für VPC-Inter-Konnektivität die niedrigsten Gesamtkosten und die höchste Gesamtleistung. 

# AWS Transit Gateway 
<a name="transit-gateway"></a>

 [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)bietet ein Hub-and-Spoke-Design für Verbindungen VPCs und lokale Netzwerke als vollständig verwalteten Service, ohne dass Sie virtuelle Appliances von Drittanbietern bereitstellen müssen. Es ist kein VPN-Overlay erforderlich und sorgt für hohe AWS Verfügbarkeit und Skalierbarkeit. 

 Mit Transit Gateway können Kunden Tausende von verbinden VPCs. Sie können Ihre gesamte Hybridkonnektivität (VPN- und Direct Connect-Verbindungen) an ein einziges Gateway anschließen und so die gesamte AWS Routing-Konfiguration Ihres Unternehmens an einem Ort konsolidieren und steuern (siehe folgende Abbildung). Transit Gateway steuert mithilfe von Routentabellen, wie der Verkehr zwischen allen verbundenen Spoke-Netzwerken weitergeleitet wird. Dieses hub-and-spoke Modell vereinfacht die Verwaltung und senkt die Betriebskosten, da VPCs nur eine Verbindung zur Transit Gateway Gateway-Instanz hergestellt wird, um Zugriff auf die verbundenen Netzwerke zu erhalten. 

![\[Ein Diagramm, das das Design von Nabe und Speiche mit darstellt AWS Transit Gateway\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/hub-and-spoke-design.png)


Transit Gateway ist eine regionale Ressource und kann Tausende von VPCs innerhalb derselben verbinden AWS-Region. Sie können mehrere Gateways über eine einzige Direct Connect-Verbindung für Hybridkonnektivität verbinden. In der Regel können Sie nur eine Transit Gateway Gateway-Instanz verwenden, die alle Ihre VPC-Instances in einer bestimmten Region verbindet, und Transit Gateway Gateway-Routing-Tabellen verwenden, um sie bei Bedarf zu isolieren. Beachten Sie, dass Sie für eine hohe Verfügbarkeit keine zusätzlichen Transit-Gateways benötigen, da Transit-Gateways von Haus aus hochverfügbar sind. Verwenden Sie aus Redundanzgründen ein einziges Gateway in jeder Region. Es gibt jedoch triftige Argumente für die Einrichtung mehrerer Gateways, um Fehlkonfigurationen, den Explosionsradius zu begrenzen, den Betrieb der Steuerungsebene zu trennen und die Verwaltung zu verwalten. ease-of-use

Mit Transit Gateway Gateway-Peering können Kunden ihre Transit Gateway-Instanzen innerhalb derselben oder mehrerer Regionen miteinander verbinden und den Verkehr zwischen ihnen weiterleiten. Es verwendet dieselbe zugrunde liegende Infrastruktur wie VPC-Peering und ist daher verschlüsselt. Weitere Informationen finden Sie unter [Aufbau eines globalen Netzwerks mit AWS Transit Gateway Inter-Region Peering](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-global-network-using-aws-transit-gateway-inter-region-peering/) und [AWS Transit Gateway unterstützt jetzt Intra-Region](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-transit-gateway-now-supports-intra-region-peering/) Peering.

 Platzieren Sie die Transit Gateway Gateway-Instanz Ihrer Organisation in ihrem Network Services-Konto. Dies ermöglicht eine zentrale Verwaltung durch Netzwerktechniker, die das Netzwerkdienstkonto verwalten. Verwenden Sie AWS Resource Access Manager (RAM), um eine Transit Gateway Gateway-Instance gemeinsam zu nutzen, um Verbindungen VPCs zwischen mehreren Konten in Ihrer AWS-Organisation innerhalb derselben Region herzustellen.AWS RAM ermöglicht Ihnen die einfache und sichere gemeinsame AWS Nutzung von Ressourcen mit beliebigen AWS-Konto oder innerhalb Ihrer AWS-Organisation. Weitere Informationen finden Sie im Blogbeitrag [Automating AWS Transit Gateway Attachments to a Transit Gateway in a central account](https://aws.amazon.com/blogs/networking-and-content-delivery/automating-aws-transit-gateway-attachments-to-a-transit-gateway-in-a-central-account/). 

Mit Transit Gateway können Sie auch Konnektivität zwischen der SD-WAN-Infrastruktur und der AWS Verwendung von Transit Gateway Connect herstellen. Verwenden Sie einen Transit Gateway Connect-Anhang mit Border Gateway Protocol (BGP) für dynamisches Routing und das GRE (Generic Routing Encapsulation) -Tunnelprotokoll für hohe Leistung mit einer Gesamtbandbreite von bis zu 20 Gbit/s pro Connect-Anhang (bis zu vier Transit Gateway Connect-Peers pro Connect-Anhang). Mithilfe von Transit Gateway Connect können Sie sowohl die lokale SD-WAN-Infrastruktur als auch SD-WAN-Appliances, die in der Cloud ausgeführt werden, über einen VPC-Anhang oder Direct Connect -Anhang als zugrunde liegende Transportschicht integrieren. Referenzarchitekturen und eine detaillierte Konfiguration finden Sie unter [Vereinfachen der SD-WAN-Konnektivität mit AWS Transit Gateway Connect](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/). 

# Transit VPC-Lösung
<a name="transit-vpc-solution"></a>

 [Transit VPCs](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) kann Konnektivität zwischen beiden auf andere Weise als VPCs durch VPC-Peering herstellen, indem ein Hub-and-Spoke-Design für Inter-VPC-Konnektivität eingeführt wird. In einem Transit-VPC-Netzwerk verbindet sich eine zentrale VPC (die Hub-VPC) mit jeder anderen VPC (Spoke-VPC) über eine VPN-Verbindung, die in der Regel BGP nutzt. [IPsec](https://en.wikipedia.org/wiki/IPsec) Die zentrale VPC enthält [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2) -Instances, auf denen Software-Appliances ausgeführt werden, die eingehenden Datenverkehr mithilfe des VPN-Overlays an ihre Ziele weiterleiten. Transit-VPC-Peering bietet die folgenden Vorteile: 
+  Transitives Routing wird mithilfe des Overlay-VPN-Netzwerks aktiviert, was ein Hub-and-Spoke-Design ermöglicht. 
+  Bei Verwendung von Drittanbietersoftware auf der EC2 Instance in der Hub-Transit-VPC VPC die Funktionen des Anbieters rund um erweiterte Sicherheit (Layer firewall/Intrusion Prevention System (IPS)/Intrusion Detection System (IDS) ) can be used. If customers are using the same software on-premises, they benefit from a unified operational/monitoring 7-Erfahrung) zur Verfügung. 
+ Die Transit VPC-Architektur ermöglicht Konnektivität, die in einigen Anwendungsfällen gewünscht sein kann. Sie können beispielsweise eine GovCloud AWS-Instance und eine Commercial Region-VPC oder eine Transit Gateway Gateway-Instance mit einer Transit-VPC verbinden und die VPC-Inter-Konnektivität zwischen den beiden Regionen aktivieren. Bewerten Sie Ihre Sicherheits- und Compliance-Anforderungen, wenn Sie diese Option in Betracht ziehen. Für zusätzliche Sicherheit können Sie ein zentralisiertes Inspektionsmodell einsetzen, das auf Entwurfsmustern basiert, die weiter unten in diesem Whitepaper beschrieben werden. 

![\[Ein Diagramm, das eine Transit-VPC mit virtuellen Appliances darstellt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/transit-vpc-virtual-appliances.png)


Transit VPC bringt seine eigenen Herausforderungen mit sich, wie z. B. höhere Kosten für den Betrieb virtueller Appliances von Drittanbietern, je EC2 nach Instanzgröße/Familie, begrenzter Durchsatz pro VPN-Verbindung (bis zu 1,25 Gbit/s pro VPN-Tunnel) und zusätzlicher Aufwand für Konfiguration, Management und Ausfallsicherheit (Kunden sind für die Verwaltung der HA und Redundanz der Instanzen verantwortlich, auf denen virtuelle Appliances von Drittanbietern ausgeführt werden). EC2

## VPC-Peering im Vergleich zu Transit VPC im Vergleich zu Transit Gateway
<a name="peering-vs"></a>

*Tabelle 1 — Vergleich der Konnektivität*


| Kriterien  | VPC-Peering  | Transit-VPC | Transit-Gateway | PrivateLink | Cloud-WAN | VPC Lattice | 
| --- | --- | --- | --- | --- | --- | --- | 
|  Scope   | Regional/Global | Regional  | Regional  | Regional | Global | Regional | 
| Architektur | Vollmaschiges Netz | VPN-basiert hub-and-spoke | Basiert auf Anhängen hub-and-spoke | Anbieter- oder Verbrauchermodell | Basierend auf Anhängen, regionsübergreifend | Konnektivität von App zu App | 
|  Skalieren   | 125 aktive Peer/VPC  | Hängt vom virtuellen Router/ ab EC2  | 5000 Anlagen pro Region  | Keine Grenzen | 5000 Anhänge pro Kernnetzwerk | 500 VPC-Zuordnungen pro Dienst | 
|  Segmentierung   | Sicherheitsgruppen  | Vom Kunden verwaltet  | Transit Gateway Gateway-Routentabellen  | Keine Segmentierung | Segmente | Service- und Servicenetzwerkrichtlinien | 
|  Latency   | Am niedrigsten  | Zusätzlich, aufgrund des Overheads bei der VPN-Verschlüsselung  | Zusätzlicher Transit Gateway Gateway-Hop  | Der Datenverkehr bleibt auf dem AWS-Backbone, Kunden sollten es testen | Verwendet dieselbe Datenebene wie Transit Gateway | Der Datenverkehr bleibt auf dem AWS-Backbone, Kunden sollten es testen | 
|  Bandbreitenbegrenzung   | Limits pro Instanz, kein Gesamtlimit  | Vorbehaltlich der Bandbreitenbeschränkungen der EC2 Instanz je nach Größe/Familie  | Bis zu 100 Gbit/s (Burst) /Verbindung  | 10 Gbit/s pro Availability Zone, automatische Skalierung auf bis zu 100 Gbit/s | Bis zu 100 Gbit/s (Burst) /Verbindung | 10 Gbit/s pro Availability Zone | 
|  Sichtbarkeit   | VPC Flow Logs  | VPC-Flow-Logs und -Metriken CloudWatch  | Transit Gateway Network Manager, VPC-Flussprotokolle, Metriken CloudWatch  | CloudWatch Metriken  | Netzwerkmanager, VPC-Flussprotokolle, Metriken CloudWatch  | CloudWatch Zugriffsprotokolle | 
|  Sicherheitsgruppe  Querverweise   | Unterstützt  | Nicht unterstützt  | Nicht unterstützt  | Nicht unterstützt | Nicht unterstützt | Nicht zutreffend | 
| IPv6 Unterstützung  | Unterstützt | Hängt von der virtuellen Appliance ab  | Unterstützt | Unterstützt | Unterstützt | Unterstützt | 

# AWS PrivateLink
<a name="aws-privatelink"></a>

[AWS PrivateLink](https://aws.amazon.com/privatelink/)bietet private Konnektivität zwischen VPCs AWS-Services und Ihren lokalen Netzwerken, ohne dass Ihr Datenverkehr dem öffentlichen Internet ausgesetzt wird. Interface-VPC-Endpoints, powered by AWS PrivateLink, machen es einfach, Verbindungen zu AWS und anderen Diensten über verschiedene Konten hinweg herzustellen und Ihre Netzwerkarchitektur erheblich VPCs zu vereinfachen. Auf diese Weise können Kunden, die möglicherweise einen Service oder eine Anwendung, die sich in einer VPC (Service Provider) befindet, privat einer AWS-Region anderen VPCs (Consumer) zugänglich machen möchten, und zwar so, dass nur der Verbraucher Verbindungen zur Service Provider-VPC VPCs initiiert. Ein Beispiel hierfür ist die Möglichkeit, dass Ihre privaten Anwendungen auf den Dienstanbieter zugreifen können. APIs

 Erstellen Sie zur Verwendung AWS PrivateLink einen Network Load Balancer für Ihre Anwendung in Ihrer VPC und eine VPC-Endpunktdienstkonfiguration, die auf diesen Load Balancer verweist. Ein Service-Consumer erstellt dann einen Schnittstellen-Endpunkt zu Ihrem Service. Dadurch wird ein elastic network interface (ENI) im Consumer-Subnetz mit einer privaten IP-Adresse erstellt, die als Einstiegspunkt für den Datenverkehr dient, der für den Service bestimmt ist. Der Verbraucher und der Service müssen sich nicht in derselben VPC befinden. Wenn die VPC unterschiedlich ist, VPCs können der Verbraucher und der Dienstanbieter überlappende IP-Adressbereiche haben. Sie können nicht nur den VPC-Schnittstellen-Endpunkt für den Zugriff auf Services in anderen erstellen VPCs, sondern auch Schnittstellen-VPC-Endpunkte erstellen, über die Sie privat auf [unterstützte AWS-Services](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) zugreifen können AWS PrivateLink, wie in der folgenden Abbildung dargestellt. 

Mit Application Load Balancer (ALB) als Ziel von NLB können Sie jetzt erweiterte ALB-Routing-Funktionen mit kombinieren. AWS PrivateLink Referenzarchitekturen und eine detaillierte Konfiguration finden Sie unter [Application Load Balancer Balancer-type Target Group for Network Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/).

![\[Ein Diagramm AWS PrivateLink zur Darstellung der Konnektivität zu anderen VPCs und AWS-Services\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/aws-privatelink.png)


 Die Wahl zwischen Transit Gateway, VPC-Peering und hängt von AWS PrivateLink der Konnektivität ab. 
+  **AWS PrivateLink**— Verwenden Sie diese Option, AWS PrivateLink wenn Sie einen Client/Server eingerichtet haben, auf dem Sie einem oder mehreren Verbrauchern VPCs unidirektionalen Zugriff auf einen bestimmten Dienst oder eine Gruppe von Instanzen in der Service Provider-VPC oder auf bestimmte Dienste gewähren möchten. AWS Nur die Clients mit Zugriff in der Consumer-VPC können eine Verbindung zum Service in der Service Provider-VPC oder AWS im Service initiieren. Dies ist auch eine gute Option, wenn sich die IP-Adressen der Clients und Server der beiden VPCs überschneiden, da die AWS PrivateLink Verwendung ENIs innerhalb der Client-VPC so erfolgt, dass keine IP-Konflikte mit dem Dienstanbieter auftreten. Sie können über VPC-Peering, VPN, Transit Gateway, Cloud WAN und auf AWS PrivateLink Endpunkte zugreifen. AWS Direct Connect
+  **VPC-Peering und Transit Gateway** — Verwenden Sie VPC-Peering und Transit Gateway, wenn Sie Layer-3-IP-Konnektivität zwischen aktivieren möchten. VPCs 

  Ihre Architektur wird eine Mischung dieser Technologien enthalten, um unterschiedliche Anwendungsfälle zu erfüllen. All diese Dienste können kombiniert und miteinander betrieben werden. Zum Beispiel die AWS PrivateLink Handhabung von Client-Server-Konnektivität im API-Stil, VPC-Peering zur Erfüllung direkter Konnektivitätsanforderungen, bei denen Platzierungsgruppen innerhalb der Region oder regionsübergreifende Konnektivität erforderlich sind, und Transit Gateway zur Vereinfachung der Konnektivität VPCs im großen Maßstab sowie Edge-Konsolidierung für Hybridkonnektivität. 

# VPC-Freigabe
<a name="amazon-vpc-sharing"></a>

 VPCs Die gemeinsame Nutzung ist nützlich, wenn die Netzwerkisolierung zwischen Teams nicht strikt vom VPC-Besitzer verwaltet werden muss, sondern die Benutzer und Berechtigungen auf Kontoebene. Mit [Shared VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) erstellen mehrere AWS-Konten ihre Anwendungsressourcen (wie EC2 Amazon-Instances) in gemeinsam genutztem, zentral verwaltetem Amazon VPCs. In diesem Modell teilt sich das Konto, dem die VPC gehört (Besitzer), ein oder mehrere Subnetze mit anderen Konten (Teilnehmern). Wenn ein Subnetz freigegeben wurde, können die Teilnehmer ihre Anwendungsressourcen in den für sie freigegebenen Subnetzen anzeigen, erstellen, ändern oder löschen. Teilnehmer können keine Ressourcen anzeigen, ändern oder löschen, die anderen Teilnehmern oder dem VPC-Eigentümer gehören. Die Sicherheit zwischen gemeinsam genutzten Ressourcen VPCs wird mithilfe von Sicherheitsgruppen, Netzwerkzugriffskontrolllisten (NACLs) oder durch eine Firewall zwischen den Subnetzen verwaltet.

 Vorteile VPC VPC-Sharing: 
+  Vereinfachtes Design — keine Komplexität im Zusammenhang mit Inter-VPC-Konnektivität 
+  Weniger verwaltet VPCs 
+  Aufgabentrennung zwischen Netzwerkteams und Anwendungseigentümern 
+  Bessere IPv4 Adressnutzung 
+  Niedrigere Kosten — keine Datenübertragungsgebühren zwischen Instances, die zu unterschiedlichen Konten innerhalb derselben Availability Zone gehören 

**Anmerkung**  
 Wenn Sie ein Subnetz mit mehreren Konten gemeinsam nutzen, sollten Ihre Teilnehmer ein gewisses Maß an Kooperation haben, da sie IP-Bereich und Netzwerkressourcen gemeinsam nutzen. Bei Bedarf können Sie für jedes Teilnehmerkonto ein anderes Subnetz gemeinsam nutzen. Ein Subnetz pro Teilnehmer ermöglicht es Netzwerk-ACL, zusätzlich zu Sicherheitsgruppen auch Netzwerkisolierung bereitzustellen. 

 Die meisten Kundenarchitekturen werden mehrere enthalten VPCs, von denen viele mit zwei oder mehr Konten gemeinsam genutzt werden. Transit Gateway und VPC-Peering können verwendet werden, um die gemeinsam genutzten Geräte zu verbinden. VPCs Nehmen wir zum Beispiel an, Sie haben 10 Anwendungen. Jede Anwendung benötigt ein eigenes AWS-Konto. Die Apps können in zwei Anwendungsportfolios eingeteilt werden (Apps innerhalb desselben Portfolios haben ähnliche Netzwerkanforderungen, App 1—5 unter „Marketing“ und App 6—10 unter „Vertrieb“). 

 Sie können eine VPC pro Anwendungsportfolio haben ( VPCs insgesamt zwei), und die VPC wird mit den verschiedenen Anwendungsbesitzerkonten innerhalb dieses Portfolios gemeinsam genutzt. App-Besitzer stellen Apps in ihrer jeweiligen gemeinsam genutzten VPC bereit (in diesem Fall in den verschiedenen Subnetzen zur Segmentierung und Isolierung von Netzwerkrouten). NACLs Die beiden gemeinsam genutzten VPCs sind über das Transit Gateway verbunden. Mit diesem Setup könnten Sie von 10 auf nur zwei Verbindungen VPCs umsteigen, wie in der folgenden Abbildung dargestellt. 

![\[Ein Diagramm, das ein Beispiel-Setup für eine gemeinsam genutzte VPC darstellt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-shared-vpc.png)


**Anmerkung**  
 VPC-Sharing-Teilnehmer können nicht alle AWS-Ressourcen in einem gemeinsam genutzten Subnetz erstellen. Weitere Informationen finden Sie im Abschnitt [Einschränkungen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) in der Dokumentation zu VPC Sharing.   
Weitere Informationen zu den wichtigsten Überlegungen und bewährten Methoden für die gemeinsame Nutzung von VPC finden Sie im Blogbeitrag [VPC-Sharing: wichtige Überlegungen und bewährte Methoden](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-key-considerations-and-best-practices/).

# Privates NAT-Gateway
<a name="private-nat-gateway"></a>

Teams arbeiten oft unabhängig voneinander und erstellen möglicherweise eine neue VPC für ein Projekt, die möglicherweise überlappende CIDR-Blöcke (Classless Interdomain Routing) enthält. Für die Integration möchten sie möglicherweise die Kommunikation zwischen Netzwerken mit Überlappung ermöglichen CIDRs, was mit Funktionen wie VPC-Peering und Transit Gateway nicht erreicht werden kann. Ein privates NAT-Gateway kann bei diesem Anwendungsfall helfen. Ein privates NAT-Gateway verwendet eine eindeutige private IP-Adresse, um die Quell-NAT für die überlappende Quell-IP-Adresse durchzuführen, und ELB führt die Ziel-NAT für die überlappende Ziel-IP-Adresse durch. Mit Transit Gateway oder einem Virtual Private Gateway können Sie den Verkehr von Ihrem privaten NAT-Gateway zu anderen VPCs oder lokalen Netzwerken weiterleiten.



![\[Ein Diagramm, das eine Beispielkonfiguration für ein privates NAT-Gateway zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-private-nat-gateway.png)


Die vorherige Abbildung zeigt zwei nicht routbare (überlappende`100.64.0.0/16`) Subnetze in VPC A und B. Um eine Verbindung zwischen ihnen herzustellen CIDRs, können Sie sekundäre, sich nicht überschneidende/routbare CIDRs (routbare Subnetze und) zu VPC A bzw. B hinzufügen. `10.0.1.0/24` `10.0.2.0/24` Das Routing sollte von dem Netzwerkmanagementteam zugewiesen werden, das für die IP-Zuweisung verantwortlich ist. CIDRs Dem routbaren Subnetz in VPC A wird ein privates NAT-Gateway mit der IP-Adresse von hinzugefügt. `10.0.1.125` Das private NAT-Gateway führt die Übersetzung der Quellnetzwerkadresse für Anfragen von Instances im nicht routbaren Subnetz von VPC A (`100.64.0.10`) als `10.0.1.125` ENI des privaten NAT-Gateways durch. Jetzt kann der Verkehr auf eine routbare IP-Adresse gerichtet werden, die dem Application Load Balancer (ALB) in VPC B (`10.0.2.10`) zugewiesen ist und das Ziel hat. `100.64.0.10` Der Verkehr wird über Transit Gateway geleitet. Der Rückverkehr wird vom privaten NAT-Gateway zurück zur ursprünglichen EC2 Amazon-Instance verarbeitet, die die Verbindung anfordert.

Das private NAT-Gateway kann auch verwendet werden, wenn Ihr lokales Netzwerk den Zugriff auf genehmigt beschränkt. IPs Die lokalen Netzwerke einiger Kunden sind aufgrund gesetzlicher Vorschriften verpflichtet, nur mit privaten Netzwerken (kein IGW) über einen begrenzten zusammenhängenden Block von zugelassenen Netzwerken zu kommunizieren, der dem Kunden gehört. IPs Anstatt jeder Instanz eine separate IP vom Block zuzuweisen, können Sie mithilfe eines privaten NAT-Gateways große Workloads AWS VPCs hinter jeder IP auf der Zulassungsliste ausführen. Einzelheiten finden Sie im Blogbeitrag [How to solve Private IP exhaustion with Private](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/) NAT Solution.

![\[Ein Diagramm, das zeigt, wie ein privates NAT-Gateway verwendet wird, um ein IPs für den lokalen Betrieb zugelassenes Netzwerk bereitzustellen\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/how-to-use-nat.png)


# AWS Cloud-WAN
<a name="aws-cloud-wan"></a>

 AWS Cloud WAN ist eine neue Möglichkeit, Netzwerke miteinander zu verbinden, was wir zuvor mit Transit Gateways, VPC Peering und IPSEC-VPN-Tunneln tun konnten. Bisher mussten Sie eine oder mehrere konfigurieren VPCs, sie mit einer der vorherigen Methoden miteinander verbinden und IPSEC-VPN verwenden oder eine Verbindung Direct Connect zu lokalen Netzwerken herstellen. Sie würden Ihre Netzwerk- und Sicherheitsstrukturen an einer Stelle und Ihre Netzwerke an einer anderen Stelle definieren. Cloud WAN ermöglicht es Ihnen, all diese Konstrukte an einem einzigen Ort zu zentralisieren. Gemäß der Richtlinie können Sie Ihre Netzwerke segmentieren, um zu bestimmen, wer mit wem sprechen kann, und den Produktionsdatenverkehr über diese Segmente von Entwicklungs- oder Test-Workloads oder Ihren lokalen Netzwerken isolieren. 

![\[Ein Diagramm, das die AWS-Cloud-WAN-Konnektivität darstellt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/cloud-wan-diagram.png)


 Verwalten Sie Ihr globales Netzwerk über die AWS Network Manager-Benutzeroberfläche und APIs. Das globale Netzwerk ist der Container auf Stammebene für all Ihre Netzwerkobjekte. Das Kernnetzwerk ist der Teil Ihres globalen Netzwerks, der von AWS verwaltet wird. Eine Kernnetzwerkrichtlinie (CNP) ist ein einzelnes, versioniertes Richtliniendokument, das alle Aspekte Ihres Kernnetzwerks definiert. Anlagen sind alle Verbindungen oder Ressourcen, die Sie Ihrem Kernnetzwerk hinzufügen möchten. Ein Core Network Edge (CNE) ist ein lokaler Verbindungspunkt für Anlagen, die der Richtlinie entsprechen. Netzwerksegmente sind Routingdomänen, die standardmäßig nur die Kommunikation innerhalb eines Segments zulassen. 

 Um CloudWAN zu verwenden: 

1.  Erstellen Sie in AWS Network Manager ein globales Netzwerk und ein zugehöriges Kernnetzwerk. 

1.  Erstellen Sie ein CNP, das Segmente, den ASN-Bereich AWS-Regionen und Tags definiert, die zum Anhängen an Segmente verwendet werden sollen. 

1.  Wenden Sie die Netzwerkrichtlinie an. 

1.  Teilen Sie das Kernnetzwerk mithilfe des Resource Access Managers mit Ihren Benutzern, Konten oder Organisationen. 

1.  Anlagen erstellen und taggen. 

1.  Aktualisieren Sie die Routen in Ihrem Anhang VPCs , sodass sie das Kernnetzwerk einbeziehen. 

 Cloud WAN wurde entwickelt, um den Prozess der weltweiten Verbindung Ihrer AWS-Infrastruktur zu vereinfachen. Es ermöglicht Ihnen, den Datenverkehr mit einer zentralen Berechtigungsrichtlinie zu segmentieren und Ihre bestehende Infrastruktur an Ihren Unternehmensstandorten zu nutzen. Cloud WAN verbindet auch Ihre SD- VPCs, Client- WANs VPNs, Firewalls- und Rechenzentrumsressourcen VPNs, um eine Verbindung zum Cloud-WAN herzustellen. Weitere Informationen finden Sie in den [Blogbeiträgen zu AWS Cloud WAN](https://aws.amazon.com/blogs/networking-and-content-delivery/category/networking-content-delivery/aws-cloud-wan/). 

 AWS Cloud WAN ermöglicht ein einheitliches Netzwerk, das Cloud- und lokale Umgebungen verbindet. Unternehmen verwenden aus Sicherheitsgründen Firewalls der nächsten Generation (NGFWs) und Intrusion Prevention-Systeme (IPSs). Der Blogbeitrag [Migration und Interoperabilitätsmuster für AWS Cloud WAN und Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-cloud-wan-and-aws-transit-gateway-migration-and-interoperability-patterns/) beschreibt Architekturmuster für die zentrale Verwaltung und Inspektion des ausgehenden Netzwerkverkehrs in einem Cloud-WAN-Netzwerk, einschließlich Netzwerken mit einer Region und mehreren Regionen, und konfiguriert Routentabellen. Diese Architekturen stellen sicher, dass Daten und Anwendungen sicher bleiben und gleichzeitig eine sichere Cloud-Umgebung aufrechterhalten wird. 

 Weitere Informationen zu Cloud WAN finden Sie im Blogbeitrag [Centralized Outbound Inspection Architecture in AWS Cloud WAN](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-outbound-inspection-architecture-in-aws-cloud-wan/). 

# Amazon VPC Lattice
<a name="vpc-lattice"></a>

 Amazon VPC Lattice ist ein vollständig verwalteter Anwendungsnetzwerkservice, der verwendet wird, um Dienste über verschiedene Konten und virtuelle private Clouds hinweg zu verbinden, zu überwachen und zu sichern. VPC Lattice hilft dabei, Dienste innerhalb einer logischen Grenze miteinander zu verbinden, sodass Sie sie effizient verwalten und ermitteln können. 

 Die Komponenten von VPC Lattice bestehen aus: 
+  **Service** — Dies ist eine Anwendungseinheit, die auf einer Instanz, einem Container oder einer Lambda-Funktion ausgeführt wird und aus Listenern, Regeln und Zielgruppen besteht. 
+  **Servicenetzwerk** — Dies ist die logische Grenze, die verwendet wird, um die Serviceerkennung und Konnektivität automatisch zu implementieren und gemeinsame Zugriffs- und Beobachtbarkeitsrichtlinien auf eine Sammlung von Diensten anzuwenden. 
+  **Authentifizierungsrichtlinien — IAM-Ressourcenrichtlinien**, die einem Servicenetzwerk oder einzelnen Diensten zugeordnet werden können, um die Authentifizierung auf Anforderungsebene und die kontextspezifische Autorisierung zu unterstützen. 
+  **Serviceverzeichnis** — Eine zentrale Ansicht der Services, die Ihnen gehören oder die Ihnen über den AWS Resource Access Manager zur Verfügung gestellt wurden. 

 Schritte zur Verwendung von VPC Lattice: 

1.  Erstellen Sie das Servicenetzwerk. Das Dienstnetzwerk befindet sich normalerweise auf einem Netzwerkkonto, auf das ein Netzwerkadministrator vollen Zugriff hat. Das Servicenetzwerk kann von mehreren Konten innerhalb einer Organisation gemeinsam genutzt werden. Die gemeinsame Nutzung kann für einzelne Dienste oder für das gesamte Dienstkonto erfolgen. 

1.  Stellen Sie eine Verbindung VPCs zum Servicenetzwerk her, um Anwendungsnetzwerke für jede VPC zu aktivieren, sodass verschiedene Dienste andere Dienste nutzen können, die im Netzwerk registriert sind. Sicherheitsgruppen werden zur Steuerung des Datenverkehrs angewendet. 

1.  Entwickler definieren die Dienste, die in das Dienstverzeichnis aufgenommen und im Dienstnetzwerk registriert werden. VPC Lattice enthält das Adressbuch aller konfigurierten Dienste. Entwickler können auch Routing-Richtlinien definieren, um blaue/grüne Bereitstellungen zu verwenden. Die Sicherheit wird auf der Service-Netzwerkebene verwaltet, auf der Authentifizierungs- und Autorisierungsrichtlinien definiert werden, und auf der Service-Ebene, auf der Zugriffsrichtlinien mit IAM implementiert werden. 

![\[Ein Diagramm, das die Kommunikationsflüsse von VPC Lattice darstellt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/vpc-lattice.png)


 Weitere Informationen finden Sie im [VPC Lattice-Benutzerhandbuch](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html ). 