EKS vs. ECS: Unerwartete Unterschiede und welche Lösung wann passt

Die Entscheidung, ob EKS oder ECS besser zu einem Projekt passt, fällt oft schwer.

Betrachtet man einzelne Eigenschaften, lässt sich schnell ein klarer Sieger ausmachen. Die eigentliche Schwierigkeit liegt darin, dass ein sinnvoller Vergleich jedes Produkt als Bündel von Eigenschaften betrachten muss – und beide Produkte sind eher ein zweischneidiges Schwert mit gleichzeitigen Vor- und Nachteilen.

Daraus ergeben sich zwei naheliegende Konsequenzen:

1. Keine der beiden Optionen ist von vornherein die beste. Welche Lösung am besten passt, hängt von den Anforderungen und Rahmenbedingungen auf Projekt- und Organisationsebene ab.

2. Eine objektive Bewertung erfordert kritisches Denken und differenzierte Überlegungen.

In diesem Artikel finden Sie selten dokumentierte Unterschiede, Implikationen und Erkenntnisse zu typischen Anforderungen auf Projekt- und Organisationsebene sowie weitere Faktoren, die in die Entscheidung einfließen sollten.

Verstehen Sie diesen Beitrag am besten als geführte Argumentation in Form bedingter Empfehlungen, aus denen sich – kombiniert mit einem konkreten Projekt – schnell praktische Hinweise für eine fundierte Entscheidung ableiten lassen.

BLUF (Bottom Line up Front)

Inhaltsverzeichnis

Zielgruppe

Einleitung

Abschnitt 1: Unterschiede zwischen EKS und ECS von geringerer Bedeutung

1. ECS hat deutlich bessere Fargate-Preise (EKS Fargate ist teuer).

2. Die EC2-Container-Dichte von EKS ist deutlich besser als die von ECS.

3. ECS bietet fortgeschrittenere Service-Discovery-Optionen.

4. EKS hat gegenüber ECS einen leichten Vorteil bei Multi-Cloud und lokaler Entwicklung, da es auf Kubernetes basiert.

5. ECS berechnet keine Kosten für die Control Plane, EKS schon.

Abschnitt 2: Erkenntnisse zu potenziell entscheidenden Unterschieden

1. EKS skaliert Container standardmäßig schneller und unterstützt mit dem Add-on keda.sh fortgeschrittenes Autoscaling.

2. Die IaC (Infrastructure as Code) von EKS ist der von ECS grundlegend überlegen, weil sie standardisiert, leicht lesbar, entkoppelt, deklarativ ist und Stateful Metadata unterstützt.

3. ECS hat keine eingebaute Unterstützung für Volumes.

4. Der Schwierigkeitsgrad von EKS ist tendenziell variabel und paradox:

"EKS ist tendenziell schwer, weil es zu einfach ist."

5. ECS-Updates sind extrem selten – ein großer Vorteil für die Stabilität und gegen Cluster-Operations-Aufwand.

6. EKS hat unvermeidbaren Wartungsaufwand und um eine Größenordnung mehr bewegliche Teile als ECS, das nie gewartet werden muss.

Abschnitt 3: Faustregeln für die Wahl von ECS, EKS oder keinem von beidem

1. ECS könnte in folgenden Szenarien die bessere Wahl sein:

2. EKS objektiv als bessere Wahl zu rechtfertigen, erfordert eine etwas tiefere Auseinandersetzung mit den situativen Faktoren: (Dieser Abschnitt enthält auch gute Hinweise zu EKS Auto Mode.)

3. Stateful Applications sind ein Szenario, das häufig genug auftritt, um eine Diskussion auf Basis von Faustregeln zu rechtfertigen:

Fazit

Dieser Artikel richtet sich an alle, die bei der Wahl zwischen EKS und ECS eine fundierte Entscheidung treffen möchten.

Wenn Sie zur Zielgruppe gehören, lohnt sich die Lektüre dieses relativ langen Beitrags, denn danach sind Sie gut aufgestellt, um das Hauptziel einer fundierten Entscheidung sowie folgende drei nützliche Nebenziele zu erreichen:

1. Unerwartete Unterschiede, Vor- und Nachteile entdecken.

(Ich konzentriere mich auf solche, die schwer zu googeln und oft undokumentiert sind.)

2. Entscheidungs-Metadaten kennenlernen.

(Etwa relevante Implikationen von Entscheidungen sowie Erkenntnisse zu häufig auftretenden kritischen Faktoren und Rahmenbedingungen, die beim Abwägen stark gewichtet werden sollten. Diese eignen sich auch hervorragend als Grundlage für Faustregel-basierte Empfehlungen.)

3. Die Argumentation hinter den Aussagen verstehen.

Wenn Sie die Begründungen und Herleitungen, mit denen die Gültigkeit von Aussagen, Implikationen oder Erkenntnissen belegt wird, verstehen, nachvollziehen und in eigenen Worten wiedergeben können, lässt sich dieses Wissen nutzen, um auf persönlicher, Team- oder Organisationsebene das Vertrauen zu stärken, dass eine Entscheidung sinnvoll und auf gültigen Aussagen basiert.

Der Rest des Artikels ist in Abschnitte gegliedert, die dem obigen Inhaltsverzeichnis entsprechen. Jeder Abschnitt enthält eine Liste von Aussagen, ergänzt durch klärende Erläuterungen, faktische Belege und anekdotische Hinweise, um deren Gültigkeit zu untermauern.

Der erste Abschnitt enthält eine nummerierte Liste EKS- bzw. ECS-spezifischer Unterschiede, die nützlich zu wissen, aber meist nicht von großer Tragweite sind.

Der zweite Abschnitt behandelt Unterschiede, denen man Aufmerksamkeit schenken sollte, weil sie bei Entscheidungen ausschlaggebend sein können.

Der dritte Abschnitt enthält bedingte Faustregeln, die sich an typischen Anliegen auf Projekt-, Team- oder Organisationsebene orientieren. Kombiniert mit Ihrer konkreten Situation lassen sich daraus praktische Empfehlungen ableiten.

Sowohl ECS als auch EKS lassen sich auf Fargate oder EC2 betreiben. In der Praxis besteht jedoch eine starke Tendenz, dass ECS auf Fargate und EKS auf EC2-Instanzen läuft.

Die ersten beiden Unterschiede in diesem Abschnitt zeigen jeweils einen Vorteil, der erklärt, warum diese Tendenz nachvollziehbar ist. Die folgenden drei Unterschiede betreffen kleinere Vorteile mitsamt Erläuterung, warum sie relativ vernachlässigbar sind.

1. ECS hat deutlich bessere Fargate-Preise (EKS Fargate ist teuer).

Das ist nur am Rande relevant, denn unabhängig vom Preis greifen EKS-Nutzer aus funktionalen Gründen häufig zu EC2. (EC2 unterstützt Container-Image-Caching und DaemonSets, Fargate nicht.)

• Theoretisch sind laut AWS Fargate-Doku Fargate-Instanzen etwas teurer als EC2 – im Gegenzug für Komfort- und Sicherheitsvorteile, die zu niedrigeren Gesamtbetriebskosten führen sollen.

In der Realität gilt das nur für ECS, denn ECS unterstützt AMD- (alias Intel/x86_64), ARM-, On-Demand- und Spot-basierte Fargate-Instanzen.

• EKS unterstützt nur On-Demand-AMD-basierte Fargate-Instanzen.

EKS unterstützt weder "Fargate Spot Instances" noch "ARM-basiertes Fargate".

• Das bedeutet: Bei einem Preisvergleich für EKS muss man die teuerste mit der günstigsten Option vergleichen UND zusätzlich zu den höheren Kosten mit Fargates Aufrundungslogik bei Instanzgrößen umgehen.
• Konkretes Beispiel: Angenommen, ein Container wurde per Right-Sizing-Analyse als ideal mit 1,8 CPU und 1,2 GB RAM bestimmt.

Wenn Sie 2 CPU benötigen, rundet Fargate automatisch auf 4 GB RAM auf, und es gilt der AMD-On-Demand-Fargate-Preis. In us-east-1 kostet Fargate 2,37 $/Tag. Derselbe Container würde auf einen ARM-basierten EKS-Spot-Node vom Typ t4g.small passen, der 0,1512 $/Tag kostet.

• EKS auf Fargate kann also 15-mal teurer sein als EKS auf EC2! (Übrigens basiert dieser Vergleich auf der günstigsten Region; in teureren Regionen fällt der Unterschied sogar noch größer aus!)

2. Die EC2-Container-Dichte von EKS ist deutlich besser als die von ECS.

Hinweis: Wenn die meisten Ihrer Container mindestens 1 CPU und 1 GB RAM nutzen, ist der Preisunterschied minimal, weil ein t3/t4g.small zwei ECS-Tasks dieser Größe hosten kann.

Wenn Sie viele Microservices mit niedriger CPU- und RAM-Auslastung deployen, lassen sich diese Container dank der höheren Container-Dichte auf EKS deutlich günstiger betreiben. (Hinweis: Für Organisationen mit großflächigen Microservice-Deployments kann das ein erheblicher Kostenfaktor sein, für die meisten dürfte der Unterschied jedoch nicht allzu gewichtig ausfallen – daher zähle ich es zu den eher kleineren Unterschieden.)

• Viele ECS-Nutzer setzen auf Fargate-Instanzen, die ohnehin nur einen Task/Pod pro Instanz erlauben. Weniger bekannt ist, dass ECS auf EC2 deutlich schlechter abschneidet als EKS auf EC2.
• Ein t4g.small kann 11 EKS-Pods oder 2 ECS-Tasks ausführen.

Ein t4g.large kann 35 EKS-Pods oder 2 ECS-Tasks ausführen.

• Berechnet habe ich das mit:

aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=t4g.*" \
--query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
--output table

• Die Ausgabe zeigt, dass t4g.small 3 ENIs unterstützt. ECS benötigt 1 für die Host-VM und vergibt dann 1 pro Task. Eine gute Kurzformel lautet: $MAX_ENI -1 = $MAX_TASKS_PER_EC2_INSTANCE. (3-1=2).
• Hinweis: ECS hat ein unglücklich benanntes Feature namens ENI Trunking (alias AWS VPC Trunking). Theoretisch soll es die Container-Dichte von ECS erhöhen, in der Praxis wird es aber nur von Instanztypen unterstützt, die aus FinOps-Sicht nie sinnvoll sind. Mein persönlicher Rat: einfach so tun, als gäbe es das nicht.
• Einige verwandte, interessante Anmerkungen:

Normalerweise sind AMD-Instanzen aufgrund niedrigerer Kosten und höherer Performance standardmäßig die beste Wahl. Das "a" in t3a steht für AMD; als allgemeine Faustregel gilt: t3a ist besser als t3. Die Container-Dichte von ECS ist jedoch ein seltener Fall, in dem t3 t3a schlägt: t3a.small hat seltsamerweise nur 2 ENIs und kann daher nur 1 ECS-Task tragen, während t3.small 3 ENIs hat und 2 ECS-Tasks unterstützt.

• Die zwei Hauptgründe, warum ECS-Nutzer Fargate-Instanzen bevorzugen, sind aus meiner Sicht:

1. ECS auf Fargate ist relativ schlüsselfertig einzurichten, ECS auf EC2 erfordert dagegen etwas mehr Aufwand.

2. Ohne deutlich höhere Container-Dichte bei EC2-Instanzen gibt es wenig Anreiz, von ECS auf Fargate zu ECS auf EC2 zu wechseln.

3. ECS bietet fortgeschrittenere Service-Discovery-Optionen.

Ich halte das für einen kleineren Vorteil von ECS, da er nur in seltenen Anwendungsfällen nützlich ist – und in diesen Fällen kann EKS durch optionale Tools, die die Basisfunktionalität erweitern, ähnliche Ergebnisse erzielen.

• Die Service Discovery von EKS basiert auf Inner-Cluster-DNS-Namen, die nur von Pods innerhalb des Clusters auflösbar sind und einem vorhersagbaren Muster folgen: $SERVICE.$NAMESPACE.svc.cluster.local
• ECS bietet zwei Optionen: eine API-basierte für Inner-ECS-Cluster-Kommunikation und eine DNS-basierte für Inner-VPC-Kommunikation. (Mehr dazu hier, falls Sie interessiert sind.)

4. EKS hat gegenüber ECS einen leichten Vorteil bei Multi-Cloud und lokaler Entwicklung, da es auf Kubernetes basiert.

Warum dieser Unterschied relativ vernachlässigbar ist:

• Multi-Cloud ist fast immer eine schlechte Idee; richtig umsetzen lässt es sich nur über cloud-agnostisches Design, was ebenfalls selten sinnvoll ist. Das Hauptproblem mit Multi-Cloud: In der Praxis findet man auf jeden theoretischen Vorteil zehn reale Probleme.
• Mit Minikube und Rancher Desktop lässt sich Kubernetes lokal betreiben, aber in der Praxis habe ich davon nur sehr erfahrene einzelne Engineers profitieren sehen, die das auf ihrem eigenen Laptop manuell umgesetzt haben.

Es gibt zahlreiche integrationsspezifische Feinheiten, die es ohne erhebliche Investitionen kaum möglich machen, eine konsistente lokale Entwicklungserfahrung mit nützlichen Integrationen teamweit umzusetzen. Der praktische Nutzen dieses Vorteils ist daher meist sehr begrenzt.

• Da ECS auf Docker basiert, können erfahrene Engineers Docker-basiertes lokales Entwickeln auf ihren Laptops betreiben. Lokale Docker-Entwicklung ist auf ECS teilweise anwendbar, ähnlich wie lokales Kubernetes auf EKS.

Ebenso wie nur sehr erfahrene Engineers die integrationsspezifischen Feinheiten beherrschen und Vorteile erzielen, die nur sie selbst als einzelne Entwickler erleben, hat auch der Docker-Bezug von ECS in der Praxis nur begrenzten Nutzen.

5. ECS berechnet keine Kosten für die Control Plane, EKS schon.

Ich halte das für einen relativ kleinen Vorteil, denn die EKS-Kosten sind sehr erschwinglich und gut zu rechtfertigen. Allerdings kann ich mir vorstellen, dass es für ein Startup, das so günstig wie möglich laufen muss, ins Gewicht fällt.

• Wenn Sie Ihren EKS-Cluster aktuell halten, kostet er 864 $/Jahr pro Cluster. In der Praxis hat man oft Dev-, Stage-, Prod- und einige temporäre Sandbox-Cluster, sodass 3.000 $/Jahr eine realistischere Schätzung sind.
• Drei Gründe, warum sich die Control-Plane-Kosten von EKS leicht rechtfertigen lassen:
• 1. Sie sind unabhängig von ECS sinnvoll.

Würden Sie eine cloud-agnostische Kubernetes-Distribution wie Talos oder Rancher betreiben, müssten Sie 3 VMs als HA/FT-Control-Plane-Nodes bezahlen. Die Control-Plane-Kosten von EKS sind günstiger als die DIY-Variante – und Sie erhalten zusätzlich die Vorteile eines Managed Service.

• 2. EKS bietet Funktionen, für die sich ein kleiner Aufpreis lohnt, vor allem bessere Debugging-Möglichkeiten und schnellere Feedback-Schleifen. (Mehr dazu im nächsten Abschnitt.)
• 3. EKS hat eigene Kostenvorteile: EKS auf EC2 ist günstiger als ECS auf Fargate und kann dank höherer Container-Dichte sogar günstiger sein als ECS auf EC2; Kubernetes Ingress erleichtert es, Load Balancer von mehreren Services gemeinsam nutzen zu lassen, sodass weniger AWS LBs nötig sind; karpenter.sh bietet automatisiertes, Right-Sizing-orientiertes Autoscaling und keda.sh fortgeschrittenes Container-Autoscaling.
• Diese Faktoren können dazu führen, dass EKS insgesamt günstiger im Hosting ist als ECS. Es gibt zu viele bedingte Variablen, um pauschal zu sagen, was günstiger ist – aber es ist nicht unüblich, dass EKS insgesamt günstiger oder kostentechnisch nahezu gleichauf liegt. Damit verlieren die Control-Plane-Kosten von EKS unter Umständen ihre Relevanz.

Dieser Abschnitt enthält drei Vorteile von EKS, ein EKS-Paradoxon, das eher ein Nachteil ist, aber auch Vorteil sein kann, sowie zwei Vorteile von ECS.

1. EKS skaliert Container standardmäßig schneller und unterstützt mit dem Add-on keda.sh fortgeschrittenes Autoscaling.

• EKS skaliert in der Regel schneller hoch als ECS. Beim Vergleich von EKS auf EC2 mit ECS auf Fargate ist das intuitiv, da Fargate kein Container-Image-Caching unterstützt.

Weniger intuitiv: EKS erzielt auch dann häufiger schnelle Startzeiten, wenn EKS und ECS beide auf EC2 laufen.

Das liegt an der höheren Container-Dichte von EKS, die häufiger vom Container-Image-Caching profitieren lässt. Dank Image-Caching ist es nicht ungewöhnlich, dass ein EKS-Pod innerhalb von Sekunden startet.

• ECS unterstützt Autoscaling gut und kann auch auf Basis benutzerdefinierter CloudWatch-Metriken skalieren, ist aber bei der Skalierung nicht so leistungsfähig wie EKS. EKS skaliert Container spürbar schneller und besser – aufgrund einiger Eigenheiten in den Implementierungsdetails von ECS, der Metric Resolution und der Unterstützung für Skalierung auf 0.
• Zu den problematischen Implementierungsdetails von ECS: Target-basiertes Autoscaling kann nur um eine fest definierte Anzahl von Capacity Units hochskalieren; als zweite Option gibt es Step-basiertes Autoscaling für eine gewisse Variabilität – allerdings entsteht zwischen Skalierungsentscheidungen eine Verzögerung von 1 Minute, weil Metrik-Datenpunkte nur einmal pro Minute erfasst werden.
• (Wie häufig Metriken erfasst werden, nennt man Metric Resolution.)
• EKS verwendet den Horizontal Pod Autoscaler (HPA) von Kubernetes mit einer Standard-Metric-Resolution von 15 Sekunden, kann also 4-mal schneller skalieren.
• Die Skalierung von ECS basiert auf CloudWatch Metrics, CloudWatch Alarms und einer Mischung aus suboptimalen und nicht editierbaren Defaults, was sie insgesamt schwächer macht als die HPA-Optionen von EKS.

ECS hat ein Best-Case-Szenario, in dem es EKS in einer Hinsicht schlagen kann – allerdings um den Preis schlechter Trade-offs. Insgesamt sind die Optionen von ECS jedoch weniger leistungsstark.

• So sieht der Best Case beim Metrik-basierten Autoscaling von ECS aus:

Eine hochauflösende benutzerdefinierte CloudWatch-Metrik kann eine Auflösung von bis zu 1 Sekunde haben.

Faktisch zählen aber nur 10-Sekunden-Schritte, weil der CloudWatch-Alarm die Skalierung auslöst und dieser eine minimale Evaluierungsperiode von 10 Sekunden hat.

Damit schlägt ECS technisch gesehen die nicht editierbare Standard-Evaluierungsperiode von 15 Sekunden im EKS-HPA, allerdings mit einem unangenehmen Trade-off: Bei einer Metric-Resolution von 10 Sekunden (eigentlich allem unter einer Minute) erhalten Sie nur 3 Stunden Metric-Retention.

• So sieht das Metrik-basierte Autoscaling von ECS in typischen Szenarien aus:
• Die CPU- und RAM-Metriken von ECS haben eine Metric-Resolution von 1 Minute (nicht editierbarer Default), wodurch die minimale Evaluierungsperiode des CloudWatch-Alarms in den häufigsten Szenarien zwangsläufig bei 1 Minute liegt.
• Selbst bei einer benutzerdefinierten Metrik wählt man oft eine Auflösung von einer Minute, um 15 Tage Retention und einen niedrigeren Preis zu haben.
• Auch erwähnenswert: Die Metric-Resolution von ECS hat einen impliziten Standardwert von 1 Minute; eine 10-Sekunden-Granularität muss explizit konfiguriert werden.

Der Metrics Server von Kubernetes hat einen besseren impliziten Standardwert von 15 Sekunden für die Metric Resolution.

• ECS kann nur dann auf 0 skalieren, wenn SQS-Queue-Metriken verwendet werden; ansonsten ist Skalierung auf 0 nicht möglich.
• EKS kann das kostenlose Add-on keda.sh installieren und so robustere Autoscaling-Funktionen bieten – z. B. benutzerdefinierte Metriken, Skalierung von HTTP-Traffic auf 0 und Cron-basierte Skalierung.

Die Cron-Option ist besonders nützlich im häufigen Szenario, dass zusätzlich zum Autoscaling eine erhöhte Grundkapazität benötigt wird, um Traffic-Spitzen während der Geschäftszeiten reibungslos abzufedern und in vorhersagbaren Phasen geringer Aktivität wieder herunterzufahren.

2. Die IaC (Infrastructure as Code) von EKS ist der von ECS grundlegend überlegen, weil sie standardisiert, leicht lesbar, entkoppelt, deklarativ ist und Stateful Metadata unterstützt.

Diese Eigenschaften ergeben Vorteile in mehreren Größenordnungen bei Debugbarkeit, Feedback-Schleifen und der gesamten DevOps-User-Experience.

• EKS folgt dem Kubernetes-Standard kubectl + YAML.

Das ist für Menschen schnell und einfach zu lesen, zu lernen und zu bearbeiten. (Dass YAML JSON intrinsisch unterstützt, ist ein Bonus, da YAML ein Superset von JSON ist.)

• ECS hat keinen wirklichen offiziellen Standard – weder bei IaC noch beim Tooling. Das macht das Lernen schwerer, da man sich erst zwischen den gängigen Tooling-Optionen AWS Copilot, AWS CDK, Terraform oder Pulumi entscheiden muss.
• Bei IaC- und Tooling-Optionen hat EKS mehr Auswahl, beim Standard gibt es jedoch nur einen. Alle EKS-Optionen basieren auf diesem einen Standard – ein deutlicher Vorteil sowohl beim Erlernen als auch bei der Wahrscheinlichkeit, dass die erworbenen Kenntnisse zwischen Arbeitgebern übertragbar sind, die nach gängigen Standards entwickeln.
• Die fehlende konzeptionelle Entkopplung und die IaC-Schwächen von ECS ziehen mehrere inhärente Nachteile nach sich.

Ein ECS Service entspricht konzeptionell einem Bündel aus EKS Deployment, Service, ConfigMap, Secret und AWS-IAM-Rolle, die eng miteinander gekoppelt sind. Das schafft mehrere Probleme:

• 1. Die enge Kopplung von Deployments in ECS schränkt In-Place-Änderungen an einem deployten Objekt ein.

Es ist nicht ungewöhnlich, dass Änderungen vollständige Redeployments oder lästige zweistufige Prozesse aus Löschen und Neuerstellen erfordern.

Bei iterativen Änderungen wird das schnell mühsam.

ECS macht das Hinzufügen, Entfernen oder Wechseln von Load-Balancer-Typen sehr umständlich. Sie können denselben Service-Namen nicht weiterverwenden, ohne ihn von Grund auf zu löschen und neu anzulegen – mit entsprechender Downtime. Ein Blue-Green-Cutover umgeht das, bringt aber Mehraufwand.

Engineers, die mit EKS arbeiten, erleben dagegen dank deklarativer und idempotenter Updates eine sehr gute User Experience.

• 2. ECS-Deployments sind naturgemäß langsamer als EKS-Deployments.
• 3. Wenn ein ECS-Deployment schiefgeht, debuggt man schnell eine Black Box ohne klares Feedback, ob der Ist-Zustand mit dem Soll-Zustand übereinstimmt.

Es ist nicht selten, dass ECS-Engineers auf Timeouts warten müssen und zwischen Iterationen rund 4 Minuten mit "Computer says no" verbringen.

Manche Tooling-Optionen wie AWS Copilot machen das Black-Box-Erlebnis noch schlimmer. In bestimmten Debug-Szenarien kann die Wartezeit zwischen Iterationen 20–60 Minuten betragen, weil man auf Timeouts von ECS, Cloud Formation und weiteren Black-Box-Abstraktionsebenen warten muss.

Und wenn Fehler auftreten, gibt die Black-Box-Natur von ECS oft kaum Hinweise oder Feedback zur Fehlerursache.

• 4. Das Debuggen von Problemen bei ECS-Deployments erfordert tendenziell mehr Iterationen als das Debuggen von EKS-YAML-Objekten, die einfacher und entkoppelbar sind.

Das liegt daran, dass ECS-Tasks ein eng gekoppeltes Bündel mehrerer Komponenten sind: Der Troubleshooting-Scope ist größer, ohne einfache Möglichkeit, ihn auf eine bestimmte Komponente einzugrenzen.

• Wenn Sie EKS doch einmal debuggen müssen, können Sie Komponenten systematisch und unabhängig voneinander deployen, bearbeiten und debuggen. Eine Feedback-Schleife im Sekundenbereich ist leicht erreichbar, weil ein "kubectl describe" oder eine YAML-Ausgabe klare Feedback-Signale aus den Stateful Events und dem Status eines YAML-Objekts liefert. Die Feedback-Schleife von EKS wird im Wesentlichen davon begrenzt, wie schnell Sie denken und tippen können.
• Dank kubectl port-forward ist das Debuggen privater IP-Services in EKS trivial. ECS hat dafür kein wirkliches Äquivalent.
• Ein wesentliches Element der hervorragenden User Experience von Kubernetes in Sachen Feedback ist, dass Controller Stateful Metadata an die YAML-Manifeste der Komponentenobjekte anhängen, die per kubectl gegen die etcd-Datenbank eines Live-Clusters appliziert werden.

Dadurch können Engineers per "kubectl describe" und YAML-Ausgaben Event- oder Status-Metadaten einsehen – schnelles und oft konkretes Feedback zu Erfolg oder Misserfolg verschiedener Phasen einzelner Komponenten.

Wenn etwas schiefgeht, lässt sich also schnell zuverlässig feststellen, welche Komponente versagt hat und warum.

• Vergleichen wir das mit dem fehleranfälligen Workflow von ECS: In der AWS-Web-GUI können Sie einen ECS Service vom Typ Load Balancer anlegen, und der Deployment-Fragebogen fragt, in welche Subnetze deployed werden soll.

Die GUI weist darauf hin, dass Sie nicht in Public und Private gleichzeitig deployen können und sich für eines entscheiden müssen – sagt aber nicht, was eigentlich gemeint ist:

Sind das die Subnetze für den Load Balancer oder für die Backend-Instanzen?

Außerdem fragt sie nur einmal nach Subnetzen, obwohl sie zweimal fragen sollte, damit man dem Best-Practice-Muster folgen kann, den Load Balancer öffentlich und die Backend-Instanzen privat zu halten.

Der Workflow von ECS lässt zudem Dinge zu, die er per Programmierung verhindern sollte – etwa einen Public-IP-Load-Balancer in einem privaten Subnetz zu deployen.

Das funktioniert offensichtlich nicht und sollte durch Eingabevalidierung abgefangen werden; stattdessen erhalten Sie einen vermeidbaren Fehler mit unbrauchbarem Feedback.

• Ein weiteres typisches Debug-Szenario, in dem EKS glänzt:

Angenommen, ein Engineer legt eine neue VPC für Tests an und deployed dann irrtümlich einen EKS- oder ECS-Cluster in eine VPC ohne NAT-Gateway.

• Bei ECS erhalten Sie null Logs und null Metriken, weil der Container-Image-Pull mangels Internetzugang fehlschlägt. Sie fliegen quasi blind, ohne Feedback zur Ursache. ECS Exec ist nicht standardmäßig schlüsselfertig in der Plattform aktiviert und schwer zu aktivieren.

Es ist leicht, viele Iterationen mit fruchtlosem Debugging der ECS-Task- oder ECS-Service-Konfiguration zu verschwenden, wenn man nicht erkennt, dass es ein VPC-Problem ist – ECS ist eher eine Black Box mit dürftigem Feedback.

Nichts weist darauf hin, dass der Image-Pull fehlgeschlagen ist; man muss intuitiv erraten, dass dies die Ursache ist.

• Bei demselben Szenario unter EKS lässt sich das Problem viel leichter lösen: Selbst wenn die Worker Nodes keinen Internetzugang haben, ist die Control Plane standardmäßig öffentlich erreichbar. Man kann also per kubectl Feedback wie "image pull failed" erhalten – ein guter Hinweis auf fehlende Internetkonnektivität.

3. ECS hat keine eingebaute Unterstützung für Volumes.

• Eine Sache, die mich bei ECS überrascht hat: Wenn man Konfiguration oder ein Secret injizieren möchte (aus einer in einer ecs-task-definition.json eingebetteten Konfiguration oder aus AWS Secrets Manager), sind Umgebungsvariablen die einzige offiziell eingebaute Option in ECS, um Konfiguration zu laden. Es gibt keine einfache, in die ECS-Plattform eingebaute Option, Konfigurationen oder Secrets als Datei einzuhängen.
• Diese fehlende Möglichkeit, dynamische Konfigurationsdateien einfach zu injizieren, ist ein Hauptgrund, warum ECS kein Äquivalent zum Kubernetes-Konzept eines Ingress Controllers hat.
• ECS kann EFS für persistenten Storage nutzen, und es gibt hacky Workarounds, um Dateien zu mounten – aber all das sind erzwungene Methoden, die nicht leicht umzusetzen sind, weil ECS auf Plattformebene keine eingebaute Unterstützung für Volumes hat.

Eine wichtige Nuance dazu:

ECS bietet auf AWS-Plattformebene Unterstützung für EFS, aber es gibt keine ECS-Plattform-Integrationen, die das Setup erleichtern.

(Es ist nicht nur nicht einfach – ich würde sogar argumentieren, dass es oft schwerer ist, EFS auf ECS einzurichten als auf Standalone-EC2 oder EKS, weil ECS sich wie eine Black Box mit langsamer Feedback-Schleife verhält und schwer zu debuggen ist.)

• EKS hat dagegen einen EFS CSI Driver, mit dem sich eine Kubernetes Storage Class einrichten lässt; diese Integration und die EKS-Plattform-seitige Unterstützung erleichtern das EFS-Setup auf EKS.
• In EKS lassen sich Konfigurationen und Secrets als Umgebungsvariable oder als Datei mounten. StatefulSets, Storage Classes, Persistent Volumes und weitere fortgeschrittene Features machen Stateful Workloads relativ einfach umsetzbar.

4. Der Schwierigkeitsgrad von EKS ist tendenziell variabel und paradox: "EKS ist tendenziell schwer, weil es zu einfach ist."

Der Schwierigkeitsgrad von ECS ist relativ statisch, weil ECS mehr fundamentale Beschränkungen hat. Die Bedeutung dieser Nuancen: Wenn ein Implementierungsteam Zugang zu erfahrener Beratung hat und mit einer guten Implementierungsstrategie arbeitet, kann EKS einfacher sein als ECS.

(Wer das nicht weiß: Diese Sichtweise basiert auf kritischem Denken und steht im Gegensatz zu der häufigen Behauptung in AWS-Dokumenten, dass ECS immer einfacher sei als EKS.)

• Bitte haben Sie Geduld – diese Erkenntnis braucht etwas Erläuterung, denn sie umfasst Nuancen, ein empirisches Paradox und ein paar Gedankengänge, die für die intuitive Erschließung essenziell sind:
• EKS hat das Potenzial, einfacher zu sein als ECS. ECS hat intrinsische, unvermeidbare Nachteile; die wichtigsten wurden bereits erwähnt. Die Nachteile von EKS sind grundsätzlich anders, weil sie tendenziell als emergente Eigenschaft eines Paradoxons entstehen, das durch natürliche Verzerrungen ausgelöst wird.

Wenn Sie das Big Picture des paradoxen Nachteils von EKS, dessen Ursache und Strategien zu seiner Vermeidung verstehen, wird EKS deutlich einfacher.

• EKS ist ein Paradebeispiel für ein altes Sprichwort: "Man kann zu viel des Guten haben. Wird Gutes auf die Spitze getrieben, entstehen oft Probleme."
• Kubernetes ist so gut, so leistungsfähig und derart erfolgreich, dass es ein riesiges Ökosystem hervorgebracht hat. Dieses massive Ökosystem ist komplex, und diese Komplexität – kombiniert mit der natürlichen Tendenz, Kubernetes-Tools mit klaren Vorteilen, aber versteckten Kosten zu adoptieren – ist ein Hauptgrund, warum EKS als schwer wahrgenommen wird.
• Eine wichtige Erkenntnis: Das große, komplexe Kubernetes-Ökosystem ist optional. Wenn Sie strategisch dessen Nutzung minimieren, bleibt EKS einfach.
• Etwas Kontext und ein verwandtes Paradox dazu:
• Eine meiner Engineering-Kernkompetenzen auf Principal-Niveau ist die Fähigkeit, zwischen Problemlösern und Problemtransformierern zu unterscheiden. Problemtransformierer sind Tools und Techniken, die ein Problem im Tausch gegen N neue Probleme lösen. Sie sind tendenziell schlechte Ideen und sollten gemieden werden, sofern man nicht genau weiß, was man tut, und die Folgen zweiter Ordnung durchdacht hat.
• Aus dieser Logik halte ich Folgendes tendenziell für schlechte Ideen:

Kubernetes Operators, StatefulSets, APIs, die nicht v1 sind, Operators, die StatefulSets über Alpha-APIs deployen (besonders kritisch), Service Meshes und der nginx-ingress Controller. Auch HashiCorp Vault sei nicht vergessen: "Friends don't let friends use hashi-vault."

• Beispiele für eingeschleppte Probleme: kritische CVEs, Wartungsaufwand und erzwungene EKS-Updates, die letztlich zu erzwungenen App-Updates führen.

Es ist nicht ungewöhnlich, dass Updates Breaking Changes mitbringen; es entstehen neue Fehlerquellen für Ihre Services und ein größerer Blast Radius bei Problemen, was zusätzlichen Testaufwand bedeutet.

• Ein hinreichend komplexes Setup kann Probleme in den Bereichen IaC, Automatisierung, Dokumentation, Skill-Set-Engpässe, Personalplanung und mehr verursachen.
• Mit diesem Kontext nun das verwandte Paradox:

Wenn jemand eine schlechte Idee hat, ist ECS restriktiv, unflexibel und gerade schwierig genug, dass schnell klar wird: Die Idee wird sich kaum umsetzen lassen. Es wird schwer genug sein, das Nötigste zu tun – also wird nur das Nötigste getan, und ECS gilt im Ergebnis als einfacher.

• EKS ist – wieder einmal – zu flexibel und zu leistungsfähig zu seinem eigenen Schaden.

Wenn jemand mit einer schlechten Idee daherkommt, bietet EKS so viel Freiheit und Umsetzungseinfachheit, dass jede Idee implementierbar ist – auch schlechte.

Schlimm wird es, wenn schlechte Ideen geteilt werden, denn Kubernetes ist so leicht zu nutzen, dass andere unbeabsichtigt schlechte Ideen übernehmen und umsetzen können.

Wenn dann Probleme auftreten, bekommt Kubernetes die Schuld, zu schwierig zu sein.

Die verborgene Wahrheit: Viele Probleme lassen sich vermeiden, indem man schlechte Ideen schlicht nicht umsetzt.

Oder anders gesagt: "EKS ist schwer, wenn man es schwer macht."

• Aus den obigen Erkenntnissen lässt sich eine gute EKS-Implementierungsstrategie ableiten:

Halten Sie sich grundsätzlich an einfache EKS-Funktionalität, bevorzugen Sie nach dem Faustprinzip eingebaute Features, denken Sie regelmäßig an das YAGNI-Prinzip und meiden Sie Features, die ECS nicht hat. (ECS bietet keine echten Operators, Ingress Controller, Persistent Volumes, instabilen APIs, kein massives Ökosystem von Drittanbieter-Tools, und die Unterstützung für AWS App Mesh wird eingestellt.)

Vergleicht man beides mit dieser Strategie im Hinterkopf, kommt man einem echten Äpfel-mit-Äpfeln-Vergleich näher – und auf einmal könnte EKS wie ein aromatischer Honeycrisp-Apfel wirken.

5. ECS-Updates sind extrem selten – ein großer Vorteil für Stabilität und gegen Cluster-Operations-Aufwand.

• Theoretisch könnte eine On-Demand-Fargate-Instanz jahrelang ohne Update auskommen; das vermeidet Ausfälle durch Breaking Changes bei Updates.
• Die EKS-Plattform zwingt Anwender irgendwann zu Updates. Wurden Anwendungen auf dem Cluster vernachlässigt und nie aktualisiert, droht durch erzwungene Plattform-Updates ein Bruch veralteter Anwendungsversionen, die für bestimmte Kubernetes-Versionen ausgelegt sind.
• Der nginx-ingress Controller ist ein gutes Beispiel für eine bekannte Anwendung, die eine Tabelle mit konkreten Kubernetes-Versionen führt, mit denen bestimmte Versionen des Ingress Controllers laufen sollen.
• Ein relativ häufiges, selbstverschuldetes, aber unangenehmes Szenario: Eine Organisation engagiert einen Auftragnehmer, um eine EKS-basierte Lösung möglichst schnell und günstig aufzusetzen. Nach Vertragsende bleibt der EKS-Cluster samt Workloads jahrelang unangetastet.

Irgendwann erfährt jemand, dass die EKS-Plattform Updates erzwingt. Entweder ist bereits etwas kaputtgegangen, oder die Organisation beauftragt jemanden in letzter Minute mit dem Update vor einem erzwungenen Auto-Update.

Häufig stellt der Engineer fest, dass er den Aufwand unterschätzt hat, weil zusätzlich zum Cluster-Update auch mehrere darauf laufende Workloads aktualisiert werden müssen.

• Im Normalfall ist das kein Problem, unter Last-Minute-Druck aber stressig. Wird die Frist nicht eingehalten, drohen Produktionsausfälle. Zumal solche Aufgaben in derartigen Organisationen meist an Nicht-Kubernetes-Experten delegiert werden – und vernachlässigte EKS-Cluster sind oft das Ergebnis schlecht geplanter Eilprojekte, sodass IaC oder Doku fehlen, weil der zuständige Engineer das Unternehmen vor über zwei Jahren verlassen hat.
• Zusätzlich zu erzwungenen Updates haben die EC2-Nodes von EKS mehr Szenarien, in denen Worker Nodes neu starten müssen, als ein ECS-Cluster auf Fargate-Instanzen.

(EC2-Nodes können von einem kostensparenden Cluster Autoscaler wie karpenter.sh herunterskaliert werden, der zudem standardmäßig On-Demand-Nodes alle 30 Tage neu startet, damit sie die neuesten Patch-Updates für EKS-Worker-Node-VMs erhalten.)

• EKS macht es zudem leichter, optionale Komplexität in Form von karpenter.sh, Kubernetes Gateway-API-Controllern, Ingress Controllern und Service Meshes einzuführen.
• Die Adoption dieser optionalen Komponenten erhöht das Risiko: neue Fehlerursachen, mehr potenzielle Fehlerquellen, neue Failure-Mode-Szenarien wie Fehlkonfigurationen, fehlerhafte Updates, Supply-Chain-Schwachstellen, kritische Schwachstellen mit Eilupdates, semi-regelmäßige Reboots als Feature oder Breaking Changes durch Updates.
• Eine Ironie: Service Meshes wie Istio bieten Features, die die Verfügbarkeit verbessern sollen – etwa multi-regionale Mesh-Verbindungen zwischen Clustern, Retry-Logik und mehr. In der Praxis sind sie aber häufig selbst Quelle von Downtime.
• Sobald eine App deployed ist und läuft, ist ECS tendenziell wartungsfrei.
• EKS-Setups haben oft mindestens 3 Cluster mit jeweils mehreren Komponenten, die alle aktualisiert werden und insgesamt einen unausweichlichen Wartungsaufwand erzeugen.
• Glücklicherweise konnte dieser Aufwand durch zahlreiche Fortschritte minimiert werden; der wichtigste ist EKS Auto Mode. Aber selbst wenn dieser nicht genutzt wird, machen AWS Managed Add-ons sowie v1-stable-APIs für Ingress und Karpenter Updates einfacher, schneller und sorgenfreier.

6. EKS hat unvermeidbaren Wartungsaufwand und um eine Größenordnung mehr bewegliche Teile als ECS, das nie gewartet werden muss.

Diese zwei scheinbar geringfügigen Nachteile von EKS erzeugen Effekte zweiter Ordnung mit erheblichen Auswirkungen auf den operativen Aufwand. Um die Größenordnung greifbar zu machen: Rechnen Sie überschlägig mit 2–14 Tagen pro Jahr Engineering-Zeit für EKS-Wartung.

• ECS verzeiht es relativ leicht, wenn übliche DevOps-Best-Practices nicht bekannt sind oder bewusst minimiert/ignoriert werden.

ECS-Admins können trotz fragwürdiger Muster Stabilität erleben, etwa:

• 1. Workflows mit einer Mischung aus manuellen Schritten und Teilautomatisierung mit minimalem IaC oder automatisiertem Workload-Deployment, aber ohne Cluster-Provisionierung.

(Das kann funktionieren, weil ECS, einmal eingerichtet, meist weiterläuft.)

• 2. Die Sicherheitsvorteile mehrerer Cluster ignorieren und alles in einen ECS-Cluster werfen.

(Selbst wenn Dev und Prod im selben ECS-Cluster liegen, leidet die Zuverlässigkeit dank typischer ECS-Architekturmuster selten – die meisten Probleme haben einen kleinen Blast Radius:

ECS-Services nutzen häufig einen eigenen AWS Managed LB statt eines geteilten Kubernetes-Ingress-Load-Balancers. Fargate-Container erhalten jeweils eigene VMs, was die Isolation erhöht.)

• 3. Keine genauen Resource Limits und Requests setzen.

(Da Fargate-Instanzen ein Verhältnis von 1 ECS-Task zu 1 VM haben, ist das nur ein Kostenoptimierungsthema, nicht zugleich ein Zuverlässigkeitsthema.)

• EKS hat genug bewegliche Teile und Komplexität, dass die rigorose Umsetzung von Best Practices für Admins, die ihre EKS-Cluster langfristig zuverlässig und wartbar halten wollen, praktisch zwingend ist.
• Diese Notwendigkeit hat einen erheblichen Nachteil.

Aufgaben rund um Wartung und Best-Practice-Implementierung binden Engineering-Zeit, und Engineering-Stunden sind teuer. Schlimmer noch: Das Streben nach Best Practices kann Engineers in DevOps-Yak-Shaving-Kaninchenlöcher ziehen.

DevOps-Yak-Shaving kann durchaus sinnvoll sein, ist aber zugleich ein potenziell problematischer Sog, weil sich "völlig sinnvoll", "möglicherweise overkill" und "komplett unnötig" schwer voneinander abgrenzen lassen.

Wichtig: ECS-Admins werden nicht nur von Aufgaben verschont, sondern stoßen auch seltener in DevOps-Yak-Shaving-Szenarien.

• Jedes Team, das EKS verwaltet, kommt schnell zu dem Schluss, dass es aus Zuverlässigkeitsgründen mindestens 2 EKS-Cluster braucht.

Man stellt schnell fest, dass EKS-Komponenten-Updates oder Fehlkonfigurationen Breaking Changes verursachen können – und Probleme bei Komponenten wie Ingress, DNS, CNI, karpenter.sh, Service Meshes oder ungesunden Nodes haben einen großen Blast Radius.

Daraus ergibt sich intuitiv, dass isolierte Umgebungen und das Testen von Updates in niedrigeren Umgebungen für die Zuverlässigkeit von EKS essenziell sind.

• Sobald sich EKS-Teams an einen Environment-Promotion-Workflow gewöhnt haben, folgt eine weitere Erkenntnis:

Tests in einer niedrigeren Umgebung sind nur dann aussagekräftig, wenn niedrige und höhere Umgebungen einander relativ ähnlich sind.

• Viele EKS-Teams investieren Zeit in eine rigorose Umsetzung von Infrastructure as Code, End-to-End-Automatisierung und CICD-Pipelines, die sicherstellen, dass niedrige und höhere Umgebungen synchron bleiben.
• Eine weitere häufige Erfahrung: Dev-Umgebungen ändern sich schneller, häufiger und sind anfälliger für manuelle Eingriffe. Auch "Break Glass"-Eingriffe von Hand in Produktion zur Behebung von Ausfällen und Incidents kommen vor.

Daher ist es nicht ungewöhnlich, dass EKS-Teams Config-Drift erleben – wenn die Live-Umgebung nicht mit dem in Git oder einer CICD-Pipeline definierten IaC und der Automatisierung übereinstimmt.

Sicherzustellen, dass Live mit IaC übereinstimmt, erfordert weitere rigorose Best-Practice-Implementierungen – meist eine Kombination aus CICD-Pipelines und GitOps-Implementierungen.

1. ECS könnte in folgenden Szenarien die bessere Wahl sein:

• Sie wollen eine App so designen, dass sie 2–10 Jahre mit maximaler Uptime und minimaler Wartung läuft.

Angenommen, Sie haben eine Anwendung, die selten aktualisiert wird – etwa interne Tools wie eine eigene Auditing-App oder eine öffentlich erreichbare Anwendung, bei der eine Zero-Day-Remote-Code-Execution-Schwachstelle keinen großen Schaden anrichten würde (dank Best Practices wie Distroless-Images ohne Shell und IAM-Rechten nach dem Least-Privilege-Prinzip).

In solchen Fällen kann es sinnvoll sein, die Stärke von ECS – nahezu null operativer Aufwand – über die Stärke von EKS – einfacheres Debugging und schnellere Feedback-Schleifen – zu stellen.

• Sie haben relativ einfache Anwendungen, deployen Updates nur wenige Male pro Tag, haben stabile Anwendungs- und Architekturanforderungen, die sich selten ändern, oder planen, in eine eigene ECS-CICD-Pipeline zu investieren, die nur einfache, immer funktionierende Muster deployt.

Unter solchen Voraussetzungen minimieren Sie Ihre Berührung mit den Schwächen von ECS – schwieriges Debugging im Fehlerfall und langsame Feedback-Schleifen.

• Sie haben ein kleines Team, ausschließlich aus Entwicklern bestehend, von denen niemand auch nur ansatzweise Interesse oder Bereitschaft mitbringt, DevOps-Best-Practices rigoros umzusetzen.

Dann ist ECS nachsichtiger (verglichen mit EKS), wenn operative Best Practices fehlen oder minimiert werden.

2. EKS objektiv als bessere Wahl zu rechtfertigen, erfordert eine etwas tiefere Auseinandersetzung mit den situativen Faktoren:

• Sowohl ECS als auch EKS sind zweischneidige Schwerter mit gleichzeitigen Vor- und Nachteilen. Man kann ECS jedoch als ausgewogener betrachten – Vor- und Nachteile sind beide relativ moderat (low risk, low reward). EKS dagegen bietet deutlichere Vorteile bei moderaten Nachteilen (moderate risk, significant reward).
• Bevor wir auf die Vorteile von EKS eingehen, ist es klug, mit den Nachteilen zu beginnen. Wer die Nachteile von vornherein bedenkt, ist mental besser darauf eingestellt, mehr aus dieser hilfreichen Frage herauszuholen:

"Gleichen die Vorteile, die ich sehe, die Nachteile zumindest aus oder überwiegen sie sogar?"

• Nachteil 1 von EKS: Eine erfolgreiche EKS-Adoption erfordert die rigorose Umsetzung von DevOps-Best-Practices – und das wiederum Bereitschaft sowie eine erhebliche Ressourceninvestition.

Das kann mehr Zeit kosten, als viele erwarten, weil "DevOps-Probleme" oft "DevOps-Lösungen" erfordern, die sich häufig erst mit Problemtransformierern paaren lassen, bevor echte Lösungen anwendbar sind.

Auch deshalb bezeichnen sich DevOps-Profis manchmal scherzhaft als professionelle Yak-Shaver. Transformiert man ein Problem unendlich oft, läuft es darauf hinaus, einen Yak zu rasieren.

(Schätzen wir das überschlägig auf 1–4 Monate einmaliger Engineering-Investition.)

• Wenn Sie diese 1–4 Monate positiv beeinflussen wollen: Zahlen Sie genug, um kritisch denkende Engineers einzustellen, die die feinen Unterschiede zwischen Problemlösungen und Problemtransformationen verstehen. Stellen Sie sicher, dass Ihr Team die Logik und Begründung hinter dem Paradox "EKS ist tendenziell schwer, weil es zu einfach ist" versteht.

Und favorisieren Sie Prinzipien und Empfehlungen wie:

KIS (Keep it Simple), YAGNI (You aren't gonna need it), v1-Stable-APIs sind Ihre Freunde, Managed Services wie der AWS LB Controller sollten DIY-Ingress-Controllern wie Nginx vorgezogen werden (Hinweis: Ersteres ist eine Lösung, Letzteres eine Problemtransformation – der Vulnerability-Scan auf quay.io ergab, dass ein 6 Jahre altes Image des nginx-ingress-controllers 76 kritische Schwachstellen aufwies, also durchschnittlich 1 kritischen CVE pro Monat!), und EKS Auto Mode ist eine Überlegung wert.

(Auto Mode ist ebenfalls eine Problemtransformation und hat Nachteile wie einen Black-Box-Effekt und höhere Kosten; für kleine Greenfield-Cluster ist er aber häufig den Aufwand wert.)

Setzen Sie diese Dinge um, und EKS bleibt relativ einfach.

Denken Sie daran: "EKS ist schwer, wenn man es schwer macht."

• Nachteil 2 von EKS: ein unausweichliches Maß an Wartungsaufwand.

(Schätzen wir das überschlägig auf 2–14 Tage Wartung pro Jahr für 3 Cluster.)

• Erwähnenswert: Der im Dezember 2024 eingeführte EKS Auto Mode kann beide Hauptnachteile von EKS deutlich abmildern.
• EKS Auto Mode eliminiert viel Vorarbeit (rund um das Setup gängiger Add-ons), Vorwissen, laufende Wartung und sogar Failure Modes, da Breaking Changes vermieden werden, indem nur Add-ons auf Basis von v1-Stable-APIs verwendet und automatisch aktualisiert werden.
• Allerdings beseitigt er die Wartung nicht vollständig und hat Nachteile: zusätzliche Kosten und ein stärkerer Black-Box-Charakter, was die Debugbarkeit beeinträchtigt.

(Er führt karpenter.sh-Pods auf den Managed-Control-Plane-Nodes aus, sodass man auf deren Logs nicht zugreifen kann – die jedoch häufig zum Debugging von Edge Cases benötigt werden.)

• Auch Voraussetzungen beseitigt EKS Auto Mode nicht vollständig. Diese verlinkte Seite nennt eine Auto-Mode-spezifische Ingress Class, Load-Balancer-Service-Annotationen und eine Storage Class, die einen Auto-Mode-spezifischen EBS Volume Provisioner referenziert, um sämtliche Auto-Mode-Features zu nutzen.
• Außerdem nützlich zu wissen: Eine Migration von "Auto Mode aus" zu "Auto Mode an" ist schwierig. Auf den ersten Blick sieht es im EKS-Webportal so aus, als ließe sich der Auto Mode einfach an- und abschalten.

Liest man jedoch diese Migration-Referenz, stellt man fest, dass eine In-Place-Migration ein sehr schmerzhafter manueller Prozess ist – derart, dass es oft einfacher ist, einen neuen Cluster zu deployen und eine Blue-Green-Migration durchzuführen. Die Migrationsschwierigkeit liegt darin, dass EKS Auto Mode eigene Ingress Class, Load Balancer Class und EBS CSI Volume Provisioner mitbringt. Versuchen Sie also eine In-Place-Migration auf einem bestehenden Cluster, müssen Sie Kubernetes-Services vom Typ Load Balancer, Ingress-Objekte und alle vor Aktivierung des Auto Mode angelegten PVCs neu erstellen.

• Aufgrund dieser kleineren Probleme und der Mehrkosten ist EKS Auto Mode nicht in jedem Fall empfehlenswert. Trotzdem halte ich ihn häufig für eine gute Wahl bei kleinen Greenfield-Clustern, die von Teams verwaltet werden, die neu in EKS sind. Auch für alle, die mehr als 6 langlebige Cluster betreiben wollen, ist EKS Auto Mode aus meiner Sicht sehr sinnvoll.
• Nun zu den Vorteilen – und der wichtigste ist ein Zeitsparer mit dem größten Effekt auf das Aufwiegen der zuvor genannten Zeitkosten.
• EKS bietet erhebliche Vorteile bei einfacherem und schnellerem Debugging sowie schnelleren Feedback-Schleifen. Unter den richtigen Umständen (Entwicklung beinhaltet oft fortlaufendes Debugging) kann allein dieser Punkt genügend Zeit einsparen, um die zuvor genannten Zeitkosten auszugleichen – und zusätzlich zu den weiteren Vorteilen netto Zeit zu sparen.
• Typische Szenarien, in denen sich EKS leicht rechtfertigen lässt: Ihre App deployt häufig genug, um eine möglichst schnelle CICD-Pipeline zu rechtfertigen, hat häufige Änderungen, komplexe Integrationen, eine Service-orientierte Architektur, befindet sich aktiv in der Transformation von Monolith zu Service-orientierter Architektur (Strangler Pattern) oder hat eine Komplexität, bei der einfaches Debugging mit schneller Feedback-Schleife als sehr wertvoll gilt.
• Erwarten Sie, dass einige Ihrer Apps stark sprunghaften Traffic haben werden und das schnellstmögliche Hochskalieren entscheidend sein könnte?

Falls ja, können die fortgeschrittenen Skalierungsoptionen von EKS (über das keda.sh-Add-on), wie Skalierung auf null und cron-basierte Skalierung, neben Kostenvorteilen zu wichtigen Stärken werden.

• Haben einige Ihrer Apps die zwingende Anforderung, Anwendungskonfiguration als Datei zu laden? Robuste Storage-Optionen?
• Brauchen oder schätzen Sie Zugriff auf fortgeschrittene Funktionalität und Engineering-Patterns wie cluster-weites RBAC, Policy as Code, GitOps, fortgeschrittenes Load Balancing, OIDC/Authn/z-Integrationen sowie generelle Anpassbarkeit, mit der sich beliebige Ideen mit hervorragender Engineering-User-Experience umsetzen lassen?
• EKS kann eine ausgezeichnete Wahl für Projekte sein, in denen die Vorteile die mit der Adoption einhergehenden 2–14 Tage/Jahr Wartungsaufwand überwiegen – sofern Sie Stakeholder dafür gewinnen, 1–4 Monate einmalige Vorlaufzeit für eine Best-Practice-konforme Implementierung zu investieren.

3. Stateful Applications sind ein Szenario, das häufig genug auftritt, um eine Diskussion auf Basis von Faustregeln zu rechtfertigen:

• EKS macht es einfach, Stateful Applications zu betreiben, und unterstützt sie gut – nur weil etwas einfach ist, ist es aber nicht automatisch eine gute Idee. Ich habe versucht, eine fundierte Sicht auf den Schwierigkeitsgrad von EKS samt Vorteilen zu vermitteln. Wichtige Klarstellung: Der bisher genannte Schwierigkeitsgrad geht von Stateless Applications aus (und vielleicht ein paar Stateful Apps, bei denen Datenverlust akzeptabel ist – etwa Valkey/Redis-Caches oder selbst gehostete Monitoring-Tools wie der PLG-Observability-Stack von Grafana Labs).
• Häufig installieren Teams Stateful Applications auf Kubernetes, ohne den vollen Lebenszyklus zu betrachten – inklusive automatisierter Backups, automatisierter Restores, Tests und CICD-Pipeline-Integration.

Werden diese vollumfänglich berücksichtigt, ist der operative Aufwand für eine langfristig hohe Zuverlässigkeit oft enorm.

• Hoch genug, um drei Optionen in Erwägung zu ziehen:
• 1. Erhöhtes Risiko mehrerer Stunden Downtime etwa einmal pro Jahr akzeptieren – im Tausch gegen die Vermeidung erheblichen operativen Aufwands, indem Best Practices für Stateful Workloads bewusst nicht rigoros umgesetzt werden.
• 2. Wenn Sie hochzuverlässige Uptime und einfachere Disaster-Recovery-Optionen brauchen, kann ein Auslagern an einen teuren Managed Service zu niedrigeren Gesamtbetriebskosten führen.
• 3. Prüfen, ob Stakeholder bereit sind, 1–6 Monate (pro einzelner Stateful App/Datenbank) dedizierte Engineering-Zeit und -Aufwand zu investieren, um Best Practices für Stateful Workloads rigoros umzusetzen – inklusive erhöhtem Wartungsaufwand.