Présentation

Les entreprises SaaS proposent des solutions pour un grand nombre de locataires. Les déploiements mutualisés des services de périphérie AWS (par exemple CloudFront, AWS WAF, etc.) nécessitent des décisions de conception minutieuses afin de répondre aux exigences commerciales telles que la flexibilité, les coûts, la capacité de mise à l'échelle et les frais opérationnels.

Décisions architecturales

Tenez compte des décisions architecturales suivantes lors de la conception d'une solution mutualisée à l'aide de CloudFront :

  • Utilisez-vous le même nom d'hôte pour tous les locataires (par exemple saas.com/tenant1, saas.com/tenant2) ou des noms d'hôtes distincts ? Si vous utilisez le même nom d'hôte, vous avez la possibilité de déployer en utilisant une seule distribution CloudFront.
  • Si vous utilisez des noms d'hôtes distincts, utilisez-vous le même nom de domaine (par exemple tenant1.saas.com, tenant2.saas.com) ou des noms distincts (par exemple tenant1.com, tenant2.com) ? Une distribution CloudFront peut être associée à un seul certificat TLS, qui peut héberger plusieurs noms d'hôtes (certificats SAN). Lorsque vous utilisez le même nom de domaine, vous avez le choix entre déployer une distribution CloudFront par locataire ou déployer une distribution unique avec un CNAME générique et un certificat TLS (*.saas.com) pour tous les locataires. Si les domaines sont différents, vous avez le choix entre déployer une distribution CloudFront par locataire ou déployer plusieurs distributions, chacune dotée d'un certificat SAN pouvant héberger jusqu'à 100 domaines différents. Toutefois, plus vous associez de domaines au même certificat TLS, plus vous compliquez le processus d'émission du certificat TLS.
  • Qui contrôle le nom de domaine ? Si les locataires contrôlent leur domaine, des étapes supplémentaires seront nécessaires pour ajouter leur nom d'hôte en tant que CNAME à une distribution CloudFront. Pour des raisons de sécurité, CloudFront vous demande de prouver que vous êtes propriétaire du domaine en joignant un certificat TLS valide qui couvre le nom d'hôte. Les locataires doivent soit partager leur propre certificat TLS, que vous chargerez sur ACM, soit vous laisser émettre un certificat TLS en leur nom à l'aide d'ACM. Avec la deuxième approche, ACM leur demande de créer un jeton CNAME dans leur DNS pour prouver qu'ils sont propriétaires du domaine.
  • Les locataires partagent-ils le même contenu ou un contenu différent ? S'ils partagent du contenu commun, envisagez d'héberger le contenu partagé sur un domaine unique qui peut être utilisé par différents locataires. Cela se traduit par un meilleur taux d'accès au cache pour le contenu partagé.
  • Si vous utilisez une distribution CloudFront pour plusieurs locataires, hébergez-vous des locataires de la même origine ou d'origines différentes ? Si vous utilisez la même origine (par exemple, un seul compartiment S3 ou un seul ALB), vous pouvez différencier les locataires par chemin d'URL ou par en-tête d'hôte. Ajoutez l'en-tête hôte à la clé de cache si vous choisissez cette méthode de différenciation des locataires. Si vous utilisez différentes origines (par exemple, un compartiment S3 par locataire ou le partage de locataires sur des clusters ALB), vous avez besoin d'un événement de demande Lambda@Edge sur la demande d'origine pour acheminer le trafic vers la bonne origine. Notez que si vous utilisez un chemin pour différencier les locataires (par exemple, saas.com/tenant1, saas.com/tenant2), vous pouvez acheminer nativement différents locataires vers leurs origines à l'aide des comportements de cache CloudFront, mais vous disposez de quotas quant au nombre de comportements par distribution CloudFront.
  • Votre conception respecte-t-elle les quotas AWS par service AWS et par compte AWS ?

Tenez compte des compromis ci-dessous dans votre conception. Notez que vous pouvez implémentez des compromis différenciés pour une offre à plusieurs niveaux. Par exemple, dans votre niveau de base où vous contrôlez le nom de domaine, tous les locataires partagent la même distribution CloudFront. Vos locataires premium bénéficieraient chacun d'une distribution CloudFront dédiée avec un domaine personnalisé et des protections de sécurité à l'aide d'AWS WAF.

  Chaque locataire est hébergé sur une distribution CloudFront dédiée Plusieurs locataires hébergés sur la même distribution CloudFront
Observabilité Disponible en mode natif par locataire Disponible au niveau de la distribution, des efforts supplémentaires sont nécessaires pour extraire les métriques par locataire à l'aide des journaux
Rayon d'explosion Un changement n'affecte qu'un seul locataire Un seul changement a un impact sur tous les locataires
Frais généraux opérationnels Nécessite une automatisation à grande échelle, avec des déploiements par lots pour éviter la limitation au niveau de l'API CloudFront Faible
Personnalisation Chaque locataire peut avoir sa propre configuration Même configuration pour tous les locataires. Lorsque vous activez le WAF, toutes les demandes sont facturées
Performances Chaque distribution CloudFront doit être chauffée séparément par le trafic (par exemple, les connexions à l'origine) Tous les locataires bénéficient d'une distribution CloudFront réchauffée

Une distribution CloudFront peut être associée à une seule WebACL AWS WAF. La même WebACL peut être utilisée dans plusieurs distributions CloudFront. Les compromis mentionnés précédemment s'appliquent également au déploiement du WAF, en plus des suivants :

  Utilisation d'une WebACL par locataire Utilisation de la même WebACL pour plusieurs locataires
Prix Le coût de WebACL/Rules évolue de manière linéaire en fonction du numéro de locataire Le coût de WebACL/Rules est indépendant du nombre de locataire
Faux positifs Une mise à jour des règles peut uniquement provoquer des faux positifs avec un seul locataire Une mise à jour des règles peut provoquer des faux positifs chez de nombreux locataires uniques

Cas d'utilisation courants

Sous-domaine par locataire

Dans ce scénario, vous créez un sous-domaine (tenant1.saas.com) pour chaque locataire. Route 53 est configurée avec un enregistrement d'alias générique (*.saas.com) vers une distribution CloudFront, également configuré avec un CNAME générique (*.saas.com), avec un en-tête hôte inclus dans la clé de cache. Une origine ALB diffusant des demandes dynamiques distingue nativement les locataires à l'aide de l'en-tête hôte. Notez que dans ce scénario, une seule invalidation de contenu s'appliquera à tous les locataires, car les invalidations CloudFront ne concernent pas les en-têtes faisant partie de la clé de cache, tels que l'en-tête hôte. Un compartiment S3 diffusant du contenu statique aurait besoin d'une fonction CloudFront configurée lors de l'événement de demande de l'utilisateur pour lire l'en-tête hôte et réécrire l'URL dans le répertoire du locataire dans S3 (par exemple, tenant1.saas.com/index.html -> s3://bucket:arn/tenant1/index.html). Si vous diffusez le même contenu à tous les locataires depuis S3, par exemple la même application d'une page unique, mais que vous différenciez les locataires grâce à des API, envisagez cette solution simple.

Si vous hébergez des locataires d'origines différentes, vous avez besoin d'une fonction Lambda@Edge configurée lors d'un événement de demande d'origine pour acheminer les demandes d'un locataire vers l'origine hébergeant le locataire. Pour en savoir plus sur cette implémentation, consultez les études de cas suivantes :

Locataires possédant leurs propres domaines

Dans ce scénario, dédiez une distribution CloudFront à chaque locataire et automatisez le processus (par exemple, la création de la distribution et l'émission de certificats TLS à l'aide d'Amazon Certificate Manager). Assurez-vous d'augmenter au préalable les quotas pertinents (par exemple, le nombre de distributions par compte, le nombre de certificats TLS). Dans certains cas, vous devez partager vos distributions CloudFront sur plusieurs comptes AWS.

Mettre fin aux connexions TLS sur vos serveurs

Si l'ampleur de vos besoins ne peut pas être satisfaite par CloudFront, envisagez de créer une flotte de proxy inverse (par exemple, basés sur NLB et EC2) pour mettre fin aux connexions TCP/TLS, et de faire appel à Global Accelerator pour améliorer la sécurité et les performances. Notez que dans ce scénario, vous devez implémenter la mise en cache dans votre proxy inverse si nécessaire.

Ressources

Cette page vous a-t-elle été utile ?

 Commentaires