

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.

# Überlegungen zu Art und Design der Hybridkonnektivität
<a name="hybrid-connectivity-type-and-design-considerations"></a>

 In diesem Abschnitt des Whitepapers werden die Überlegungen behandelt, die sich auf Ihre Entscheidungen bei der Auswahl eines Hybridnetzwerks auswirken, mit dem Sie Ihre lokalen Umgebungen verbinden möchten. AWS Es folgt einem logischen Denkprozess, der Sie bei der Auswahl einer optimalen Hybrid-Konnektivitätslösung unterstützen soll. Die Überlegungen, die sich auf Ihren Entwurf auswirken, sind in Überlegungen unterteilt, die sich auf Ihren *Konnektivitätstyp* auswirken, und Überlegungen, die sich auf Ihr *Konnektivitätsdesign* auswirken. Überlegungen zum Konnektivitätstyp helfen Ihnen bei der Entscheidung, ob Sie ein internetbasiertes VPN oder Direct Connect verwenden möchten. Überlegungen zum Konnektivitätsdesign helfen Ihnen bei der Entscheidung, wie die Verbindungen eingerichtet werden sollen. 

 Die folgenden Überlegungen, die sich auf Ihren *Konnektivitätstyp* auswirken, werden behandelt: Zeit bis zur Bereitstellung, Sicherheit, SLA, Leistung und Kosten. Nachdem Sie diese Überlegungen und deren Auswirkungen auf Ihre Entwurfsentscheidungen geprüft haben, können Sie entscheiden, ob die Verwendung einer internetbasierten Verbindung oder Direct Connect zur Erfüllung Ihrer Anforderungen empfohlen wird. 

 Die folgenden Überlegungen, die sich auf Ihr *Konnektivitätsdesign* auswirken, werden behandelt: Skalierbarkeit, Kommunikationsmodell, Zuverlässigkeit und SD-WAN-Integration von Drittanbietern. Nachdem Sie diese Überlegungen und deren Auswirkungen auf Ihre Entwurfsentscheidungen geprüft haben, können Sie entscheiden, welches optimale logische Design für Ihre Anforderungen empfohlen wird. 

 Die folgende Struktur wird verwendet, um die einzelnen Auswahl- und Entwurfsüberlegungen zu erörtern und zu analysieren: 
+  **Definition** — Kurze Definition dessen, was die Überlegung ist. 
+  **Wichtige Fragen** — Enthält eine Reihe von Fragen, anhand derer Sie die mit der Überlegung verbundenen Anforderungen zusammenfassen können. 
+  **Zu berücksichtigende Fähigkeiten** — Lösungen zur Erfüllung der mit der Prüfung verbundenen Anforderungen. 
+  **Entscheidungsbaum** — Für einige Überlegungen oder eine Gruppe von Überlegungen steht ein Entscheidungsbaum zur Verfügung, der Sie bei der Auswahl der optimalen hybriden Netzwerklösung unterstützt. 

 Die Überlegungen, die Ihr hybrides Netzwerkdesign beeinflussen, werden in einer Reihenfolge behandelt, in der das Ergebnis einer Überlegung Teil der Eingabe für die nachfolgende Überlegung ist. Wie in Abbildung 2 dargestellt, besteht der erste Schritt darin, sich für den Konnektivitätstyp zu entscheiden und ihn anschließend anhand der Überlegungen zur Entwurfsauswahl zu verfeinern. 

 Abbildung 2 zeigt die beiden Kategorien von Überlegungen, die einzelnen Überlegungen und die logische Reihenfolge, in der die Überlegungen in den nachfolgenden Unterabschnitten behandelt werden. Dies sind die wichtigsten Überlegungen, wenn Sie eine Entscheidung über den Entwurf eines hybriden Netzwerks treffen. Wenn das angestrebte Design nicht all diese Überlegungen erfordert, können Sie sich auf die Überlegungen konzentrieren, die für Ihre Anforderungen relevant sind. 

![\[Diagramm, das die Kategorien der Überlegungen, die einzelnen Überlegungen und die logische Reihenfolge zwischen ihnen zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/consideration-categories.png)


# Auswahl des Konnektivitätstyps
<a name="connectivity-type-selection"></a>

 In diesem Abschnitt werden Überlegungen behandelt, die sich auf den Konnektivitätstyp auswirken, den Sie für Ihren Workload auswählen. Dazu gehören Bereitstellungszeit, SicherheitSLA, Leistung und Kosten. 

**Topics**
+ [Zeit für die Bereitstellung](time-to-deploy.md)
+ [Sicherheit](security.md)
+ [Vereinbarung SLA zum Servicelevel ()](service-level-agreement-sla.md)
+ [Leistung](performance.md)
+ [Kosten](cost.md)

# Zeit für die Bereitstellung
<a name="time-to-deploy"></a>

## Definition
<a name="definition"></a>

 Die Zeit bis zur Bereitstellung kann ein wichtiger Faktor bei der Auswahl eines geeigneten Konnektivitätstyps für einen Workload sein. Je nach Art der Konnektivität und den Standorten vor Ort kann die Konnektivität innerhalb von Stunden hergestellt werden. Es kann jedoch Wochen oder Monate dauern, wenn zusätzliche Leitungen installiert werden müssen. Dies beeinflusst Ihre Entscheidung, eine internetbasierte Verbindung, eine private dedizierte Verbindung oder eine private gehostete Verbindung zu verwenden, die von einem Partner als verwalteter Service bereitgestellt wird. AWS Direct Connect 

## Die wichtigsten Fragen
<a name="key-questions"></a>
+  Was ist der erforderliche Zeitplan für die Bereitstellung — Stunden, Tage, Wochen oder Monate? 
+  Wie lange wird die Verbindung benötigt — handelt es sich um ein kurzlebiges Projekt oder um eine permanente Infrastruktur? 

## Zu berücksichtigende Fähigkeiten
<a name="capabilities-to-consider"></a>

 Wenn Sie innerhalb von Stunden oder Tagen AWS Konnektivität benötigen, müssen Sie höchstwahrscheinlich eine bestehende Netzwerkverbindung verwenden. Dies bedeutet häufig, eine VPN Verbindung AWS über das öffentliche Internet herzustellen. Wenn ein vorhandener AWS DX-Partner Ihnen private AWS Konnektivität zur Verfügung stellt, kann innerhalb weniger Stunden eine neue gehostete Verbindung bereitgestellt werden. 

 Wenn Sie Tage oder Wochen Zeit haben, können Sie mit einem AWS Direct Connect Partner zusammenarbeiten, um eine private Konnektivität herzustellen. AWS AWS Direct Connect Partner helfen Ihnen dabei, Netzwerkkonnektivität zwischen AWS Direct Connect Standorten und Ihrem Rechenzentrum, Büro oder Ihrer Kollokationsumgebung herzustellen. Bestimmte [AWS Direct Connect Partner](https://aws.amazon.com/directconnect/partners/) sind berechtigt, [Direct Connect Hosted Connections](https://docs.aws.amazon.com/directconnect/latest/UserGuide/hosted_connection.html) anzubieten. Gehostete Verbindungen können oft schneller bereitgestellt werden als dedizierte Verbindungen. AWS Direct Connect Der Partner stellt jede gehostete Verbindung mithilfe seiner vorhandenen Infrastruktur bereit, die mit dem AWS Backbone verbunden ist. 

 Wenn Sie mehrere Wochen bis Monate Zeit haben, können Sie den Aufbau einer dedizierten privaten Verbindung mit prüfen AWS. Dienstanbieter und AWS Direct Connect Partner ermöglichen AWS Direct Connect dedizierte Verbindungen. Es ist üblich, dass Dienstanbieter Netzwerkgeräte am Standort des Kunden installieren, um eine dedizierte Direct Connect-Verbindung zu ermöglichen. Je nach Dienstanbieter, Standort Ihres Standorts und anderen physikalischen Faktoren kann die Installation einer Direct Connect Dedicated Connection mehrere Wochen bis einige Monate dauern. 

 Wenn Sie Ihre Netzwerkausrüstung bereits in derselben Colocation-Einrichtung installiert haben, in der sich der AWS Direct Connect Standort befindet, können Sie schnell eine AWS Direct Connect dedizierte Verbindung über eine Cross-Connect-Verbindung am Colocation-Standort einrichten. Stellt Ihnen, nachdem Sie die Verbindung angefordert haben, AWS ein Autorisierungsschreiben und die Zuweisung von Verbindungseinrichtungen (LOA-CFA) zum Herunterladen zur Verfügung oder sendet Ihnen eine E-Mail mit der Bitte um weitere Informationen. Das LOA - CFA ist die Autorisierung, mit der Sie eine Verbindung herstellen können AWS, und wird von Ihrem Netzwerkanbieter benötigt, um eine Cross-Connect-Verbindung für Sie zu bestellen. 

*Tabelle 1 — Vergleich der Kostenwirksamkeit*


|   |  Internetbasierte Konnektivität  |  Dedizierte DX-Verbindung (vorhandene Geräte am DX-Standort)  |  Dedizierte DX-Verbindung (neuwertig)  |  Gehostete DX-Verbindung (vorhandener Port mit DX-Partner)  |  DX Hosted Connection (neuwertig)  | 
| --- | --- | --- | --- | --- | --- | 
|  Bereitstellungszeit  |  Stunden bis Tage  |  Tage  |  Mehrere Wochen bis Monate  |  Stunden bis Tage  |  Mehrere Tage bis Wochen bis Monate  | 

**Anmerkung**  
Die bereitgestellten Richtlinien für die Bereitstellungszeit basieren auf realen Beobachtungen und dienen nur der Veranschaulichung. Wenn Sie den Standort Ihres Standorts, die Nähe zu Standorten mit Direktverbindungen und die bereits vorhandene Infrastruktur berücksichtigen, wirken sich all diese Faktoren auf die Bereitstellungszeit aus. Ihr AWS Direct Connect Partner wird Sie bezüglich der genauen Bereitstellungszeit beraten. 

# Sicherheit
<a name="security"></a>

## Definition
<a name="definition-sec"></a>

 Die Sicherheitsanforderungen wirken sich auf Ihren Hybrid-Konnektivitätstyp aus. Zu diesen Überlegungen gehören: 
+  Transporttyp — Internet- oder private Netzwerkverbindung 
+  Anforderungen an die Verschlüsselung 

## Die wichtigsten Fragen
<a name="key-questions-sec"></a>
+  Erlauben Ihre Sicherheitsanforderungen und -richtlinien die Verwendung verschlüsselter Verbindungen über das Internet AWS, um eine Verbindung herzustellen, oder schreiben sie die Verwendung von privaten Netzwerkverbindungen vor? 
+  Muss die Netzwerkschicht bei der Nutzung privater Netzwerkverbindungen für Verschlüsselung bei der Übertragung sorgen? 

## Technische Lösungen
<a name="technical-solutions"></a>

 Ihre Sicherheitsanforderungen und -richtlinien erlauben möglicherweise die Nutzung des Internets oder erfordern die Verwendung einer privaten Netzwerkverbindung zwischen Ihrem Unternehmensnetzwerk AWS und Ihrem Unternehmensnetzwerk. Sie wirken sich auch auf die Entscheidung aus, ob das Netzwerk Verschlüsselung bei der Übertragung bereitstellen muss oder ob eine Verschlüsselung auf Anwendungsebene zulässig ist. 

 Wenn Sie das Internet nutzen können, AWS Site-to-Site VPN können Sie damit verschlüsselte Tunnel zwischen Ihrem Netzwerk und Ihrem Amazon VPCs oder AWS Transit Gateway s über das Internet erstellen. Die Erweiterung Ihrer [WANSD-Lösung](https://en.wikipedia.org/wiki/SD-WAN) AWS auf das Internet ist auch eine Option, wenn Sie eine internetbasierte Verbindung nutzen. Im Abschnitt Kundenverwaltet VPN und SD- werden weiter unten WAN in diesem Whitepaper die spezifischen Überlegungen zu SD- behandelt. WAN 

 Wenn Sie eine private Netzwerkverbindung zwischen Ihrem Unternehmensnetzwerk AWS und Ihrem Unternehmensnetzwerk benötigen, AWS empfiehlt es sich, AWS Direct Connect Dedicated Connections oder Hosted Connections zu verwenden. Wenn eine Verschlüsselung bei der Übertragung über eine private Netzwerkverbindung erforderlich ist, sollten Sie eine direkte Connect (entweder VPN über öffentliche Verbindungen VIF oder öffentliche VerkehrsmittelVIF) einrichten oder die Verwendung MACsec einer dedizierten Verbindung mit 10 Gbit/s oder 100 Gbit/s in Betracht ziehen. 

*Tabelle 2 — Beispiel für Anforderungen an den Konnektivitätstyp von Automotive Corp.*


|   |  Site-to-Site VPN  |  Direct Connect  | 
| --- | --- | --- | 
|  Transport  |  Internet  |  Private Netzwerkverbindung  | 
|  Verschlüsselung während der Übertragung  |  Ja  |  Erfordert S2S VPN über DX, S2S VPN über einen Transit oder über eine VIF dedizierte 10-Gbit/s- oder MACsec 100-Gbit/s-Verbindung  | 

# Vereinbarung SLA zum Servicelevel ()
<a name="service-level-agreement-sla"></a>

## Definition
<a name="definition-sla"></a>

 Unternehmen benötigen häufig einen Dienstleister, der SLA für jeden Service, den das Unternehmen in Anspruch nimmt, eine Leistung erbringt. Die Organisation wiederum baut darauf ihre eigenen Dienste auf und kann ihren eigenen Verbrauchern eine SLA anbieten. Dies SLA ist wichtig, da es beschreibt, wie der Dienst bereitgestellt und betrieben wird, und häufig spezifische messbare Merkmale wie die Verfügbarkeit enthält. Sollte der Service nicht den festgelegten Anforderungen entsprechenSLA, bietet ein Dienstanbieter in der Regel eine finanzielle Entschädigung an, die in der Vereinbarung festgelegt ist. An SLA definiert die Art der Maßnahme, die Anforderung und den Messzeitraum. Ein Beispiel finden Sie in der Definition des Verfügbarkeitsziels unter [AWS Direct Connect SLA](https://aws.amazon.com/directconnect/sla/). 

## Die wichtigsten Fragen
<a name="key-questions-sla"></a>
+  Ist eine Hybrid-Konnektivitätsverbindung SLA mit Service-Credits erforderlich? 
+  Muss das gesamte Hybridnetzwerk ein Verfügbarkeitsziel einhalten? 

## Zu berücksichtigende Fähigkeiten
<a name="capabilities-to-consider-sla"></a>

 **Art der Konnektivität:** Die Internetkonnektivität kann unvorhersehbar sein. Die Verwaltung des Internets AWS erfordert zwar große Sorgfalt bei der Einrichtung mehrerer Links mit einer Vielzahl von VerbindungenISPs, aber die Verwaltung des Internets erfolgt einfach außerhalb der AWS administrativen Domäne eines einzelnen Anbieters. Sobald der Verkehr die Grenze seines Netzwerks verlassen hat, gibt es ein begrenztes Maß an Routenplanung und Verkehrsbeeinflussung, die ein Cloud-Anbieter ausüben kann. Allerdings gibt es eine, [AWS Site-to-Site VPN SLA](https://aws.amazon.com/vpn/site-to-site-vpn-sla/)die Verfügbarkeitsziele für AWS Site-to-Site VPN Endpunkte vorgibt. 

 AWS [Direct Connect bietet ein formelles](https://aws.amazon.com/directconnect/sla/) Service SLA mit Servicegutschriften, die als Prozentsatz der gesamten AWS Direct Connect Port-Hour-Gebühren berechnet werden, die Sie für die entsprechenden Verbindungen bezahlt haben, die in dem monatlichen Abrechnungszeitraum nicht verfügbar SLA waren, in dem die Gebühren nicht eingehalten wurden. Dies ist der empfohlene Transport, falls ein erforderlich SLA ist. AWS Direct Connect listet [spezifische Mindestkonfigurationsanforderungen](https://aws.amazon.com/directconnect/sla/) für jedes Verfügbarkeitsziel auf, z. B. Anzahl der AWS Direct Connect Standorte, Verbindungen und andere Konfigurationsdetails. Wenn die Anforderungen nicht erfüllt werden, können keine Servicegutschriften angeboten werden, sollte die Serviceunterbrechung definiert SLAs werden. 

 Wichtig ist, dass selbst wenn der für die Bereitstellung von Hybridkonnektivität ausgewählte Dienst so konfiguriert ist, dass er die SLA Anforderungen erfüllt, der Rest des Netzwerks möglicherweise nicht das gleiche Niveau von bietetSLA. Die AWS Verantwortung endet am AWS Direct Connect Standort am AWS Direct Connect Hafen. Sobald AWS der Datenverkehr an das Netzwerk Ihres Unternehmens weitergeleitet wurde, liegt er nicht mehr in der Verantwortung von AWS. Wenn Sie einen Dienstanbieter zwischen AWS und Ihrem lokalen Netzwerk verwenden, hängt die Konnektivität gegebenenfalls von der Verbindung SLA zwischen Ihnen und dem Dienstanbieter ab. Denken Sie bei der Entwicklung hybrider Konnektivität daran, dass das gesamte Hybridnetzwerk genauso gut ist wie der schwächste Teil davon. 

 AWS Direct Connect Partner bieten AWS Direct Connect Konnektivität. Der Partner kann auf der Grundlage seines Produktangebots bis zum Demarkationspunkt SLA mit Servicegutschriften anbieten. AWS Die Option sollte direkt mit den Partnern evaluiert und weiter untersucht werden. APN AWS veröffentlicht [eine Liste validierter Lieferpartner](https://aws.amazon.com/directconnect/partners/). 

 **Logischer Entwurf:** Neben dem Konnektivitätstyp müssen Sie bei Ihrem Gesamtentwurf auch andere Bausteine berücksichtigen. Als Beispiel [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/sla/)hat es seine eigenenSLA, ebenso wie [AWS S2S VPN](https://aws.amazon.com/vpn/site-to-site-vpn-sla/). Möglicherweise verwenden Sie AWS Transit Gateway for Scale und AWS S2S aus VPN Sicherheitsgründen, aber Sie müssen beide so gestalten, dass sie jeweils einheitlich sind, SLAs um Anspruch auf Servicegutschriften für den jeweiligen Service zu haben. 

Lesen Sie die [AWS Direct Connect Resilienz-Empfehlungen und das [Resiliency](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html)](https://aws.amazon.com/directconnect/resiliency-recommendation/) Toolkit. 

![\[Diagramm, das einen Entscheidungsbaum für Überlegungen SLA zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/sla-decision-tree.png)


# Leistung
<a name="performance"></a>

## Definition
<a name="definition-perf"></a>

 Es gibt mehrere Faktoren, die die Netzwerkleistung beeinflussen, wie Latenz, Paketverlust, Jitter und Bandbreite. Je nach Anwendungsanforderungen kann die Bedeutung der einzelnen Faktoren variieren. 

## Die wichtigsten Fragen
<a name="key-questions-perf"></a>

 Auf der Grundlage Ihrer Anwendungsanforderungen müssen Sie die Netzwerkleistungsfaktoren identifizieren und priorisieren, die sich auf Ihr Anwendungsverhalten und Ihre Benutzererfahrung auswirken. 

### Bandbreite
<a name="bandwidth"></a>

 *Bandbreite* bezieht sich auf die Datenübertragungsrate einer Verbindung und wird normalerweise in Bit pro Sekunde (bps) gemessen. Megabit pro Sekunde (Mbit/s) und Gigabit pro Sekunde (Gbit/s) sind übliche Skalierungen und entsprechen der Basis 10 (1.000.000 Bit pro Sekunde = 1 Mbit/s) im Gegensatz zur Basis 2 (2^10), wie man sie an anderer Stelle findet. 

 Beachten Sie bei der Bewertung des Bandbreitenbedarfs von Anwendungen, dass sich die Bandbreitenanforderungen im Laufe der Zeit ändern können. Die anfängliche Bereitstellung in der Cloud, der normale Betrieb, neue Workloads und Failover-Szenarien können alle unterschiedliche Bandbreitenanforderungen haben. 

 Für Anwendungen können eigene Überlegungen zur Bandbreite gelten. Einige Anwendungen erfordern möglicherweise eine deterministische Leistung über eine Verbindung mit hoher Bandbreite, während andere sowohl eine deterministische Leistung als auch eine hohe Bandbreite erfordern können. Eine Anwendung benötigt möglicherweise eine spezielle Konfiguration, um mehrere Verkehrsflüsse (manchmal auch als Streams oder Sockets bezeichnet) parallel zu verwenden, wenn sie die Bandbreitenbeschränkungen pro Verkehrsfluss erreicht, sodass sie einen größeren Teil der Verbindungsbandbreite nutzen kann. VPNskann den Durchsatz aufgrund von Tunnelkosten, niedrigeren MTU Grenzwerten oder Beschränkungen der Hardwarebandbreite einschränken. 

### Latency
<a name="latency"></a>

*Latenz* ist die Zeit, die ein Paket benötigt, um über eine Netzwerkverbindung von der Quelle zum Ziel zu gelangen. Sie wird normalerweise in Millisekunden (ms) gemessen, wobei niedrige Latenzanforderungen manchmal in Mikrosekunden (μs) ausgedrückt werden. Die Latenz ist eine Funktion der Lichtgeschwindigkeit, daher nimmt die Latenz mit der Entfernung zu. 

 Die Latenzanforderungen für Anwendungen können unterschiedliche Formen annehmen. Bei einer hochgradig interaktiven Anwendung, wie z. B. einem virtuellen Desktop, kann ein Latenzziel festgelegt werden, das vom Zeitpunkt der Benutzereingabe bis zum Zeitpunkt der Reaktion des virtuellen Desktops auf diese Eingabe gemessen wird. Voice over IP (VoIP) -Anwendungen können ähnliche Anforderungen haben. Eine zweite Art von Workloads, die in Betracht gezogen werden sollten, sind solche, die in hohem Maße transaktionaler Natur sind und eine Antwort vom Server benötigen, bevor sie fortgesetzt werden können. Datenbanken oder andere Arten von Schlüssel-/Wertespeichern können durch eine erhöhte Netzwerklatenz stark beeinträchtigt werden. 

### Jitter
<a name="jitter"></a>

*Jitter* misst, wie konsistent die Netzwerklatenz ist, und wird ebenso wie die Latenz normalerweise in Millisekunden (ms) gemessen. 

 Anwendungs-Jitter-Anforderungen finden sich in der Regel in Echtzeit-Streaming-Anwendungen, einschließlich Video- und Sprachübertragung. Bei diesen Anwendungen ist in der Regel ein gleichbleibender Datenfluss mit gleichbleibender Geschwindigkeit und Verzögerung sowie kleine Puffer zur Korrektur geringer Jittermengen erforderlich. 

### Verlust von Paketen
<a name="packet-loss"></a>

*Paketverlust* ist das Maß dafür, wie viel Prozent des Netzwerkverkehrs nicht zugestellt werden. In allen Netzwerken kommt es manchmal zu einem gewissen Grad an Paketverlust, was auf hohe Datenverkehrsspitzen, Kapazitätsreduzierungen, Netzwerkausfälle und andere Gründe zurückzuführen ist. Daher müssen Anwendungen eine gewisse Toleranz gegenüber Paketverlusten aufweisen. Wie viel sie tolerieren können, kann jedoch von Anwendung zu Anwendung variieren. 

 Anwendungen, die ihren Datenverkehr TCP zum Transport verwenden, können Paketverluste durch erneute Übertragung korrigieren. Anwendungen, die zusätzlich zu IP eigene Protokolle verwendenUDP, müssen ihre eigenen Methoden zur Behandlung von Paketverlusten implementieren und reagieren möglicherweise sehr empfindlich darauf. Eine Voice-over-IP-Anwendung kann den Teil des Anrufs, bei dem das Paket verloren gegangen ist, einfach zum Schweigen bringen, anstatt eine erneute Übertragung zu versuchen. Einige VPN Lösungen verfügen über eigene Mechanismen zur Wiederherstellung nach einem Paketverlust in dem Netzwerk, das sie für die Übertragung des Datenverkehrs verwenden. 

## Zu berücksichtigende Fähigkeiten
<a name="capabilities-to-consider-perf"></a>

 Wenn vorhersehbare Latenz und Durchsatz erforderlich sind, AWS Direct Connect ist dies die empfohlene Wahl, da sie eine deterministische Leistung bietet. Die Bandbreite kann auf der Grundlage der Durchsatzanforderungen ausgewählt werden. AWS empfiehlt die Verwendung AWS Direct Connect , wenn Sie ein konsistenteres Netzwerkerlebnis benötigen, als es internetbasierte Verbindungen bieten können. Private VIFs und Transit VIFs unterstützen Jumbo-Frames, wodurch die Anzahl der Pakete im Netzwerk reduziert und der Durchsatz aufgrund des geringeren Overheads verbessert werden kann. AWS Direct Connect [SiteLink](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/)ermöglicht die Nutzung des AWS Backbones zur Bereitstellung von Konnektivität zwischen Ihren Standorten und kann bei Bedarf aktiviert werden. Die verwendete Bandbreite SiteLink sollte bei Ihrer Direct Connect-Bandbreitenauswahl berücksichtigt werden. 

 Durch die Verwendung eines VPN Overs AWS Direct Connect wird die Verschlüsselung hinzugefügt. Dadurch wird jedoch die MTU Größe reduziert, was den Durchsatz verringern könnte. AWS Verwaltete VPN Funktionen Site-to-Site (S2S) finden Sie in der [AWS Site-to-Site VPN Dokumentation](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html). Viele Direct Connection-Standorte unterstützen, MACsec ob die Verschlüsselung über Ihre Verbindung die primäre Verschlüsselungsanforderung ist. MACsechat nicht den gleichen MTU oder den potenziellen Durchsatz von Site-to-Site VPN Verbindungen. AWS Transit Gateway ermöglicht es Kunden, die Anzahl der VPN Verbindungen horizontal zu skalieren und den Durchsatz mit gleichwertigem Mehrweg-Routing () entsprechend zu erhöhen. ECMP AWS Das verwaltete Site-to-Site VPN System unterstützt die Verwendung von Direct Connect Transit VIFs für private Konnektivität. Weitere Informationen finden Sie unter [Private IP VPN mit AWS Direct Connect](https://docs.aws.amazon.com/vpn/latest/s2svpn/private-ip-dx.html). 

 Eine weitere Option ist die Verwendung einer Site-to-Site VPN über das Internet AWS verwalteten Verbindung. Es kann aufgrund der geringen Kosten eine attraktive Option sein und ist allgemein verfügbar. Beachten Sie jedoch, dass die Leistung über das Internet am besten ist. Wetterereignisse, Staus und erhöhte Latenzzeiten im Internet können unvorhersehbar sein. AWS bietet eine Lösung mit [AWS Accelerated S2S VPN](https://aws.amazon.com/blogs/architecture/improve-vpn-network-performance-of-aws-hybrid-cloud-with-global-accelerator/), mit der einige der Nachteile der Nutzung eines Internetpfads gemildert werden können. Accelerated S2S VPN verwendet AWS Global Accelerator, wodurch der VPN Datenverkehr so früh und so nah wie möglich am Kunden-Gateway-Gerät in das AWS Netzwerk gelangen kann. Dadurch wird der Netzwerkpfad optimiert, indem das AWS globale Netzwerk ohne Überlastung genutzt wird, um den Datenverkehr an den Endpunkt weiterzuleiten, der die beste Leistung bietet. Sie können beschleunigte VPN Verbindungen verwenden, um Netzwerkunterbrechungen zu vermeiden, die auftreten können, wenn der Datenverkehr über das öffentliche Internet geleitet wird. 

# Kosten
<a name="cost"></a>

## Definition
<a name="definition-cost"></a>

 In der Cloud beinhalten die Kosten für Hybridkonnektivität die Kosten für bereitgestellte Ressourcen und deren Nutzung. Die Kosten der bereitgestellten Ressourcen werden in Zeiteinheiten gemessen, normalerweise stündlich. Die Nutzung wird für die Datenübertragung und -verarbeitung in der Regel in Gigabyte (GB) angegeben. Zu den weiteren Kosten gehören die Kosten für die Konnektivität zum AWS Netzwerkpoint of Presence. Wenn sich Ihr Netzwerk in derselben Colocation-Einrichtung befindet, sind die Kosten möglicherweise so gering wie die Kosten für eine Cross-Connect-Verbindung. Wenn sich Ihr Netzwerk an einem anderen Standort befindet, fallen Kosten für einen Dienstanbieter oder einen APN Direct Connect-Partner an. 

## Die wichtigsten Fragen
<a name="key-questions-cost"></a>
+  Wie viele Daten werden voraussichtlich AWS pro Monat aus Ihrer Einrichtung und aus dem Internet gesendet? 
+  Wie viele Daten werden voraussichtlich AWS pro Monat an Ihre Einrichtung und das Internet gesendet? 
+  Wie oft werden sich diese Beträge ändern? 
+  Was ändert sich in einem Ausfallszenario? 

## Zu berücksichtigende Fähigkeiten
<a name="capabilities-to-consider-cost"></a>

 Wenn Sie bandbreitenintensive Workloads haben, die Sie ausführen möchten AWS, AWS Direct Connect können Sie Ihre Netzwerkkosten auf zweierlei Weise senken. AWS Erstens können Sie durch die AWS direkte Übertragung von Daten zu und von dort die Bandbreitenkosten senken, die Sie an Ihren Internetdienstanbieter zahlen. Zweitens werden alle Daten, die über Ihre dedizierte Verbindung übertragen werden, mit der reduzierten AWS Direct Connect Datenübertragungsrate und nicht mit den Internet-Datenübertragungsraten berechnet. Weitere Informationen finden Sie auf der [Seite mit den Direct Connect-Preisen](https://aws.amazon.com/directconnect/pricing/). 

 AWS Direct Connect ermöglicht die Nutzung von AWS Direct Connect SiteLink , um Ihre Standorte über den AWS Backbone miteinander zu verbinden. Weitere Informationen finden Sie [im SiteLink Launch-Blog](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/). Wenn Sie diese Funktion nutzen, fallen normale Direct Connect-Datenübertragungskosten an, und es SiteLink ist eine Gebühr pro Stunde aktiviert. Sie können sie bei SiteLink Bedarf aktivieren und deaktivieren. Dies ist möglicherweise eine gute Option für Ausfallszenarien, die das Internet oder private Netzwerkkonnektivität betreffen. 

 Wenn Sie einen Netzwerkdienstanbieter für die Konnektivität zwischen einem lokalen Standort und einem Direct Connect-Standort verwenden, hängen Ihre Fähigkeit und der Zeitaufwand für die Änderung Ihrer Bandbreitenverpflichtungen von Ihrem Vertrag mit dem Dienstanbieter ab. 

 Der AWS Backbone kann Ihren Datenverkehr von jedem AWS Netzwerkpräsenzpunkt aus in alle Länder AWS-Region außer China weiterleiten. Diese Funktion bietet viele technische Vorteile gegenüber der Nutzung des Internets für den Fernzugriff AWS-Regionen, ist jedoch mit Kosten verbunden. Weitere Informationen finden Sie auf der [Preisseite für EC2 Datenübertragungen](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer). Wenn [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/pricing/)im Verkehrspfad eine vorhanden ist, fallen die Datenverarbeitungskosten pro GB an. Wenn Sie jedoch regionsübergreifendes Peering zwischen zwei Transit Gateways verwenden, wird Ihnen die Transit Gateway Gateway-Datenverarbeitung nur einmal in Rechnung gestellt. 

 Ein optimales Anwendungsdesign sorgt dafür, dass die Datenverarbeitung im Rahmen bleibt AWS und unnötige Gebühren für den Datenausgang minimiert werden. Der Datenzugriff auf ist kostenlos. AWS 

**Anmerkung**  
Als Teil der gesamten Konnektivitätslösung sollten Sie neben den AWS Verbindungskosten auch die Kosten für die end-to-end Konnektivität berücksichtigen, einschließlich der Kosten für den Dienstanbieter, Querverbindungen, Racks und Ausrüstung am DX-Standort (falls erforderlich). 

 Wenn Sie sich nicht sicher sind, ob Sie das Internet oder eine private Verbindung nutzen sollten, berechnen Sie eine Gewinnschwelle, bei der es AWS Direct Connect günstiger ist als die Nutzung des Internets. Wenn das Datenvolumen bedeutet, dass dies günstiger AWS Direct Connect ist und Sie eine permanente Konnektivität benötigen, AWS Direct Connect ist dies die optimale Verbindungsoption. 

 Wenn die Konnektivität temporär ist und das Internet andere Anforderungen erfüllt, kann es aufgrund der Elastizität des Internets günstiger sein, AWS S2S VPN über das Internet zu verwenden. Beachten Sie, dass hierfür eine ausreichende Internetverbindung über Ihr lokales Netzwerk erforderlich ist. 

 Wenn Sie sich in einer Einrichtung befinden, in der dies der AWS Direct Connect Fall ist (die Liste ist [auf der Direct Connect-Website verfügbar](https://aws.amazon.com/directconnect/locations/)), können Sie eine Cross-Connect-Verbindung zu AWS einrichten. Das bedeutet, dass Sie dedizierte Verbindungen mit 1,10 oder 100 Gbit/s verwenden müssen. AWS Direct Connect Partner bieten mehr Bandbreitenoptionen und kleinere Kapazitäten, wodurch Ihre Verbindungskosten optimiert werden können. Sie können beispielsweise mit einer gehosteten Verbindung mit 50 Mbit/s beginnen und nicht mit einer dedizierten Verbindung mit 1 Gbit/s. 

 Mit AWS Transit Gateway können Sie Ihre VPN und Direct Connect-Verbindungen mit vielen teilenVPCs. Ihnen werden zwar die Anzahl der Verbindungen, die Sie AWS Transit Gateway pro Stunde herstellen, und die Menge des durchfließenden Datenverkehrs in Rechnung gestellt AWS Transit Gateway, aber das vereinfacht die Verwaltung und reduziert die Anzahl der VIFs benötigten VPN Verbindungen. Die Vorteile und Kosteneinsparungen eines geringeren Betriebskosten können die zusätzlichen Kosten der Datenverarbeitung leicht aufwiegen. Optional können Sie ein Design in Betracht ziehen, bei dem AWS Transit Gateway die meistenVPCs, aber nicht alle Verkehrswege erreicht werden. Dieser Ansatz vermeidet die AWS Transit Gateway Datenverarbeitungsgebühren für Anwendungsfälle, in die Sie große Datenmengen übertragen müssen AWS. Weitere Informationen zu diesem Design finden Sie im Abschnitt Konnektivitätsmodelle. Ein anderer Ansatz ist die Kombination AWS Direct Connect als primärer Pfad mit AWS S2S VPN über das Internet als Backup-/Failover-Pfad. Diese Lösung ist zwar technisch machbar und sehr kostengünstig, hat aber auch technische Nachteile (die im Abschnitt Zuverlässigkeit dieses Whitepapers behandelt werden) und kann schwieriger zu verwalten sein. AWS [empfiehlt dies nicht für sehr kritische oder kritische Workloads](https://aws.amazon.com/directconnect/resiliency-recommendation/). 

 Der letzte Ansatz ist eine vom Kunden verwaltete VPN oder WAN SD-bereitgestellte Lösung in EC2 Amazon-Instance (s). Dies kann im Vergleich zu AWS VPN S2S in großem Maßstab günstiger sein, wenn es Dutzende bis Hunderte von Standorten gibt. Für jede virtuelle Appliance müssen jedoch Verwaltungsaufwand, Lizenzkosten und EC2 Ressourcenkosten berücksichtigt werden. 

## Entscheidungsmatrix
<a name="decision-matrix"></a>

*Tabelle 3 — Beispiele für Designeingaben von Corp. für Automobilkonnektivität*


|  Kategorie  |  Vom Kunden verwaltet VPN oder SD- WAN  |  AWS S2S VPN  |  AWS Beschleunigtes S2S VPN  |  AWS Direct Connect Gehostete Verbindung  |  AWS Direct Connect Dedizierte Verbindung  | 
| --- | --- | --- | --- | --- | --- | 
|  Erfordert eine Internetverbindung  |  Ja  |  Ja  |  Ja  |  Nein  |  Nein  | 
|  Kosten für bereitgestellte Ressourcen  |  EC2Instanz- und Softwarelizenzierung  |  [AWS S2S VPN](https://aws.amazon.com/vpn/pricing/)  |  [AWS[S2S VPN und Global Accelerator AWS](https://aws.amazon.com/global-accelerator/pricing/)](https://aws.amazon.com/vpn/pricing/)  |  [Anwendbarer Kapazitätsanteil der Hafenkosten](https://aws.amazon.com/directconnect/pricing/)  |  [Kosten für den dedizierten Port](https://aws.amazon.com/directconnect/pricing/)  | 
|  Kosten für die Datenübertragung  |  Internet-Tarif  |  Internet-Tarif oder Direct Connect-Tarif  |  Internet mit Premium-Datenübertragung  |  Rate für direkte Connect  |  Rate für direkte Connect  | 
|  Transit-Gateway  |  Optional  |  Optional  |  Erforderlich  |  Optional  |  Optional  | 
|  AWS Kosten für die Datenverarbeitung  |  N/A  |  Nur mit AWS Transit Gateway  |  Ja  |  Nur mit AWS Transit Gateway  |  Nur mit AWS Transit Gateway  | 
|  Kann übermäßig verwendet werden AWS Direct Connect?  |  Ja  |  Ja  |  Nein  |  N/A  |  N/A  | 

# Auswahl des Konnektivitätsdesigns
<a name="connectivity-design-selection"></a>

 In diesem Abschnitt des Whitepapers werden die Überlegungen behandelt, die sich auf die Auswahl Ihres Konnektivitätsdesigns auswirken. Das Konnektivitätsdesign umfasst die logischen Aspekte sowie die Frage, wie Sie die Zuverlässigkeit Ihrer Hybrid-Konnektivität entwerfen und optimieren können. 

 Die folgenden Überlegungen werden behandelt: Skalierbarkeit, Konnektivitätsmodelle, Zuverlässigkeit sowie kundenorientiertes Management VPN und SD-WAN. 

**Topics**
+ [Skalierbarkeit](scalability.md)
+ [Konnektivitätsmodelle](connectivity-models.md)
+ [Zuverlässigkeit](reliability.md)
+ [Vom Kunden verwaltet VPN und SD- WAN](customer-managed-vpn-and-sd-wan.md)

# Skalierbarkeit
<a name="scalability"></a>

## Definition
<a name="definition-sca"></a>

 Skalierbarkeit bezieht sich auf die Fähigkeit Ihrer Konnektivitätslösung, mit der Zeit zu wachsen und sich weiterzuentwickeln, wenn sich Ihre Anforderungen ändern. 

 Beim Entwerfen einer Lösung müssen Sie sowohl die aktuelle Größe als auch das erwartete Wachstum berücksichtigen. Dieses Wachstum kann organisches Wachstum sein oder auf eine schnelle Expansion zurückzuführen sein, z. B. bei Zusammenschlüssen und Übernahmen. 

 Hinweis: Je nach angestrebter Lösungsarchitektur müssen möglicherweise nicht alle oben genannten Elemente berücksichtigt werden. Sie können jedoch als grundlegende Elemente zur Identifizierung der Skalierbarkeitsanforderungen der meisten gängigen hybriden Netzwerklösungen dienen. Dieses Whitepaper konzentriert sich auf die Auswahl und das Design hybrider Konnektivität. Es wird empfohlen, auch den Umfang der Hybridkonnektivität in Bezug auf die VPC Netzwerkarchitektur zu berücksichtigen. Weitere Informationen finden Sie im Whitepaper [Aufbau einer skalierbaren und sicheren VPC AWS Multinetzwerkinfrastruktur](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html). 

## Die wichtigsten Fragen
<a name="key-questions-sca"></a>
+  Für welche Anzahl von ihnen ist derzeit und zu erwartenVPCs, dass Konnektivität zu einem oder mehreren lokalen Standorten erforderlich ist? 
+  Werden sie in einer AWS-Region oder mehreren Regionen VPCs eingesetzt? 
+  Mit wie vielen lokalen Standorten muss eine Verbindung hergestellt werden? AWS
+  Mit wie vielen Kunden-Gateway-Geräten (in der Regel Router oder Firewalls) müssen Sie pro Standort eine Verbindung herstellen? AWS
+  Wie viele Routen werden voraussichtlich bei Amazon beworben VPCs und wie viele Routen werden voraussichtlich von der AWS Seite empfangen? 
+  Muss die Bandbreite im AWS Laufe der Zeit erhöht werden? 

## Zu berücksichtigende Fähigkeiten
<a name="capabilities-to-consider-sca"></a>

 Die Skalierbarkeit ist ein wichtiger Faktor beim Design hybrider Konnektivität. Bis zu diesem Punkt wird der nachfolgende Abschnitt die Skalierung als Teil des Entwurfs eines gezielten Konnektivitätsmodells berücksichtigen. 

 Im Folgenden werden bewährte Methoden zur Minimierung der Skalenkomplexität des Designs hybrider Netzwerkkonnektivität empfohlen: 
+  Die Routenzusammenfassung sollte verwendet werden, um die Anzahl der beworbenen und empfangenen Routen zu reduzieren. AWS Daher muss das IP-Adressierungsschema so konzipiert sein, dass die Routenzusammenfassung optimal genutzt wird. Die Verkehrstechnik ist eine wichtige allgemeine Überlegung. Weitere Informationen zur Verkehrstechnik finden Sie im Unterabschnitt Verkehrstechnik im Abschnitt [Zuverlässigkeit](reliability.md). 
+  Minimiere die Anzahl der BGP Peering-Sitzungen, indem du DXGW mit VGW oder verwendest AWS Transit Gateway, wobei eine einzelne BGP Sitzung Konnektivität für mehrere bereitstellen kann. VPCs 
+  Ziehen Sie die Cloud in Betracht, WAN wenn mehrere AWS-Regionen und lokale Standorte miteinander verbunden werden müssen. 

# Konnektivitätsmodelle
<a name="connectivity-models"></a>

## Definition
<a name="definition-con"></a>

 Das Konnektivitätsmodell bezieht sich auf das Kommunikationsmuster zwischen lokalen Netzwerken und den Cloud-Ressourcen in AWS. Sie können Cloud-Ressourcen innerhalb eines Amazons VPC innerhalb einer AWS-Region oder mehrerer VPCs Regionen sowie AWS Dienste mit einem öffentlichen Endpunkt in einer oder mehreren Regionen bereitstellen AWS-Regionen, wie Amazon S3 und DynamoDB. 

## Die wichtigsten Fragen
<a name="key-questions-con"></a>
+  Besteht ein Bedarf an VPC Kommunikation innerhalb einer Region und zwischen Regionen? 
+  Besteht die Anforderung, direkt von lokalen Standorten aus auf AWS öffentliche Endgeräte zuzugreifen? 
+  Besteht eine Anforderung für den Zugriff auf AWS Dienste über VPC Endgeräte vor Ort? 

## Zu berücksichtigende Fähigkeiten
<a name="capabilities-to-consider-con"></a>

 Im Folgenden sind einige der gängigsten Szenarien für Konnektivitätsmodelle aufgeführt. Jedes Konnektivitätsmodell deckt Anforderungen, Eigenschaften und Überlegungen ab. 

 Hinweis: Wie bereits erwähnt, konzentriert sich dieses Whitepaper auf die hybride Konnektivität zwischen lokalen Netzwerken und. AWS Weitere Informationen zum Aufbau von Verbindungen finden Sie im VPCs Whitepaper [Aufbau einer skalierbaren und sicheren VPC AWS Multinetzwerkinfrastruktur](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html). 

**Topics**
+ [Definition](#definition-con)
+ [Die wichtigsten Fragen](#key-questions-con)
+ [Zu berücksichtigende Fähigkeiten](#capabilities-to-consider-con)
+ [AWS Beschleunigt Site-to-Site VPN — AWS Transit Gateway, einzeln AWS-Region](aws-accelerated-site-to-site-vpn-aws-transit-gateway-single-aws-region.md)
+ [AWS DX — DXGW mitVGW, einzelner Region](aws-dx-dxgw-with-vgw-single-region.md)
+ [AWS DX — DXGW mitVGW, mit mehreren Regionen und öffentlichem Peering AWS](aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.md)
+ [AWS DX — DXGW mit AWS Transit Gateway, mit mehreren Regionen und öffentlichem Peering AWS](aws-dx-dxgw-with-aws-transit-gateway-multi-regions-and-aws-public-peering.md)
+ [AWS DX — DXGW mit AWS Transit Gateway, mehreren Regionen (mehr als 3)](aws-dx-dxgw-with-aws-transit-gateway-multi-regions-more-than-3.md)

# AWS Beschleunigt Site-to-Site VPN — AWS Transit Gateway, einzeln AWS-Region
<a name="aws-accelerated-site-to-site-vpn-aws-transit-gateway-single-aws-region"></a>

 **Dieses Modell besteht aus:** 
+  Einzeln AWS-Region. 
+  AWS Verwaltete Site-to-Site VPN Verbindung mit AWS Transit Gateway. 
+  Beschleunigt VPN aktiviert. 

![\[Diagramm, das AWS Managed VPN — AWS Transit Gateway, Single zeigt AWS-Region\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/managed-vpn-tg-single-region.png)


 **Eigenschaften des Konnektivitätsmodells:** 
+  Bieten Sie die Möglichkeit, optimierte VPN Verbindungen über das öffentliche Internet mithilfe [AWS beschleunigter Site-to-Site VPN Verbindungen herzustellen](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html). 
+  Bieten Sie die Möglichkeit, eine höhere VPN Verbindungsbandbreite zu erreichen, indem Sie mehrere VPN Tunnel mit konfigurierenECMP. 
+  Kann für Verbindungen von mehreren entfernten Standorten aus verwendet werden. 
+  Bietet automatisiertes Failover mit dynamischem Routing (BGP). 
+  Mit AWS Transit Gateway connected to VPCs VPCs können alle verbundenen Benutzer dieselben VPN Verbindungen verwenden. Sie können auch das gewünschte Kommunikationsmodell zwischen den VPCs steuern. Weitere Informationen finden Sie unter [Funktionsweise von Transit-Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html). 
+  Bietet flexible Designoptionen zur Integration von Sicherheits- und WAN virtuellen SD-Geräten von Drittanbietern. AWS Transit Gateway Weitere Informationen finden Sie unter [Zentralisierte Netzwerksicherheit für den Datenverkehr VPC-to-VPC und den lokalen VPC Datenverkehr](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html). 

 **Überlegungen zur Skalierung:** 
+  Bis zu 50 Gbit/s Bandbreite bei mehreren ECMP konfigurierten IPsec Tunneln (jeder Datenfluss wird auf die maximale Bandbreite pro VPN Tunnel begrenzt). 
+  [Tausende](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html) davon VPCs können pro AWS Transit Gateway verbunden werden. 
+  Weitere Maßstabsgrenzen, wie z. B. die Anzahl der Routen, finden Sie in den [Site-to-Site VPNKontingenten](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html). 

 **Weitere Überlegungen:** 
+  Die zusätzlichen AWS Transit Gateway Verarbeitungskosten für die Datenübertragung zwischen dem lokalen Rechenzentrum und AWS. 
+  In Sicherheitsgruppen einer Remoteanlage VPC kann nicht referenziert werden AWS Transit Gateway — dies wird jedoch durch VPC Peering unterstützt. 

# AWS DX — DXGW mitVGW, einzelner Region
<a name="aws-dx-dxgw-with-vgw-single-region"></a>

 **Dieses Modell besteht aus:** 
+  Einzeln AWS-Region. 
+  Doppelte AWS Direct Connect Verbindungen zu unabhängigen DX-Standorten. 
+  AWS DXGWdirekt an die VPCs Nutzung angeschlossenVGW. 
+  Optionale Verwendung von AWS Transit Gateway für VPC Interkommunikation. 

![\[Das Diagramm zeigt AWS DX — DXGW mitVGW, Single AWS-Region\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/dxgw-with-vgw-single-region.png)


 **Eigenschaften des Konnektivitätsmodells:** 
+  Bietet die Möglichkeit, in future Verbindungen zu VPCs und DX-Verbindungen in anderen Regionen herzustellen. 
+  Bietet automatisiertes Failover mit dynamischem Routing (BGP). 
+  Mit können AWS Transit Gateway Sie das gewünschte Kommunikationsmodell zwischen den VPCs steuern. Weitere Informationen finden Sie unter [Funktionsweise von Transit-Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html). 

 **Überlegungen zur Skalierung:** 

 Weitere Informationen zu anderen Skalierungsbeschränkungen, wie z. B. der Anzahl der unterstützten Präfixe und der Anzahl VIFs pro DX-Verbindungstyp (dediziert, gehostet), finden Sie unter [AWS Direct Connect Kontingente](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html). Einige wichtige Überlegungen: 
+  In einer privaten BGP Sitzung VIF können jeweils bis zu 100 Routen für IPv4 und angekündigt IPv6 werden. 
+  Pro BGP Sitzung VPCs können bis zu 20 DXGW Verbindungen hergestellt werden. Wenn mehr als 20 benötigt VPCs werden, DXGWs können weitere hinzugefügt werden, um die Konnektivität im großen Maßstab zu erleichtern, oder erwägen Sie die Verwendung der Transit Gateway Gateway-Integration.
+  Zusätzliche AWS Direct Connect s können nach Wunsch hinzugefügt werden. 

 **Andere Überlegungen:** 
+  Es fallen keine AWS Transit Gateway entsprechenden Verarbeitungskosten für die Datenübertragung zwischen AWS und lokalen Netzwerken an. 
+  Es VPC kann nicht auf Sicherheitsgruppen einer Remote-Verbindung verwiesen werden AWS Transit Gateway (VPCPeering erforderlich). 
+  VPCPeering kann verwendet werden, anstatt die Kommunikation zwischen den AWS Transit Gateway Systemen zu erleichtern. Dies erhöht jedoch die VPCs betriebliche Komplexität, da eine große Anzahl von VPC point-to-point Peerings in großem Umfang aufgebaut und verwaltet werden muss. 
+  Wenn VPC Interkommunikation nicht erforderlich ist, ist bei diesem AWS Transit Gateway Konnektivitätsmodell weder VPC Peering noch Peering erforderlich. 

# AWS DX — DXGW mitVGW, mit mehreren Regionen und öffentlichem Peering AWS
<a name="aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering"></a>

**Dieses Modell besteht aus:**
+ Mehrere lokale Rechenzentren mit dualen Verbindungen zu AWS.
+  Doppelte AWS Direct Connect Verbindungen zu unabhängigen DX-Standorten. 
+  AWS DXGWdirekt an mehr als 10 Benutzer VPCs angeschlossenVGW, bis zu 20 VPCs BenutzerVGW. 
+  Optionale Verwendung von AWS Transit Gateway für die Kommunikation zwischen VPC und zwischen Regionen. 

![\[Das Diagramm zeigt AWS DX — DXGW mitVGW, Multi-Regionen und Public VIF\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/dxgw-with-vgw-multi-region-public-vif.png)


 **Eigenschaften des Konnektivitätsmodells:** 
+ AWS DXGWdirekt an mehr als 10 angeschlossen, VPCs wobei VGW bis zu 20 VPCs verwendet VGW werden können.
+  AWS DX public VIF wird verwendet, um direkt über die AWS DX-Verbindungen auf AWS öffentliche Dienste wie Amazon S3 zuzugreifen. 
+  Bieten Sie in future die Möglichkeit, Verbindungen zu VPCs und DX-Verbindungen in anderen Regionen herzustellen. 
+  Interregionale VPC und interregionale VPC Kommunikation, die durch AWS Transit Gateway Transit Gateway Gateway-Peering erleichtert wird. 

 **Überlegungen zur Skalierung:** 

 Weitere Informationen zu anderen Skalierungsbeschränkungen, wie z. B. der Anzahl der unterstützten Präfixe und der Anzahl VIFs pro DX-Verbindungstyp (dediziert, gehostet), finden Sie unter [AWS Direct Connect Kontingente](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html). Einige wichtige Überlegungen: 
+  In einer privaten BGP Sitzung VIF können jeweils bis zu 100 Routen für IPv4 und angekündigt IPv6 werden. 
+  In jeder privaten Sitzung VPCs können bis zu DXGW 20 Verbindungen pro BGP Sitzung verbunden werdenVIF, bis zu 30 private VIFs pro SitzungDXGW.
+  Zusätzliche AWS Direct Connect s können nach Wunsch hinzugefügt werden. 

 **Andere Überlegungen:** 
+  Es fallen keine AWS Transit Gateway entsprechenden Verarbeitungskosten für die Datenübertragung zwischen AWS und lokalen Netzwerken an. 
+  Auf Sicherheitsgruppen einer Fernbedienung VPC kann nicht verwiesen werden AWS Transit Gateway (VPCPeering ist erforderlich). 
+  VPCPeering kann anstelle von verwendet werdenVPCs, AWS Transit Gateway um die Kommunikation zwischen den Systemen zu erleichtern. Dies erhöht jedoch die betriebliche Komplexität, da VPC point-to-point Peering in großem Umfang aufgebaut und verwaltet werden muss. 
+  Wenn VPC Interkommunikation nicht erforderlich ist, ist bei diesem AWS Transit Gateway Konnektivitätsmodell weder VPC Peering noch Peering erforderlich. 

# AWS DX — DXGW mit AWS Transit Gateway, mit mehreren Regionen und öffentlichem Peering AWS
<a name="aws-dx-dxgw-with-aws-transit-gateway-multi-regions-and-aws-public-peering"></a>

**Dieses Modell besteht aus:**
+  Mehrfach AWS-Regionen. 
+  Doppelte AWS Direct Connect Verbindungen zu unabhängigen DX-Standorten. 
+  Ein einziges lokales Rechenzentrum mit dualen Verbindungen zu AWS. 
+  AWS DXGWmit AWS Transit Gateway. 
+  Hoher Maßstab VPCs pro Region. 

![\[Diagramm, das AWS DX zeigt — DXGW mit AWS Transit Gateway, Multi-Regionen und Public AWS VIF\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/dxgw-with-tg-multi-region-public-peering.png)


 **Eigenschaften des Konnektivitätsmodells:** 
+  AWS DX public VIF wird verwendet, um direkt über die AWS DX-Verbindungen auf AWS öffentliche Ressourcen wie S3 zuzugreifen. 
+  Bieten Sie in future die Möglichkeit, Verbindungen zu VPCs und/oder DX-Verbindungen in anderen Regionen herzustellen. 
+  Mit AWS Transit Gateway Connected to VPCs kann eine vollständige oder teilweise Mesh-Konnektivität zwischen den erreicht werdenVPCs. 
+  VPCKommunikation zwischen VPC und zwischen Regionen, die durch AWS Transit Gateway Peering erleichtert wird. 
+  Bietet flexible Designoptionen zur Integration von Sicherheits- und SDWAN virtuellen Appliances von Drittanbietern. AWS Transit Gateway Siehe: [Zentralisierte Netzwerksicherheit für den Datenverkehr VPC-to-VPC und den lokalen VPC Datenverkehr](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html). 

 **Überlegungen zur Skalierung:** 
+  Die Anzahl der Routen von und zu den Routen AWS Transit Gateway ist auf die maximal unterstützte Anzahl von Routen über einen Transit begrenzt VIF (eingehende und ausgehende Verbindungen variieren). Weitere Informationen zu den Skalenbeschränkungen und der unterstützten Anzahl von Routen und finden Sie in den [AWS Direct Connect Kontingenten](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html). VIFs 
+  Skalieren Sie in einer einzigen BGP Sitzung AWS Transit Gateway auf bis zu Tausende VPCs pro. 
+  Einzelner Transit VIF pro AWS DX. 
+  Zusätzliche AWS DX-Verbindungen können nach Wunsch hinzugefügt werden. 

 **Weitere Überlegungen:** 
+  Es fallen zusätzliche AWS Transit Gateway Verarbeitungskosten für die Datenübertragung zwischen einem Standort AWS und einem Standort vor Ort an. 
+  Auf Sicherheitsgruppen einer Remote-Verbindung VPC kann nicht verwiesen werden AWS Transit Gateway (VPCPeering erforderlich). 
+  VPCPeering kann anstelle von verwendet werdenVPCs, AWS Transit Gateway um die Kommunikation zwischen den Systemen zu erleichtern. Dies erhöht jedoch die betriebliche Komplexität, da VPC point-to-point Peering in großem Umfang aufgebaut und verwaltet werden muss. 

# AWS DX — DXGW mit AWS Transit Gateway, mehreren Regionen (mehr als 3)
<a name="aws-dx-dxgw-with-aws-transit-gateway-multi-regions-more-than-3"></a>

 **Dieses Modell besteht aus:** 
+  AWS-Regionen Mehrfach (mehr als 3). 
+  Zwei lokale Rechenzentren. 
+  Duale AWS Direct Connect Verbindungen zu unabhängigen DX-Standorten pro Region. 
+  AWS DXGWmit AWS Transit Gateway. 
+  Hoher Maßstab VPCs pro Region. 
+  Vollständiges Netz von Peering zwischen AWS Transit Gateway s. 

![\[Diagramm AWS Transit Gateway, das AWS DX — DXGW mit mehreren Regionen (mehr als drei) zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/dxgw-with-tg-multi-region.png)




 **Eigenschaften des Konnektivitätsmodells:** 
+  Niedrigster betrieblicher Overhead. 
+  AWS DX public VIF wird verwendet, um direkt über die AWS DX-Verbindungen auf AWS öffentliche Ressourcen wie S3 zuzugreifen. 
+  Bieten Sie in future die Möglichkeit, Verbindungen zu VPCs und DX-Verbindungen in anderen Regionen herzustellen. 
+  Mit AWS Transit Gateway Connected to VPCs kann eine vollständige oder teilweise Mesh-Konnektivität zwischen den erreicht werdenVPCs. 
+  Die VPC Kommunikation zwischen Regionen wird durch AWS Transit Gateway Peering erleichtert. 
+  Bietet flexible Designoptionen zur Integration von Sicherheits- und SDWAN virtuellen Appliances von Drittanbietern. AWS Transit Gateway Siehe: [Zentralisierte Netzwerksicherheit für den Datenverkehr VPC-to-VPC und den lokalen VPC Datenverkehr](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html). 

 **Überlegungen zur Skalierung:** 
+  Die Anzahl der Routen von und zu den Routen AWS Transit Gateway ist auf die maximal unterstützte Anzahl von Routen über einen Transit begrenzt VIF (eingehende und ausgehende Verbindungen variieren). Weitere Informationen zu den [AWS Direct Connect Staffelbeschränkungen finden Sie in den Kontingenten](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html). Ziehen Sie bei Bedarf eine Routenzusammenfassung in Betracht, um die Anzahl der Routen zu reduzieren. 
+  Skalieren Sie bis zu Tausende VPCs pro AWS Transit Gateway pro BGP Sitzung pro Sitzung DXGW (vorausgesetzt, die von den bereitgestellten AWS DX-Verbindungen bereitgestellte Leistung ist ausreichend). 
+  Pro DXGW Verbindung können bis zu sechs AWS Transit Gateway s angeschlossen werden. 
+  Wenn mehr als drei Regionen miteinander verbunden werden müssen AWS Transit Gateway, DXGWs sind weitere erforderlich. 
+  Einzelner Transit VIF pro AWS DX. 
+  Zusätzliche AWS DX-Verbindungen können nach Wunsch hinzugefügt werden. 

 **Weitere Überlegungen:** 
+  Es fallen zusätzliche AWS Transit Gateway Verarbeitungskosten für die Datenübertragung zwischen dem Standort vor Ort und an. AWS
+  Auf Sicherheitsgruppen einer Remote-Verbindung VPC kann nicht verwiesen werden AWS Transit Gateway (VPCPeering erforderlich). 
+  VPCPeering kann auch verwendet werdenVPCs, um die Kommunikation zwischen den Systemen AWS Transit Gateway zu erleichtern. Dies erhöht jedoch die betriebliche Komplexität, da eine große Anzahl von VPC point-to-point Peerings in großem Umfang aufgebaut und verwaltet werden muss. 

 Der folgende Entscheidungsbaum behandelt die Überlegungen zur Skalierbarkeit und zum Kommunikationsmodell: 

![\[Diagramm, das die Skalierbarkeit und den Entscheidungsbaum für das Kommunikationsmodell zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/scalability-communication-model-decision-tree.png)


**Anmerkung**  
Wenn für den ausgewählten Verbindungstyp in der Regel die Leistung berücksichtigt wirdVPN, sollte die Entscheidung getroffen werden, ob es sich bei dem VPN Endpunkt um eine AWS Transit Gateway AWS VPN S2S-Verbindung handelt AWS VGW. Falls noch nicht hergestellt, können Sie das erforderliche Kommunikationsmodell zwischen den und die Anzahl der VPC Verbindungen, die VPC an die VPN Verbindung (en) angeschlossen werden müssen, berücksichtigen, um Ihnen bei der Entscheidung zu helfen. 

# Zuverlässigkeit
<a name="reliability"></a>

## Definition
<a name="definition-rel"></a>

 Zuverlässigkeit bezieht sich auf die Fähigkeit eines Dienstes oder Systems, bei Bedarf die erwartete Funktion zu erfüllen. Die Zuverlässigkeit eines Systems kann anhand des Niveaus seiner Betriebsqualität innerhalb eines bestimmten Zeitraums gemessen werden. Im Gegensatz dazu steht Resilienz, die sich auf die Fähigkeit eines Systems bezieht, sich dynamisch und zuverlässig nach Infrastruktur- oder Serviceunterbrechungen zu erholen. 

 Weitere Informationen darüber, wie Verfügbarkeit und Resilienz zur Messung der Zuverlässigkeit verwendet werden, finden Sie in der [Zuverlässigkeitssäule](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) des AWS Well-Architected Framework. 

## Die wichtigsten Fragen
<a name="key-questions-7"></a>

### Verfügbarkeit
<a name="availability"></a>

 Verfügbarkeit ist der Prozentsatz der Zeit, für den eine Workload zur Verfügung steht. Zu den allgemeinen Zielen gehören 99% (3,65 Tage zulässige Ausfallzeit pro Jahr), 99,9% (8,77 Stunden) und 99,99% (52,6 Minuten), wobei die Anzahl der neun in dem Prozentsatz abgekürzt wird („zwei Neunen“ für 99%, „drei Neunen“ für 99,9% usw.). Die Verfügbarkeit der Netzwerklösung zwischen AWS und dem lokalen Rechenzentrum kann sich von der Verfügbarkeit der Gesamtlösung oder der Anwendung unterscheiden. 

 Zu den wichtigsten Fragen zur Verfügbarkeit einer Netzwerklösung gehören: 
+  Können meine AWS Ressourcen weiterarbeiten, wenn sie nicht mit meinen lokalen Ressourcen kommunizieren können? Umgekehrt? 
+  Sollte ich geplante Ausfallzeiten für geplante Wartungsarbeiten als in der Verfügbarkeitsmetrik eingeschlossen oder ausgeschlossen betrachten? 
+  Wie werde ich die Verfügbarkeit der Netzwerkschicht unabhängig vom allgemeinen Zustand der Anwendung messen? 

 Der [Abschnitt Verfügbarkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) des Well-Architected Framework Reliability Pillar enthält Vorschläge und Formeln für die Verfügbarkeit von Berechnungen. 

### Ausfallsicherheit
<a name="resiliency"></a>

 Unter Ausfallsicherheit versteht man die Fähigkeit einer Workload, sich von Infrastruktur- oder Serviceunterbrechungen zu erholen, Datenverarbeitungsressourcen dynamisch zur Erfüllung des Bedarfs anzufordern und Unterbrechungen zu minimieren, die beispielsweise aus Fehlkonfigurationen oder vorübergehenden Netzwerkproblemen entstehen. Wenn eine redundante Netzwerkkomponente (Link, Netzwerkgeräte usw.) nicht ausreichend verfügbar ist, um die erwartete Funktion eigenständig bereitzustellen, ist sie wenig widerstandsfähig gegenüber Ausfällen. Die Folge ist eine schlechte und verschlechterte Benutzererfahrung. 

 Zu den wichtigsten Fragen zur Ausfallsicherheit einer Netzwerklösung gehören: 
+  Mit wie vielen gleichzeitigen, diskreten Ausfällen sollte ich rechnen? 
+  Wie kann ich einzelne Fehlerquellen sowohl bei den Konnektivitätslösungen als auch bei meinem internen Netzwerk reduzieren? 
+  Was ist meine Sicherheitslücke gegenüber Distributed-Denial-of-Service (DDoS) -Ereignissen? 

## Technische Lösung
<a name="technical-solution"></a>

 Zunächst ist es wichtig zu beachten, dass nicht jede hybride Netzwerkverbindungslösung ein hohes Maß an Zuverlässigkeit erfordert und dass ein steigendes Maß an Zuverlässigkeit mit einem entsprechenden Anstieg der Kosten einhergeht. In einigen Szenarien sind für einen primären Standort möglicherweise zuverlässige (redundante und belastbare) Verbindungen erforderlich, da sich die Ausfallzeit stärker auf das Unternehmen auswirkt, wohingegen regionale Standorte aufgrund der geringeren Auswirkungen auf das Geschäft im Falle eines Ausfalls möglicherweise nicht dasselbe Maß an Zuverlässigkeit erfordern. Es wird empfohlen, sich an die [AWS Direct Connect Resilienz-Empfehlungen](https://aws.amazon.com/directconnect/resiliency-recommendation/) zu halten, da darin die AWS bewährten Methoden zur Sicherstellung einer AWS Direct Connect hohen Ausfallsicherheit beim Design erläutert werden. 

 Um eine zuverlässige hybride Netzwerkverbindungslösung im Kontext der Ausfallsicherheit zu erreichen, müssen beim Entwurf die folgenden Aspekte berücksichtigt werden: 
+  **Redundanz:** Ziel ist es, jeden einzelnen Fehlerpunkt im Hybrid-Netzwerkverbindungspfad zu eliminieren, einschließlich, aber nicht beschränkt auf Netzwerkverbindungen, Edge-Netzwerkgeräte, Redundanz zwischen Availability Zones und DX-Standorten sowie Gerätestromquellen, Glasfaserpfade und Betriebssysteme. AWS-Regionen Für Zweck und Umfang dieses Whitepapers konzentriert sich Redundanz auf die Netzwerkverbindungen, Edge-Geräte (z. B. Gateway-Geräte von Kunden), den AWS DX-Standort und AWS-Regionen (für Architekturen mit mehreren Regionen). 
+  **Zuverlässige Failover-Komponenten:** In einigen Szenarien ist ein System möglicherweise funktionsfähig, erfüllt seine Funktionen jedoch nicht auf dem erforderlichen Niveau. Eine solche Situation tritt häufig bei einem einzelnen Ausfall auf, bei dem festgestellt wird, dass geplante redundante Komponenten nicht redundant betrieben wurden. Ihre Netzwerklast kann aufgrund der Auslastung nicht an einen anderen Ort geleitet werden, was zu einer unzureichenden Kapazität für die gesamte Lösung führt. 
+  **Failover-Zeit:** Die Failover-Zeit ist die Zeit, die eine sekundäre Komponente benötigt, um die Rolle der primären Komponente vollständig zu übernehmen. Die Failover-Zeit hängt von mehreren Faktoren ab: wie lange es dauert, bis der Fehler erkannt wird, wie lange es dauert, die sekundäre Konnektivität zu aktivieren, und wie lange es dauert, bis der Rest des Netzwerks über die Änderung informiert wird. Die Fehlererkennung kann mithilfe von Dead Peer Detection (DPD) für VPN Links und Bidirectional Forwarding Detection (BFD) für AWS Direct Connect Links verbessert werden. Die Aktivierung der sekundären Konnektivität kann sehr kurz sein (wenn diese Verbindungen immer aktiv sind), es kann sich um ein kurzes Zeitfenster handeln (wenn eine vorkonfigurierte VPN Verbindung aktiviert werden muss) oder länger (wenn physische Ressourcen verschoben oder neue Ressourcen konfiguriert werden müssen). Die Benachrichtigung des restlichen Netzwerks erfolgt in der Regel über Routing-Protokolle innerhalb des Kundennetzwerks, von denen jedes unterschiedliche Konvergenzzeiten und Konfigurationsoptionen hat — deren Konfiguration würde den Rahmen dieses Whitepapers sprengen. 
+  **Verkehrstechnik:** Die Verkehrstechnik im Kontext eines robusten hybriden Netzwerkkonnektivitätsdesigns zielt darauf ab, zu regeln, wie der Verkehr in normalen Szenarien und in Ausfallszenarien über mehrere verfügbare Verbindungen fließen sollte. Es wird empfohlen, das Konzept des *Entwurfs für Ausfälle* zu befolgen, bei dem Sie prüfen müssen, wie die Lösung in verschiedenen Ausfallszenarien funktioniert und ob sie für das Unternehmen akzeptabel ist oder nicht. In diesem Abschnitt werden einige der häufigsten Anwendungsfälle der Verkehrstechnik erörtert, mit denen die allgemeine Ausfallsicherheit der hybriden Netzwerkkonnektivitätslösung verbessert werden soll. Dieser [AWS Direct Connect Abschnitt befasst sich BGP mit dem Routing und geht auf](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) verschiedene verkehrstechnische Optionen zur Beeinflussung des Verkehrsflusses ein (Gemeinden, BGP lokale Präferenz, AS-Pfadlänge). Um eine effektive verkehrstechnische Lösung zu entwickeln, müssen Sie genau wissen, wie die einzelnen AWS Netzwerkkomponenten das IP-Routing im Hinblick auf die Routenbewertung und -auswahl handhaben und welche Mechanismen zur Beeinflussung der Routenauswahl möglich sind. Die Einzelheiten dazu würden den Rahmen dieses Dokuments sprengen. Weitere Informationen finden Sie unter [Reihenfolge der Routenbewertung von Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview), [Site-to-Site VPNRoutenpriorität](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html#vpn-route-priority) und [Direct Connect-Routing sowie](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) bei Bedarf in der BGP Dokumentation. 

**Anmerkung**  
In der VPC Routentabelle können Sie auf eine Präfixliste verweisen, die zusätzliche Regeln für die Routenauswahl enthält. Weitere Informationen zu diesem Anwendungsfall finden Sie unter [Routenpriorität für Präfixlisten](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-tables-priority). AWS Transit Gateway Routentabellen unterstützen auch Präfixlisten, aber sobald sie angewendet sind, werden sie auf bestimmte Routeneinträge erweitert. 

## Beispiel für duale Site-to-Site VPN Verbindungen mit spezifischeren Routen
<a name="dual-site-to-site-vpn-connections-with-more-specific-routes-example"></a>

 Dieses Szenario basiert auf einer kleinen lokalen Site, die AWS-Region über redundante VPN Verbindungen über das Internet eine Verbindung zu AWS Transit Gateway einer einzigen herstellt. Das in Abbildung 10 dargestellte verkehrstechnische Design zeigt, dass Sie mit Hilfe der Verkehrstechnik die Pfadauswahl beeinflussen und so die Zuverlässigkeit der hybriden Konnektivitätslösung erhöhen können, indem Sie: 
+  Stabile Hybridkonnektivität: Redundante VPN Verbindungen bieten jeweils dieselbe Leistungskapazität, unterstützen automatisches Failover mithilfe des dynamischen Routing-Protokolls (BGP) und beschleunigen die Erkennung von Verbindungsausfällen mithilfe der VPN Dead-Peer-Erkennung. 
+  Leistungseffizienz: Die Konfiguration ECMP für beide VPN Verbindungen AWS Transit Gateway trägt zur Maximierung der gesamten VPN Verbindungsbandbreite bei. Alternativ kann die Last unabhängig von den beiden VPN Verbindungen verwaltet werden, indem verschiedene, spezifischere Routen zusammen mit der Site-Übersichtsroute angekündigt werden 

![\[Beispiel für ein Diagramm, das duale Site-to-Site VPN Verbindungen mit spezifischeren Routen zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/dual-s2s-example.png)


## Beispiel für zwei lokale Standorte mit mehreren DX-Verbindungen
<a name="dual-on-premises-sites-with-multiple-dx-connections-example"></a>

 Das in Abbildung 11 dargestellte Szenario zeigt zwei lokale Rechenzentrumsstandorte, die sich in unterschiedlichen geografischen Regionen befinden und über das Konnektivitätsmodell mit maximaler Resilienz (beschrieben in den [AWS Direct Connect Resilienzempfehlungen](https://aws.amazon.com/directconnect/resiliency-recommendation/)) AWS mithilfe von mit und verbunden sind. AWS Direct Connect DXGW VGW Diese beiden lokalen Standorte sind über einen Datencenter-Interconnect-Link () miteinander verbunden. DCI Die lokalen IP-Präfixe (192.168.0.0/16), die zu Remote-Zweigstellen gehören, werden von beiden lokalen Rechenzentrumsstandorten aus angekündigt. Der primäre Pfad für dieses Präfix sollte Rechenzentrum 1 sein. Bei einem Ausfall von Rechenzentrum 1 oder beiden DX-Standorten erfolgt ein Failover für den Datenverkehr zu und von den Remote-Zweigstellen auf Rechenzentrum 2. Außerdem gibt es für jedes Rechenzentrum ein standortspezifisches IP-Präfix. Diese Präfixe müssen direkt und über den anderen Rechenzentrumsstandort erreicht werden, falls beide DX-Standorte ausfallen. 

 Indem Sie BGP Community-Attribute mit den beworbenen Routen verknüpfen AWS DXGW, können Sie die Auswahl des Ausgangspfads von der Seite aus beeinflussen. AWS DXGW Diese Community-Attribute steuern AWS das BGP lokale Präferenzattribut, das der angekündigten Route zugewiesen ist. Weitere Informationen finden Sie unter AWS DX [Routing Policies and BGP Communities](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html). 

 Um die Zuverlässigkeit der Konnektivität auf dieser AWS-Region Ebene zu maximieren, wird jedes Paar von AWS DX-Verbindungen ECMP so konfiguriert, dass beide gleichzeitig für die Datenübertragung zwischen den einzelnen lokalen Standorten und verwendet werden können. AWS

![\[Beispiel für ein Diagramm mit zwei lokalen Standorten und mehreren DX-Verbindungen\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/dual-dx-example.png)


 Bei diesem Design werden die Datenflüsse, die für die lokalen Netzwerke bestimmt sind (mit derselben angekündigten Präfixlänge und BGP Community), auf die dualen DX-Verbindungen pro Standort verteilt. ECMP Wenn dies jedoch nicht für die gesamte DX-Verbindung erforderlich ECMP ist, kann dasselbe Konzept, das zuvor erörtert und in der Dokumentation zu [Routing-Richtlinien und BGP Communities](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) beschrieben wurde, verwendet werden, um die Pfadauswahl auf DX-Verbindungsebene weiter zu optimieren. 

 Hinweis: Wenn sich im Pfad innerhalb der lokalen Rechenzentren Sicherheitsgeräte befinden, müssen diese Geräte so konfiguriert werden, dass Datenströme, die über einen DX-Link gehen und von einem anderen DX-Link (beide Verbindungen werden verwendetECMP) innerhalb desselben Rechenzentrumsstandorts kommen, möglich sind. 

## VPNBeispiel für eine Verbindung als Backup zur AWS DX-Verbindung
<a name="vpn-connection-as-a-backup-to-aws-dx-connection-example"></a>

 VPNkann ausgewählt werden, um eine Backup-Netzwerkverbindung zu einer AWS Direct Connect Verbindung bereitzustellen. In der Regel wird diese Art von Konnektivitätsmodell durch die Kosten bestimmt, da es aufgrund der undeterministischen Leistung über das Internet eine geringere Zuverlässigkeit der gesamten hybriden Konnektivitätslösung bietet und für eine Verbindung über SLA das öffentliche Internet keine Garantie bietet. Es ist ein gültiges und kostengünstiges Konnektivitätsmodell und sollte verwendet werden, wenn die Kosten oberste Priorität haben und das Budget begrenzt ist, oder möglicherweise als Zwischenlösung, bis ein sekundärer DX bereitgestellt werden kann. Abbildung 12 zeigt den Entwurf dieses Konnektivitätsmodells. Eine wichtige Überlegung bei diesem Design, bei dem VPN sowohl die als auch die DX-Verbindung am enden AWS Transit Gateway, ist, dass die VPN Verbindung eine höhere Anzahl von Routen ankündigen kann als die, die über eine DX-Verbindung angekündigt werden können, mit der verbunden ist. AWS Transit Gateway Dies kann zu einer suboptimalen Routingsituation führen. Eine Option zur Lösung dieses Problems besteht darin, die Routenfilterung auf dem Kunden-Gateway-Gerät (CGW) für die über die VPN Verbindung empfangenen Routen zu konfigurieren, sodass nur die Übersichtsrouten akzeptiert werden. 

 Hinweis: Um die Übersichtsroute auf dem zu erstellen AWS Transit Gateway, müssen Sie eine statische Route zu einem beliebigen Anhang in der AWS Transit Gateway Routentabelle angeben, sodass die Zusammenfassung entlang der spezifischeren Route gesendet wird. 

 Aus Sicht der AWS Transit Gateway Routingtabelle werden die Routen für das lokale Präfix sowohl von der AWS DX-Verbindung (viaDXGW) als auch vonVPN, mit derselben Präfixlänge empfangen. Gemäß der [Route-Prioritätslogik von AWS Transit Gateway haben über Direct Connect empfangene Routen eine höhere Priorität](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview) als Routen Site-to-SiteVPN, die über sie empfangen werden, und daher AWS Direct Connect wird der Pfad über den bevorzugt, um die lokalen Netzwerke zu erreichen. 

![\[Diagramm, das eine VPN Verbindung als Backup zur AWS DX-Verbindung zeigt. Beispiel\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/vpn-as-backup-to-dx.png)


 Die folgende Entscheidungsstruktur hilft Ihnen dabei, die gewünschte Entscheidung zu treffen, um eine stabile Hybrid-Netzwerkkonnektivität zu erreichen (was zu einer zuverlässigen) Hybrid-Netzwerkkonnektivität führt. Weitere Informationen finden Sie im [AWS Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html). 

![\[Diagramm, das einen Entscheidungsbaum zur Zuverlässigkeit zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/hybrid-connectivity/images/reliability-decision-tree.png)


# Vom Kunden verwaltet VPN und SD- WAN
<a name="customer-managed-vpn-and-sd-wan"></a>

## Definition
<a name="definition-8"></a>

 Konnektivität zum Internet ist eine Selbstverständlichkeit, und die verfügbare Bandbreite nimmt von Jahr zu Jahr zu. Manche Kunden entscheiden sich dafür, ein virtuelles WAN System auf dem Internet aufzubauen, anstatt ein eigenes System aufzubauen und zu betreibenWAN. Ein softwaredefiniertes Wide Area Network (SD-WAN) ermöglicht es Unternehmen, dieses virtuelle Netzwerk WAN durch geschickten Einsatz von Software schnell bereitzustellen und zentral zu verwalten. Andere Kunden entscheiden sich für die traditionelle, von Standort zu Standort selbst verwaltete Lösung. VPNs 

## Auswirkungen auf Designentscheidungen
<a name="impact-on-design-decisions"></a>

 SD- WAN und kundenseitig verwaltete Systeme VPNs können über das Internet oder AWS Direct Connect ausgeführt werden. SD- WAN (oder ein beliebiges VPN Software-Overlay) ist genauso zuverlässig wie der zugrunde liegende Netzwerktransport. Daher sind die Zuverlässigkeit und die oben in diesem Whitepaper erörterten SLA Überlegungen auch hier anwendbar. Zum Beispiel bietet die Erstellung eines WAN SD-Overlays über das Internet nicht die gleiche Zuverlässigkeit wie wenn es über einem erstellt wird. AWS Direct Connect

## Definition der Anforderungen
<a name="requirement-definition"></a>
+  Verwenden Sie SD- WAN in Ihrem lokalen Netzwerk? 
+  Benötigen Sie bestimmte Funktionen, die nur auf bestimmten virtuellen Appliances verfügbar sind, die für die VPN Terminierung verwendet werden? 

## Technische Lösungen
<a name="technical-solutions-1"></a>

 AWS empfiehlt die Integration von SD AWS Transit Gateway- WAN mit und veröffentlicht eine Liste [der Anbieter, die die AWS Transit Gateway Integration unterstützen](https://aws.amazon.com/transit-gateway/network-manager/). AWS kann als Hub für WAN SD-Websites oder als Spoke-Site fungieren. Der AWS Backbone kann verwendet werden, um verschiedene WAN SD-Hubs zu verbinden, die in AWS einem äußerst zuverlässigen und leistungsstarken Netzwerk eingesetzt werden. WANSD-Lösungen unterstützen automatisiertes Failover über jeden verfügbaren Pfad sowie zusätzliche Überwachungs- und Beobachtungsfunktionen in einem einzigen Verwaltungsbereich. Der umfangreiche Einsatz von auto Konfiguration und Automatisierung ermöglicht eine schnelle Bereitstellung und Transparenz im Vergleich zu herkömmlichen WANs Systemen. Der Einsatz von Tunneling- und Verschlüsselungskosten ist jedoch nicht vergleichbar mit dedizierten Hochgeschwindigkeits-Glasfaserverbindungen, die für private Konnektivität verwendet werden. 

 In einigen Fällen können Sie sich dafür entscheiden, eine virtuelle Appliance mit entsprechender Funktionalität zu verwenden. VPN Zu den Gründen für die Wahl einer selbstverwalteten virtuellen Appliance gehören technische Funktionen und die Kompatibilität mit dem Rest Ihres Netzwerks. Wenn Sie sich für eine selbstverwaltete Lösung VPN oder eine WAN SD-Lösung entscheiden, die eine virtuelle Appliance verwendet, die in einer EC2 Instanz bereitgestellt wird, sind Sie für die Verwaltung dieser Appliance verantwortlich. Sie sind auch für die Hochverfügbarkeit und den Failover zwischen virtuellen Appliances verantwortlich. Ein solches Design erhöht Ihre betriebliche Verantwortung, könnte Ihnen jedoch mehr Flexibilität bieten. Die Funktionen und Fähigkeiten der Lösung hängen von der ausgewählten virtuellen Appliance ab. 

 AWS Marketplace enthält viele VPN virtuelle Appliances, die Kunden bei Amazon einsetzen könnenEC2. AWS empfiehlt, mit AWS verwaltetem S2S zu beginnen VPN und nach anderen Optionen zu suchen, falls es Ihren Anforderungen nicht entspricht. Der Verwaltungsaufwand virtueller Appliances liegt in der Verantwortung des Kunden. 