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.

Consommateurs de solutions SaaS opérant sur AWS

Cette section décrit les options de connectivité si vous et vos clients opérez dans le AWS Cloud. Ce scénario offre la plus grande flexibilité, car bon nombre d'entre eux s'intègrent de Services AWS manière native et parce que les deux parties ont accès à l'ensemble du Service AWS portefeuille.

La carte des valeurs réseau suivante résume le score de chacune de ces options pour chaque métrique d'évaluation. Pour plus d'informations sur les mesures d'évaluation, consultez la section Mesures d'évaluation dans ce guide. Sur la carte, cinq représente le meilleur score, tel que le coût total de possession le plus faible, la meilleure isolation du réseau ou le délai de réparation le plus court. Pour plus d'informations sur la lecture de cette carte radar, consultez Carte des valeurs du réseau ce guide.

La carte radar montre les valeurs suivantes.

Intégration avec AWS PrivateLink

AWS PrivateLinkest le moyen le plus natif du cloud pour intégrer une offre SaaS. Les fournisseurs de SaaS peuvent héberger leur application soit derrière un Network Load Balancer. Le Network Load Balancer s'intègre directement à un Application Load Balancer, à Amazon Elastic Container Service (Amazon ECS), à Amazon Elastic Kubernetes Service(Amazon EKS) et à des groupes Auto Scaling. Il est également possible d'acheminer le trafic depuis le Network Load Balancer vers les points de terminaison VPC de l'interface dans le compte du fournisseur SaaS. Cela vous permet d'utiliser une API pour accéder à des applications, par exemple via Amazon API Gateway ou AWS AppSync. Si votre application nécessite l'accès à des ressources de l'environnement client qui ne sont pas équilibrées en termes de charge, telles qu'une base de données, vous pouvez utiliser des points de terminaison VPC de ressources.

AWS PrivateLink prend en charge une bande passante allant jusqu'à 100 Gbit/s par zone de disponibilité. Le schéma suivant montre une configuration de base avec quelques intégrations possibles. Il connecte deux comptes consommateurs au compte du fournisseur de SaaS via AWS PrivateLink. Il existe des points de terminaison de service dans les comptes des consommateurs et un Network Load Balancer dans le compte du fournisseur de services SaaS.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

Partage d'un service Amazon VPC Lattice

Pour utiliser Amazon VPC Lattice comme option de connectivité pour votre application SaaS, vous devez d'abord créer un ou plusieurs services VPC Lattice qui représentent les composants de votre application SaaS. Vous configurez les écouteurs et les règles de routage pour diriger le trafic vers vos cibles principales, telles que les instances, les conteneurs ou les fonctions Amazon EC2. AWS Lambda Pour plus d'informations, consultez Connecter des services Saas au sein d'un réseau de services VPC Lattice (AWS article de blog). D'un point de vue conceptuel, cela revient presque à configurer un Application Load Balancer. Ensuite, vous partagez votre service SaaS en toute sécurité avec le client Comptes AWS ou les organisations en utilisant AWS Resource Access Manager (AWS RAM), en spécifiant les autorisations dont ils disposent. Une fois que les clients ont accepté le partage des ressources, ils peuvent associer votre service SaaS à leurs réseaux de services VPC Lattice existants ou nouvellement créés pour permettre la communication. service-to-service

Chaque service VPC Lattice peut prendre en charge jusqu'à 10 Gbit/s et 10 000 demandes par seconde par zone de disponibilité. En mettant en œuvre des politiques d'authentification, vos clients peuvent avoir un contrôle précis sur les services et les ressources qui peuvent accéder à l'application SaaS. Vous pouvez utiliser des passerelles de ressources pour accéder aux ressources qui nécessitent une connexion TCP. Par exemple, il peut s'agir d'un cluster Amazon EKS que vous gérez ou d'une ressource gérée par le client à laquelle votre application doit accéder. Pour plus d'informations sur l'utilisation de passerelles de ressources pour les offres SaaS, consultez Étendre les fonctionnalités SaaS à Comptes AWS l'aide de la AWS PrivateLink prise en charge des ressources VPCAWS (article de blog).

Le schéma suivant montre une configuration VPC Lattice de haut niveau avec quelques exemples d'intégrations. Il utilise des réseaux de services gérés par le client pour accéder à l'application SaaS.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

Création de connexions d'appairage VPC

Lorsque vous utilisez le peering VPC pour connecter le VPC du fournisseur de SaaS au VPC du consommateur, les deux parties peuvent établir des connexions. Cela nécessite une configuration appropriée des groupes de sécurité, des pare-feux et des listes de contrôle d'accès réseau (NACLs) dans les deux comptes. Dans le cas contraire, du trafic indésirable risque d'entrer sur le réseau via la connexion d'appairage. Vous pouvez utiliser des groupes de sécurité pour référencer des groupes de sécurité issus de peered VPCs. Cela peut vous aider à contrôler l'accès à votre application, car les groupes de sécurité autorisés fournissent un contrôle d'accès plus explicite et plus précis que les listes d'adresses IP autorisées.

Avec le peering VPC, l'offre SaaS est accessible via un service ou une ressource déployés dans le VPC. La plupart des applications SaaS reposent sur un Application Load Balancer ou un Network Load Balancer. AWS AppSync private APIs ou Amazon API Gateway private APIs sont d'autres points d'entrée courants pour les applications SaaS, car ils peuvent être la cible d'une connexion d'appairage via des points de terminaison VPC d'interface.

Après avoir établi une connexion d'appairage, vous devez mettre à jour les tables de routage pour les VPCs deux comptes afin de définir la connexion d'appairage comme le prochain saut pour la plage d'adresses CIDR correspondante. Cette solution est recommandée uniquement aux fournisseurs de SaaS qui ont peu de clients, car la gestion de plusieurs connexions de peering devient rapidement trop complexe.

Le schéma suivant montre une configuration de base avec quelques intégrations possibles. VPCs dans deux comptes consommateurs, disposez d'une connexion de peering avec un VPC sur le compte du fournisseur SaaS.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

Connexion VPCs avec AWS Transit Gateway

Lorsque vous vous connectez AWS Transit Gateway, il crée des pièces jointes VPCs au VPC et déploie des interfaces réseau dans les sous-réseaux de chaque zone de disponibilité qui doivent acheminer le trafic vers et depuis le VPC. Il est recommandé de disposer d'un /28 sous-réseau dédié dans chaque zone de disponibilité pour l'attachement VPC. Pour plus d'informations, consultez les meilleures pratiques de conception d'Amazon VPC Transit Gateway. Une table de routage mise à jour est VPCs nécessaire pour envoyer le trafic via l'interface réseau déployée, et les tables de routage de Transit Gateway doivent être mises à jour en conséquence. Dans une configuration multi-locataires, vous souhaitez que le VPC du fournisseur de SaaS dispose d'un itinéraire vers tous les consommateurs. VPCs Le consommateur VPCs doit avoir un itinéraire uniquement vers le VPC du fournisseur de SaaS.

Transit Gateway est conçu pour être hautement disponible. Il prend en charge la surveillance à l'aide des journaux de flux VPC, et la bande passante maximale pour une connexion Transit Gateway est de 100 Gbit/s par zone de disponibilité. Tout comme le peering VPC, cette approche permet le référencement des groupes de sécurité inter-VPC, ce qui simplifie le contrôle d'accès entre les environnements.

Il existe deux options principales pour connecter les consommateurs à votre offre SaaS avec Transit Gateway.

Option 1 : utilisation de la RAM

Dans la première option, le fournisseur de services partage le Transit Gateway avec les consommateurs en utilisant AWS Resource Access Manager (AWS RAM). Cela permet aux consommateurs de déployer les pièces jointes VPC dans leurs propres comptes. Le schéma suivant montre cette option à un niveau élevé.

Option 2 : passerelles de transport en commun jumelées

La deuxième option consiste à associer votre passerelle de transit à une passerelle de transit dans les comptes des consommateurs. Cela offre aux consommateurs une plus grande flexibilité, car ils peuvent désormais contrôler entièrement les tables de routage au sein de leur passerelle de transit. Par exemple, ils pourraient configurer une inspection centralisée entre le service et leurs charges de travail. L'inconvénient de cette option est que seul le routage statique entre les passerelles de transit est pris en charge. Le schéma suivant montre cette option à un niveau élevé.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :