SaaS auf AWS: Multi-Tenant-Architekturmuster

Warum Mandantenfähigkeit die zentrale SaaS-Architekturentscheidung ist

Im Gegensatz zu On-Premises-Software bedient eine SaaS-Plattform typischerweise Hunderte oder Tausende von Kunden gleichzeitig über eine gemeinsame Infrastruktur. Multi-Tenancy beschreibt, wie diese Kunden — in der Cloud-Terminologie: Tenants oder Mandanten — technisch voneinander getrennt werden, während sie dieselbe Software-Instanz nutzen.

Diese Entscheidung ist fundamental, weil sie sich auf nahezu alle anderen Architekturentscheidungen auswirkt: Datenbankdesign, Authentifizierungsarchitektur, Kostenmodell, Skalierungsstrategie und Compliance-Dokumentation. Eine nachträgliche Änderung des Tenant-Modells ist in der Regel mit erheblichem Aufwand verbunden.

Schlüsselbegriffe der Multi-Tenant-Architektur

Tenant

Ein einzelner Kunde (Unternehmen oder Organisation), der eine SaaS-Plattform nutzt. Ein Tenant kann mehrere Nutzer haben, aber aus Isolationsperspektive als eine Einheit betrachtet werden.

Tenant-Isolation

Technische Garantie, dass Daten und Ressourcen eines Tenants nicht für andere Tenants zugänglich sind. Kann auf Infrastruktur-, Datenbankebene oder durch Verschlüsselung realisiert werden.

Noisy-Neighbor-Problem

Situation, in der ein einzelner Tenant durch intensive Nutzung die Performance anderer Tenants beeinträchtigt. Tritt vor allem im Pool-Modell auf und erfordert aktives Resource-Throttling.

Tenant-Onboarding

Der automatisierte Prozess, durch den ein neuer Tenant in die SaaS-Plattform aufgenommen wird: Erstellung von Accounts, Konfiguration von Ressourcen, Bereitstellung von Zugangsdaten.

Row-Level Security (RLS)

Datenbankfunktion, die den Zugriff auf einzelne Tabellenzeilen basierend auf der Identität des anfragenden Benutzers einschränkt. Schlüsseltechnologie für Datenisolierung im Pool-Modell.

Das Silo-Modell: Maximale Isolation

Im Silo-Modell erhält jeder Tenant eine vollständig isolierte Infrastruktur. Auf AWS bedeutet das typischerweise separate AWS-Accounts pro Tenant, verwaltet über AWS Organizations und AWS Control Tower.

Vorteile des Silo-Modells

• Stärkste Datenisolierung — vollständige Trennung auf Infrastrukturebene
• Einfache Auditierbarkeit für Compliance (ISO 27001, BSI C5, BaFin-Anforderungen)
• Kein Noisy-Neighbor-Problem
• Individuelle Anpassung pro Tenant möglich (Custom-Deployments, eigene Domains)
• Kunden-spezifische Datenresidenz leicht durchsetzbar (z. B. Frankfurt-only für DSGVO)

Nachteile des Silo-Modells

• Höhere Infrastrukturkosten — jeder Tenant trägt eigene Fixkosten
• Komplexes Operations-Management bei vielen Tenants
• Skalierung des Onboarding-Prozesses erfordert Automatisierung via CloudFormation/CDK
• Nicht geeignet für Freemium-Modelle oder sehr viele kleine Tenants

AWS-Implementierung: AWS Organizations mit Service Control Policies (SCPs), AWS Control Tower für Account-Vending-Machine, separate VPCs und Datenbanken pro Account. Zentrale Verwaltung über Management Account.

Das Pool-Modell: Maximale Effizienz

Im Pool-Modell teilen sich alle Tenants dieselbe Infrastruktur: eine gemeinsame Datenbank, dieselben EC2-Instanzen oder Lambda-Funktionen, dieselbe Netzwerkinfrastruktur. Isolation wird auf Applikations- und Datenbankebene durchgesetzt.

Datenisolierung im Pool-Modell

Zwei zentrale Techniken sorgen für Datentrennung:

1. Row-Level Security (RLS): Jede Tabelle enthält eine tenant_id-Spalte. PostgreSQL- oder Aurora-RLS-Policies stellen sicher, dass jede Datenbankabfrage automatisch auf die Zeilen des authentifizierten Tenants beschränkt wird. Implementiert als Datenbankpolicy: CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant_id')::uuid).
2. AWS KMS Customer Managed Keys (CMKs): Jeder Tenant erhält einen eigenen KMS-Schlüssel. Daten werden tenant-spezifisch verschlüsselt, sodass selbst bei Datenbankzugriff die Daten anderer Tenants nicht entschlüsselt werden können.

AWS-Implementierung: Amazon RDS/Aurora mit aktivierter RLS, Amazon Cognito für Tenant-Identität und JWT-Claims mit Tenant-ID, AWS KMS für per-Tenant-Verschlüsselung, Amazon ECS oder Lambda für Compute.

Das Bridge-Modell: Balance zwischen Isolation und Effizienz

Das Bridge-Modell (auch: Hybrid-Modell) kombiniert Elemente beider Ansätze. Typischerweise werden Compute-Ressourcen geteilt (Pool), während Datenbankinstanzen isoliert sind (Silo). Oder: Basic-Tier-Kunden nutzen geteilte Infrastruktur, Enterprise-Kunden erhalten dedizierte Ressourcen.

Das Bridge-Modell eignet sich besonders für ISVs, die verschiedene Preistiers anbieten:

Tenant-Identität mit Amazon Cognito

Amazon Cognito ist der AWS-Dienst für Authentifizierung und Autorisierung in SaaS-Anwendungen. Für Multi-Tenant-Architekturen gibt es zwei gängige Ansätze:

1. Shared User Pool mit Tenant-Claims: Ein einzelner Cognito User Pool für alle Tenants. Tenant-Zugehörigkeit wird als Custom Attribute (custom:tenantId) im JWT-Token gespeichert. Applikation extrahiert die Tenant-ID aus dem Token und verwendet sie für RLS und Ressourcenzugriff.
2. User Pool pro Tenant (Silo): Jeder Tenant erhält seinen eigenen Cognito User Pool. Ermöglicht individuelle Konfiguration (eigene Domain, eigenes Branding, SAML/OIDC-Federation mit Unternehmens-IdP), jedoch höherer Verwaltungsaufwand.

Für Enterprise-Kunden ist SAML-Federation entscheidend: Cognito unterstützt SAML 2.0 als Identity Provider, sodass Unternehmenskunden ihr bestehendes Active Directory oder Azure AD für die Authentifizierung nutzen können.

Tenant-Onboarding automatisieren

Manuelles Tenant-Onboarding ist nicht skalierbar. Ab 50+ Tenants ist Vollautomatisierung Pflicht. Die AWS-Referenzarchitektur für automatisiertes Onboarding nutzt folgende Komponenten:

1. API Gateway + Lambda: REST-API empfängt Onboarding-Request (Firmenname, Plan, Admin-E-Mail)
2. Step Functions: Orchestriert den mehrstufigen Onboarding-Prozess (sequenziell oder parallel)
3. CloudFormation/CDK: Provisioniert tenant-spezifische Ressourcen (bei Silo: gesamten AWS-Account; bei Pool: Tenant-Eintrag in Konfigurationsdatenbank)
4. Cognito: Erstellt Tenant-spezifischen User Pool oder User Pool Client, sendet Einladungs-E-Mail an Admin
5. DynamoDB (Control Plane): Speichert Tenant-Konfiguration: Tenant-ID, Plan, Ressourcen-IDs, Status

AWS-Dienste im Vergleich: Eignung für Multi-Tenancy

Entscheidungshilfe: Welches Modell für welchen ISV?

1. Regulierte Branchen (Finanz, Gesundheit, öffentliche Verwaltung): Silo-Modell bevorzugen. Strikte Isolation ist Compliance-Anforderung, nicht nur Best Practice.
2. Horizontale B2B-SaaS mit vielen KMU-Kunden: Pool-Modell mit RLS und CMKs. Kosteneffizienz ist entscheidend für Unit Economics.
3. Produkte mit verschiedenen Preistiers: Bridge-Modell. Starter im Pool, Enterprise im Silo.
4. Sehr geringe Tenant-Anzahl (<100) und hohe Umsätze pro Tenant: Silo. Komplexität ist handhabbar, Kunden zahlen für Isolation.
5. PLG-Modell (Product-Led Growth) mit Freemium: Pool zwingend erforderlich. Hunderte kostenlose Tenants rechtfertigen keine Silo-Infrastruktur.

Häufig gestellte Fragen zur Multi-Tenant-Architektur

Was bedeutet Mandantenfähigkeit (Multi-Tenancy) in SaaS?

Mandantenfähigkeit bedeutet, dass eine einzelne Software-Instanz gleichzeitig mehrere Kunden (Mandanten/Tenants) bedient, wobei deren Daten strikt voneinander getrennt sind. Die Trennung kann auf Datenbankebene, Infrastrukturebene oder durch Verschlüsselung realisiert werden.

Welches Multi-Tenant-Modell ist für regulierte Branchen geeignet?

Für regulierte Branchen (Finanzdienstleister, Gesundheitswesen, öffentliche Verwaltung) eignet sich das Silo-Modell am besten. Jeder Tenant erhält eigene AWS-Ressourcen (separate Accounts, eigene Datenbanken), was die stärkste Isolation und die einfachste Auditierbarkeit bietet.

Wie implementiert man Row-Level Security in Amazon Aurora?

Aurora PostgreSQL unterstützt nativen PostgreSQL-RLS. Eine Policy wird direkt auf der Tabelle definiert: CREATE POLICY tenant_rls ON table_name USING (tenant_id = current_setting('app.tenant_id')::uuid). Die Applikation setzt die Tenant-ID bei jeder Datenbankverbindung via SET app.tenant_id = '...'.

Kann ein Tenant sein eigenes Active Directory nutzen?

Ja. Amazon Cognito unterstützt SAML 2.0 und OIDC für die Federation mit externen Identity Providern. Tenants können ihr eigenes Azure AD, Okta, ADFS oder einen anderen SAML-fähigen IdP einbinden. Dies ist bei Enterprise-Kunden häufig eine Kaufvoraussetzung.

Wie viele Tenants kann ein Pool-Modell bedienen?

Theoretisch unbegrenzt. In der Praxis hängt es von der Applikationsarchitektur und der Skalierbarkeit der genutzten AWS-Dienste ab. Amazon Aurora kann mit RDS Proxy horizontal skalieren. Lambda und DynamoDB skalieren automatisch. Gut designed Pool-Architekturen bedienen zehntausende Tenants.

Storm Reply: SaaS-Architekturberatung für ISVs

Storm Reply ist AWS Premier Consulting Partner DACH mit dem AWS SaaS Competency. Wir helfen ISVs, die richtige Multi-Tenant-Architektur zu wählen und umzusetzen — von der initialen Architekturentscheidung bis zur vollständig automatisierten Tenant-Onboarding-Pipeline.

Unsere Architekten verfügen über praktische Erfahrung mit allen drei Tenant-Modellen und kennen die spezifischen Compliance-Anforderungen des deutschen Markts: DSGVO, BSI C5, BaFin-Anforderungen für Fintech-ISVs und KRITIS-Regulatorik.