Das Wichtigste in Kürze
Die Frage „EKS oder eigene Infrastruktur" wird meist als Kostenfrage gestellt und ist in Wahrheit eine Personalfrage. Die Control Plane kostet bei Amazon EKS rund 73 USD je Cluster und Monat — ein Betrag, der in jeder Rechnung untergeht. Entschieden wird die Sache an fünf anderen Stellen: wer die Control Plane patcht, wer nachts geweckt wird, wie schnell ein Kubernetes-Release nachgezogen wird, wer die Compliance-Nachweise erbringt und wie teuer der Rückweg ist.
Für die meisten Häuser im DACH-Mittelstand fällt die Entscheidung zugunsten von EKS, weil der Eigenbetrieb dauerhaft zwei bis drei Vollzeitstellen mit knappem Kubernetes-Wissen bindet. Der Eigenbetrieb bleibt richtig, wenn Daten das Haus physisch nicht verlassen dürfen, wenn vorhandene Hardware noch abgeschrieben wird oder wenn Kubernetes-Betrieb selbst zum Produkt gehört.
Was ist Amazon EKS?
Amazon Elastic Kubernetes Service (EKS) ist ein verwalteter Kubernetes-Dienst, bei dem AWS die Control Plane betreibt, patcht und über mehrere Availability Zones hochverfügbar hält, während der Kunde seine Worker Nodes und Workloads behält.
Der Unterschied zum Eigenbetrieb liegt genau an dieser Schnittstelle. Die Control Plane — API-Server, Scheduler, Controller Manager, etcd — ist der Teil, der im Eigenbetrieb die meiste Arbeit macht und am wenigsten Wert stiftet. Sie ist bei jedem Cluster gleich, sie muss ständig aktuell gehalten werden, und ihr Ausfall legt alles lahm. Was ein Haus von seinen Wettbewerbern unterscheidet, läuft auf den Worker Nodes, nicht in etcd.
„Eigene Infrastruktur" meint in dieser Gegenüberstellung beides: Kubernetes auf selbst verwalteten EC2-Instanzen und Kubernetes im eigenen Rechenzentrum. Der Unterschied zwischen diesen beiden ist für die hier behandelte Frage klein — in beiden Fällen gehört die Control Plane dem Haus.
AWS EKS im Vergleich zur eigenen Infrastruktur
| Kriterium | Amazon EKS | Eigene Infrastruktur |
|---|---|---|
| Control Plane | AWS betreibt und patcht sie; Hochverfügbarkeit über mehrere AZs ist zugesichert. | Das eigene Team baut, betreibt und patcht sie, inklusive etcd-Backup und Wiederanlauf. |
| Direkte Kosten | Rund 73 USD je Cluster und Monat zuzüglich Worker Nodes, Storage und Netzwerk. | Keine Cluster-Gebühr, dafür Hardware oder EC2, Ersatzteile, Rechenzentrum und Personal. |
| Personalbindung | Kubernetes-Wissen für Workloads und Node-Gruppen genügt. | Zusätzlich Control-Plane-Betrieb, Upgrade-Pfade und 24/7-Rufbereitschaft. |
| Versionspflege | AWS stellt neue Kubernetes-Versionen bereit; das Upgrade bleibt eine bewusste Entscheidung des Kunden. | Jedes Minor-Release muss selbst geprüft, getestet und ausgerollt werden. |
| Compliance-Nachweis | Der Dienst ist Teil der AWS-Zertifizierungen; das Haus weist seinen Teil des Modells nach. | Der Nachweis muss vollständig selbst erbracht und gepflegt werden. |
| Datenhoheit | Control Plane liegt bei AWS, wählbar in einer EU-Region. | Vollständig im eigenen Zugriff, auch physisch. |
| Exit-Pfad | Workloads sind portabel, da Kubernetes die Schnittstelle bleibt; AWS-spezifische Add-ons sind es nicht. | Kein Anbieterwechsel nötig, dafür Bindung an die eigene Hardware-Abschreibung. |
Wann welcher Weg der richtige ist: EKS, sobald Kubernetes-Betrieb Mittel zum Zweck ist und das Ops-Team kleiner als zehn Personen bleibt. Eigene Infrastruktur, wenn eine Aufsicht oder ein Vertrag die physische Datenhaltung vorschreibt, wenn vorhandene Hardware noch läuft, oder wenn der Betrieb selbst zur Leistung gehört, die das Haus verkauft.
Die Kostenrechnung, die meistens falsch aufgestellt wird
Der Vergleich beginnt fast immer bei den 73 USD und endet dort auch. Das ist die unwichtigste Zahl in der ganzen Rechnung. Wer ehrlich rechnet, stellt drei Posten daneben.
Erstens die Personalbindung: Ein selbst betriebener Kubernetes-Cluster mit Produktionsanspruch braucht Menschen, die Control-Plane-Upgrades beherrschen, etcd wiederherstellen können und nachts erreichbar sind. Das sind in der Praxis zwei bis drei Stellen, und es sind Stellen, die am Markt schwer zu besetzen sind.
Zweitens die Opportunität: Dieselben Leute könnten an der Anwendung arbeiten. Jede Stunde Control-Plane-Pflege ist eine Stunde, die der Kunde nicht sieht.
Drittens das Ausfallrisiko: Eine Control Plane, die nur in einer Availability Zone steht, ist ein Single Point of Failure für alles, was darauf läuft. Die Kosten dieses Risikos tauchen in keiner Rechnung auf, bis sie anfallen.
Erst wenn diese drei Posten dastehen, ist der Vergleich belastbar — und dann sieht er für die meisten Häuser anders aus als die reine Infrastrukturrechnung vermuten lässt.
Wann der Eigenbetrieb die richtige Antwort bleibt
Es gibt belastbare Gründe für die eigene Infrastruktur, und sie sind selten technisch.
Der häufigste ist regulatorisch: Wenn eine Aufsicht, ein Kunde oder ein Vertrag vorschreibt, dass bestimmte Daten das Haus physisch nicht verlassen, erübrigt sich die Abwägung. Der zweite ist kaufmännisch: Hardware, die noch nicht abgeschrieben ist, lässt sich nicht durch ein Betriebsmodell wegrechnen. Der dritte ist geschäftlich: Wer Kubernetes-Betrieb als Leistung verkauft, kann ihn nicht auslagern, ohne das Produkt aufzugeben.
Was hingegen kein tragfähiger Grund ist: die Sorge vor Anbieterbindung. Kubernetes ist die Schnittstelle, und sie bleibt dieselbe. Was bindet, sind die Add-ons rundherum — und die wählt man bewusst oder eben nicht.
Die Storm Reply Perspektive
Wir sehen die Frage regelmäßig in Modernisierungsprojekten, und sie kommt fast nie allein. Sie steht neben der Frage, ob es überhaupt Kubernetes sein muss. Für einen erheblichen Teil der Workloads, die mit „wir brauchen Kubernetes" zu uns kommen, ist Amazon ECS mit Fargate die ruhigere Antwort: weniger bewegliche Teile, kein Cluster-Upgrade-Pfad, derselbe Container.
Unsere Reihenfolge in der Beratung ist deshalb: erst klären, ob die Workloads Kubernetes wirklich brauchen, dann klären, wer die Control Plane betreibt. Wer diese beiden Fragen vertauscht, diskutiert über Control-Plane-Kosten für einen Cluster, den es nicht geben müsste.
Welcher Compute-Dienst zu welchem Team passt, haben wir in der Entscheidungsmatrix für EKS, ECS und Lambda entlang von fünf Kriterien aufgeschrieben.
Regulatorische Aspekte
Für Häuser unter NIS2 oder DORA verschiebt die Entscheidung keine Pflichten, sie verschiebt nur, wer welchen Nachweis führt. Im Modell der geteilten Verantwortung deckt AWS die Control Plane und das Rechenzentrum ab und belegt das über seine Zertifizierungen; alles darüber — Konfiguration, Zugriffsrechte, Netzwerktrennung, Protokollierung — bleibt beim Kunden und muss dort nachweisbar sein.
Im Eigenbetrieb fällt beides zusammen. Das ist kein Nachteil an sich, aber es ist Arbeit, die eingeplant und besetzt werden muss. Wer den Eigenbetrieb mit Souveränität begründet, sollte zusätzlich prüfen, ob eine EU-Region oder die AWS European Sovereign Cloud die Anforderung bereits erfüllt.
Häufig gestellte Fragen
- Was kostet die EKS Control Plane?
- Rund 0,10 USD pro Cluster und Stunde, also etwa 73 USD im Monat. Hinzu kommen Worker Nodes, Storage und Datenverkehr — diese Posten fallen im Eigenbetrieb ebenso an.
- Spare ich mit eigener Infrastruktur Geld?
- An der Cluster-Gebühr ja, an den Gesamtkosten meist nicht. Der Eigenbetrieb bindet zwei bis drei Stellen für Control-Plane-Pflege und Rufbereitschaft; dieser Posten ist größer als die Gebühr, die er einspart.
- Bindet mich EKS an AWS?
- Die Workloads nicht — Kubernetes bleibt die Schnittstelle, und Manifeste laufen auch anderswo. Bindend sind AWS-spezifische Add-ons wie IAM Roles for Service Accounts oder der AWS Load Balancer Controller. Wie stark die Bindung wird, entscheidet man bei jedem Add-on neu.
- Kann ich die Control Plane im Eigenbetrieb hochverfügbar machen?
- Ja, über mehrere etcd-Knoten in getrennten Brandabschnitten oder Verfügbarkeitszonen. Es ist machbar und gut dokumentiert — die Frage ist, ob das Haus diesen Aufbau dauerhaft pflegen und im Ernstfall wiederherstellen kann.
- Was ist mit EKS Anywhere?
- EKS Anywhere bringt die EKS-Distribution ins eigene Rechenzentrum und ist der Mittelweg, wenn Daten vor Ort bleiben müssen, das Haus aber keine eigene Kubernetes-Distribution pflegen will. Der Betrieb bleibt beim Kunden.