AWS Serverless Multi-Tenant SaaS: Architektur, die pro Tenant skaliert

Die Frage, die deine Architektur definiert

Ich sag es direkt: Die eine Entscheidung, die ein Multi-Tenant-SaaS prägt, ist, wie du Tenants isolierst. Triffst du sie richtig, skalierst du auf tausende Kunden auf gemeinsamer Infrastruktur mit einem sauberen Kostenmodell. Triffst du sie falsch, leakst du entweder die Daten eines Kunden an einen anderen, was das Ende der Firma ist, oder du stellst dedizierte Infrastruktur pro Tenant hin, was sie in die Pleite treibt.

Die Antwort ist nicht "wähl ein Isolationsmodell". Die Antwort ist, Isolation auf jeder Ebene anzuwenden, damit kein einzelner Fehler Daten über Tenants hinweg offenlegt. Das ist Defense in Depth, angewandt auf Multi-Tenancy, und es ist der Unterschied zwischen einer Plattform, der du Enterprise-Daten anvertrauen kannst, und einer Demo, der du das nicht kannst.

Multi-Tenant-Isolation ist kein Feature, das du dazubaust. Sie ist eine Eigenschaft, die du auf jeder Ebene erzwingst: in der Datenbank, im Suchindex, in der API, in den Agents und im Dashboard. Eine Ebene reicht nicht.

Wir betreiben diese Architektur produktiv in unserer eigenen Exfinity-Plattform, einem Multi-Tenant-SaaS auf AWS, das isolierte Tenants aus gemeinsamer Infrastruktur in einer EU-Region bedient. Dieser Guide ist das echte Design. Für die Container-Orchestrierungs-Alternative sieh dir unseren Guide zu Kubernetes für SaaS-Plattformen an, und das hier ist Kern unserer Cloud-Arbeit.

Wer sich wofür interessiert

Serverless versus Container: Entscheide pro Service

Serverless ist kein Alles-oder-nichts. Die richtige Architektur nutzt beides, pro Workload gewählt.

Functions-as-a-Service passen zu spitzenlastiger, event-getriebener, kurzlebiger Arbeit: ein API-Endpoint, ein Queue-Consumer, ein geplanter Job. Du zahlst pro Invocation und skalierst auf null. Langlaufende oder zustandsbehaftete Services, eine Such-API mit warmen Indexen, eine KI-Runtime, die Agent-State verwaltet, passen zu Containern auf Managed Compute, wo du Prozesse warm hältst und die Runtime kontrollierst.

Exfinity betreibt seine API und Checkout-Flows als Functions und seine Suche, KI-Runtime, Ingestion und das Dashboard als Container auf Managed Compute, jedes skaliert unabhängig. Die Lektion: Zwing nicht ein Modell auf alles. Unser Platform-Engineering-Guide behandelt diesen Trade-off im Detail.

Die sechs Ebenen der Tenant-Isolation

Das ist der Kern des ganzen Guides. Isolation wird auf jeder Ebene durchgesetzt, die ein Request berührt.

Request with tenant identity
   │
   ▼
[1] API middleware   ── tenant id from the token, never the query string
[2] Database         ── tenant id as partition key on every query
[3] Search index     ── tenant filter on every search
[4] Agents / AI       ── conversation and memory scoped per tenant
[5] Tool layer       ── every tool checks scope before it runs
[6] Dashboard        ── cross-tenant access returns not-found, not forbidden

API-Middleware. Die Tenant-Identität kommt aus verifizierten Token-Claims, nicht aus einem Query-Parameter, den ein Aufrufer fälschen könnte. Eine Tenant-ID in der URL von einem Nicht-Admin wird stillschweigend ignoriert. Das ist das erste Gate und das, das am häufigsten falsch gebaut wird.

Datenbank. Jede Query enthält den Tenant als Partition Key. Es gibt keinen Codepfad, der eine Tabelle ohne Tenant-Scope liest. Das wird im Data-Access-Layer erzwungen, nicht jedem Aufrufer zum Merken überlassen.

Suchindex. Jede Suche trägt einen Tenant-Filter, sodass die Query eines Tenants nie die Dokumente eines anderen zurückgeben kann, obwohl sie sich einen Index teilen.

Agents und Memory. Jede Konversation ist auf einen einzigen Tenant gescoped, und der Memory-Recall der Agents erzwingt diesen Scope, sodass ein Agent für Tenant A nicht die Threads von Tenant B abrufen kann. Das behandeln wir in unserem Agent-Memory-Guide.

Tool-Ebene. Jedes Tool, das ein Agent aufrufen kann, prüft vor der Ausführung den Tenant-Scope und trägt Tenant, Channel und erlaubte Ressourcen in seinem Runtime-Kontext.

Dashboard. Cross-Tenant-Zugriff liefert ein Not-Found statt eines Forbidden, damit die Antwort nicht einmal bestätigt, dass die Ressource eines anderen Tenants existiert.

Sechs Ebenen, und ein einzelner vergessener Check auf einer davon legt keine Daten offen, weil die anderen weiter halten. Genau das ist der Punkt von Defense in Depth. Unser Guide zum Multi-Tenant-Systemdesign geht tiefer auf die Patterns ein.

Die AWS-Bausteine

So mappen die Teile auf konkrete Services, gezogen aus einem Produktions-Deployment.

Das Pattern zum Mitnehmen: Datenspeicher liegen in privaten Subnetzen ohne öffentlichen Zugriff, Compute erreicht sie über das VPC, und nur der Load Balancer und das CDN zeigen ins Internet. Die Token-Anreicherung im Auth-Layer ist der Ort, an dem die Tenant-Identität in jeden Request gestempelt wird, sodass Downstream-Services ihr vertrauen können. Unser Infrastructure-as-Code-Guide behandelt, wie du all das reproduzierbar provisionierst.

Limits pro Tenant: Damit ein Tenant nicht das ganze Schiff versenkt

Gemeinsame Infrastruktur heißt: Die Runaway-Last oder der geleakte Key eines Tenants ist das Problem aller, außer du begrenzt es. Zwei Kontrollen zählen.

Rate Limits pro Tenant deckeln das Request-Volumen nach Tenant und nach Credential-Typ, damit ein heißer Tenant den Rest nicht aushungert. Kostenlimits pro Tenant setzen eine harte monatliche Obergrenze für teure Operationen, vor allem Model-Calls, als Blast-Radius-Absicherung gegen einen geleakten Key oder eine Agent-Schleife, die durchdreht. In Exfinity liegen diese Caps deutlich über der erwarteten Nutzung eines Tiers, sie sind also ein Sicherheitsnetz, keine Billing-Drossel, und wer eines erreicht, bekommt für den Rest des Monats einen klaren Fehler statt einer stillen Überberechnung.

Ohne das setzt dein nachlässigster Kunde den Reliability-Floor für alle. Unser Guide zum Design von Systemen für den Fehlerfall behandelt diese defensive Haltung.

Das Event-Backbone: Die Plattform entkoppeln

Eine Multi-Tenant-Plattform, die alles im Request-Pfad erledigt, ist fragil, weil eine langsame Abhängigkeit den User blockiert. Die Services, die gut skalieren, schieben Arbeit aus dem Request-Pfad auf ein asynchrones Backbone, damit der User eine schnelle Antwort bekommt und die schwere Arbeit außerhalb passiert.

Zwei Mechanismen tragen das. Geordnete Queues übernehmen Arbeit, die genau einmal und in Reihenfolge passieren muss, eine Buchung, die zu einer Supplier-Reservierung wird, mit einer Dead-Letter-Queue, die alles Fehlgeschlagene auffängt, damit nichts still verloren geht. Ein Scheduling-Service feuert wiederkehrende Jobs, Freshness-Checks, Cleanup, Archivierung, ohne einen Cron-Server, den jemand babysitten muss.

User action ──▶ fast response
     │
     └──▶ ordered queue ──▶ worker ──(fail)──▶ dead-letter queue
                                                      │
                                            alert, inspect, replay

Exfinity fährt Buchungen und Dokumentgenerierung über geordnete Queues mit Dead-Letter-Queues und treibt seine Crawl- und Wartungszeitpläne über einen Event-Bus. Eine gesunde Plattform hält diese Dead-Letter-Queues leer, eine nicht leere ist also ein Alert. Das ist dieselbe Reliability-Disziplin wie in unserem Enterprise-Integration-Guide, angewandt innerhalb einer einzelnen Plattform, und das allgemeine Pattern steht in unserem Guide zu Event-getriebener Architektur.

Datenresidenz: Wo die Daten physisch liegen

Für europäische Kunden ist das keine Präferenz, sondern eine Anforderung. Wenn dein Vertrag oder die GDPR sagt, dass Daten in der EU bleiben, muss deine Architektur das erzwingen, nicht nur behaupten.

Das heißt, eine Region bewusst wählen und Speicherung wie Verarbeitung darin halten. Exfinity läuft in einer EU-Region, mit allen operativen Daten, der Suche und dem Caching in der Region, plus einer dokumentierten Liste der Subprozessoren und was jeder davon berührt. Model-Provider außerhalb der EU werden als Subprozessoren mit Data-Processing-Terms geführt, und personenbezogene Daten kannst du mit Tokenisierung komplett aus ihnen raushalten, wie in unserem PII-sicheren RAG-Guide beschrieben. Unser GDPR-und-KI-Guide und unsere Trust-Seite liefern die Compliance-Einordnung.

Infrastructure as Code: Reproduzierbar oder gar nicht

Eine Multi-Tenant-Plattform, die du nicht aus Code neu aufbauen kannst, ist eine Belastung. Alles, Networking, Compute, Datenspeicher, IAM, ist als Code definiert und wird über eine Pipeline angewandt, damit Umgebungen reproduzierbar sind und Änderungen reviewed werden.

Die Disziplin, die zählt: getrennter State pro Umgebung, Least-Privilege-Rollen für die Pipeline selbst und keine manuellen Konsolen-Änderungen, die vom Code wegdriften. Exfinity provisioniert seinen Stack mit Terraform und einem Wrapper für Per-Service-Konfiguration und Remote State, promotet durch Development, Staging und Production mit manueller Freigabe auf Production. Unser Infrastructure-as-Code-Guide behandelt die Praktiken, die das wartbar halten.

Erste Schritte

1. Entscheide zuerst die Isolation. Erzwing den Tenant-Scope auf jeder Ebene, bevor du Features baust.
2. Teile Compute nach Workload. Functions für spitzenlastig und event-getrieben, Container für warm und zustandsbehaftet.
3. Stemple die Tenant-Identität beim Auth. Pack sie in verifizierte Token-Claims, vertrau nie dem Client.
4. Füg Limits pro Tenant früh hinzu. Rate Limits und Kostenlimits, bevor du echte Last onboardest.
5. Codifiziere alles. Infrastructure as Code vom ersten Tag, nicht nachgerüstet.

Das ist gestaffelt und passt zur phasenweisen Lieferung in unserer Methodik. Unsere Cloud- und Consulting-Teams designen und bauen diese Plattformen. Starte über Kontakt oder hol dir ein Angebot.

Wie das typischerweise schiefgeht

1. Isolation auf einer Ebene. Ein einzelner vergessener Check leakt Daten. Erzwing den Tenant-Scope überall.
2. Dem Client bei der Tenant-Identität vertrauen. Eine Tenant-ID in der URL ist fälschbar. Nutz verifizierte Token-Claims.
3. Keine Limits pro Tenant. Die Last oder der geleakte Key eines Tenants versenkt alle. Begrenze es.
4. Öffentliche Datenspeicher. Datenbanken und Suche gehören in private Subnetze, nur über das VPC erreichbar.
5. Manuelle Infrastruktur. Konsolen-Änderungen driften und lassen sich nicht neu aufbauen. Codifiziere alles.
6. Residenz ignorieren, bis ein Vertrag danach fragt. Region-Constraints nachzurüsten ist schmerzhaft. Wähle bewusst von Anfang an.

Wer das baut

Oronts ist eine gründergeführte Softwarefirma in München. Refaat Al Ktifan, unser Gründer und Solution Architect, führt ein Senior-Team über Backend, Cloud und Platform. Die Architektur in diesem Guide ist das echte Design hinter Exfinity, einem Multi-Tenant-SaaS, das wir auf AWS in einer EU-Region betreiben. Wir designen das Isolationsmodell, bauen die Serverless- und Container-Ebenen, codifizieren die Infrastruktur und übergeben dir eine Plattform, die du betreiben und skalieren kannst. Sieh dir unsere Seiten Services und Solutions an.

Kernpunkte

• Die definierende Entscheidung im Multi-Tenant-SaaS ist die Isolation, erzwungen auf jeder Ebene, nicht nur auf einer.
• Teile Compute nach Workload: Functions für spitzenlastig und event-getrieben, Container für warm und zustandsbehaftet.
• Stemple die Tenant-Identität im Auth-Layer aus verifizierten Claims und vertrau dafür nie dem Client.
• Begrenze jeden Tenant mit Rate Limits und Kostenlimits, damit keiner die Plattform versenken kann.
• Wähle deine Region bewusst für Datenresidenz und codifiziere die gesamte Infrastruktur.

Multi-Tenancy, richtig gemacht, ist für den Kunden unsichtbar und in der Architektur offensichtlich. Jede Ebene weiß, wessen Daten sie hält, und kein einzelner Fehler kann diese Linie überschreiten.

Du baust oder skalierst eine Multi-Tenant-Plattform auf AWS? Erzähl uns von deinen Isolations- und Residenzanforderungen. Starte über Kontakt oder hol dir ein konkretes Angebot.