Managed Kubernetes vs Self-Hosted: Betriebsmodell & TCO 2026

Robin Werner, Kubernetes-Consultant bei Pexon Consulting | 14 Min. Lesezeit | 29.08.2026

TL;DR

Managed Kubernetes (AKS, EKS, GKE) ist 2026 für rund 85% der DACH-Mittelständler die wirtschaftlich überlegene Wahl gegenüber Self-Hosting. Self-Hosting lohnt sich nur bei On-Prem-KRITIS, sehr großen Clustern oder strategischer Souveränität. Pexon Consulting liefert die Betriebsmodell-Entscheidung als 1-Wochen-Festpreis-Sprint zwischen 8 und 14k EUR.

Warum die Betriebsmodell-Frage teuer wird, wenn ihr sie aufschiebt

Die falsche Betriebsmodell-Entscheidung kostet DACH-Mittelständler oft 80-120k EUR im ersten Jahr, bevor jemand die Rechnung sauber aufstellt. Nicht weil Cloud-Preise überraschend wären, sondern weil Control-Plane-Arbeit, Update-Disziplin und On-Call stillschweigend im Engineering-Budget landen.

Ein typisches Muster: Das Team startet mit kubeadm auf drei VMs, „nur für den Pilot“. Sechs Monate später laufen drei Business-Apps darauf, niemand hat etcd-Restore geübt, und das Minor-Upgrade hängt seit zwei Releases. Dann kommt der Audit. Dann kommt der Notfall-Umbau auf AKS. Die Migration allein frisst 4-12 Wochen.

Wir hören die Frage in fast jedem Discovery-Sprint: „Brauchen wir wirklich AKS, oder setzen wir Kubernetes selbst auf VMs oder Bare Metal?“ Die Antwort hängt selten an Features. Kubernetes kann beides. Die Antwort hängt an Operations-Kapazität, Compliance-Rahmen und daran, ob ihr ein Platform-Team habt, das etcd und API-Server wirklich tragen will.

Genau deshalb ist dieser Vergleich kein Feature-Shootout. Es ist eine Make-or-Buy-Entscheidung für Schicht 1 der Cluster-Operations.

Wo der Unterschied im Alltag spürbar wird

Strukturell gibt es drei Operations-Schichten in einem Kubernetes-Cluster. Nur Schicht 1 trennt Managed und Self-Hosted wirklich.

Schicht 1: Control-Plane. API-Server, etcd, Controller-Manager, Scheduler. Bei Managed Kubernetes übernimmt der Cloud-Provider Hochverfügbarkeit, Zertifikatsrotation und die meisten Control-Plane-Patches. Bei Self-Hosting baut ihr eine 3-Master-Topologie, etcd-Backups, Recovery-Tests und Update-Reihenfolge selbst. Engineering-Aufwand dafür: oft 0,5 FTE laufend, sobald Production und Audit-Trail ernst gemeint sind.

Schicht 2: Worker-Nodes. OS-Patches, Container-Runtime, Node-Pool-Lifecycle. Managed-Anbieter automatisieren Teile davon (Node-Image-Upgrades, Autoscaler). Self-Hosted bleibt komplett bei euch, inklusive Kernel-CVEs und Containerd-Upgrades.

Schicht 3: Add-ons und Workloads. Ingress, Cert-Manager, Monitoring, GitOps, Anwendungs-Deployments. Diese Schicht bleibt in beiden Modellen eure Verantwortung. Wer glaubt, Managed Kubernetes nehme ihm Observability und Security-Baseline ab, unterschätzt den Shared-Responsibility-Anteil.

Ein praktischer Indikator: Wenn euer Board „Kubernetes betreiben“ mit „Container deployen“ verwechselt, fehlt die Trennung der Schichten. Deployen ist Schicht 3. Betreiben ist Schicht 1 und 2. Mehr zur Einordnung im Kubernetes-Beratung-Pillar.

Was Managed Kubernetes in Deutschland konkret kostet, hängt stark vom Anbieter ab: Control-Plane-Gebühr, Node-Preise und Load Balancer unterscheiden sich deutlich. Einen Referenz-Cluster mit drei Nodes rechnen wir auf unserem Vergleichsportal im Managed-Kubernetes-Kostenvergleich für zehn Anbieter mit Listenpreisen und offenem Rechenweg durch.

Managed Kubernetes im Detail

AKS, EKS und GKE sind 2026 die drei relevanten Managed-Optionen für den Mittelstand. Die Control-Plane-Gebühr ist sichtbar klein. Die eigentliche Ersparnis sitzt in den eingesparten SRE-Stunden.

Bei Azure AKS stehen drei Management-Tiers zur Wahl (Stand August 2026, Microsoft Learn): Free ohne finanziell hinterlegte SLA, Standard mit SLA (rund 0,10 USD pro Cluster und Stunde, also grob 65-75 EUR/Monat), Premium mit SLA plus Long Term Support über 24 Monate. Production ohne Standard-Tier ist Geld sparen an der falschen Stelle.

Stärken.

• Production-Cluster steht in Minuten, nicht in Wochen.
• Control-Plane-Updates kommen vom Provider, ihr steuert Wartungsfenster und Version.
• Identity, Storage und Monitoring hängen nativ am Cloud-Stack.
• Horizontal Pod Autoscaler, KEDA und Cluster-Autoscaler brauchen keine eigene Control-Plane-Engineering.

Schwächen.

• Vendor-Lock-in ist moderat: Workloads sind portabel, Storage-Klassen und Identity-Integrationen weniger.
• Cost-Sichtbarkeit ist Default oft unvollständig. Ohne Labels, Namespaces und Budgets seht ihr keine Workload-Kostenstelle.
• Regionale Abhängigkeiten und Cloud-Outages bleiben. Managed heißt nicht „nie Ausfall“.
• Manche Edge- oder Air-Gapped-Szenarien passen schlicht nicht in das Modell.

Ein AKS-Standard-Cluster mit automatischen Node-OS-Upgrades legt ihr so an:

# AKS Standard-Tier, Kubernetes 1.35.x, automatische Node-OS-Upgrades
# Stand August 2026 - Version gegen az aks get-versions prüfen
az aks create 
  --resource-group rg-platform-prod 
  --name aks-platform-prod 
  --tier standard 
  --kubernetes-version 1.35.2 
  --node-count 3 
  --node-vm-size Standard_D4s_v5 
  --enable-cluster-autoscaler 
  --min-count 3 
  --max-count 12 
  --auto-upgrade-channel patch 
  --node-os-upgrade-channel NodeImage 
  --network-plugin azure 
  --generate-ssh-keys

Das ist der Einstieg, nicht der Betrieb. Danach kommen Node-Pools, Network Policies, Backup und Observability. Den Hyperscaler-Vergleich führen wir im Artikel zu AKS, EKS und GKE aus.

Self-Hosted Kubernetes im Detail

Self-Hosted heißt Bare Metal, On-Prem-VMs oder kubeadm/Cluster-API auf Cloud-VMs, bei denen ihr die Control-Plane selbst betreibt. Die Infrastrukturrechnung sieht oft günstiger aus als AKS. Die Menschenrechnung meist nicht.

Stärken.

• Volle Datenresidenz und Netzwerk-Isolation, wenn Cloud-Verarbeitung ausgeschlossen ist.
• Keine Abhängigkeit von Provider-Control-Planes und deren Release-Kalender.
• Hardware und Lizenzkosten sind direkt zurechenbar.
• Sonderhardware (lokale GPUs, spezielle NICs, FIPS-Only-Stacks) lässt sich feiner verdrahten.

Schwächen.

• Setup dauert 4-8 Wochen Engineering, wenn HA-etcd, Networking und Backup ernsthaft gebaut werden.
• Laufender Operations-Overhead liegt bei 1-2 FTE für Production-Cluster mit Audit-Anforderungen.
• Jede Minor-Version ist euer Projekt: Staging, Canary, Rollback-Plan, Zertifikats- und etcd-Checks.
• Personalrisiko: Fällt der eine etcd-Kenner aus, steht die Plattform-Roadmap.

Ein minimales Self-Hosted-Upgrade-Signal sieht so aus (nur zur Illustration, kein Produktionsrezept):

# Version prüfen, bevor ihr kubeadm upgrade plant
kubectl get nodes -o wide
kubeadm upgrade plan
# Danach: control-plane nodes sequenziell, dann workers
# etcd-Snapshot VOR dem ersten Master-Upgrade ist Pflicht
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%F).db

Wir raten klar davon ab, Self-Hosting als „Lernprojekt mit Production-Workloads“ zu starten. Wer die Plattform lernen will, nimmt Managed und baut Schicht 3. Wer Self-Hosting wählt, braucht ein Platform-Team mit On-Call und dokumentierter Recovery.

Die TCO-Rechnung konkret

Beispiel: Mittelständler mit 600 Mitarbeitern, 12 Worker-Nodes Äquivalent, Production plus Staging, DACH-Kostenannahmen 2026.

Managed AKS (Standard-Tier):

Jahresrechnung Managed: rund 86.400 EUR.

Self-Hosted on-prem:

Jahresrechnung Self-Hosted: rund 184.800 EUR.

Differenz: etwa 98k EUR/Jahr zugunsten Managed Kubernetes. Die Control-Plane-Gebühr von ~70 EUR/Monat verschwindet neben 1,2 FTE Operations. Wer Self-Hosting mit „Cloud ist teuer“ begründet und Personal nicht einpreist, rechnet falsch.

Zwei Caveats, die wir in Reviews immer nennen: GPU- oder High-IO-Workloads können die Cloud-Seite verdoppeln. Und wenn ihr ohnehin ein ausgelastetes Platform-Team von fünf Leuten habt, sinkt der OpEx-Nachteil von Self-Hosting. Die Zahlen sind Richtwerte, keine Angebotskalkulation. Was oft fehlt: eine dritte Spalte für Opportunitätskosten, also Features, die das Team nicht baut, weil es etcd pflegt. Die taucht in keiner Cloud-Rechnung auf, entscheidet aber über Time-to-Market. Bei zwei Senior-Engineers, die je ein Viertel ihrer Zeit in Control-Plane-Arbeit stecken, sind das schnell 40-60k EUR Produktfortschritt, die auf dem Cluster „verbrannt“ werden. Ausführlicher in der Kubernetes-Cluster-Kostenrechnung 2026.

Upgrade-Disziplin 2026: warum Self-Hosting hier wehtut

Kubernetes veröffentlicht etwa alle 15 Wochen eine Minor-Version. Supportfenster sind eng. Am 27. August 2026 ist Kubernetes 1.34 in den Maintenance-Modus gegangen, End of Life folgt am 27. Oktober 2026. Aktive Linien liegen bei 1.35 und 1.36 (Stand Ende August 2026).

Bei Managed Kubernetes plant ihr Wartungsfenster und Version-Pins. Der Provider testet Control-Plane-Upgrades vor euch. Bei Self-Hosting seid ihr Release-Train, Compatibility-Matrix und Incident-Owner in einem. Teams ohne feste Upgrade-Cadence rutschen in Unsupported-Versionen und merken es erst beim Security-Audit.

Unsere klare Empfehlung: Wenn ihr keine dokumentierte Minor-Upgrade-Pipeline (Staging, Soak, Rollback) habt, wählt Managed. Self-Hosting ohne diese Disziplin ist kein Sparmodell, sondern ein aufgeschobenes Incident. Das gilt auch, wenn „wir machen das nebenbei“ im Backlog steht. Nebenbei ist kein Betriebsmodell.

Ein zweites Frische-Argument: AKS Premium mit Long Term Support verlängert die Kubernetes-Version auf 24 Monate. Das ist für regulierte Umgebungen mit langen Freigabezyklen oft der pragmatische Mittelweg zwischen „immer aktuell“ und „nie upgraden“. Self-Hosting ohne Vendor-LTS bedeutet, dass ihr diese Verlängerung selbst stemmt oder auf alten Patches stehenbleibt.

Wann Self-Hosting trotzdem sinnvoll ist

Vier Konstellationen, in denen wir Self-Hosting aktiv mitdenken.

KRITIS-Tier-1 oder Defence. Cloud-Verarbeitung ist ausgeschlossen oder politisch nicht freigegeben. Dann ist Self-Hosting Pflicht, und das Budget muss die FTEs tragen. Hier zählen Isolationszonen, Offline-Updates und nachweisbare Recovery höher als die Cloud-Rechnung.

Sehr große Cluster (ab ca. 100 Nodes). Ab dieser Größe können Provider-Margins und Node-Kosten das Bild drehen. Unter 50 Nodes sehen wir das in der Praxis selten. Dazwischen (50-100) rechnen wir Fall für Fall, oft mit Hybrid: Managed Control-Plane wo erlaubt, On-Prem für sensible Workloads.

Strategische Souveränität. Manche Banking- und Public-Sector-Setups treffen eine politische Entscheidung gegen Hyperscaler-Control-Planes, auch wenn die TCO-Rechnung Managed favorisiert. Das ist legitim. Dann bitte die Mehrkosten bewusst freigeben, nicht schönrechnen.

Bestehende Platform-Mannschaft. Ein produktives 4-6-Personen-Platform-Team mit On-Call und GitOps kann Self-Hosting tragen. Ein 2-Personen-DevOps-Team mit App-Delivery-Last eher nicht. Mehr zum On-Prem-Pfad im Kubernetes on-premise DSGVO-Pattern.

Entscheidungscheckliste: Managed oder Self-Hosted?

Geht die Liste ehrlich durch. Drei oder mehr „Nein“ sprechen klar für Managed Kubernetes.

1. Habt ihr mindestens 1 FTE Platform/SRE nur für Cluster-Betrieb (nicht App-Delivery)?
2. Ist Cloud-Verarbeitung regulatorisch oder politisch ausgeschlossen?
3. Habt ihr in den letzten 12 Monaten ein Control-Plane-Upgrade inkl. Recovery-Test durchgeführt?
4. Könnt ihr etcd-Backup und Restore in unter 60 Minuten nachweisen?
5. Liegt euer Ziel-Cluster klar über 50 Worker-Nodes oder hat Sonderhardware (GPU-Farm on-prem)?
6. Ist der CFO bereit, 1-2 FTE Operations dauerhaft zu budgetieren?

Wenn Punkt 2 „Ja“ ist, endet die Diskussion: Self-Hosting. Sonst gewinnt Managed in den meisten Mittelstands-Setups. Wenn ihr unsicher bei Punkt 3 und 4 seid, ist das kein Schwachstellen-Geständnis, sondern der Normalzustand vor dem ersten echten Platform-Setup.

Pexon-Sprint und Investment

1-Wochen-Decision-Sprint: 8-14k EUR Festpreis. TCO-Rechnung für euer Setup, Compliance-Bewertung, klare Empfehlung Managed vs Self-Hosted, Sprint-Roadmap für die Umsetzung.

Implementation danach: 32-58k EUR je nach Modell (AKS-Landing, GitOps-Baseline, Observability) bzw. höher bei On-Prem-HA.

Laufender Managed Service (optional): bei typischem 12-Node-AKS 4-7k EUR/Monat für Updates, Incident-Response, Audit-Trail und monatliche Compliance-Reports. Das ersetzt intern oft 0,5-1 Operations-FTE.

Was ihr nach dem Sprint in der Hand habt: eine Entscheidungsvorlage für IT-Leitung und ggf. Betriebsrat/Compliance, eine Kostenbandbreite für 12 und 36 Monate, und eine konkrete Build-Reihenfolge. Kein 80-Seiten-Konzept ohne nächste Action. Die Empfehlung ist binär formuliert: Managed, Self-Hosted oder Hybrid mit klarer Workload-Trennung.

Häufig gestellte Fragen

Was kostet Managed Kubernetes im Vergleich zu Self-Hosted bei 3-5 Nodes?

Managed ist klar günstiger. Self-Hosting lohnt sich bei dieser Größe wirtschaftlich nicht, weil die Control-Plane-Arbeit kaum skaliert und trotzdem FTE bindet. Nehmt Free- oder Standard-Tier je nach SLA-Bedarf und investiert die Kapazität in Workloads.

Was kostet Pexon-Managed-Service zusätzlich zum Cloud-Anbieter?

Bei einem typischen 12-Node-AKS-Setup 4-7k EUR/Monat für Operations, Updates, Audit-Trail-Pflege und monatliche Compliance-Reports. Das ersetzt 0,5-1 internen Operations-FTE und setzt auf der Cloud-Rechnung auf, ersetzt sie nicht.

Managed Kubernetes vs Self-Hosted bei Multi-Cloud: was ist sinnvoller?

Technisch geht beides. Operativ wird Multi-Cloud teuer, weil ihr Policies, Identity und Observability verdoppelt. Meist reicht ein Hyperscaler plus klare Exit-Strategie. Distributionen und Multi-Cluster sind ein eigenes Thema (k3s, Vanilla-k8s, Rancher).

Wie verändert OpenShift die Self-Hosting-Rechnung?

OpenShift macht Self-Hosting pragmatischer (Operator-Ökosystem, Support-Vertrag), aber nicht billig. Lizenz plus Betrieb liegen oft über reinem kubeadm. Für viele Mittelständler ist OpenShift der Kompromiss, wenn On-Prem Pflicht ist und gleichzeitig Support-Vertrag gewünscht wird.

Können wir später von Self-Hosted auf Managed wechseln?

Ja, aber plant 4-12 Wochen Engineering für Networking, Identity, Storage-Klassen und Cutover. Wir empfehlen die Entscheidung im Discovery-Sprint sauber zu treffen, statt „erstmal selbst“ und später zu migrieren.

Nächster Schritt

Wenn euer Engineering-Team zwischen Managed und Self-Hosted schwankt: 30-Minuten-Call. Wir skizzieren den Decision-Sprint und die TCO-Annahmen für euer Setup.

Verwandte Themen