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.

Anti-patterns pour l'accès au réseau dans AWS Cloud

Un anti-modèle est une solution fréquemment utilisée pour un problème récurrent où la solution est contre-productive, inefficace ou moins efficace qu'une alternative. Les options de conception mentionnées dans cette section fonctionnent généralement, mais elles présentent des inconvénients importants. Dans la mesure du possible, elles doivent être évitées car de meilleures alternatives sont disponibles.

Incompatibilité de la zone de disponibilité avec AWS PrivateLink

Lorsqu'ils fournissent un accès à une application via AWS PrivateLink, les utilisateurs du SaaS peuvent créer des points de terminaison VPC d'interface uniquement dans les zones de disponibilité où l'application est déployée. Par exemple, si l'application est déployée dans use1-az1 etuse1-az2, le consommateur ne peut pas déployer de point de terminaison VPC dans. use1-az3 Nous vous recommandons de déployer l'offre SaaS dans chaque zone de disponibilité. La majorité d'entre eux Régions AWS ont trois zones de disponibilité, bien que certains en aient plus. Pour une liste complète, voir Régions et zones de disponibilité. Tenez compte du nombre de zones de disponibilité lorsque vous choisissez un Région AWS.

Si un fournisseur de SaaS choisit de ne pas le déployer dans toutes les zones de disponibilité, cela a des conséquences. Supposons que l'offre SaaS soit déployée dans use1-az1 etuse1-az2, mais que le consommateur utilise les trois zones de disponibilité, y comprisuse1-az3. Les points de terminaison VPC de l'interface sont déployés côté consommateur dans use1-az1 etuse1-az2, à présent, l'application use1-az3 doit accéder à l'un de ces points de terminaison. Tout d'abord, le trafic doit être autorisé depuis les sous-réseaux des zones de disponibilité sans correspondance vers les points de terminaison VPC respectifs. Le consommateur peut décider d'utiliser le nom AWS PrivateLink DNS régional, qui peut être attribué à l'un ou l'autre des points de terminaison VPC et qui répartit le trafic de manière égale entre les deux. Le consommateur peut également choisir d'envoyer le trafic directement vers un point de terminaison, par exempleuse1-az2. Cela signifie que 67 % du trafic arrive du côté du fournisseur use1-az2 et 33 % du trafic entrantuse1-az1. La figure suivante illustre ce scénario.

Compte tenu du nombre important de consommateurs et de la répartition inégale du trafic, une charge de travail peut rencontrer des problèmes de capacité dans une zone de disponibilité et être insuffisante dans une autre. Pour résoudre ce problème, le fournisseur de SaaS peut décider d'équilibrer la charge du trafic de son côté de manière uniforme en activant l'équilibrage de charge entre zones sur le Network Load Balancer. Cela entraîne des frais supplémentaires.

Si le fournisseur de services ne correspond qu'à une seule zone de disponibilité, l'ensemble du trafic transitera par un seul point de terminaison. Cela crée un déséquilibre encore plus important. Par conséquent, l'offre SaaS n'est plus très disponible pour le consommateur. Peu importe pour le consommateur que l'application soit desservie par des zones de disponibilité supplémentaires qu'il n'utilise pas lui-même. Dans le pire des cas, un fournisseur de SaaS pourrait ne pas être en mesure de servir un consommateur qui n'utilise aucune des mêmes zones de disponibilité.

Dans les rares cas où le fournisseur SaaS ne dispose pas d'une option viable pour approvisionner son application sur toutes les zones de disponibilité, il est également possible de créer un sous-réseau uniquement dans les zones de disponibilité manquantes, puis d'étendre le service à ces zones de disponibilité vides. L'équilibrage de charge entre zones peut ensuite répartir le trafic entrant sur les points de terminaison de l'application réels dans les autres zones de disponibilité.

AWS Site-to-Site VPN connexions entre Comptes AWS

Les entreprises qui migrent d'environnements sur site vers le cloud tentent parfois de déplacer l'ensemble du réseau. Cela peut entraîner des problèmes car il existe des différences importantes entre les pratiques de mise en réseau sur site et dans le cloud. Si ce changement de mentalité ne se produit pas, des choses comme les AWS Site-to-Site VPN connexions d'un VPC à un autre VPC peuvent se produire. Cette approche ne permet pas de tirer parti des services réseau spécialement conçus dans le AWS Cloud, qui simplifient la gestion et améliorent les performances. L'adaptation aux conceptions natives du cloud permet de réduire les frais opérationnels et d'améliorer la fiabilité et l'évolutivité de la connectivité entre les deux VPCs.

Si vous envisagez de proposer cette option de connectivité en tant que fournisseur de SaaS, demandez-vous, ou demandez au consommateur, pourquoi elle AWS Site-to-Site VPN devrait être utilisée. Ensuite, revenez en arrière à partir de ces exigences pour trouver une meilleure option de connectivité. La section Comparaison des capacités de service de ce guide contient une matrice que vous pouvez utiliser pour identifier les options. Ensuite, vous pouvez parcourir les sections pertinentes de ce guide pour trouver une approche architecturale adaptée à votre cas d'utilisation.