Was ist Multi-Tenant-Cloud-Hosting?

Multi-Tenant-Cloud-Hosting ist ein Modell, bei dem ein Satz Server und Software viele Kunden bedient, mit logischer Isolation zwischen den Tenants. Denken Sie an ein Mehrfamilienhaus: Die Parteien teilen sich Gebäude, Leitungen und Strom, aber jede Tür hat ein Schloss. Die Alternative – Single-Tenant-Hosting – ist das freistehende Haus: volle Kontrolle, höhere Miete, und mehr Instandhaltung liegt bei Ihnen.

Das Wichtigste in Kürze

Wie Tenant-Daten getrennt bleiben

Jedes Multi-Tenant-System beantwortet zuerst eine Frage: Wo lebt die Isolation? Auf der Datenbankebene gibt es drei kanonische Muster – geteiltes Schema, Schema pro Tenant und Datenbank pro Tenant. Das geteilte Schema ist das Arbeitspferd, und es ist am sichersten, wenn die Datenbank selbst die Grenze durchsetzt:

-- Muster 1: geteiltes Schema — jede Zeile trägt ihren Tenant
CREATE TABLE invoices (
  id        bigserial PRIMARY KEY,
  tenant_id uuid NOT NULL,
  amount    numeric(10,2) NOT NULL
);

-- Isolation in der Datenbank erzwingen, nicht in jeder Abfrage
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Mit einer zeilenbasierten Richtlinie gibt eine Abfrage, die ihren Tenant-Filter vergisst, nichts zurück statt alles – der Fehlerfall kippt vom Datenabfluss zur leeren Seite.

Auf einem Backend as a Service drückt sich dasselbe Prinzip als Zugriffskontrolle pro Objekt statt als SQL-Richtlinie aus. Jeder Datensatz trägt eine ACL, die die Tenant-Rolle benennt, die ihn sehen darf, und die Plattform setzt das bei jeder Anfrage durch:

// JavaScript / Node.js — Back4app JS SDK
const doc = new Parse.Object('Invoice');
doc.set('amount', 480);

const acl = new Parse.ACL();
acl.setPublicReadAccess(false); // invisible to every other tenant
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();

// Flutter / Dart — Back4app Flutter SDK
final doc = ParseObject('Invoice')..set('amount', 480);

final acl = ParseACL();
acl.setPublicReadAccess(allowed: false);
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();

// iOS / Swift — Back4app Swift SDK
var doc = Invoice()
doc.amount = 480

var acl = ParseACL()
acl.publicRead = false
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
doc.ACL = acl
doc.save { _ in }

// Android / Kotlin — Back4app Android SDK
val doc = ParseObject("Invoice").apply { put("amount", 480) }

val acl = ParseACL().apply {
  publicReadAccess = false
  setRoleReadAccess("tenant-acme", true)
  setRoleWriteAccess("tenant-acme", true)
}
doc.acl = acl
doc.saveInBackground()

Isolation ist ein Spektrum, kein Schalter

Zwischen “alles geteilt” und “alles dediziert” liegen die drei Deployment-Formen, aus denen die meisten realen Systeme wählen:

Reife Plattformen mischen die Modelle: die vielen kleinen Tenants poolen, die mittelgroßen per Bridge trennen und die wenigen isolieren, die reguliert, enorm oder laut sind. Der Fehler besteht darin, diese Wahl als globale zu behandeln – sie lässt sich pro Tarif treffen, und sogar pro Komponente.

Multi-Tenant- vs. Single-Tenant-Hosting

Zwei Bedeutungen, die man trennen sollte

“Multi-Tenant-Cloud-Hosting” wird auf zwei verschiedenen Flughöhen verwendet, und die meisten Erklärungen verwischen sie:

• Als Hosting-Stufe: geteiltes Hosting – Ihre Workload läuft auf denselben physischen Maschinen wie die anderer Kunden. Das ist der Standardmodus jeder Public Cloud; die NIST-Definition führt das Bündeln von Ressourcen über Tenants hinweg als wesentliches Merkmal des Cloud Computing selbst auf.
• Als Anwendungsarchitektur: Ihr eigenes Produkt bedient seine Kunden aus einem geteilten Backend – so wird Abonnementsoftware gebaut. Hier sind Sie der Vermieter, und Tenant-Isolation wird Ihre Verantwortung; genau dort greifen die Muster von oben.

Beides setzt sich zusammen: Ein SaaS-Produkt (Multi-Tenancy auf Anwendungsebene) läuft üblicherweise auf gebündelter Cloud-Infrastruktur (Multi-Tenancy auf Hosting-Ebene), wobei jede Schicht ihre eigenen Tenants isoliert.

Das Noisy-Neighbor-Problem

Teilen heißt Konkurrenz um Ressourcen: Der Massenimport eines Tenants kann den Checkout eines anderen verlangsamen. Die üblichen Gegenmittel, in aufsteigender Schärfe:

1. Quoten und Rate Limiting pro Tenant – deckeln, was ein Tenant pro Zeitfenster verbrauchen darf.
2. Ressourcenplanung und Autoscaling – Spitzen abfangen, bevor sie zur Latenz eines anderen werden.
3. Trennung der Workloads – schwere Jobs (Exporte, Analytik) in Hintergrund-Queues abseits des Anfragepfads verschieben.
4. Teilweises Siloing – wenn ein Tenant dauerhaft am Anschlag läuft, bekommt die umkämpfte Komponente (meist die Datenbank) eine eigene Partition, der Rest bleibt gepoolt.

Typische Anwendungsfälle

• SaaS-Produkte. Jede Abo-Anwendung, die alle Kunden aus einer Codebasis bedient – der kanonische Fall und der Grund, warum es das Muster gibt.
• BaaS und Plattform-Hosting. Plattformen betreiben Tausende Anwendungen auf geteilter, isolierter Infrastruktur, sodass die Bereitstellung jeder einzelnen nahezu nichts kostet – das Modell hinter kostenlosen Tarifen.
• B2B-Anwendungen mit Tenant-Workspaces. Ein Deployment, viele Kundenorganisationen, jede mit eigenen Benutzern, Rollen und Datengrenzen.
• Interne Plattformen. Ein Analytik- oder Werkzeug-Deployment, das sich Abteilungen teilen, isoliert nach Team.
• Agenturen mit vielen Kundenanwendungen. Eine geteilte Plattform darunter, ein isoliertes Backend pro Kunde darüber.

Multi-Tenant, Single-Tenant oder gemischt? Eine Entscheidungsmatrix

Beginnen Sie standardmäßig multi-tenant und weichen Sie nur dort davon ab, wo ein Tenant es verdient – Tenancy nachträglich in eine Single-Tenant-Codebasis einzuziehen ist weit schwerer, als später einen heißen Kunden in ein Silo zu stellen.

Grenzen und Trade-offs

• Isolation ist nur so gut wie ihre Durchsetzung. Ein vergessener Tenant-Filter im Anwendungscode ist das klassische Leck zwischen Tenants. Schieben Sie die Grenze in die Datenschicht – zeilenbasierte Richtlinien, ACLs pro Objekt –, damit die Plattform im Zweifel sperrt statt öffnet.
• Geteilter Schadensradius. Ein Ausfall, ein schlechtes Deployment oder ein Einbruch kann alle Tenants auf einmal treffen. Gestaffelte Rollouts und Backups pro Tenant verkleinern den Schaden, nicht das Teilen.
• Noisy Neighbors sind strukturell. Quoten und Planung verwalten die Konkurrenz; nur teilweises Siloing beseitigt sie, zum Preis eines Teilsilos.
• Obergrenze der Anpassbarkeit. Tenants teilen sich eine Codebasis, also lebt tenantspezifisches Verhalten in Konfiguration und Feature Flags – eine Einschränkung, die Single-Tenant-Kunden nicht haben.
• Tenant-Kontext überall. Jede Abfrage, jeder Cache-Schlüssel, jeder Job und jede Logzeile muss den Tenant kennen; die Komplexität wandert von der Infrastruktur in die Anwendung – genau die Last, die verwaltete Isolation in der Datenschicht abnehmen soll.

Multi-Tenant-Hosting mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Sie ist auf beiden Flughöhen multi-tenant. Als Plattform betreibt sie Tausende isolierter App-Backends auf geteilter Infrastruktur – deshalb steht ein neues Backend im kostenlosen Tarif in Minuten bereit. Für die Tenants Ihrer Anwendung ist Isolation ein Feature der Datenschicht statt einer Konvention: Jedes Objekt trägt eine ACL, Rollen gruppieren Benutzer pro Tenant, und Klassenberechtigungen setzen Regeln für das ganze Schema, alles von Back4app bei jeder Anfrage durchgesetzt. Die technische Vertiefung zu Row-Level Security zeigt das vollständige Muster auf einer Dokumentdatenbank – ohne Disziplin bei der WHERE-Klausel.