Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Scénarios d'accès réseau avancés pour les offres SaaS dans le AWS Cloud
Les architectures décrites dans Scénarios d'accès au réseau pour les offres SaaS dans le AWS Cloud cette section devraient vous aider à trouver une solution pour la majorité des cas d'utilisation. Cependant, certains scénarios présentent des exigences techniques spécifiques. Nombre d'entre eux dépassent le cadre de ce guide.
Cette section décrit les exigences et considérations techniques avancées suivantes :
Communication bidirectionnelle
Dans certains cas, les applications nécessitent un trafic bidirectionnel pour fonctionner comme prévu. Les cas d'utilisation courants sont les webhooks ou les services de notification. En général, vous pouvez y parvenir en établissant une WebSocket connexion entre le serveur et le client. Cette connexion maintient la session TCP ouverte et permet aux deux participants d'envoyer du trafic via la connexion. La plupart des services décrits dans ce guide sont pris en charge de manière native WebSocket, notamment les équilibreurs de charge réseau, les équilibreurs de charge d'application, Amazon API Gateway et AWS AppSync (via des points de AWS PrivateLink terminaison privés en temps réel).
Dans d'autres cas, une application du côté du fournisseur de SaaS peut avoir besoin d'accéder à des ressources côté consommateur, telles qu'une base de données. Lorsque vous vous connectez via des canaux bidirectionnels, tels qu'une AWS Site-to-Site VPN connexion, cela ne pose aucun problème.
D'autre part, AWS PrivateLink Elastic Load Balancing ne prend en charge que le trafic unidirectionnel. Si vous utilisez ces services, vous devez configurer un autre chemin réseau pour le trafic provenant de votre offre SaaS. Par exemple, il peut s'agir d'une AWS PrivateLink connexion supplémentaire qui va dans le sens inverse.
TCP, UDP et protocoles propriétaires
De nombreuses applications sont servies via HTTP ou HTTPS, mais pas toutes. Certains peuvent utiliser d'autres protocoles de couche 7 en plus du protocole TCP, tels que Message Queuing Telemetry Support (MQTT). D'autres pourraient même utiliser le protocole UDP pour servir les consommateurs. Dans de rares cas, les services utilisent des protocoles propriétaires qui doivent être transmis dans des paquets (couche 3). Pour ces scénarios, il est important de comprendre quels services prennent en charge votre offre SaaS.
Pour les services de couche 3, vous pouvez utiliser AWS PrivateLink des équilibreurs de charge réseau, qui prennent tous deux en charge l'ensemble du trafic TCP et UDP.
Pour les services de couche 7, les équilibreurs de charge d'application et Amazon CloudFront prennent en charge les protocoles HTTP WebSocket, HTTPS et Google Remote Procedure Calls (gRPC). De même, Amazon API Gateway et AWS AppSync chacun d'entre eux prennent en charge les protocoles HTTP, HTTPS et WebSocket. Amazon CloudFront est le seul service qui supporte actuellement le HTTP/3.
Vous pouvez utiliser Amazon VPC Lattice pour connecter des applications de couche 7 et des ressources de couche 3. Il prend en charge le transfert HTTP, HTTPS, gRPC, TCP et TLS.
Si l'application ne peut desservir le trafic que sur la couche 3, il est essentiel que vous utilisiez les services AWS réseau principaux, tels que AWS Transit Gateway, AWS Direct Connect AWS Site-to-Site VPN, et le peering VPC. Le trafic doit ensuite être acheminé directement du consommateur SaaS vers la couche de calcul de l'offre SaaS.
