Managed Kubernetes für SaaS-Anbieter: Was es 2026 wirklich kostet und wie Sie auswählen

TL;DR

Für einen SaaS-Anbieter mit 10-100 Mitarbeitern rechnet sich Managed Kubernetes fast immer gegenüber selbst betriebenen Clustern. Ein typisches 15-Node-Produktions-Setup kostet bei AKS, EKS oder GKE zwischen 5.000 und 6.500 € pro Monat (Listenpreise, Region Frankfurt, Stand Juli 2026 — Details und Rechenweg unten). Ein eigenes 2-Personen-Ops-Team kostet dagegen rund 17.000 € pro Monat an Personalkosten — zusätzlich zur Infrastruktur. Der Break-even für Self-Managed liegt realistisch erst bei Setups, in denen Sie ohnehin drei oder mehr Plattform-Engineers beschäftigen oder harte On-Premises-Anforderungen haben. Die Anbieterwahl entscheidet sich für DACH-SaaS meist an drei Punkten: EU-Datenresidenz, Egress-Preisen und Support-Kosten — nicht an der Kubernetes-Version.

Das Problem: Ihr Produkt-Team soll skalieren, nicht Cluster-Nodes patchen

Die Situation kennen die meisten SaaS-Anbieter zwischen 10 und 100 Mitarbeitern: Das Produkt läuft, Kunden kommen dazu, und irgendwann trägt ein einzelner Entwickler nebenbei die Verantwortung für das Kubernetes-Cluster. Der Kalender dieses Entwicklers sieht dann so aus:

• etcd-Backups prüfen (oder feststellen, dass es keine gibt)
• Control-Plane-Upgrades von 1.31 auf 1.32 planen, testen, durchführen
• CVEs in containerd und im Kernel der Worker-Nodes bewerten
• Zertifikatsrotation der Kubelet-Zertifikate im Blick behalten
• Nachts aufstehen, wenn der API-Server nicht mehr antwortet

Jede dieser Stunden fehlt im Produkt. Bei einem intern kalkulierten Entwickler-Tagessatz von 600-800 € summiert sich ein halber Ops-Tag pro Woche auf 1.200-1.600 € pro Monat an Opportunitätskosten — für Arbeit, die AKS, EKS und GKE als Commodity abnehmen. Wie SaaS-Teams das komplett ohne dediziertes Ops-Team lösen, haben wir in Kubernetes für SaaS-Anbieter ohne Ops-Team beschrieben.

Grundlagen: Was Managed Kubernetes wirklich abnimmt — und was nicht

Managed Kubernetes ist kein Vollservice. Die Trennlinie verläuft exakt zwischen Control-Plane und Ihren Workloads.

Das übernimmt der Anbieter:

• Control-Plane-Betrieb: API-Server, Scheduler, Controller-Manager laufen hochverfügbar, ohne dass Sie eine VM dafür sehen
• etcd: Betrieb, Verschlüsselung at-rest, Backups des Cluster-States
• Control-Plane-Upgrades: neue Kubernetes-Minor-Versionen per Klick oder API-Call
• Node-Pool-Management: Provisionierung, OS-Images mit gehärteten Defaults, automatisierte Node-Upgrades (bei GKE Autopilot vollständig automatisiert)
• Cluster-Autoscaling: Integration mit den jeweiligen VM-Scale-Mechanismen (VMSS, Auto Scaling Groups, MIGs)

Das bleibt bei Ihnen:

• Workload-Manifeste, Deployments, Helm-Charts
• RBAC, NetworkPolicies, Pod Security Standards
• Observability (Prometheus, Loki, Alerting)
• Kostenkontrolle über Requests und Limits
• Applikations-Security und Image-Scanning (z. B. mit Trivy)

Ein Beispiel für das, was Sie weiterhin selbst sauber definieren müssen — ein Deployment mit Spread über Availability Zones, damit ein Zonenausfall Ihr SaaS nicht mitreißt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend
  namespace: production
spec:
  replicas: 6
  selector:
    matchLabels:
      app: api-backend
  template:
    metadata:
      labels:
        app: api-backend
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-backend
      containers:
        - name: api
          image: registry.example.com/api-backend:1.42.0
          resources:
            requests:
              cpu: 500m
              memory: 1Gi
            limits:
              memory: 1Gi

Dazu das passende PodDisruptionBudget, damit automatisierte Node-Upgrades des Managed-Anbieters nie mehr als einen Pod gleichzeitig evakuieren:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-backend-pdb
  namespace: production
spec:
  minAvailable: 5
  selector:
    matchLabels:
      app: api-backend

Ob Ihre Manifeste solche Basics erfüllen, prüfen Sie automatisiert — etwa mit Polaris oder kubeaudit in der CI-Pipeline.

Praxis: TCO-Vergleich AKS vs. EKS vs. GKE für ein 15-Node-SaaS-Cluster

Referenz-Workload: ein B2B-SaaS mit 40-60 Services pro Umgebung, Produktions-Cluster mit 15 Worker-Nodes à 8 vCPU / 32 GB RAM, 3 Availability Zones, Region Frankfurt (bzw. eu-central-1 / europe-west3), 2 TB Block-Storage, 2 Load Balancer, 5 TB Egress pro Monat.

Alle Zahlen sind On-Demand-Listenpreise, Stand Juli 2026, gerundet und als Schätzung zu verstehen — Cloud-Preise ändern sich, und Ihre Instanzwahl weicht ab. Wechselkurs mit 1 USD ≈ 0,92 € angesetzt.

Drei Beobachtungen daraus:

1. Die Anbieter liegen bei Compute nur 5-8 % auseinander. Wer den Anbieter allein über den VM-Preis auswählt, optimiert die falsche Stellschraube.
2. Commitments sind der größte Hebel: 1-Jahres-Reservierungen sparen auf Compute typischerweise 28-35 %, 3 Jahre bis zu 55-60 %. Für ein SaaS mit stabiler Baseline ist das risikoarm.
3. Egress ist der versteckte Posten: 5 TB sind für ein API-lastiges B2B-SaaS realistisch; ein medienlastiges Produkt liegt schnell beim Drei- bis Fünffachen — und dann reden wir über 1.200-2.000 €/Monat nur für ausgehenden Traffic.

Ihre konkreten Zahlen mit eigener Node-Anzahl, Instanztyp und Egress-Volumen rechnen Sie direkt durch: Der Multi-Cloud-Kostenrechner AKS vs. EKS vs. GKE nutzt aktuelle Listenpreise für die EU-Regionen und zeigt die Commitment-Ersparnis pro Anbieter.

Break-even-Rechnung: Managed vs. eigenes 2-Personen-Ops-Team

Die ehrliche Vergleichsrechnung ist nicht "Managed vs. kostenlos", sondern "Managed plus wenig eigene Ops-Zeit" gegen "Self-Managed plus eigenes Team". Konservativ gerechnet:

Die Personalannahme (85.000 € brutto für einen Platform Engineer mit Kubernetes-Produktionserfahrung in Deutschland, 2026) ist eher unter- als übertrieben; die 0,3 FTE auf Managed-Seite decken Node-Pool-Upgrades, RBAC-Pflege und Incident-Response ab. Ergebnis: Self-Managed kostet in diesem Szenario rund das Dreifache. Der Break-even kippt erst, wenn Sie (a) fünf oder mehr große Cluster betreiben, über die sich das Team amortisiert, (b) On-Prem-Pflichten haben (Kundenvorgabe, Datenhaltung) oder (c) das Team ohnehin aus anderen Gründen existiert. Die ausführliche Herleitung inklusive der oft vergessenen Kostenblöcke (Recruiting, Vertretung, Weiterbildung) steht im TCO-Vergleich Managed Service vs. Inhouse.

Auswahlkriterien: Worauf es für DACH-SaaS wirklich ankommt

Kurzfassung für die typische Ausgangslage: Wählen Sie den Anbieter, bei dem Ihre Datenbank und Ihr Identity-Provider schon liegen. Die Kubernetes-Qualität selbst ist 2026 bei allen drei kein Differenzierer mehr. Für ISVs, die ihr Produkt zusätzlich in Kundenumgebungen deployen müssen, gelten Sonderregeln — die haben wir in Kubernetes für ISVs und Software-Anbieter aufgeschrieben.

Fallstricke

1. Vendor-Lock-in entsteht nicht durch Kubernetes, sondern drumherum. Ihre Deployments sind portabel. Nicht portabel sind: IAM-Anbindungen (IRSA, Workload Identity), anbieterspezifische Ingress-Annotationen, CSI-Treiber-Details und vor allem die Datenbank daneben. Zählen Sie die anbieterspezifischen Annotationen in Ihren Manifesten:

kubectl get ingress -A -o json | jq -r '.items[].metadata.annotations | keys[]' | sort | uniq -c | sort -rn

Alles, was mit alb.ingress.kubernetes.io/, service.beta.kubernetes.io/azure- oder cloud.google.com/ beginnt, ist späterer Migrationsaufwand.

2. Versteckte Support-Kosten. Der AWS-Business-Support kostet 3-10 % des monatlichen Spends — bei 5.000 € Cloud-Rechnung ab ~160 €/Monat, bei wachsendem Spend proportional mehr. Das fehlt in fast jeder TCO-Rechnung, ist aber für Produktionsbetrieb faktisch Pflicht.

3. Egress-Fallen im Cluster selbst. Cross-Zone-Traffic innerhalb des Clusters kostet bei AWS und GCP extra (~0,01 €/GB pro Richtung). Ein gesprächiges Microservice-Mesh über 3 Zonen kann intern mehr Traffic-Kosten erzeugen als der Kunden-Egress. Gegenmittel: Topology Aware Routing aktivieren:

kubectl annotate service api-backend -n production service.kubernetes.io/topology-mode=Auto

4. Extended-Support-Gebühren für alte Kubernetes-Versionen. EKS und AKS berechnen für Cluster auf Versionen außerhalb des Standard-Supports deutlich erhöhte Control-Plane-Gebühren — bei EKS das Sechsfache (0,60 $/h statt 0,10$/h). Wer Upgrades zwei Jahre schiebt, zahlt dafür. Prüfen Sie Ihre Version:

kubectl version --output=json | jq -r '.serverVersion.gitVersion'

5. Autoscaling ohne Requests ist wirkungslos. Der Cluster Autoscaler skaliert auf Basis von Requests, nicht der tatsächlichen Last. Pods ohne Requests machen jede Kostenoptimierung zum Blindflug. Finden Sie die Kandidaten:

kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].resources.requests == null) | "\(.metadata.namespace)/\(.metadata.name)"' | sort -u

FAQ: Die fünf häufigsten Kauf-Fragen

Ab welcher Größe lohnt sich Managed Kubernetes für einen SaaS-Anbieter? Praktisch ab dem ersten Produktions-Cluster. Die Control-Plane-Gebühr von ~67 €/Monat ist gegen die eigene Betriebszeit (etcd, Upgrades, HA-Setup) immer die günstigere Option. Die eigentliche Frage ist nicht "Managed ja/nein", sondern wie viel Workload-Ops Sie zusätzlich intern abdecken oder extern vergeben.

Welcher Anbieter passt für DACH-SaaS mit DSGVO-Anforderungen am besten? Alle drei bieten Frankfurt-Regionen, AVV/SCC und Verschlüsselung. Unterschiede liegen im Detail: Azure punktet mit der EU Data Boundary und der Verbreitung von Entra ID im deutschen Mittelstand, AWS mit der größten Service-Breite, Google mit dem am stärksten automatisierten Betrieb. Bei harten Souveränitätsanforderungen (Behördenkunden, KRITIS-Umfeld) sind zusätzlich deutsche Anbieter wie StackIT, plusserver oder IONOS eine Prüfung wert — mit deutlich kleinerem Ökosystem als Trade-off.

Wie lange dauert eine Migration von Self-Managed zu Managed Kubernetes? Für ein Setup unserer Referenzgröße mit sauberen Helm-Charts und GitOps: realistisch 4-8 Wochen inklusive Parallelbetrieb und DNS-Umzug. Die Kubernetes-Manifeste selbst sind selten das Problem — Zeit kosten Stateful-Workloads, IAM-Umbau und CI/CD-Anpassungen. Ohne GitOps-Basis eher 3-4 Monate.

Was kostet ein realistisches Staging-Setup zusätzlich? Mit Spot-/Preemptible-Instanzen und einem Drittel der Node-Anzahl: 600-1.000 €/Monat. Staging auf Spot-Kapazität ist bei allen drei Anbietern der Standard-Sparhebel (60-80 % Rabatt auf Compute) und für nicht-produktive Umgebungen risikolos genug.

Managed Kubernetes oder gleich vollständig gemanagter Betrieb durch einen Dienstleister? Managed Kubernetes nimmt die Control-Plane ab, nicht den Workload-Betrieb. Wenn intern niemand Alerting, Node-Pool-Upgrades und Incident-Response übernehmen kann, brauchen Sie zusätzlich entweder eine interne Teilzeit-Rolle (0,3-0,5 FTE) oder einen Betriebs-Partner. Die Zwischenstufe "Hyperscaler-Cluster plus externer Workload-Betrieb" ist für SaaS mit 10-100 Mitarbeitern häufig das beste Verhältnis aus Kosten und Verantwortungsklarheit.

Fazit

Für SaaS-Anbieter mit 10-100 Mitarbeitern ist die Entscheidung 2026 klar: Managed Kubernetes bei AKS, EKS oder GKE, Anbieterwahl nach vorhandenem Stack und Datenstrategie, Commitment nach 3-6 Monaten stabiler Baseline. Ein 15-Node-Produktions-Cluster kostet mit Commitment rund 3.800-4.000 €/Monat — ein eigenes Ops-Team für Self-Managed das Dreifache und mehr, ohne besseren Schlaf zu liefern. Die Kostenkontrolle verlagert sich damit von "Cluster betreiben" zu "Workloads richtig dimensionieren": Requests, Autoscaling, Egress und Support-Tier sind die vier Posten, an denen Sie tatsächlich steuern können.

Rechnen Sie Ihr eigenes Szenario durch, bevor Sie sich festlegen: Der kostenlose Multi-Cloud-Rechner vergleicht AKS, EKS und GKE mit Ihren Node-Zahlen, Instanztypen und Egress-Volumen — inklusive Commitment-Rabatten und in Euro.