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 services opérant sur place

Cette section décrit les options de connectivité entre les charges de travail SaaS dans les AWS Cloud centres de données et sur site. De nombreux consommateurs ayant des exigences sur site, en particulier au niveau de l'entreprise, considèrent le cloud comme une extension de leur réseau physique, et ils souhaitent en tenir compte dans leur architecture. Cela signifie une connectivité privée à l'offre SaaS dans le cloud, soit via des tunnels logiques, soit même via une connexion physique privée. Les autres consommateurs accepteront la connectivité via l'Internet public, qui est également abordée dans cette section.

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.

Connexion avec AWS Site-to-Site VPN

AWS Site-to-Site VPNles connexions peuvent se terminer sur une passerelle privée virtuelle ou une passerelle de transit. Une passerelle privée virtuelle est le point de terminaison VPN situé du AWS côté de votre connexion Site-to-Site VPN qui peut être rattaché à un seul VPC. Une passerelle de transit est un hub de transit qui peut être utilisé pour interconnecter plusieurs VPCs réseaux locaux. Il peut également être utilisé comme point de terminaison VPN du AWS côté de la connexion Site-to-Site VPN. Cette section décrit les deux options.

Connexion via une passerelle privée virtuelle

Après avoir créé une passerelle privée virtuelle, vous l'associez au VPC qui contient votre offre SaaS. Ensuite, vous activez la propagation des routes pour propager les routes VPN vers la table de routage du VPC. Ces routes peuvent être statiques ou dynamiques annoncées par le BGP.

Pour une haute disponibilité, une connexion Site-to-Site VPN possède deux tunnels VPN qui se terminent par deux zones de disponibilité sur le AWS côté. Si l'un d'entre eux n'est plus disponible, le second tunnel peut prendre le relais. Un seul tunnel permet une bande passante maximale de 1,25 Gbit/s. Les passerelles privées virtuelles ne prenant pas en charge le routage multichemin à coût égal (ECMP), vous ne pouvez utiliser qu'un seul tunnel à la fois.

Pour augmenter la tolérance aux pannes, vous pouvez configurer une deuxième connexion VPN vers une deuxième passerelle client physique. Une fois la connexion établie, le consommateur peut accéder aux ressources du VPC du fournisseur de SaaS.

Le schéma suivant illustre cette architecture.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

Connexion via une passerelle de transit

Les connexions via les passerelles de transit sont similaires aux passerelles virtuelles. Cependant, il y a quelques différences à garder à l'esprit.

Tout d'abord, les itinéraires de la pièce jointe VPN peuvent être automatiquement propagés dans la table de routage de la passerelle de transit, mais vous devez ajouter manuellement les itinéraires à la pièce jointe VPCs.

Comparé à une passerelle virtuelle, Transit Gateway prend en charge l'ECMP. Si la passerelle client prend en charge l'ECMP, elle peut utiliser les deux tunnels pour atteindre un débit maximal total de 2,5 Gbit/s. Vous pouvez établir plusieurs connexions entre le même réseau local et la passerelle de transit. Grâce à cette approche, vous pouvez augmenter la bande passante maximale jusqu'à 2,5 Gbit/s par connexion.

Le schéma suivant illustre cette architecture.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

Connexion avec AWS Direct Connect

AWS Direct Connectrelie votre réseau interne à un Direct Connect emplacement via un câble à fibre optique Ethernet standard. Contrairement aux autres options d'architecture, une connexion dédiée ne peut pas être établie en quelques minutes. Au lieu de cela, ce processus peut prendre plusieurs jours si toutes les exigences sont satisfaites. Si ce n'est pas le cas, cela peut prendre plus de temps. Nous vous suggérons donc de contacter l'équipe chargée de votre AWS compte ou d' AWS Support obtenir de l'aide concernant cette approche. Vous pouvez éventuellement choisir une connexion hébergée fournie par un AWS partenaire et partagée avec d'autres clients. L'architecture est toujours la même. Vous pouvez choisir Direct Connect parce qu'il réduit le temps de latence, améliore la bande passante ou est conforme aux exigences réglementaires.

Pour utiliser la Direct Connect connexion, les consommateurs doivent créer une interface virtuelle publique, privée ou de transit. Différentes options d'architecture sont disponibles. La solution la plus flexible pour connecter plusieurs sites sur site AWS Cloud est une interface virtuelle de transit connectée à une Direct Connect passerelle. Une Direct Connect passerelle est un composant logique global qui permet au fournisseur de services d'y connecter jusqu'à six passerelles de transit. En outre, vous pouvez connecter jusqu'à 30 interfaces virtuelles à la passerelle. Pour des raisons d'échelle, vous pouvez créer des Direct Connect passerelles supplémentaires. Dans le compte du fournisseur SaaS, les passerelles de transit se rattachent ensuite au VPCs, comme décrit précédemment.

Les consommateurs peuvent se connecter en utilisant une à quatre Direct Connect connexions à partir d'un ou deux Direct Connect sites au total, selon le niveau de résilience souhaité. Pour plus d'informations, voir Configurer Direct Connect pour une résilience maximale. Une AWS Site-to-Site VPN connexion via Internet peut également servir de chemin de sauvegarde à moindre coût pour une Direct Connect connexion. Les connexions Direct Connect dédiées prises en charge peuvent être utilisées MACsecpour chiffrer le lien sur la couche 2 entre l' Direct Connect emplacement et le centre de données. Il est courant d'avoir une connexion Site-to-Site VPN pour renforcer la confidentialité des données. La connexion Site-to-Site VPN peut se terminer sur la passerelle de transit en utilisant une connexion VPN normale. Le schéma suivant illustre cette architecture.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

Connexion à une architecture VPC de transit

Transit VPC est une option d'architecture qui donne de la flexibilité aux consommateurs quant à la manière de se connecter AWS, et qui permet aux fournisseurs de SaaS de bénéficier d'un accès unifié à leur service via. AWS PrivateLink Le consommateur se connecte sur site à un VPC de transit qui ne contient qu'un point d'entrée (tel qu'une passerelle privée virtuelle) et un point de terminaison VPC d'interface, qui est une ressource. AWS PrivateLink Le transit VPCs doit appartenir soit au fournisseur de SaaS, soit aux consommateurs. Cette section décrit les deux options.

Vous pouvez créer le VPC de transit et les sous-réseaux avec des plages d'adresses CIDR compatibles avec le centre de données sur site. S'ils ont besoin d'une connectivité privée, les consommateurs peuvent se connecter à ce VPC via AWS Direct Connect ou. AWS Site-to-Site VPN Vous pouvez également configurer l'accès au compte de transit depuis l'Internet public à l'aide d'un Application Load Balancer ou d'un Network Load Balancer pointant vers le point de terminaison du VPC.

VPC de transit géré par le consommateur

Dans cette approche, le fournisseur de SaaS laisse la gestion du transit VPCs aux consommateurs. D'un point de vue technique, l'architecture du fournisseur de SaaS est la même que lors de la connexion directe aux AWS Cloud consommateurs AWS PrivateLink. Du point de vue des ventes et du produit, cela représente un effort supplémentaire, car certains consommateurs ne l'ont pas Comptes AWS encore fait. Ils peuvent hésiter à ouvrir et à gérer un compte. Le fournisseur de SaaS doit fournir des conseils à ses clients sur la manière de créer Comptes AWS et de connecter leur centre de données sur site. Le schéma suivant montre une combinaison d'accès public et privé, où les consommateurs sont propriétaires du transport en commun VPCs.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

VPC de transit géré par le fournisseur

Cette approche utilise les mêmes technologies, mais les limites des comptes et les responsabilités changent. Ici, le fournisseur SaaS est propriétaire du transit VPCs, de préférence sur un compte distinct de celui de l'offre SaaS. Ce découplage réduit les coûts, réduit les risques et permet au compte de transport d'évoluer de manière indépendante. Pour les environnements nécessitant un degré élevé d'isolation, vous pouvez créer une séparation supplémentaire entre les locataires en utilisant un sous-réseau ou en créant un VPC de transit distinct pour chaque consommateur. Les consommateurs peuvent ensuite choisir le mode de connexion au VPC de transit. Cette approche offre davantage d'options pour étendre l'ensemble du marché adressable, mais elle entraîne un coût total de possession plus élevé pour le fournisseur de SaaS en raison de la nécessité d'exploiter et de surveiller des composants architecturaux supplémentaires.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

Connexion via l'Internet public

L'accès public à Internet est également une option valable pour accéder à une offre SaaS, bien qu'il n'offre pas de connectivité privée au sens traditionnel du terme. Certains consommateurs peuvent toujours préférer une approche d'accès public, car elle ne nécessite aucune infrastructure réseau supplémentaire entre eux et le fournisseur de SaaS. Il réduit la complexité, les coûts et le temps d'intégration en échange d'une surface d'attaque accrue. Des mécanismes d'authentification et d'autorisation puissants peuvent contribuer à atténuer l'augmentation du niveau de menace, et vous devez toujours chiffrer le trafic. Il est toujours recommandé de disposer d'un niveau de sécurité supplémentaire dans ce scénario, par exemple en utilisant AWS WAF.

L'architecture de ce scénario est simple. Le consommateur se connecte à un hébergeur public (le fournisseur de SaaS) via Internet. L'application peut être hébergée directement sur une instance publique Amazon Elastic Compute Cloud (Amazon EC2) dotée d'une adresse IP Elastic. L'option préférée est de l'héberger derrière un Application Load Balancer ou un service similaire. Pour améliorer les performances et la mise en cache des actifs statiques, vous pouvez utiliser un réseau de diffusion de contenu tel qu'Amazon CloudFront. Pour desservir une application avec une latence minimale sur deux adresses IP Anycast statiques globales, vous pouvez la placer AWS Global Acceleratordevant une instance Amazon EC2, Network Load Balancer ou Application Load Balancer. En outre CloudFront, les équilibreurs de charge d'application et Amazon API Gateway s'intègrent tous à AWS WAF. AWS AppSync Le schéma suivant donne un aperçu des options de connectivité pour l'accès public à Internet.

Le tableau suivant décrit les protocoles et les intégrations pris en charge pour ce scénario.

Les avantages de cette approche sont les suivants :

Les inconvénients de cette approche sont les suivants :

D'autres avantages et inconvénients s'appliquent, selon les services que vous choisissez.