---
canonical: https://enum.co/de/use-cases/saas
locale: de
---

**SaaS & Cloud-Anwendungen**

# SaaS Infrastruktur

Bringe Multi-Tenant-Produkte auf Kubernetes live, das mit Tenants skaliert, nicht mit Deinem Ops-Team.

SaaS-Unternehmen und ISVs betreiben Multi-Tenant-Anwendungen auf enums europäischer Public Cloud: Managed Kubernetes mit isolierter Control Plane pro Cluster, S3-kompatiblem Object Storage und VPC-Networking in Frankfurt. Enterprise-Käufer bekommen DSGVO-konforme Datenresidenz und planbare Euro-Preise.


### Was SaaS-Teams trifft

- Tenant-Isolation ohne ein Labyrinth aus eigenen Control Planes
- Traffic-Spitzen, wenn ein großer Kunde live geht
- Enterprise-Käufer, die fragen, wo Daten liegen und wer Zugriff erzwingen kann
- Cloud-Rechnungen, die schneller wachsen als der Umsatz

### Was Du auf enum betreibst

- Isolierte Kubernetes Control Plane pro Cluster, inklusive
- Horizontale und vertikale Auto-Skalierung für Workloads
- Region Frankfurt mit DSGVO-konformer Datenresidenz
- Transparente Preise pro Ressource in Euro, ohne Egress-Überraschungen

### Was sich ändert

- Produktionsreife Cluster ab Tag eins, ohne selbst etcd zu betreiben
- Eine klare Antwort zur EU-Datenresidenz in Security-Fragebögen
- Kosten, die Du mit neuen Tenants modellieren kannst, nicht erst nach der Rechnung

### So gehen SaaS-Teams auf enum live

Vom ersten Cluster bis zu zahlenden Tenants.

- **Cluster aufsetzen**: Erstelle ein produktionsreifes Kubernetes-Cluster mit enumctl, API oder Terraform. Control-Plane-HA ist inklusive.
- **Tenants isolieren**: Nutze Namespaces, Network Policies und getrennte Cluster, wo Verträge es verlangen. Das Isolationsmodell bleibt bei Dir.
- **Speichern und vernetzen**: Lege Artefakte und Backups in S3-kompatiblem Object Storage ab. Verbinde Services über VPC-Networking und Load Balancer.

### Plattformteile, die zählen

Dieselben Produkte, die Product-Teams schon bedienen können.

- **enum Kubernetes Engine**: Upstream Kubernetes mit isolierter Control Plane pro Cluster. Gebaut für Multi-Tenant-Produkt-Workloads.
- **Object Storage**: S3-kompatibler Storage für Backups, Exports und Kundenartefakte. Daten bleiben in Frankfurt.
- **VPC & Networking**: Private Cluster by default, L4 Load Balancing und Host-based NAT ohne Zone-Aufschläge.

### Weiterlesen

- [enum Kubernetes Engine](/kubernetes-engine): Isolierte Control Planes, Upstream Kubernetes
- [enum for Startups](/startups): Cloud Credits für Early-Stage-Teams
- [Kundenstories](/customers): Wie Teams Produktion auf enum betreiben
- [AWS-Alternative](/alternative-to-aws): Vergleich mit EKS und US-Regionen
- [Preise](/pricing): Euro-Preise zum Modellieren
- [Fintech Use Case](/use-cases/fintech): Regulierte Workloads auf derselben Plattform

### FAQ


**Können wir Multi-Tenant-SaaS auf einem gemeinsamen Cluster betreiben?**
Ja. Die meisten Teams starten mit Namespace- und Network-Policy-Isolation auf einem Cluster. Wenn ein Kundenvertrag stärkere Trennung verlangt, startest Du ein weiteres Cluster. Jedes Cluster bekommt eine eigene isolierte Control Plane.

**Wo liegen Kundendaten?**
In Frankfurt, auf enums europäischer Public Cloud. Workloads, Object Storage und Networking bleiben unter deutscher und EU-Jurisdiktion ohne Abhängigkeit von einem US-Hyperscaler.

**Wie provisionieren wir Cluster?**
Self-Service über enumctl, die REST-API oder Terraform. Du wartest nicht auf ein Ticket, um ein Cluster zu erstellen oder zu vergrößern.

**Ist die Preisgestaltung für SaaS-Unit-Economics brauchbar?**
Die Preise sind pro Ressource in Euro und auf der Website veröffentlicht. Es gibt keinen Control-Plane-Aufschlag und kein CLOUD-Act-Transferrisiko in der Rechnung.