Übersicht

SaaS-Unternehmen betreiben Lösungen für eine große Anzahl von Mandanten. Bereitstellungen von AWS Edge-Services (z. B. CloudFront, AWS WAF usw.) mit mehreren Mandanten müssen sorgfältig konzipiert werden, um die geschäftlichen Anforderungen in Bezug auf Flexibilität, Kosten, Skalierbarkeit und Betriebsaufwand zu erfüllen.

Architektur-Entscheidungen

Bedenken Sie bei der Konzeption einer Lösung für mehrere Mandanten mit CloudFront die folgenden architektonischen Entscheidungen:

  • Verwenden Sie denselben Hostnamen für alle Mandanten (z. B. saas.com/tenant1, saas.com/tenant2) oder separate Hostnamen? Wenn Sie denselben Hostnamen verwenden, können Sie eine einzige CloudFront-Verteilung für die Bereitstellung verwenden.
  • Wenn Sie separate Hostnamen verwenden, verwenden Sie denselben Domainnamen (z. B. tenant1.saas.com, tenant2.saas.com) oder separate (z. B. tenant1.com, tenant2.com)? Eine CloudFront-Verteilung kann mit einem einzigen TLS-Zertifikat verknüpft werden, das mehrere Hostnamen (SAN-Zertifikate) hosten kann. Wenn Sie denselben Domainnamen verwenden, können Sie eine CloudFront-Verteilung pro Mandant bereitstellen oder eine einzelne Verteilung mit Platzhalter-CNAME und TLS-Zertifikat (*.saas.com) für alle Mandanten. Wenn die Domains unterschiedlich sind, können Sie eine CloudFront-Verteilung pro Mandant oder mehrere Verteilungen mit jeweils einem SAN-Zertifikat bereitstellen, das bis zu 100 verschiedene Domains hosten kann. Je mehr Domains Sie jedoch demselben TLS-Zertifikat zuordnen, desto problematischer wird der Prozess der TLS-Zertifikatsausstellung.
  • Wer kontrolliert den Domainnamen? Wenn Mandanten ihre Domain kontrollieren, sind weitere Schritte erforderlich, um ihren Hostnamen als CNAME zu einer CloudFront-Verteilung hinzuzufügen. Aus Sicherheitsgründen verlangt CloudFront, dass Sie Ihre Eigentümerschaft an der Domain nachweisen, indem Sie ein gültiges TLS-Zertifikat für den Hostnamen beifügen. Mandanten müssen entweder ihr eigenes TLS-Zertifikat bereitstellen, das Sie auf ACM hochladen, oder sich von Ihnen mit ACM ein TLS-Zertifikat in ihrem Namen ausstellen lassen. Im zweiten Fall muss ACM ein CNAME-Token in ihrem DNS erstellen, um die Eigentümerschaft an der Domain nachzuweisen.
  • Teilen die Mandanten dieselben Inhalte oder sind es unterschiedliche Inhalte? Wenn sie denselben Inhalt teilen, sollten Sie erwägen, den gemeinsamen Inhalt auf einer einzigen Domain zu hosten, die von verschiedenen Mandanten genutzt werden kann. Dies führt zu einer besseren Cache-Trefferquote für geteilte Inhalte.
  • Wenn Sie eine CloudFront-Verteilung für mehrere Mandanten verwenden, hosten Sie die Mandanten auf demselben Ursprung oder auf verschiedenen Ursprüngen? Wenn Sie denselben Ursprung verwenden (z. B. einen einzelnen S3-Bucket oder einen einzelnen ALB), können Sie Mandanten nach URL-Pfad oder Host-Header unterscheiden. Fügen Sie den Host-Header zum Cache-Schlüssel hinzu, wenn Sie diese Methode zur Differenzierung von Mandanten wählen. Wenn Sie verschiedene Ursprünge verwenden (z. B. einen S3-Bucket pro Mandant oder Sharding von Mandanten auf ALB-Clustern), benötigen Sie ein Ursprungsanfrage-Ereignis für Lambda@Edge, um den Datenverkehr an den richtigen Ursprung zu leiten. Anmerkung: Wenn Sie einen Pfad zur Unterscheidung von Mandanten verwenden (z. B. saas.com/tenant1, saas.com/tenant2), können Sie verschiedene Mandanten mithilfe von Cache-Verhaltensweisen von CloudFront nativ zu ihren Ursprüngen leiten. Es gelten jedoch Kontingente für die Anzahl der Verhaltensweisen pro CloudFront-Verteilung.
  • Respektiert Ihr Design die AWS-Kontingente pro AWS-Service und pro AWS-Konto?

Berücksichtigen Sie bei Ihrem Design die folgenden Kompromisse. Beachten Sie, dass Sie bei mehrstufigen Angeboten differenzierte Kompromisse eingehen können. Wenn Sie beispielsweise in Ihrer Basic-Stufe den Domainnamen kontrollieren, wird für alle Mandanten die gleiche CloudFront-Verteilung freigegeben. Ihre Premium-Mandanten hätten jeweils eine eigene CloudFront-Verteilung mit einer benutzerdefinierten Domain und Sicherheitsvorkehrungen mit AWS WAF.

  Jeder Mandant wird auf einer dedizierten CloudFront-Verteilung gehostet Mehrere Mandanten, die auf derselben CloudFront-Verteilung gehostet werden
Beobachtbarkeit Nativ pro Mandant verfügbar Steht auf der Verteilungsebene zur Verfügung, es ist jedoch zusätzlicher Aufwand erforderlich, um anhand von Protokollen Metriken pro Mandant zu extrahieren.
Auswirkungsradius Eine Änderung wirkt sich nur auf einen Mandanten aus. Eine einzige Änderung wirkt sich auf alle Mandanten aus.
Betriebsaufwand Erfordert skalierbare Automatisierung mit Batch-Rollouts, um eine Drosselung auf CloudFront-API-Ebene zu vermeiden. Niedrig
Individuelle Anpassung Jeder Mandant kann eine eigene, unterschiedliche Konfiguration haben Gleiche Konfiguration für alle Mandanten. Wenn Sie WAF aktivieren, wird es für alle Anfragen berechnet.
Leistung Jede CloudFront-Verteilung muss separat für den Datenverkehr aktiviert werden (z. B. für Verbindungen zum Ursprung). Alle Mandanten profitieren von einer aktivierten CloudFront-Verteilung

Eine CloudFront-Verteilung kann einer einzelnen AWS WAF WebACL zugeordnet werden. Dieselbe WebACL kann für mehrere CloudFront-Verteilungen verwendet werden. Die bereits erwähnten Kompromisse gelten auch für den WAF-Einsatz, zusätzlich zu den folgenden Punkten:

  Verwenden einer WebACL pro Mandant Verwenden derselben WebACL für mehrere Mandanten
Preis Die Kosten für WebACL/Rules skalieren linear mit der Anzahl der Mandanten Die Kosten für WebACL/Rules sind unabhängig von der Anzahl der Mandanten
Falsch-positive Ergebnisse Eine Regelaktualisierung verursacht möglicherweise nur bei einem einzigen Mandanten falsch-positive Ergebnisse. Eine Regelaktualisierung verursacht möglicherweise bei vielen Mandanten falsch-positive Ergebnisse.

Häufige Anwendungsfälle

Subdomain pro Mandant

In diesem Szenario erstellen Sie eine Subdomain (tenant1.saas.com) für jeden Mandanten. Route 53 ist mit einem Platzhalter-Alias-Datensatz (*.saas.com) für eine CloudFront-Verteilung konfiguriert, die ebenfalls mit einem Platzhalter-CNAME (*.saas.com) konfiguriert ist, wobei der Host-Header im Cache-Schlüssel enthalten ist. Ein ALB-Ursprung, der dynamische Anfragen bedient, unterscheidet die Mandanten nativ anhand des Host-Headers. Anmerkung: In diesem Szenario gilt eine einzige Inhaltsinvalidierung für alle Mandanten, da CloudFront-Invalidierungen unabhängig von Headern sind, die Teil des Cache-Schlüssels sind, wie z. B. dem Host-Header. Ein S3-Bucket, der statische Inhalte bereitstellt, benötigt eine CloudFront-Funktion, die für die Viewer-Anfrage konfiguriert ist, um den Host-Header zu lesen und die URL in das Mandantenverzeichnis in S3 umzuschreiben (z. B. tenant1.saas.com/index.html -> s3://bucket:arn/tenant1/index.html). Wenn Sie für alle Mandanten denselben Inhalt aus S3 bereitstellen, z. B. dieselbe Single-Page-Anwendung, aber die Mandanten durch APIs unterscheiden, sollten Sie diese einfache Lösung in Betracht ziehen.

Wenn Sie Mandanten auf verschiedenen Ursprüngen hosten, benötigen Sie eine Lambda@Edge-Funktion, die für das Ursprungsanfrage-Ereignis konfiguriert ist, um eine Mandantenanfrage an den Ursprung weiterzuleiten, der den Mandanten hostet. Weitere Informationen zu dieser Implementierung finden Sie in den folgenden Fallstudien:

Mandanten mit eigenen Domänen

In diesem Szenario weisen Sie jedem Mandanten eine CloudFront-Verteilung zu und automatisieren Sie den Prozess (z. B. Erstellung der Verteilung und Ausstellung von TLS-Zertifikaten mit Amazon Certificate Manager). Stellen Sie sicher, dass Sie zuvor die entsprechenden Kontingente erhöhen (z. B. Anzahl der Distributionen pro Konto, Anzahl der TLS-Zertifikate). In bestimmten Fällen müssen Sie Ihre CloudFront-Verteilungen auf mehrere AWS-Konten aufteilen.

Beenden Sie TLS auf Ihren Servern

Sollte der Umfang Ihrer Anforderungen nicht durch CloudFront abgedeckt werden, empfiehlt sich der Aufbau einer Flotte von Reverse Proxys (z. B. auf der Basis von NLB und EC2). Diese beenden TCP/TLS-Verbindungen und bieten eine bessere Sicherheit und Leistung durch Global Accelerator. Beachten Sie, dass Sie in diesem Szenario bei Bedarf ein Caching in Ihrem Reverse Proxy implementieren müssen.

Ressourcen

War diese Seite hilfreich?

 Feedback