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.

SaaS-Verbraucher, die auf AWS

In diesem Abschnitt werden die Konnektivitätsoptionen für den Fall beschrieben, dass sowohl Sie als auch Ihre Kunden in der AWS Cloud Dieses Szenario bietet die größte Flexibilität, da viele AWS-Services Systeme systemintern integriert sind und beide Parteien Zugriff auf das gesamte AWS-Service Portfolio haben.

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.

Integration mit AWS PrivateLink

AWS PrivateLinkist die Cloud-nativste Methode zur Integration eines SaaS-Angebots. SaaS-Anbieter können ihre Anwendung entweder hinter einem Network Load Balancer hosten. Der Network Load Balancer lässt sich direkt in einen Application Load Balancer, Amazon Elastic Container Service (Amazon ECS), AmazonElastic Kubernetes Service (Amazon EKS) und Auto Scaling Scaling-Gruppen integrieren. Es ist auch möglich, den Datenverkehr vom Network Load Balancer zu VPC-Endpunkten im SaaS-Anbieterkonto weiterzuleiten. Auf diese Weise können Sie eine API verwenden, um Anwendungen zu erreichen, z. B. über Amazon API Gateway oder AWS AppSync. Wenn Ihre Anwendung Zugriff auf Ressourcen in der Kundenumgebung benötigt, die keinen Lastenausgleich aufweisen, z. B. eine Datenbank, können Sie Ressourcen-VPC-Endpunkte verwenden.

AWS PrivateLink unterstützt eine Bandbreite von bis zu 100 Gbit/s pro Availability Zone. Das folgende Diagramm zeigt eine Grundkonfiguration mit einigen möglichen Integrationen. Es verbindet zwei Verbraucherkonten über das SaaS-Anbieterkonto AWS PrivateLink. Es gibt Dienstendpunkte in den Verbraucherkonten und einen Network Load Balancer im SaaS-Anbieterkonto.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Einen Amazon VPC Lattice-Service teilen

Um Amazon VPC Lattice als Konnektivitätsoption für Ihre SaaS-Anwendung zu verwenden, erstellen Sie zunächst einen oder mehrere VPC Lattice-Dienste, die Ihre SaaS-Anwendungskomponenten darstellen. Sie konfigurieren Listener und Routing-Regeln, um den Datenverkehr an Ihre Back-End-Ziele wie Amazon EC2 EC2-Instances, Container oder Funktionen weiterzuleiten. AWS Lambda Weitere Informationen finden Sie unter Verbinden von Saas-Diensten innerhalb eines VPC-Lattice-Dienstnetzwerks (AWS Blogbeitrag). Vom Konzept her entspricht dies fast der Konfiguration eines Application Load Balancer. Anschließend teilen Sie Ihren SaaS-Dienst sicher mit Kunden AWS-Konten oder Organisationen, indem Sie AWS Resource Access Manager (AWS RAM) verwenden und angeben, über welche Berechtigungen sie verfügen. Nachdem Kunden die gemeinsame Nutzung der Ressourcen akzeptiert haben, können sie Ihren SaaS-Service ihren bestehenden oder neu erstellten VPC-Lattice-Dienstnetzwerken zuordnen, um die Kommunikation zu ermöglichen service-to-service.

Jeder VPC Lattice-Dienst kann bis zu 10 Gbit/s und 10.000 Anfragen pro Sekunde pro Availability Zone unterstützen. Durch die Implementierung von Authentifizierungsrichtlinien können Ihre Kunden genau steuern, welche Dienste und Ressourcen auf die SaaS-Anwendung zugreifen können. Sie können Ressourcen-Gateways verwenden, um auf Ressourcen zuzugreifen, für die eine TCP-Verbindung erforderlich ist. Dies kann beispielsweise ein Amazon EKS-Cluster sein, den Sie verwalten, oder es könnte sich um eine vom Kunden verwaltete Ressource handeln, auf die Ihre Anwendung zugreifen muss. Weitere Informationen zur Verwendung von Ressourcen-Gateways für SaaS-Angebote finden Sie unter Erweitern der SaaS-Funktionen über die AWS-Konten Nutzung der AWS PrivateLink Unterstützung für VPC-Ressourcen (AWS Blogbeitrag).

Das folgende Diagramm zeigt eine VPC-Lattice-Konfiguration auf hoher Ebene mit einigen Beispielintegrationen. Es verwendet vom Kunden verwaltete Servicenetzwerke, um auf die SaaS-Anwendung zuzugreifen.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

VPC-Peering-Verbindungen erstellen

Wenn Sie VPC-Peering verwenden, um die VPC des SaaS-Anbieters mit der VPC des Verbrauchers zu verbinden, können beide Parteien Verbindungen initiieren. Dies erfordert die korrekte Konfiguration von Sicherheitsgruppen, Firewalls und Netzwerkzugriffskontrolllisten () in beiden Konten. NACLs Andernfalls könnte unerwünschter Datenverkehr über die Peering-Verbindung in das Netzwerk gelangen. Sie können Sicherheitsgruppen verwenden, um auf Sicherheitsgruppen von VPCs Peered zu verweisen. Dies kann Ihnen helfen, den Zugriff auf Ihre Anwendung zu kontrollieren, da Sicherheitsgruppen, die eine Zulassungsliste enthalten, eine explizitere und detailliertere Zugriffskontrolle bieten als IP-Adressen, die auf der Zulassungsliste stehen.

Mit VPC-Peering kann das SaaS-Angebot über einen Dienst oder eine Ressource erreicht werden, die in der VPC bereitgestellt werden. Die meisten SaaS-Anwendungen befinden sich hinter einem Application Load Balancer oder Network Load Balancer. AWS AppSync Private APIs oder Amazon API Gateway Private APIs sind weitere gängige Einstiegspunkte für SaaS-Anwendungen, da sie über eine Peering-Verbindung über Schnittstellen-VPC-Endpunkte als Ziel dienen können.

Nachdem Sie eine Peering-Verbindung hergestellt haben, müssen Sie die Routing-Tabellen für beide Konten aktualisieren, um die VPCs Peering-Verbindung als nächsten Hop für den jeweiligen CIDR-Bereich zu definieren. Diese Lösung wird nur für SaaS-Anbieter mit wenigen Verbrauchern empfohlen, da die Verwaltung mehrerer Peering-Verbindungen schnell zu komplex wird.

Das folgende Diagramm zeigt eine Grundkonfiguration mit einigen möglichen Integrationen. VPCs in zwei Verbraucherkonten besteht eine Peering-Verbindung mit einer VPC im SaaS-Anbieterkonto.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt:

Verbindung herstellen VPCs mit AWS Transit Gateway

Wenn Sie eine Verbindung VPCs herstellen AWS Transit Gateway, erstellt es VPC-Anlagen und stellt Netzwerkschnittstellen in den Subnetzen jeder Availability Zone bereit, die den Verkehr zur und von der VPC weiterleiten sollen. Es wird empfohlen, in jeder Availability Zone ein eigenes /28 Subnetz für den VPC-Anhang einzurichten. Weitere Informationen finden Sie unter Bewährte Entwurfsmethoden für Amazon VPC Transit Gateways. VPCs Sie benötigen eine aktualisierte Routentabelle, um Verkehr über die bereitgestellte Netzwerkschnittstelle zu senden, und die Transit Gateway Gateway-Routentabellen müssen entsprechend aktualisiert werden. In einer Konfiguration mit mehreren Mandanten möchten Sie, dass die VPC des SaaS-Anbieters eine Route zu allen Verbrauchern hat. VPCs Der Verbraucher VPCs sollte nur eine Route zur VPC des SaaS-Anbieters haben.

Transit Gateway ist von Haus aus hochverfügbar. Es unterstützt die Überwachung mit VPC Flow Logs, und die maximale Bandbreite für einen Transit Gateway Gateway-Anhang beträgt 100 Gbit/s pro Availability Zone. Wie beim VPC-Peering ermöglicht dieser Ansatz die VPC-Sicherheitsgruppenreferenzierung, wodurch die Zugriffskontrolle zwischen den Umgebungen vereinfacht wird.

Es gibt zwei Hauptoptionen, um Verbraucher mit Ihrem SaaS-Angebot mit Transit Gateway zu verbinden.

Option 1: RAM verwenden

Bei der ersten Option teilt der Dienstanbieter das Transit Gateway mithilfe von AWS Resource Access Manager (AWS RAM) mit den Verbrauchern. Auf diese Weise können die Verbraucher die VPC-Anhänge in ihren eigenen Konten bereitstellen. Das folgende Diagramm zeigt diese Option auf hoher Ebene.

Option 2: Peering-Transit-Gateways

Die zweite Option besteht darin, Ihr Transit-Gateway mit einem Transit-Gateway in den Konten der Verbraucher zu verbinden. Dies bietet Verbrauchern mehr Flexibilität, da sie jetzt die vollständige Kontrolle über die Routentabellen in ihrem Transit-Gateway haben. Sie könnten beispielsweise eine zentrale Inspektion zwischen dem Service und ihren Workloads einrichten. Ein Nachteil dieser Option besteht darin, dass nur statisches Routing zwischen Transit-Gateways unterstützt wird. Das folgende Diagramm zeigt diese Option auf hoher Ebene.

Diese Herangehensweise bietet folgende Vorteile:

Im Folgenden sind die Nachteile dieses Ansatzes aufgeführt: