

# Planen der Netzwerktopologie
<a name="plan-your-network-topology"></a>

 Workloads existieren oft in mehreren Umgebungen. Dazu gehören mehrere Cloud-Umgebungen (sowohl öffentlich zugänglich als auch privat) und möglicherweise Ihre bestehende Rechenzentrumsinfrastruktur. Die Pläne müssen Netzwerkaspekte umfassen, wie z. B. Konnektivität innerhalb und zwischen Systemen, Verwaltung öffentlicher und privater IP-Adressen und Auflösung von Domainnamen. 

 Wenn Sie eine Architektur für Systeme entwickeln und dazu IP-Adressen-basierte Netzwerke verwenden, müssen Sie die Netzwerktopologie und Adresszuweisung mit Blick auf das künftige Wachstum und die Integration mit anderen Systemen und zugehörigen Netzwerken planen. 

 Mit Amazon Virtual Private Cloud (Amazon VPC) können Sie einen privaten, isolierten Teil der AWS-Cloud bereitstellen. Dort können Sie AWS-Ressourcen in einem virtuellen Netzwerk starten. 

**Topics**
+ [REL02-BP01 Bereitstellen einer hochverfügbaren Netzwerkkonnektivität für öffentliche Endpunkte der Workload](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Bereitstellen redundanter Konnektivität zwischen privaten Netzwerken in der Cloud und in On-Premises-Umgebungen](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Berücksichtigen von Erweiterungen und Verfügbarkeit bei der Zuweisung von IP-Adressen für Subnetze](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Vorziehen von Hub-and-Spoke-Topologien gegenüber M-zu-N-Netzen](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Erzwingen von sich nicht überschneidenden privaten IP-Adressbereichen in allen privaten Adressbereichen, in denen eine Verbindung besteht](rel_planning_network_topology_non_overlap_ip.md)

# REL02-BP01 Bereitstellen einer hochverfügbaren Netzwerkkonnektivität für öffentliche Endpunkte der Workload
<a name="rel_planning_network_topology_ha_conn_users"></a>

 Der Aufbau einer hochverfügbaren Netzwerkkonnektivität zu öffentlichen Endpunkten Ihres Workloads kann Ihnen helfen, Ausfallzeiten aufgrund von Konnektivitätsverlusten zu reduzieren und die Verfügbarkeit und SLA Ihres Workloads zu verbessern. Verwenden Sie dazu hochverfügbares DNS, Content Delivery Networks (CDNs), API-Gateways, Load-Balancing oder Reverse-Proxies. 

 **Gewünschtes Ergebnis:** Es ist von entscheidender Bedeutung, eine hochverfügbare Netzwerkkonnektivität für Ihre öffentlichen Endpunkte zu planen, aufzubauen und in Betrieb zu nehmen. Wenn Ihr Workload aufgrund eines Konnektivitätsverlustes nicht mehr erreichbar ist, sehen Ihre Kunden Ihr System als ausgefallen an – selbst wenn Ihr Workload läuft und verfügbar ist. Durch die Kombination einer hochverfügbaren und stabilen Netzwerkkonnektivität für die öffentlichen Endpunkte Ihres Workloads mit einer stabilen Architektur für Ihren Workload selbst können Sie Ihren Kunden die bestmögliche Verfügbarkeit und das bestmögliche Serviceniveau bieten. 

 AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, AWS Lambda-Funktions-URLs, AWS AppSync-APIs und Elastic Load Balancing (ELB) bieten alle hochverfügbare öffentliche Endpunkte. Amazon Route 53 bietet einen hochverfügbaren DNS-Service für die Auflösung von Domain-Namen, um sicherzustellen, dass die Adressen Ihrer öffentlichen Endpunkte aufgelöst werden können. 

 Sie können außerdem AWS Marketplace-Software-Appliances für das Load-Balancing und für Proxys nutzen. 

 **Typische Anti-Muster:** 
+ Entwurf eines hochverfügbaren Workloads, ohne eine DNS- und Netzwerkkonnektivität mit hoher Verfügbarkeit einzuplanen.
+  Verwendung öffentlicher Internetadressen auf einzelnen Instances oder Containern und Verwalten der Konnektivität zu diesen per DNS.
+  Verwendung von IP-Adressen anstelle von Domain-Namen zur Lokalisierung von Services.
+  Keine Tests von Szenarien, in denen die Konnektivität zu Ihren öffentlichen Endpunkten verloren geht. 
+  Keine Analyse des Bedarfs für den Netzwerkdurchsatz und die Verteilungsmuster im Netzwerk. 
+  Keine Tests und Planungen für Szenarien, in denen die Internet-Netzwerkkonnektivität zu Ihren öffentlichen Endpunkten der Workloads unterbrochen werden könnte. 
+  Bereitstellen von Inhalten (z. B. Webseiten, statische Komponenten oder Mediendateien) für ein großes geografisches Gebiet ohne Verwendung eines Content-Delivery-Networks. 
+  Keine Planung für Distributed Denial of Service (DDoS)-Angriffe. Bei DDoS-Angriffen besteht die Gefahr, dass der legitime Datenverkehr unterbrochen wird und die Verfügbarkeit für Ihre Benutzer sinkt. 

 **Vorteile der Nutzung dieser bewährten Methode:** Die Planung einer hochverfügbaren und stabilen Netzwerkkonnektivität stellt sicher, dass Ihr Workload für Ihre Benutzer zugreifbar und verfügbar ist. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Das Wichtigste beim Aufbau einer hochverfügbaren Netzwerkkonnektivität zu Ihren öffentlichen Endpunkten ist das Routing des Datenverkehrs. Um sicherzustellen, dass Ihr Datenverkehr die Endpunkte erreichen kann, muss das DNS in der Lage sein, die Domain-Namen in die entsprechenden IP-Adressen aufzulösen. Verwenden Sie ein hochverfügbares und skalierbares [Domain Name System (DNS)](https://aws.amazon.com/route53/what-is-dns/) wie Amazon Route 53, um die DNS-Einträge Ihrer Domäne zu verwalten. Sie können außerdem die von Amazon Route 53 bereitgestellten Zustandsprüfungen verwenden. Die Zustandsprüfungen überprüfen, ob Ihre Anwendung erreichbar, verfügbar und funktionstüchtig ist. Sie können so eingerichtet werden, dass sie das Verhalten Ihres Benutzers nachahmen, z. B. das Anfordern einer Webseite oder einer bestimmten URL. Im Falle eines Fehlers reagiert Amazon Route 53 auf DNS-Auflösungsanfragen und leitet den Datenverkehr nur an Health-Endpunkte weiter. Sie können außerdem die von Amazon Route 53 angebotenen Funktionen für Geo-DNS und latenzbasiertes Routing nutzen. 

 Um zu überprüfen, ob Ihr Workload selbst hochverfügbar ist, verwenden Sie Elastic Load Balancing (ELB). Amazon Route 53 kann verwendet werden, um den Datenverkehr an ELB zu leiten, das den Datenverkehr an die Ziel-Computing-Instances verteilt. Sie können Amazon API Gateway außerdem zusammen mit AWS Lambda für eine Serverless-Lösung verwenden. Kunden können Workloads zudem in mehreren AWS-Regionen ausführen. Mit einem [Multi-Site Aktiv/Aktiv-Muster](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) kann der Workload den Datenverkehr aus mehreren Regionen bedienen. Bei einem Multi-Site Aktiv/Passiv-Muster bedient der Workload den Datenverkehr aus der aktiven Region, während die Daten in die sekundäre Region repliziert werden, die im Falle eines Fehlers in der primären Region aktiv wird. Mit Amazon Route 53-Zustandsprüfungen können Sie dann das DNS-Failover von einem beliebigen Endpunkt in einer primären Region zu einem Endpunkt in einer sekundären Region steuern und so sicherstellen, dass Ihr Workload erreichbar und für Ihre Benutzer verfügbar ist. 

 Amazon CloudFront bietet eine einfache API für die Verteilung von Inhalten mit geringer Latenz und hohen Datenübertragungsraten, indem Anfragen über ein Netzwerk von Edge-Standorten auf der ganzen Welt bedient werden. Content Delivery Networks (CDNs) dienen den Kunden, indem sie Inhalte bereitstellen, die sich in der Nähe des Benutzers befinden oder dort zwischengespeichert werden. Dies verbessert auch die Verfügbarkeit Ihrer Anwendung, da die Last der Inhalte von Ihren Servern auf die [Edge-Standorte](https://aws.amazon.com/products/networking/edge-networking/) von CloudFront verlagert wird. Die Edge-Standorte und regionalen Edge-Caches halten zwischengespeicherte Kopien Ihrer Inhalte in der Nähe Ihrer Benutzer vor, was einen schnellen Abruf ermöglicht und die Erreichbarkeit und Verfügbarkeit Ihres Workloads erhöht. 

 Bei Workloads mit geografisch verteilten Benutzern hilft AWS Global Accelerator Ihnen, die Verfügbarkeit und Leistung der Anwendungen zu verbessern. AWS Global Accelerator bietet statische Anycast-IP-Adressen, die als fester Zugangspunkt zu Ihrer Anwendung dienen, die in einer oder mehreren AWS-Regionen gehostet wird. Dadurch kann der Datenverkehr so nah wie möglich an Ihren Benutzern in das globale AWS Netzwerk geleitet werden, was die Erreichbarkeit und Verfügbarkeit Ihres Workloads verbessert. AWS Global Accelerator überwacht außerdem den Zustand Ihrer Anwendungsendpunkte mithilfe von TCP-, HTTP- und HTTPS-Zustandsprüfungen. Jede Änderung im Zustand oder in der Konfiguration Ihrer Endpunkte leitet den Benutzerverkehr auf funktionierende Endpunkte weiter, die Ihren Benutzern die beste Leistung und Verfügbarkeit bieten. Darüber hinaus verfügt AWS Global Accelerator über ein fehlerisolierendes Design, das zwei statische IPv4-Adressen verwendet, die von unabhängigen Netzwerkzonen bedient werden und die Verfügbarkeit Ihrer Anwendungen erhöhen. 

 AWS bietet AWS Shield Standard, um Kunden vor DDoS-Angriffen zu schützen. Shield Standard wird automatisch aktiviert und schützt vor gängigen Infrastrukturangriffen (Layer 3 und 4) wie SYN/UDP-Floods und Reflection-Angriffen, um die hohe Verfügbarkeit Ihrer Anwendungen auf AWS zu unterstützen. Für zusätzlichen Schutz vor ausgefeilteren und größeren Angriffen (wie UDP-Floods), State-Exhaustion-Angriffen (wie TCP-SYN-Floods) und zum Schutz Ihrer Anwendungen, die auf Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator und Amazon Route 53 ausgeführt werden, können Sie AWS Shield Advanced verwenden. Zum Schutz vor Angriffen auf der Anwendungsebene wie HTTP-POST- oder GET-Floods verwenden Sie AWS WAF. AWS WAF kann IP-Adressen, HTTP-Header, HTTP-Body, URI-Strings, SQL-Injections und Cross-Site-Scripting-Bedingungen verwenden, um zu bestimmen, ob eine Anfrage blockiert oder zugelassen werden soll. 

 **Implementierungsschritte** 

1.  Amazon Route 53 ist ein hochverfügbarer und skalierbarer [Domain Name System (DNS)](https://aws.amazon.com/route53/what-is-dns/)-Web-Service. Route 53 verbindet Benutzeranfragen mit Internetanwendungen, die auf AWS oder On-Premises ausgeführt werden. Weitere Informationen finden Sie unter [Konfigurieren von Amazon Route 53 als DNS-Service.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html). 

1.  Richten Sie Zustandsprüfungen ein: Wenn Sie Amazon Route 53 verwenden, vergewissern Sie sich, dass nur korrekt funktionierende Ziele auflösbar sind. Starten Sie mit der [Erstellung von Route 53-Zustandsprüfungen und der Konfiguration des DNS-Failovers](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Bei der Einrichtung von Zustandsprüfungen sind die folgenden Aspekte zu beachten: 

   1. [ So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)

   1. [ Erstellen, Aktualisieren und Löschen von Zustandsprüfungen ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)

   1. [ Den Status von Zustandsprüfungen überwachen und Benachrichtigungen erhalten ](https://docs.aws.amazon.com/)

   1. [ Bewährte Methoden für Amazon Route 53 DNS ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)

1. [ Verbinden Sie Ihren DNS-Service mit Ihren Endpunkten. ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)

   1.  Wenn Sie Elastic Load Balancing als Ziel für Ihren Datenverkehr verwenden, erstellen Sie einen [Alias-Eintrag](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) mit Amazon Route 53, der auf den regionalen Endpunkt Ihres Load-Balancers verweist. Setzen Sie bei der Erstellung des Alias-Eintrags die Option „Zielzustand evaluieren“ auf „Ja“. Setzen Sie bei der Erstellung des Alias-Eintrags die Option „Zielzustand evaluieren“ auf „Ja“. 

   1.  Verwenden Sie bei der Nutzung von API Gateway für Serverless-Workloads oder private APIs Route 53, [um den Datenverkehr zu API Gateway zu routen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html). 

1.  Entscheiden Sie sich für ein Content Delivery Netzwerk. 

   1.  Informieren Sie sich zunächst über [die Art und Weise, wie CloudFront-Inhalte über Edge-Standorte in der Nähe des Benutzers bereitgestellt werden](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html). 

   1.  Starten Sie mit einer [einfachen CloudFront-Verteilung](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html). CloudFront weiß dann, von wo aus die Inhalte ausgeliefert werden sollen, und kennt die Details zur Nachverfolgung und Verwaltung der Content-Bereitstellung. Die folgenden Aspekte sollten Sie kennen und berücksichtigen, wenn Sie die CloudFront-Verteilung einrichten: 

      1. [ Funktionsweise der Zwischenspeicherung mit CloudFront-Edge-Standorten ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)

      1. [ Erhöhen des Anteils der Anforderungen, die direkt von den CloudFront-Caches bereitgestellt werden (Cache-Trefferrate) ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)

      1. [ Verwenden von Amazon CloudFront Origin Shield ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)

      1. [ Optimieren der Hochverfügbarkeit mit CloudFront-Ursprungs-Failover ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)

1.  Einrichten des Schutzes auf der Anwendungsebene: AWS WAF hilft Ihnen, sich gegen gängige Web-Exploits und Bots zu schützen, die die Verfügbarkeit beeinträchtigen, die Sicherheit gefährden oder übermäßig viele Ressourcen verbrauchen können. Um ein tieferes Verständnis zu erlangen, lesen Sie [How AWS WAF works](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html). Wenn Sie bereit sind, den Schutz vor HTTP-POST- und -GET-Floods auf der Anwendungsebene zu implementieren, lesen Sie [Getting started with AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html). Sie können außerdem AWS WAF mit CloudFront verwenden. In der Dokumentation erfahren Sie, [wie AWS WAF mit Amazon CloudFront-Funktionen arbeitet](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html). 

1.  Richten Sie einen zusätzlichen DDoS-Schutz ein: Standardmäßig erhalten alle Kunden von AWS mit AWS Shield Standard ohne zusätzliche Kosten einen Schutz gegen die gängigsten DDoS-Angriffe auf Netzwerk- und Transportebene, die sich gegen Ihre Website oder Anwendung richten. Für zusätzlichen Schutz von Anwendungen, die auf Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator und Amazon Route 53 ausgeführt werden, können Sie [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) einsetzen und sich [Beispiele für DDoS-resistente Architekturen ansehen](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html). Um Ihren Workload und Ihre öffentlichen Endpunkte vor DDoS-Angriffen zu schützen, lesen Sie [Getting started with AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html). 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [REL10-BP01 Bereitstellen des Workloads an mehreren Standorten](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md) 
+  [REL11-BP06 Senden von Benachrichtigungen, wenn sich Ereignisse auf die Verfügbarkeit auswirken](rel_withstand_component_failures_notifications_sent_system.md) 

 **Zugehörige Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Was ist Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
+  [Was ist Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [Was ist Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+ [ Network Connectivity capability - Establishing Your Cloud Foundations ](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)
+ [ Was ist Amazon API Gateway? ](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
+ [ Was sind AWS WAF, AWS Shield und AWS Firewall Manager? ](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)
+ [ Was ist Amazon Application Recovery Controller? ](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [ Benutzerdefinierte Zustandsprüfungen für das DNS-Failover konfigurieren ](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)

 **Zugehörige Videos:** 
+ [AWS re:Invent 2022 – Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2020 – Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
+ [AWS re:Invent 2022 – Operating highly available Multi-AZ applications ](https://www.youtube.com/watch?v=mwUV5skJJ0s)
+ [AWS re:Invent 2022 – Dive deep on AWS networking infrastructure ](https://www.youtube.com/watch?v=HJNR_dX8g8c)
+ [AWS re:Invent 2022 – Building resilient networks ](https://www.youtube.com/watch?v=u-qamiNgH7Q)

 **Zugehörige Beispiele:** 
+ [ Notfallwiederherstellung mit Amazon Application Recovery Controller (ARC) ](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [AWS Global Accelerator Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)

# REL02-BP02 Bereitstellen redundanter Konnektivität zwischen privaten Netzwerken in der Cloud und in On-Premises-Umgebungen
<a name="rel_planning_network_topology_ha_conn_private_networks"></a>

 Implementieren Sie Redundanz in Ihren Verbindungen zwischen privaten Netzwerken in der Cloud und On-Premises-Umgebungen, um die Stabilität der Konnektivität zu erreichen. Dies kann erreicht werden, indem zwei oder mehr Verbindungen und Datenverkehrspfade bereitgestellt werden, sodass die Konnektivität bei Netzwerkausfällen erhalten bleibt. 

 **Typische Anti-Muster:** 
+  Sie verlassen sich auf nur eine Netzwerkverbindung, was zu einer einzigen Fehlerquelle führt. 
+  Sie verwenden nur einen VPN-Tunnel oder mehrere Tunnel, die in derselben Availability Zone enden. 
+  Sie verlassen sich bei der VPN-Konnektivität auf einen ISP, was bei ISP-Ausfällen zu kompletten Ausfällen führen kann. 
+  Keine Implementierung dynamischer Routing-Protokolle wie BGP, die für die Umleitung des Datenverkehrs bei Netzwerkunterbrechungen von entscheidender Bedeutung sind. 
+  Sie ignorieren die Bandbreitenbeschränkungen von VPN-Tunneln und überschätzen deren Backup-Fähigkeiten. 

 **Vorteile der Nutzung dieser bewährten Methode:** Durch die Implementierung redundanter Konnektivität zwischen Ihrer Cloud-Umgebung und Ihrer Unternehmens- bzw. On-Premises-Umgebung wird die sichere Kommunikation der abhängigen Services zwischen den beiden Umgebungen gewährleistet. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Wenn Sie AWS Direct Connect verwenden, um Ihr On-Premises-Netzwerk mit AWS zu verbinden, können Sie maximale Netzwerkstabilität (SLA von 99,99 %) erreichen, indem Sie separate Verbindungen verwenden, die auf verschiedenen Geräten an mehr als einem On-Premises-Standort und mehr als einem AWS Direct Connect-Standort enden. Diese Topologie bietet Widerstandsfähigkeit gegen Geräteausfälle, Verbindungsprobleme und komplette Standortausfälle. Alternativ können Sie eine hohe Ausfallsicherheit (SLA von 99,9 %) erreichen, indem Sie zwei einzelne Verbindungen zu mehreren Standorten verwenden (jeder On-Premises-Standort ist mit einem einzigen Direct-Connect-Standort verbunden). Dieser Ansatz schützt vor Verbindungsunterbrechungen, die durch getrennte Glasfaserkabel oder Geräteausfälle verursacht werden, und trägt dazu bei, die Auswirkungen kompletter Standortausfälle zu mindern. Das Direct Connect Resiliency Toolkit unterstützt Sie beim Entwerfen Ihrer AWS Direct Connect-Topologie. 

 Sie können auch erwägen, dass AWS Site-to-Site VPN auf einem AWS Transit Gateway endet, um ein kostengünstiges Backup Ihrer primären Verbindung mit AWS Direct Connect zu erhalten. Dieses Setup ermöglicht Equal-Cost-Multipath (ECMP)-Routing über mehrere VPN-Tunnel und ermöglicht einen Durchsatz von bis zu 50 Gbit/s, obwohl jeder VPN-Tunnel auf 1,25 Gbit/s begrenzt ist. Es ist jedoch wichtig zu beachten, dass AWS Direct Connect immer noch die effektivste Wahl ist, um Netzwerkunterbrechungen zu minimieren und eine stabile Konnektivität bereitzustellen. 

 Wenn Sie VPNs über das Internet verwenden, um Ihre Cloud-Umgebung mit Ihrem On-Premises-Rechenzentrum zu verbinden, konfigurieren Sie zwei VPN-Tunnel als Teil einer einzigen Site-to-Site-VPN-Verbindung. Jeder Tunnel sollte aus Gründen der Hochverfügbarkeit in einer anderen Availability Zone enden und redundante Hardware verwenden, um Ausfälle von On-Premises-Geräten zu verhindern. Erwägen Sie außerdem mehrere Internetverbindungen von verschiedenen Internetdienstanbietern (ISPs) an Ihrem On-Premises-Standort, um eine vollständige Unterbrechung der VPN-Konnektivität durch den Ausfall eines einzigen ISP zu vermeiden. Die Auswahl von ISPs mit unterschiedlichem Routing und Infrastruktur, insbesondere solchen mit separaten physischen Pfaden zu AWS-Endpunkten, sorgt für eine hohe Konnektivitätsverfügbarkeit. 

 Neben der physischen Redundanz mit mehreren AWS Direct Connect-Verbindungen und VPN-Tunneln (oder einer Kombination aus beiden) ist auch die Implementierung des dynamischen Routings des Border Gateway Protocol (BGP) von entscheidender Bedeutung. Dynamisches BGP ermöglicht die automatische Umleitung des Datenverkehrs von einem Pfad zum nächsten, basierend auf Netzwerkbedingungen in Echtzeit und konfigurierten Richtlinien. Dieses dynamische Verhalten ist besonders vorteilhaft zur Aufrechterhaltung der Netzwerkverfügbarkeit und Servicekontinuität bei Verbindungs- oder Netzwerkausfällen. Es wählt schnell alternative Pfade aus und verbessert so die Ausfallsicherheit und Zuverlässigkeit des Netzwerks. 

### Implementierungsschritte
<a name="implementation-steps"></a>
+  Erwerben Sie hochverfügbare Konnektivität zwischen AWS und Ihrer On-Premises-Umgebung. 
  +  Verwenden Sie mehrere AWS Direct Connect-Verbindungen oder VPN-Tunnel zwischen separat bereitgestellten privaten Netzwerken. 
  +  Verwenden Sie für eine hohe Verfügbarkeit mehrere Direct Connect-Standorte. 
  +  Wenn Sie mehrere AWS-Regionen verwenden, sorgen Sie in mindestens zwei davon für Redundanz. 
+  Verwenden Sie AWS Transit Gateway, wenn möglichy, um Ihre [VPN-Verbindung](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpn-attachments.html) zu beenden. 
+  Beurteilen Sie AWS Marketplace-Appliances, um VPNs zu beenden oder [erweitern Sie Ihr SD-WAN auf AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-transit-gateway-sd-wan.html). Stellen Sie bei Verwendung von AWS Marketplace-Appliances redundante Instances bereit, um eine hohe Verfügbarkeit in verschiedenen Availability Zones zu gewährleisten. 
+  Stellen Sie auf Ihrer On-Premises-Umgebung eine redundante Verbindung her. 
  +  Möglicherweise benötigen Sie redundante Verbindungen zu mehreren AWS-Regionen, um die erforderliche Verfügbarkeit zu gewährleisten. 
  +  Verwenden Sie das [Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html), um loszulegen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [AWS Direct Connect Resiliency Recommendations](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
+  [Using Redundant Site-to-Site VPN Connections to Provide Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
+  [Routing policies and BGP communities](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) 
+  [Active/Active and Active/Passive Configurations in AWS Direct Connect](https://docs.aws.amazon.com/architecture-diagrams/latest/active-active-and-active-passive-configurations-in-aws-direct-connect/active-active-and-active-passive-configurations-in-aws-direct-connect.html) 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  Whitepaper [Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) 
+  [Using redundant Site-to-Site VPN connections to provide failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
+  [Using the Direct Connect Resiliency Toolkit to get started](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) 
+  [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [What is a transit gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [Was ist AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
+  [Working with Direct Connect gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) 

 **Zugehörige Videos:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC ](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP03 Berücksichtigen von Erweiterungen und Verfügbarkeit bei der Zuweisung von IP-Adressen für Subnetze
<a name="rel_planning_network_topology_ip_subnet_allocation"></a>

 Die IP-Adressbereiche für Amazon VPC müssen ausreichend groß sein, um die Anforderungen eines Workloads zu erfüllen. Dabei sind zukünftige Erweiterungen und Zuweisungen von IP-Adressen zu Subnetzen in verschiedenen Availability Zones zu berücksichtigen. Dies betrifft Load Balancer, EC2-Instances sowie containerbasierte Anwendungen. 

 Wenn Sie Ihre Netzwerktopologie planen, besteht der erste Schritt in der Definition des IP-Adressbereichs. Private IP-Adressbereiche (gemäß RFC 1918-Richtlinien) sollten jeder VPC zugewiesen werden. Berücksichtigen Sie im Rahmen dieses Prozesses die folgenden Anforderungen: 
+ Ermöglichen Sie einen IP-Adressbereich für mehr als eine VPC pro Region. 
+ Planen Sie innerhalb einer VPC Platz für mehrere Subnetze ein, damit Sie mehrere Availability Zones abdecken können. 
+ Lassen Sie für eine zukünftige Erweiterung stets Raum für nicht verwendete CIDR-Blöcke innerhalb einer VPC.
+ Stellen Sie sicher, dass ein IP-Adressbereich vorhanden ist, um die Anforderungen von temporären Amazon EC2-Instances zu erfüllen, die Sie möglicherweise verwenden, z. B. Spot-Flotten für Machine Learning, Amazon EMR-Cluster oder Amazon Redshift-Cluster. Ähnliche Überlegungen sollten für Kubernetes-Cluster wie Amazon Elastic Kubernetes Service (Amazon EKS) getroffen werden, da jedem Kubernetes-Pod standardmäßig eine routbare Adresse aus dem VPC-CIDR-Block zugewiesen wird.
+ Beachten Sie, dass die ersten vier IP-Adressen und die letzte IP-Adresse in jedem Subnetz-CIDR-Block reserviert und nicht für Sie verfügbar sind.
+ Beachten Sie, dass der VPC CIDR-Block, der anfänglich Ihrer VPC zugewiesen war, nicht geändert oder gelöscht werden kann. Sie können der VPC jedoch zusätzliche, nicht überlappende CIDR-Blöcke hinzufügen. IPv4-CIDRs für Subnetze können nicht geändert werden, IPv6 CIDRs jedoch schon.
+ Der größte mögliche VPC-CIDR-Block entspricht /16 und der kleinste /28.
+ Berücksichtigen Sie andere verbundene Netzwerke (VPC, On-Premises oder sonstige Cloud-Anbieter) und stellen Sie sicher, dass sich der IP-Adressraum nicht überschneidet. Weitere Informationen finden Sie unter [Erzwingen von sich nicht überschneidenden privaten IP-Adressbereichen in allen privaten Adressbereichen, in denen eine Verbindung besteht](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html).

 **Gewünschtes Ergebnis:** Ein skalierbares IP-Subnetz kann Ihnen helfen, zukünftiges Wachstum zu bewältigen und unnötige Verschwendung zu vermeiden.

 **Typische Anti-Muster:** 
+ Wenn zukünftiges Wachstum nicht berücksichtigt wird, sind die CIDR-Blöcke zu klein und müssen neu konfiguriert werden, was zu Ausfallzeiten führen kann.
+ Es wird falsch eingeschätzt, wie viele IP-Adressen ein Elastic Load Balancer verwenden kann.
+ Es werden viele Load Balancer mit hohem Datenverkehr in denselben Subnetzen bereitgestellt.
+ Es werden automatische Skalierungsmechanismen verwendet, während der Verbrauch von IP-Adressen nicht überwacht wird.
+ Die Definition übermäßig großer CIDR-Bereiche liegt weit über den zukünftigen Wachstumserwartungen, was zu Schwierigkeiten beim Peering mit anderen Netzwerken mit überlappenden Adressbereichen führen kann.

 **Vorteile der Nutzung dieser bewährten Methode:** So wird sichergestellt, dass Sie das Wachstum Ihrer Workloads bewältigen können und beim Hochskalieren weiterhin die entsprechende Verfügbarkeit bereitstellen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

Berücksichtigen Sie bei der Planung Ihres Netzwerks Ihr zukünftiges Wachstum, die Einhaltung gesetzlicher Vorschriften sowie die Kompatibilität mit anderen Netzwerken. Das Wachstum kann unterschätzt werden, gesetzliche Vorschriften können sich ändern, und bei Unternehmensübernahmen oder privaten Netzwerkverbindungen kann die Implementierung ohne fundierte Planung zur Herausforderung werden. 
+  Wählen Sie relevante AWS-Konten und Regionen anhand von Serviceanforderungen, regulatorischen Anforderungen sowie Anforderungen für die Latenz und die Notfallwiederherstellung aus. 
+  Identifizieren Sie Ihre Anforderungen bezüglich regionaler VPC-Bereitstellungen. 
+  Ermitteln Sie die erforderliche Größe der VPCs. 
  +  Ermitteln Sie, ob Multi-VPC-Konnektivität bereitgestellt werden soll. 
    +  [Was ist ein Transit-Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
    +  [Multi-VPC-Konnektivität in einer Region](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
  +  Ermitteln Sie, ob aufgrund von Compliance-Anforderungen getrennte Netzwerke erforderlich sind. 
  + Erstellen Sie VPCs mit CIDR-Blöcken in geeigneter Größe, um Ihren aktuellen und zukünftigen Anforderungen gerecht zu werden.
    + Wenn Sie unbekannte Wachstumsprognosen haben, sollten Sie sich für größere CIDR-Blöcke entscheiden, um das Potenzial einer zukünftigen Neukonfiguration zu verringern.
  + Erwägen Sie die Verwendung von [IPv6-Adressierung](https://aws.amazon.com/vpc/ipv6/) für Subnetze als Teil einer Dual-Stack-VPC. IPv6 eignet sich gut für den Einsatz in privaten Subnetzen, die Flotten kurzlebiger Instances oder Container enthalten, für die andernfalls eine große Anzahl von IPv4-Adressen erforderlich wäre.

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden für Well-Architected:** 
+  [REL02-BP05 Erzwingen von sich nicht überschneidenden privaten IP-Adressbereichen in allen privaten Adressbereichen, in denen eine Verbindung besteht](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html) 

 **Zugehörige Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Whitepaper Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Multi-VPC-Konnektivität in einer Region](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [IPv6 auf AWS](https://aws.amazon.com/vpc/ipv6) 
+  [IPv6 in Referenzarchitekturen](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/IPv6-reference-architectures-for-AWS-and-hybrid-networks-ra.pdf) 
+  [Amazon Elastic Kubernetes Service launches IPv6 support](https://aws.amazon.com/blogs/containers/amazon-eks-launches-ipv6-support/) 
+ [ Empfehlungen für Ihre VPC – Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-backend-instances.html#set-up-ec2)
+ [ Availability-Zone-Subnetze – Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#availability-zones)
+ [ Availability Zones – Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#availability-zones)

 **Zugehörige Videos:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 
+  [AWS re:Invent 2023: AWS Ready for what's next? Designing networks for growth and flexibility (NET310)](https://www.youtube.com/watch?v=FkWOhTZSfdA) 

# REL02-BP04 Vorziehen von Hub-and-Spoke-Topologien gegenüber M-zu-N-Netzen
<a name="rel_planning_network_topology_prefer_hub_and_spoke"></a>

 Wenn Sie mehrere private Netzwerke wie Virtual Private Clouds (VPCs) und On-Premises-Netzwerke verbinden, sollten Sie sich für eine Hub-and-Spoke-Topologie statt für eine verflochtene Topologie entscheiden. Im Gegensatz zu verflochtenen Topologien, bei denen jedes Netzwerk direkt mit dem anderen verbunden ist, was die Komplexität und den Verwaltungsaufwand erhöht, zentralisiert die Hub-and-Spoke-Architektur Verbindungen über einen einzigen Hub. Diese Zentralisierung vereinfacht die Netzwerkstruktur und verbessert deren Bedienbarkeit, Skalierbarkeit und Kontrolle. 

 AWS Transit Gateway ist ein verwalteter, skalierbarer und hochverfügbarer Service, der für den Aufbau von Hub-and-Spoke-Netzwerken auf AWS entwickelt wurde. Er dient als zentraler Knotenpunkt Ihres Netzwerks, der Netzwerksegmentierung, zentralisiertes Routing und die vereinfachte Verbindung zu Cloud- und On-Premises-Umgebungen ermöglicht. Die folgende Abbildung zeigt, wie Sie Ihre Hub-and-Spoke-Topologie mit AWS Transit Gateway entwickeln können. 

![\[AWS Transit Gateway connecting various services like VPCs, Direct Connect, and third-party appliances.\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/hub-and-spoke.png)


 

 **Gewünschtes Ergebnis:** Sie haben Ihre Virtual Private Clouds (VPCs) und On-Premises-Netzwerke über einen zentralen Hub verbunden. Sie konfigurieren Ihre Peering-Verbindungen über den Hub, der als hoch skalierbarer Cloud-Router fungiert. Das Routing ist vereinfacht, da Sie nicht mit komplexen Peering-Beziehungen arbeiten müssen. Der Datenverkehr zwischen Netzwerken ist verschlüsselt und Sie haben die Möglichkeit, Netzwerke zu isolieren. 

 **Typische Anti-Muster:** 
+  Sie erstellen komplexe Netzwerk-Peering-Regeln. 
+  Sie stellen Routen zwischen Netzwerken bereit, die nicht miteinander kommunizieren sollten (z. B. separate Workloads, die keine gegenseitigen Abhängigkeiten haben). 
+  Die Verwaltung der Hub-Instance ist ineffektiv. 

 **Vorteile der Nutzung dieser bewährten Methode:** Wenn die Anzahl der verbundenen Netzwerke zunimmt, wird die Verwaltung und Erweiterung der Mesh-Konnektivität immer schwieriger. Eine Mesh-Architektur bringt zusätzliche Herausforderungen mit sich, z. B. zusätzliche Infrastrukturkomponenten, Konfigurationsanforderungen und Überlegungen zur Bereitstellung. Das Mesh bringt außerdem zusätzlichen Aufwand für die Verwaltung und Überwachung der Komponenten der Datenebene und der Steuerebene mit sich. Sie müssen darüber nachdenken, wie eine hohe Verfügbarkeit der Mesh-Architektur gewährleistet werden kann, wie der Zustand und die Leistung des Mesh überwacht werden können und wie mit Upgrades der Mesh-Komponenten umzugehen ist. 

 Ein Hub-and-Spoke-Modell hingegen ermöglicht die zentrale Weiterleitung des Datenverkehrs über mehrere Netzwerke hinweg. Es bietet einen einfacheren Ansatz für die Verwaltung und Überwachung der Komponenten der Datenebene und der Steuerebene. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: **Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Erstellen Sie ein Network-Services-Konto, wenn keins vorhanden ist. Platzieren Sie den Hub im Network-Services-Konto der Organisation. Dies ermöglicht die zentrale Verwaltung des Hubs durch Netzwerktechniker. 

 Im Hub-and-Spoke-Modell dient der Hub als virtueller Router für den Datenverkehr zwischen Ihren Virtual Private Clouds (VPCs) und On-Premises-Netzwerken. Dies reduziert die Netzwerkkomplexität und vereinfacht die Behebung von Netzwerkproblemen. 

 Berücksichtigen Sie Ihr Netzwerkdesign, einschließlich der VPCs, AWS Direct Connect und die Site-to-Site-VPN-Verbindungen, die Sie herstellen möchten. 

 Verwenden Sie für jede angefügte Transit-Gateway-VPC ein separates Subnetz. Verwenden Sie für jedes Subnetz einen kleinen CIDR-Wert (z. B. /28), damit Sie mehr Adressraum für Computing-Ressourcen haben. Erstellen Sie eine Netzwerk-Zugriffskontrollliste (ACL) und weisen Sie diese allen Subnetzen zu, die mit dem Hub verbunden sind. Halten Sie die Netzwerk-ACL sowohl in der Richtung für eingehenden als auch in der Richtung für ausgehender Datenverkehr geöffnet. 

 Entwerfen und implementieren Sie Ihre Routing-Tabellen so, dass Routen nur zwischen Netzwerken bereitgestellt werden, die miteinander kommunizieren sollen. Lassen Sie Routen zwischen Netzwerken aus, die nicht miteinander kommunizieren sollen (z. B. zwischen separaten Workloads, die keine gegenseitigen Abhängigkeiten haben). 

### Implementierungsschritte
<a name="implementation-steps"></a>

1.  Planen Sie Ihr Netzwerk. Ermitteln Sie, welche Netzwerke Sie verbinden möchten, und stellen Sie sicher, dass diese keine sich überschneidenden CIDR-Bereiche teilen. 

1.  Erstellen Sie ein AWS Transit Gateway und hänfügen Sie Ihre VPCs an. 

1.  Erstellen Sie VPN-Verbindungen oder Direct-Connect-Gateways und verknüpfen Sie diese mit dem Transit-Gateway. wenn notwendig. 

1.  Definieren Sie durch die Konfiguration Ihrer Routing-Tabelle für den Transit-Gateway, wie der Datenverkehr zwischen den verbundenen VPCs und anderen Verbindungen geleitet wird. 

1.  Verwenden Sie Amazon CloudWatch, um Konfigurationen zu überwachen und bei Bedarf zur Leistungs- und Kostenoptimierung anzupassen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [REL02-BP03 Berücksichtigen von Erweiterung und Verfügbarkeit bei der Zuweisung von IP-Adressen für Subnetze](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html) 
+  [REL02-BP05 Durchsetzen von sich nicht überschneidenden privaten IP-Adressbereichen in allen privaten Adressbereichen, in denen eine Verbindung besteht](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html) 

 **Zugehörige Dokumente:** 
+  [Was ist ein Transit-Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [Bewährte Methoden für das Transit-Gateway-Design](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html) 
+  [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) 
+  [Building a global network using 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/) 
+  [Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 

 **Zugehörige Videos:** 
+  [AWS re:Invent 2.023 - AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4) 
+  [AWS re:Invent 2.023 - Advanced VPC designs and new capabilities](https://www.youtube.com/watch?v=cRdDCkbE4es) 

 **Zugehörige Workshops:** 
+  [AWS Transit Gateway-Workshop](https://catalog.workshops.aws/trasitgw/en-US) 

# REL02-BP05 Erzwingen von sich nicht überschneidenden privaten IP-Adressbereichen in allen privaten Adressbereichen, in denen eine Verbindung besteht
<a name="rel_planning_network_topology_non_overlap_ip"></a>

Die IP-Adressbereiche Ihrer VPCs dürfen sich nicht überschneiden, wenn sie per Peering oder über Transit Gateway oder VPN verbunden sind. Vermeiden Sie IP-Adresskonflikte zwischen einer VPC und On-Premises-Umgebungen oder anderen verwendeten Cloud-Anbietern. Sie müssen bei Bedarf auch die Möglichkeit haben, private IP-Adressbereiche zuzuweisen. Ein IP-Adressenverwaltungssystem (IPAM) kann bei der Automatisierung helfen. 

 **Gewünschtes Ergebnis:** 
+  Keine Konflikte mit IP-Adressbereichen zwischen VPCs, On-Premises-Umgebungen oder anderen Cloud-Anbietern. 
+  Eine angemessene IP-Adressverwaltung ermöglicht eine einfachere Skalierung der Netzwerkinfrastruktur, um wachsenden und sich wandelnden Netzwerkanforderungen gerecht zu werden. 

 **Typische Anti-Muster:** 
+  Verwendung desselben IP-Bereichs in Ihrer VPC wie On-Premises, in Ihrem Unternehmensnetzwerk oder bei anderen Cloud-Anbietern. 
+  Keine Verfolgung von IP-Bereichen von VPCs, die zur Bereitstellung der Workloads verwendet werden. 
+  Alleinige Nutzung manueller IP-Adressverwaltungsprozesse wie Tabellenkalkulationen. 
+  Über- oder Unterdimensionierung von CIDR-Blöcken, was zu einer Verschwendung von IP-Adressen oder zu wenig Adressbereichen für Ihren Workload führt. 

 **Vorteile der Nutzung dieser bewährten Methode:** Mit der aktiven Planung des Netzwerks stellten Sie sicher, dass dieselbe IP-Adresse in miteinander verbunden Netzwerken nicht mehrmals vorkommt. So wird verhindert, dass Routing-Probleme in Teilen der Workload auftreten, die die verschiedenen Anwendungen verwenden. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Verwenden Sie ein IPAM, z. B. den [Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html), um Ihre CIDR-Nutzung zu überwachen und zu verwalten. Im AWS Marketplace stehen auch mehrere IPAMs zur Verfügung. Bewerten Sie die potenzielle Nutzung in AWS, fügen Sie vorhandenen VPCs CIDR-Bereiche hinzu und erstellen Sie neue VPCs, um das geplante Wachstum abzudecken. 

### Implementierungsschritte
<a name="implementation-steps"></a>
+  Ermitteln Sie den aktuellen CIDR-Umfang (z. B. VPCs und Subnetze). 
  +  Erfassen Sie über die Service API den aktuellen CIDR-Umfang. 
  +  Verwenden Sie den [Amazon VPC IP Address Manager, um Ressourcen zu entdecken](https://docs.aws.amazon.com/vpc/latest/ipam/res-disc-work-with-view.html). 
+  Erfassen Sie die aktuelle Subnetzauslastung. 
  +  [Ermitteln](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) Sie über die Service-API die in jeder Region pro VPC vorhandenen Subnetze. 
  +  Verwenden Sie den [Amazon VPC IP Address Manager, um Ressourcen zu entdecken](https://docs.aws.amazon.com/vpc/latest/ipam/res-disc-work-with-view.html). 
+  Zeichnen Sie die aktuelle Auslastung auf. 
+  Prüfen Sie, ob sich IP-Bereiche überschneiden. 
+  Berechnen Sie die freie Kapazität. 
+  Identifizieren Sie sich überschneidende IP-Bereiche. Sie können wahlweise zu einem neuen Adressbereich migrieren oder Techniken wie [privates NAT-Gateway](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/private-nat-gateway.html) oder [AWS PrivateLink](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/aws-privatelink.html) verwenden, wenn Sie die sich überschneidenden Bereiche verbinden müssen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+ [ Schutz von Netzwerken ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html)

 **Zugehörige Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  Whitepaper [Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+ [ Connecting Networks with Overlapping IP Ranges ](https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-networks-with-overlapping-ip-ranges/)
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Was ist IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 

 **Zugehörige Videos:** 
+ [AWS re:Invent 2023: Advanced VPC designs and new capabilities ](https://www.youtube.com/watch?v=cRdDCkbE4es)
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc) 
+ [AWS re:Invent 2023: Ready for what’s next? Designing networks for growth and flexibility ](https://www.youtube.com/watch?v=FkWOhTZSfdA)
+ [AWS re:Invent 2021: \$1New Launch\$1 Manage your IP addresses at scale on AWS](https://www.youtube.com/watch?v=xtLJgJfhPLg)