Managed Kubernetes vs. selbst betreiben: Kostenvergleich und Entscheidung 2026

TL;DR

Die Build-vs-Buy-Entscheidung lässt sich auf eine Zahl und einen Schwellwert reduzieren: Der Managed-Aufpreis für die Control Plane liegt bei ca. 850 € pro Cluster und Jahr (EKS/AKS/GKE Standard-Tier, Stand Juli 2026). Die Personalkosten für einen selbst betriebenen Production-Cluster liegen bei mindestens einer zusätzlichen vollen Stelle, also grob 110.000 € pro Jahr all-in. Das Verhältnis ist 1:130. Self-managed rechnet sich erst, wenn Sie den Personal-Mehraufwand über günstigere Infrastruktur (Bare Metal statt Cloud-VMs) wieder hereinholen – und das passiert nach unserer Rechnung frühestens ab 40–60 Worker-Nodes bei stabiler Last. Für den typischen SaaS-Betrieb mit 10–100 Mitarbeitern und 5–30 Nodes ist Managed Kubernetes die klar günstigere Option. Die 3-Jahres-TCO-Differenz im Beispielszenario unten: rund 324.000 €.

Das Problem: Selbst betreiben wirkt billiger – auf dem Papier

Die Rechnung, die in vielen Entscheidungsvorlagen steht, sieht so aus: Drei Control-Plane-VMs bei Hetzner kosten 150 € im Monat, die EKS-Control-Plane kostet 0,10 USD pro Stunde – "das sparen wir uns, kubeadm ist ja schnell aufgesetzt". Das stimmt. kubeadm init läuft in 15 Minuten durch.

Was in dieser Rechnung fehlt, sind die Kosten ab Tag 2:

• etcd-Backups, die nicht nur laufen, sondern auch getestet restored werden
• Drei bis vier Kubernetes-Minor-Upgrades pro Jahr (Release-Zyklus ~15 Wochen, Support-Fenster 14 Monate), jeweils Control Plane plus alle Nodes, in der richtigen Version-Skew-Reihenfolge
• CVE-Response: Wenn das nächste containerd- oder ingress-nginx-CVE kommt, patcht das niemand für Sie
• On-Call: Ein Cluster, auf dem Ihr SaaS-Produkt läuft, braucht jemanden, der nachts um 3 Uhr rangeht, wenn etcd keinen Leader mehr wählt
• Zertifikats-Rotation, CNI-Upgrades, OS-Patching der Nodes

Jeder einzelne Punkt ist machbar. Zusammen sind sie eine Dauerstelle. Und genau diese Stelle taucht in der 150-€-Hetzner-Rechnung nicht auf, weil sie im Engineering-Budget versteckt ist – als die 30 % Arbeitszeit, die Ihre zwei Senior-Entwickler nicht mehr am Produkt arbeiten.

Grundlagen: Was "selbst betreiben" konkret bedeutet

Damit die TCO-Rechnung nicht abstrakt bleibt, hier die vier Arbeitspakete, die Sie bei self-managed (kubeadm, kOps oder Cluster API auf eigenen VMs/Bare Metal) dauerhaft besitzen – mit den Handgriffen, die dahinterstecken.

1. etcd: Backup, Restore, Disaster Recovery

etcd ist der Single Point of Truth Ihres Clusters. Ohne getestetes Backup ist jeder etcd-Datenverlust ein Totalschaden. Das Minimum ist ein Snapshot-Cron plus regelmäßige Restore-Übung:

# Snapshot ziehen (auf einem Control-Plane-Node)
ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd/snap-$(date +%F).db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key

# Snapshot verifizieren – ein Backup ohne Verify ist kein Backup
ETCDCTL_API=3 etcdctl snapshot status /var/backups/etcd/snap-$(date +%F).db --write-out=table

Dazu gehört Velero (oder ein Äquivalent) für Workload- und PV-Backups, als Schedule im Cluster:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-cluster-backup
  namespace: velero
spec:
  schedule: '0 2 * * *'
  template:
    includedNamespaces: ['*']
    excludedNamespaces: ['kube-system']
    ttl: 720h # 30 Tage Aufbewahrung
    snapshotVolumes: true

Bei Managed Kubernetes entfällt der etcd-Teil komplett – die Control-Plane-Datenhaltung inklusive Backup ist Teil des SLA. Velero für Workloads brauchen Sie in beiden Welten.

2. Upgrades: drei- bis viermal pro Jahr, in fester Reihenfolge

Die Version-Skew-Policy erlaubt beim kubelet mehr Spielraum, als viele denken: Seit Kubernetes 1.28 darf der kubelet bis zu drei Minor-Versionen älter sein als der kube-apiserver (davor waren es zwei). Enger ist es innerhalb der Control Plane: Komponenten wie kube-controller-manager und kube-scheduler dürfen maximal einen Minor hinter dem API-Server liegen. Dass Sie mit kubeadm trotzdem keine Minor-Version überspringen können, liegt nicht am Skew, sondern am Tool selbst: kubeadm upgrade unterstützt nur den Sprung von einem Minor zum nächsten. Wer zwei Releases aufholen muss, upgradet also zweimal hintereinander. Der Ablauf pro Upgrade, pro Cluster:

# 1. Prüfen, was ansteht und ob der Skew passt
kubectl get nodes -o wide
kubeadm upgrade plan

# 2. Control Plane upgraden (erster Node)
kubeadm upgrade apply v1.34.2

# 3. Jeden Worker-Node einzeln: erst kubeadm aktualisieren und die Node-Konfiguration
#    upgraden, dann drainen, kubelet/kubectl aktualisieren, wieder freigeben
apt-mark unhold kubeadm
apt-get install -y kubeadm=1.34.2-1.1
apt-mark hold kubeadm
kubeadm upgrade node
kubectl drain node-07 --ignore-daemonsets
apt-mark unhold kubelet kubectl
apt-get install -y kubelet=1.34.2-1.1 kubectl=1.34.2-1.1
apt-mark hold kubelet kubectl
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon node-07

Realistischer Aufwand pro Minor-Upgrade auf einem Production-Cluster mit 10–15 Nodes: 1–2 Personentage inklusive Staging-Durchlauf, Changelog-Review (API-Deprecations!) und Addon-Kompatibilität (CNI, Ingress, cert-manager). Mal 3–4 Upgrades, mal Anzahl Cluster. Bei Managed reduziert sich das auf einen Klick bzw. ein az aks upgrade / eksctl upgrade cluster plus denselben Staging-Test – der Node-Rollout, die Control-Plane-Migration und das Skew-Management übernimmt der Anbieter.

3. Sicherheit: Sie sind die Security-Abteilung

Self-managed heißt: CIS-Benchmark-Konformität (prüfbar mit kube-bench), Image-Scanning (Trivy), Runtime-Detection (Falco) und Node-OS-Patching liegen vollständig bei Ihnen – inklusive der Control-Plane-Komponenten, die bei Managed gar nicht erst in Ihrem Zuständigkeitsbereich liegen:

# CIS-Benchmark gegen den eigenen Cluster fahren
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Bei Managed prüft kube-bench nur noch die Node- und Policy-Ebene; API-Server-Flags, etcd-Verschlüsselung und Controller-Manager-Härtung sind Anbieterseite. Das ist kein Detail: Es ist der Unterschied zwischen ~50 und ~110 CIS-Prüfpunkten in Ihrer Verantwortung.

4. On-Call und der Bus-Faktor

Eine Person kann keinen 24/7-Betrieb leisten. Zwei Personen können es formal (jede zweite Woche Rufbereitschaft), aber nicht nachhaltig – Urlaub, Krankheit, Kündigung. Ernsthafte On-Call-Rotation beginnt bei drei Personen mit Cluster-Tiefenwissen. In einem Unternehmen mit 10–100 Mitarbeitern sind drei Kubernetes-tiefe Engineers fast immer eine Fehlallokation von Engineering-Kapazität.

Praxis: Der 3-Jahres-TCO im Vergleich

Szenario, auf das die Zahlen kalibriert sind: SaaS-Unternehmen, 25 Mitarbeiter, 2 Cluster (Production + Staging), 12 Worker-Nodes Production (je 8 vCPU / 32 GB), Deutschland. Alle Beträge sind Schätzungen auf Basis marktüblicher Gehälter und Listenpreise Stand Juli 2026, keine Fallstudie. Gehaltsbasis: Senior Platform Engineer 90.000 € brutto + ~21 % Arbeitgeberanteil ≈ 109.000 €/Jahr all-in.

Differenz: 323.700 € über drei Jahre – zugunsten Managed. Und die Struktur der Tabelle zeigt, warum: Die Control-Plane-Gebühr (5.100 €) ist Rauschen. Die Infrastruktur ist self-managed sogar günstiger (–25.000 €). Entschieden wird die Rechnung fast ausschließlich über den Personal-Delta von einer vollen Stelle. Wer den TCO-Vergleich nur auf Cloud-Listenpreise rechnet, rechnet am eigentlichen Kostentreiber vorbei.

Die 1,5 FTE für self-managed sind konservativ: Sie decken Upgrades, Patching, Backup-Tests, Monitoring-Pflege und eine dünne On-Call-Abdeckung. Wer echtes 24/7 mit Drei-Personen-Rotation will, liegt eher bei 2–2,5 FTE – dann wächst die Differenz auf über 500.000 €.

Break-even-Analyse: Ab wann kippt die Rechnung?

Self-managed hat einen einzigen strukturellen Kostenvorteil: Sie können auf Bare Metal ausweichen. Ein dedizierter Server mit 16 Cores / 64 GB kostet bei deutschen Hostern rund 120–150 €/Monat; eine vergleichbare Cloud-VM liegt on-demand bei 350–450 €/Monat, mit Reserved Instances bei 200–280 €. Die realistische Ersparnis pro Node: 150–250 €/Monat.

Dagegen steht der Personal-Mehraufwand von ~1 FTE ≈ 9.100 €/Monat. Daraus folgt die Break-even-Formel:

Break-even-Nodes = Personal-Mehrkosten / Infra-Ersparnis pro Node
                 = 9.100 € / (150 … 250 €)
                 = 36 … 60 Nodes

Nach Teamgröße differenziert (Schätzung, Konfidenz mittel):

Zwei Einschränkungen, die die Break-even-Schwelle nach oben verschieben: Erstens gilt die Bare-Metal-Ersparnis nur bei stabiler Grundlast – wer stark autoskaliert, bezahlt Bare Metal für die Peak-Kapazität. Zweitens ist der Vergleichsmaßstab nicht on-demand, sondern der optimierte Cloud-Preis (Reserved/Savings Plans, Spot für Batch). Wie groß die Preisunterschiede zwischen den drei Hyperscalern selbst ausfallen, können Sie für Ihre konkrete Node-Konfiguration im Multi-Cloud-Rechner durchspielen – dazu unten mehr.

Entscheidungs-Matrix: Wann self-managed trotzdem richtig ist

Es gibt legitime Gründe gegen Managed, auch unterhalb der Break-even-Node-Zahl:

Wichtig: "Managed" ist kein Monolith. Zwischen reiner Managed Control Plane (EKS/AKS/GKE), vollgemanagten Plattformen und deutschen Betreibern mit Betriebsverantwortung liegen erhebliche Unterschiede in Leistung und Preis – die Plattform-Übersicht 2026 sortiert das Feld. Und wer gar kein eigenes Ops-Personal binden will, findet in der Übersicht der SaaS-Anbieter ohne eigenes Ops-Team die Optionen eine Abstraktionsebene höher.

Fallstricke, die in keiner Preisliste stehen

1. Der Bus-Faktor ist eine Verbindlichkeit, keine Fußnote. Wenn Ihr self-managed Cluster von einer Person abhängt, haben Sie keine Infrastruktur, sondern eine Wette auf deren Verbleib. Kündigt sie, kaufen Sie das Wissen für 900–1.400 €/Tag als Freelancer zurück – während der Cluster weiterlaufen muss.

2. Upgrades werden aufgeschoben, bis sie gefährlich sind. Das typische Muster: Team ist mit Features ausgelastet, Cluster bleibt auf einer EOL-Version, keine Security-Patches mehr. Managed-Anbieter erzwingen Upgrades über Support-Fenster – unbequem, aber genau deshalb wirksam.

3. Compliance-Last wird unterschätzt. Für NIS2, ISO 27001 oder TISAX müssen Sie Patch-Management, Backup-Tests und Zugriffskontrolle der Control Plane nachweisen. Bei Managed deckt der Anbieter-Nachweis (SOC 2, C5) einen erheblichen Teil ab; self-managed schreiben Sie die Runbooks, Reports und Audit-Antworten selbst.

4. "Wir sparen die Managed-Gebühr" ist Zahlenkosmetik. 850 €/Jahr Control-Plane-Gebühr gegen einen einzigen ungeplanten etcd-Incident zu stellen (2 Engineers × 2 Tage ≈ 3.500 € Personalkosten, plus Ausfallkosten), beendet die Diskussion in der Regel schnell.

5. Lock-in wird am falschen Ort gefürchtet. Die Kubernetes-API ist portabel; Workload-Manifeste laufen überall. Der reale Lock-in entsteht bei den Diensten drumherum (IAM-Integration, Cloud-Load-Balancer-Annotations, proprietäre CSI-Treiber) – und der trifft self-managed in der Cloud genauso.

FAQ

Gibt es ein hybrides Modell – Managed Control Plane, aber eigene Nodes? Ja, und es ist oft der beste Mittelweg: Managed Control Plane beim Hyperscaler, dazu selbst verwaltete Node-Pools oder – etwa bei GKE/EKS mit Anthos/Outposts-Konstrukten bzw. bei deutschen Anbietern – Nodes im eigenen Rechenzentrum. Sie eliminieren damit den teuersten Betriebsteil (etcd, API-Server, Upgrades der Control Plane) und behalten Hardware-Kontrolle auf Node-Ebene.

Können wir von Managed später zurück zu self-managed wechseln? Technisch ja, und leichter als umgekehrt: Workloads sind in Git (GitOps), Manifeste sind portabel, ein Cluster-Umzug ist mit Velero oder einem Blue-Green-Cluster-Switch in Wochen machbar. Der eigentliche Aufwand ist nicht die Migration, sondern der Aufbau des Betriebsteams – rechnen Sie 6–12 Monate, bevor das interne Team das Niveau des Anbieters erreicht.

Wie hoch ist der Lock-in bei EKS, AKS und GKE wirklich? Auf Kubernetes-Ebene gering – Deployments, Services, Ingress und RBAC sind standardkonform. Konkret werden es die Ränder: IAM-Bindings (IRSA bei AWS, Workload Identity bei GCP/Azure), LoadBalancer-Annotations und CSI-Storage-Klassen. Wer diese Stellen in Helm-Values oder Kustomize-Overlays isoliert, hält die Migrationskosten zwischen Hyperscalern bei Wochen, nicht Monaten.

Was kostet die Migration von self-managed zu Managed? Für das Szenario oben (2 Cluster, 12 Nodes, GitOps vorhanden): schätzungsweise 15–30 Personentage, also 10.000–25.000 € intern oder extern beauftragt. Ohne GitOps und mit stateful Workloads (Datenbanken im Cluster) eher das Doppelte. Die Migration amortisiert sich im Beispielszenario in unter drei Monaten über die Personal-Differenz.

Reicht bei Managed Kubernetes wirklich eine halbe Stelle? Für den Cluster-Betrieb ja – nicht aber für alles darüber. CI/CD, Observability der Anwendungen, Kostenkontrolle und Security-Policies (Kyverno/OPA, Trivy in der Pipeline) bleiben Ihre Aufgabe. Die halbe Stelle in der TCO-Rechnung deckt genau diesen verbleibenden Plattform-Anteil; sie ist keine Null.

Fazit

Die Entscheidung "Managed Kubernetes vs. selbst betreiben" ist 2026 keine Technologie-, sondern eine Personalrechnung. Die Control-Plane-Gebühr von ~850 € pro Cluster und Jahr steht gegen mindestens eine volle Engineer-Stelle – ein Verhältnis von 1:130. Unterhalb von ~40 Worker-Nodes gibt es fast kein Szenario, in dem self-managed günstiger ist; erst mit stabiler Grundlast, Bare-Metal-Strategie und einem bestehenden Platform-Team ab etwa 40–60 Nodes kippt die Rechnung. Für die typische SaaS-Firma mit 10–100 Mitarbeitern heißt das: Managed Control Plane nehmen, die gesparte Stelle ins Produkt stecken, und die Betriebsverantwortung dort behalten, wo sie differenziert – bei Ihren Workloads.

Welcher Hyperscaler für Ihre konkrete Node-Konfiguration am günstigsten ist, rechnen Sie in fünf Minuten selbst nach: AKS vs. EKS vs. GKE im Multi-Cloud-Kostenrechner vergleichen.

Alle Beträge sind Schätzungen auf Basis von Listenpreisen und marktüblichen Gehältern in Deutschland, Stand Juli 2026. Ihre konkreten Zahlen hängen von Workload-Profil, Region und Verhandlungsposition ab.