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.

Servicekunden, die vor Ort tätig sind

In diesem Abschnitt werden die Konnektivitätsoptionen zwischen SaaS-Workloads in den AWS Cloud und den lokalen Rechenzentren beschrieben. Viele Verbraucher mit lokalen Anforderungen, insbesondere auf Unternehmensebene, betrachten die Cloud als Erweiterung ihres physischen Netzwerks, und sie möchten dies in ihrer Architektur widerspiegeln. Das bedeutet private Konnektivität zum SaaS-Angebot in der Cloud, entweder über logische Tunnel oder sogar über eine private physische Verbindung. Andere Verbraucher werden Konnektivität über das öffentliche Internet akzeptieren, was ebenfalls in diesem Abschnitt erörtert wird.

In der folgenden Netzwerkwerteübersicht wird zusammengefasst, wie jede dieser Optionen bei jeder Bewertungsmetrik abschneidet. Weitere Informationen zu den Bewertungsmetriken finden Sie unter Bewertungskennzahlen in diesem Leitfaden. In der Übersicht steht eine Fünf für das beste Ergebnis, z. B. für die niedrigsten Gesamtbetriebskosten, die beste Netzwerkisolierung oder die kürzeste Reparaturzeit. Weitere Informationen zum Lesen dieses Radardiagramms finden Sie Wertübersicht der Netzwerke in diesem Handbuch.

Das Radardiagramm zeigt die folgenden Werte.

Verbindung herstellen mit AWS Site-to-Site VPN

AWS Site-to-Site VPNVerbindungen können entweder auf einem Virtual Private Gateway oder einem Transit-Gateway enden. Ein virtuelles privates Gateway ist der VPN-Endpunkt auf der AWS Seite Ihrer Site-to-Site VPN-Verbindung, der an eine einzelne VPC angeschlossen werden kann. Ein Transit-Gateway ist ein Transit-Hub, über den mehrere VPCs und lokale Netzwerke miteinander verbunden werden können. Es kann auch als VPN-Endpunkt für die AWS Seite der Site-to-Site VPN-Verbindung verwendet werden. In diesem Abschnitt werden beide Optionen beschrieben.

Verbindung über ein virtuelles privates Gateway

Nachdem Sie ein virtuelles privates Gateway erstellt haben, fügen Sie es der VPC hinzu, die Ihr SaaS-Angebot enthält. Anschließend aktivieren Sie die Route-Propagierung, um die VPN-Routen an die VPC-Routentabelle weiterzugeben. Bei diesen Routen kann es sich entweder um statische Routen oder um vom BGP angekündigte dynamische Routen handeln.

Um eine hohe Verfügbarkeit zu gewährleisten, verfügt eine Site-to-Site VPN-Verbindung über zwei VPN-Tunnel, die in zwei Availability Zones an der Seite enden. AWS Wenn einer nicht verfügbar ist, kann der zweite Tunnel die Kontrolle übernehmen. Ein einzelner Tunnel ermöglicht eine maximale Bandbreite von 1,25 Gbit/s. Da Virtual Private Gateways ECMP (Equal-Cost Multi-Path Routing) nicht unterstützen, können Sie jeweils nur einen Tunnel verwenden.

Um die Fehlertoleranz zu erhöhen, können Sie eine zweite VPN-Verbindung zu einem zweiten physischen Kunden-Gateway einrichten. Nachdem die Verbindung hergestellt wurde, kann der Verbraucher auf Ressourcen in der VPC des SaaS-Anbieters zugreifen.

Das folgende Diagramm zeigt diese Architektur.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Verbindung über ein Transit-Gateway

Verbindungen über Transit-Gateways ähneln virtuellen Gateways. Es sind jedoch einige Unterschiede zu beachten.

Erstens können Routen für den VPN-Anhang automatisch innerhalb der Routentabelle des Transit-Gateways weitergegeben werden, aber Sie müssen die Routen manuell zu den angehängten VPCs Routen hinzufügen.

Im Vergleich zu einem virtuellen Gateway unterstützt Transit Gateway ECMP. Wenn das Kunden-Gateway ECMP unterstützt, kann es beide Tunnel verwenden, um einen maximalen Gesamtdurchsatz von 2,5 Gbit/s zu erreichen. Sie können mehrere Verbindungen zwischen demselben lokalen Netzwerk und dem Transit-Gateway herstellen. Mit diesem Ansatz können Sie die maximale Bandbreite um bis zu 2,5 Gbit/s pro Verbindung erhöhen.

Das folgende Diagramm zeigt diese Architektur.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Verbindung herstellen mit AWS Direct Connect

AWS Direct Connectverbindet Ihr internes Netzwerk über ein Standard-Ethernet-Glasfaserkabel mit einem Direct Connect Standort. Im Gegensatz zu den anderen Architekturoptionen kann eine dedizierte Verbindung nicht in wenigen Minuten hergestellt werden. Stattdessen kann dieser Vorgang bis zu mehreren Tagen dauern, wenn alle Anforderungen erfüllt sind. Wenn nicht, kann es länger dauern. Wir empfehlen Ihnen daher, sich an Ihr AWS Account-Team zu wenden oder Hilfe AWS Support bei diesem Ansatz zu erhalten. Optional können Sie eine gehostete Verbindung wählen, die von einem AWS Partner bereitgestellt und mit anderen Kunden geteilt wird. Die Architektur ist trotzdem dieselbe. Sie könnten sich dafür entscheiden, Direct Connect weil sie die Latenz reduziert, die Bandbreite verbessert oder gesetzliche Anforderungen erfüllt.

Um die Direct Connect Verbindung nutzen zu können, müssen Verbraucher entweder eine öffentliche, eine private oder eine virtuelle Transitschnittstelle einrichten. Es stehen verschiedene Architekturoptionen zur Verfügung. Die flexibelste Methode, um mehrere lokale Standorte miteinander zu verbinden, AWS Cloud ist eine virtuelle Transitschnittstelle, die mit einem Direct Connect Gateway verbunden ist. Ein Direct Connect Gateway ist eine globale, logische Komponente, die es dem Dienstanbieter ermöglicht, bis zu sechs Transit-Gateways mit ihm zu verbinden. Darüber hinaus können Sie bis zu 30 virtuelle Schnittstellen mit dem Gateway verbinden. Zur Skalierung können Sie zusätzliche Direct Connect Gateways erstellen. Im SaaS-Anbieterkonto verbinden sich die Transit-Gateways dann VPCs, wie zuvor beschrieben, mit dem.

Verbraucher können je nach gewünschter Ausfallsicherheit über ein bis vier Direct Connect Verbindungen von insgesamt einem oder zwei Direct Connect Standorten aus eine Verbindung herstellen. Weitere Informationen finden Sie unter Konfiguration Direct Connect für maximale Ausfallsicherheit. Eine AWS Site-to-Site VPN Verbindung über das Internet kann auch als kostengünstigerer Backup-Pfad für eine Verbindung dienen. Direct Connect Unterstützte Direct Connect dedizierte Verbindungen können verwendet werden MACsec, um die Verbindung auf Layer 2 zwischen dem Direct Connect Standort und dem Rechenzentrum zu verschlüsseln. Es ist üblich, eine Site-to-Site VPN-Verbindung zu haben, um die Vertraulichkeit der Daten zu erhöhen. Die Site-to-Site VPN-Verbindung kann auf dem Transit-Gateway mithilfe eines normalen VPN-Anhangs beendet werden. Das folgende Diagramm zeigt diese Architektur.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Verbindung mit einer Transit-VPC-Architektur herstellen

Transit VPC ist eine Architekturoption, die den Verbrauchern Flexibilität bei der Art der Verbindung bietet und es SaaS-Anbietern ermöglicht AWS, von einem einheitlichen Zugriff auf ihren Service zu profitieren. AWS PrivateLink Der Verbraucher stellt von einem lokalen Standort aus eine Verbindung zu einer Transit-VPC her, die nur einen Einstiegspunkt (z. B. ein virtuelles privates Gateway) und einen VPC-Schnittstellen-Endpunkt enthält, bei dem es sich um eine AWS PrivateLink Ressource handelt. Der Transit VPCs sollte entweder dem SaaS-Anbieter oder den Verbrauchern gehören. In diesem Abschnitt werden beide Optionen beschrieben.

Sie können die Transit-VPC und Subnetze mit CIDR-Bereichen erstellen, die mit dem lokalen Rechenzentrum kompatibel sind. Wenn sie private Konnektivität benötigen, können Verbraucher über AWS Direct Connect oder AWS Site-to-Site VPN eine Verbindung zu dieser VPC herstellen. Sie können den Zugriff auf das Transitkonto auch vom öffentlichen Internet aus konfigurieren, indem Sie einen Application Load Balancer oder Network Load Balancer verwenden, der auf den VPC-Endpunkt verweist.

Von Verbrauchern verwaltete Transit-VPC

Bei diesem Ansatz überlässt der SaaS-Anbieter die Verwaltung des Transports VPCs den Verbrauchern. Aus technischer Sicht ist die Architektur des SaaS-Anbieters dieselbe wie bei der AWS Cloud durchgehenden Verbindung zu Verbrauchern AWS PrivateLink. Aus Vertriebs- und Produktsicht ist dies ein zusätzlicher Aufwand, da einige Verbraucher dies AWS-Konten noch nicht getan haben. Sie zögern möglicherweise, ein Konto zu eröffnen und zu führen. Der SaaS-Anbieter sollte seinen Verbrauchern Anleitungen zum Aufbau AWS-Konten und zur Verbindung ihres lokalen Rechenzentrums geben. Das folgende Diagramm zeigt eine Mischung aus öffentlichem und privatem Zugang, wobei die Verbraucher den Transit VPCs selbst bestimmen.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Anbieterverwaltete Transit-VPC

Bei diesem Ansatz werden dieselben Technologien verwendet, aber die Kontogrenzen und Verantwortlichkeiten ändern sich. Hier ist der SaaS-Anbieter Eigentümer des Transports VPCs, vorzugsweise in einem vom SaaS-Angebot getrennten Konto. Diese Entkopplung reduziert die Kosten, reduziert Risiken und ermöglicht es dem Transitkonto, unabhängig zu skalieren. In Umgebungen, die ein hohes Maß an Isolation erfordern, können Sie eine zusätzliche Trennung zwischen Mandanten herstellen, indem Sie ein Subnetz verwenden oder für jeden Verbraucher eine separate Transit-VPC erstellen. Die Verbraucher können dann wählen, wie sie eine Verbindung zur Transit-VPC herstellen möchten. Dieser Ansatz bietet mehr Optionen zur Erweiterung des gesamten adressierbaren Marktes, hat jedoch höhere Gesamtbetriebskosten für den SaaS-Anbieter, da zusätzliche Architekturkomponenten betrieben und überwacht werden müssen.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Verbindung über das öffentliche Internet herstellen

Der öffentliche Internetzugang ist auch eine gültige Option für den Zugang zu einem SaaS-Angebot, obwohl er keine private Konnektivität im herkömmlichen Sinne bietet. Einige Verbraucher bevorzugen möglicherweise immer noch einen Ansatz mit öffentlichem Zugriff, da dafür keine zusätzliche Netzwerkinfrastruktur zwischen ihnen und dem SaaS-Anbieter erforderlich ist. Es reduziert die Komplexität, die Kosten und die Integrationszeit und bietet im Gegenzug eine größere Angriffsfläche. Starke Authentifizierungs- und Autorisierungsmechanismen können dazu beitragen, das erhöhte Bedrohungsniveau zu verringern, und Sie sollten den Datenverkehr immer verschlüsseln. Es wird dennoch empfohlen, in diesem Szenario über eine zusätzliche Sicherheitsebene zu verfügen, z. B. durch die Verwendung von. AWS WAF

Die Architektur in diesem Szenario ist einfach. Der Verbraucher stellt über das Internet eine Verbindung zu einem öffentlichen Host (dem SaaS-Anbieter) her. Die Anwendung kann direkt auf einer öffentlichen Amazon Elastic Compute Cloud (Amazon EC2) -Instance mit einer Elastic IP-Adresse gehostet werden. Die bevorzugte Option besteht darin, es hinter einem Application Load Balancer oder einem ähnlichen Dienst zu hosten. Für eine bessere Leistung und das Zwischenspeichern statischer Ressourcen können Sie ein Content Delivery Network wie Amazon CloudFront verwenden. Um eine Anwendung mit minimaler Latenz über zwei globale statische Anycast-IP-Adressen bereitzustellen, können Sie sie vor einer Amazon EC2 EC2-Instance, einem Network Load Balancer oder einem Application Load Balancer platzieren AWS Global Accelerator. Darüber CloudFront hinaus lassen sich Application Load Balancers und Amazon API Gateway alle in integrieren AWS WAF. AWS AppSync Das folgende Diagramm bietet einen Überblick über die Verbindungsoptionen für den öffentlichen Internetzugang.

In der folgenden Tabelle werden die unterstützten Protokolle und Integrationen für dieses Szenario beschrieben.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Je nachdem, für welche Dienste Sie sich entscheiden, gelten weitere Vor- und Nachteile.