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.
Erweiterte Netzwerkzugriffsszenarien für SaaS-Angebote in der AWS Cloud
Die in Netzwerkzugriffsszenarien für SaaS-Angebote in der AWS Cloud diesem Abschnitt erörterten Architekturen sollen Ihnen helfen, eine Lösung für die meisten Anwendungsfälle zu finden. Es gibt jedoch einige Szenarien mit spezifischen technischen Anforderungen. Viele gehen über den Rahmen dieses Handbuchs hinaus.
In diesem Abschnitt werden die folgenden fortgeschrittenen technischen Anforderungen und Überlegungen erörtert:
Bidirektionale Kommunikation
In einigen Fällen benötigen Anwendungen bidirektionalen Verkehr, um erwartungsgemäß zu funktionieren. Häufige Anwendungsfälle sind Webhooks oder Benachrichtigungsdienste. Im Allgemeinen können Sie dies erreichen, indem Sie eine WebSocket Verbindung zwischen dem Server und dem Client herstellen. Diese Verbindung hält die TCP-Sitzung offen und ermöglicht es beiden Teilnehmern, Datenverkehr über die Verbindung zu senden. Die meisten der in diesem Handbuch beschriebenen Dienste unterstützen nativ WebSocket, einschließlich Network Load Balancers, Application Load Balancers, Amazon API Gateway und AWS AppSync (über private Echtzeit-Endpunkte). AWS PrivateLink
In anderen Fällen benötigt eine Anwendung auf der SaaS-Anbieterseite möglicherweise Zugriff auf Ressourcen auf der Verbraucherseite, z. B. eine Datenbank. Wenn Sie eine Verbindung über bidirektionale Kanäle herstellen, z. B. eine AWS Site-to-Site VPN Verbindung, ist das kein Problem.
Andererseits unterstützt Elastic Load Balancing nur unidirektionalen Datenverkehr. AWS PrivateLink Wenn Sie diese Dienste verwenden, müssen Sie einen anderen Netzwerkpfad für den Datenverkehr einrichten, der von Ihrem SaaS-Angebot ausgeht. Dies kann beispielsweise eine zusätzliche AWS PrivateLink Verbindung sein, die in umgekehrter Richtung verläuft.
TCP, UDP und proprietäre Protokolle
Viele Anwendungen werden über HTTP oder HTTPS bedient, aber nicht alle. Einige verwenden möglicherweise zusätzlich zu TCP weitere Layer-7-Protokolle, z. B. Message Queuing Telemetry Support (MQTT). Andere könnten sogar UDP verwenden, um Verbraucher zu bedienen. In seltenen Fällen verwenden Dienste proprietäre Protokolle, die innerhalb von Paketen übertragen werden müssen (Schicht 3). Für diese Szenarien ist es wichtig zu verstehen, welche Dienste Ihr SaaS-Angebot unterstützen.
Für Layer-3-Dienste können Sie Network Load Balancer verwenden AWS PrivateLink , die beide den gesamten TCP- und UDP-Verkehr unterstützen.
Für Layer-7-Services CloudFront unterstützen Application Load Balancers und Amazon HTTP WebSocket, HTTPS und Google Remote Procedure Calls (gRPC). In ähnlicher Weise unterstützen Amazon API Gateway und AWS AppSync beide HTTP, HTTPS und WebSocket. Amazon CloudFront ist der einzige Dienst, der derzeit HTTP/3 unterstützt.
Sie können Amazon VPC Lattice verwenden, um Layer-7-Anwendungen und Layer-3-Ressourcen zu verbinden. Es unterstützt HTTP-, HTTPS-, gRPC-, TCP- und TLS-Passthrough.
Wenn die Anwendung Datenverkehr nur über Layer 3 bereitstellen kann, ist es wichtig, dass Sie zentrale AWS Netzwerkdienste wie, AWS Transit Gateway AWS Direct Connect AWS Site-to-Site VPN, und VPC-Peering verwenden. Der Datenverkehr sollte dann direkt vom SaaS-Verbraucher zur Rechenschicht des SaaS-Angebots weitergeleitet werden.
