ECS Fargate oder Kubernetes: Was braucht eine normale Anwendung wirklich?

Wenn ich heute eine normale Backend-Anwendung auf AWS neu aufsetze, fange ich nicht mit Kubernetes an. Ich fange mit ECS auf Fargate an.

Nicht weil Kubernetes schlecht wäre. Ich habe mit Kubernetes gearbeitet, auch in Produktion, und es gibt Systeme, bei denen ich es genau so wieder einsetzen würde. Aber Kubernetes löst eine Klasse von Problemen, die eine normale Anwendung häufig noch gar nicht hat. Und ich wähle Architektur nicht danach aus, was ein System irgendwann theoretisch brauchen könnte, sondern danach, was es heute tatsächlich braucht.

Was hier eigentlich verglichen wird

Streng genommen vergleicht die Frage nicht Gleiches mit Gleichem. Amazon ECS und Kubernetes sind Orchestrierungssysteme. AWS Fargate ist dagegen die Rechenschicht, auf der Container laufen, und lässt sich sowohl unter ECS als auch unter Amazon EKS verwenden.

Wenn ich von ECS Fargate spreche, meine ich deshalb den oberen Stapel, mit Kubernetes im AWS-Kontext den unteren:

ECS Fargate                     Kubernetes auf AWS

Container                       Container
   ↓                               ↓
Amazon ECS                      Amazon EKS
   ↓                               ↓
AWS Fargate                     EC2, EKS Auto Mode oder Fargate

Die eigentliche Entscheidung lautet also: Braucht meine Anwendung die Kubernetes-Plattform, oder reicht die deutlich schmalere Abstraktion von ECS? Für viele Anwendungen ist meine Antwort: ECS reicht.

Was ich unter einer normalen Anwendung verstehe

Damit die Aussage nicht beliebig wird, grenze ich „normal" ein. Gemeint ist ein SaaS-Backend, eine API, ein PHP-Monolith, ein paar Go-Services oder eine interne Fachanwendung, mit ungefähr diesem Zuschnitt:

• einige HTTP-Services und Hintergrundjobs,
• eine relationale Datenbank, Redis und eine Queue wie SQS,
• ein Load Balancer davor,
• automatische Deployments und horizontale Skalierung,
• Logs, Metriken und Tracing.

Vielleicht drei Container, vielleicht zehn, vielleicht irgendwann zwanzig. Das sind ernsthafte Produktionssysteme. Aber sie sind noch keine Containerplattform. Der Unterschied ist wichtig, denn aus „wir betreiben mehrere Container" wird erstaunlich oft unbemerkt „wir brauchen Kubernetes". Das eine folgt nicht aus dem anderen.

Was ECS Fargate schon mitbringt

Bei ECS auf Fargate beschreibe ich im Wesentlichen, welchen Container ich ausführen will, welche CPU und wie viel Speicher er bekommt, wie sein Netzwerk aussieht, welche IAM-Rechte er hat und wie viele Instanzen laufen sollen. Die Server darunter stelle ich nicht bereit und verwalte sie nicht als Clusterkapazität.

Ein typischer Webservice sieht dann so aus, ergänzt je nach Anwendung um SQS, ElastiCache, Secrets Manager, ECR, Route 53 und CloudWatch oder OpenTelemetry:

Application Load Balancer
        ↓
    ECS Service
        ↓
   Fargate Tasks
        ↓
       RDS

Das ist keine Spielzeugarchitektur. Die Alltagsfragen beantwortet der Dienst selbst:

• Der Service braucht vier Instanzen? Dann laufen vier Tasks.
• Der Verkehr wächst? Dann skaliert der Service über Auto Scaling anhand einer Metrik.
• Eine neue Version kommt? ECS startet neue Tasks, wartet auf den Gesundheitscheck und nimmt die alten aus dem Verkehr. Scheitert das Deployment, rollt der Deployment Circuit Breaker auf die letzte funktionierende Version zurück.
• Ein Task stirbt? Der Service ersetzt ihn.
• Ich muss in einen laufenden Container? Dafür gibt es ECS Exec, ohne SSH und ohne offenen Port.

Damit lassen sich hochverfügbare, horizontal skalierende und automatisch ausgerollte Anwendungen bauen. Und vor allem: Ich betreibe die Anwendung, nicht zusätzlich eine Plattform für die Anwendung. Das ist für mich der entscheidende Punkt.

Wie das für einen bestehenden PHP-Monolithen konkret aussieht, vom Image bis zum Gesundheitscheck, steht in Ein PHP-Monolith auf ECS Fargate.

Was Kubernetes zusätzlich mitbringt, und was es kostet

Kubernetes kann deutlich mehr. Deployments beschreiben einen gewünschten Zustand, den die Plattform deklarativ herstellt, und um diesen Kern liegt ein großes Ökosystem für Netzwerk, Speicher, Autoscaling, Policies, Operatoren, Service Meshes und eigene Controller.

Amazon EKS nimmt einen wichtigen Teil des Betriebs ab: AWS betreibt und skaliert den Control Plane und ersetzt dort fehlerhafte Instanzen. Das ist viel wert. Aber ein verwalteter Control Plane macht Kubernetes nicht zu ECS. Das Systemmodell bleibt, und jemand im Team muss es verstehen:

Cluster, Namespaces, Deployments, Pods, Services, Ingress,
ConfigMaps, Secrets, ServiceAccounts, RBAC, Network Policies,
Autoscaler, Storage Classes, CRDs, Controller, ...

Keiner dieser Bausteine ist schlecht. Die Frage ist nur: Welches Problem meiner Anwendung löst er? Wenn ich darauf keine konkrete Antwort habe, will ich ihn nicht besitzen.

Denn Komplexität ist nicht kostenlos, nur weil sie aus YAML besteht. Noch ein Manifest, noch ein Helm Chart, noch ein Controller sehen am Anfang billig aus. Der Preis entsteht später: beim Upgrade, beim Incident, beim Onboarding, bei der nächsten Sicherheitslücke. Wenn ein Zertifikat nicht erneuert wird. Wenn ein Controller mit der neuen Kubernetes-Version nicht mehr läuft. Wenn jemand verstehen muss, warum der Pod läuft, der Service aber keinen Verkehr bekommt, oder warum ein erfolgreiches Deployment von einer Network Policy isoliert wird.

Das Upgrade ist dabei kein Einzelfall, sondern ein Takt. Eine Kubernetes-Version bleibt bei EKS rund 14 Monate im Standard-Support, danach kostet die verlängerte Unterstützung deutlich mehr. Wer EKS betreibt, hebt den Cluster also ungefähr jedes Jahr, samt aller Erweiterungen, die darauf laufen. Bei ECS gibt es diesen Takt nicht, weil es keinen Control Plane gibt, den ich versioniere.

Technologie wird nicht dadurch kostenlos, dass AWS einen Teil davon verwaltet. Jede Plattformfunktion, die ich einführe, ist Wissen, das im Team vorhanden sein muss.

Vier Argumente, die allein nicht reichen

Vier Begründungen höre ich für Kubernetes am häufigsten. Jede enthält etwas Wahres, keine trägt die Entscheidung allein.

„Kubernetes ist flexibler." Stimmt. Aber jede zusätzliche Möglichkeit erzeugt eine zusätzliche Entscheidung. Wer verschiedene Ingress-Controller betreiben kann, muss einen auswählen. Wer eigene Controller installieren kann, muss sie aktualisieren. Wer hundert Erweiterungen einsetzen kann, muss entscheiden, welche zehn dauerhaft zur Plattform gehören. Bei ECS ist der Lösungsraum kleiner. Das kann ein Nachteil sein, bei einer normalen Anwendung empfinde ich es als Vorteil. Ich will nicht die flexibelste Plattform, sondern die kleinste, die mein Problem zuverlässig löst.

„ECS bedeutet Vendor Lock-in." Technisch richtig: Task Definition, Task-Rollen und ECS Service sind AWS-spezifisch. EKS dagegen implementiert Upstream-Kubernetes und ist konform, ein Deployment läuft grundsätzlich auch anderswo. Die Frage ist, wie viel Portabilität in der realen Anwendung übrig bleibt. Nutzt sie RDS, S3, SQS, SNS, EventBridge, IAM, Secrets Manager, CloudFront und DynamoDB, dann macht ein Kubernetes-Deployment daraus keine cloudunabhängige Anwendung. Mein Compute ist portabler geworden, mein System nicht. Ist Multi-Cloud eine konkrete Geschäftsanforderung, sieht die Rechnung anders aus. „Vielleicht wollen wir irgendwann AWS verlassen" reicht mir dafür nicht.

„Wir wollen stark wachsen." Skalierung ist kein einzelnes Problem. Mehr Anfragen brauchen mehr Instanzen, das kann ECS. Eine wachsende Queue braucht mehr Worker, das kann ECS auch. Eine Datenbank am Limit oder ein langsamer externer Dienst: Da hilft Kubernetes überhaupt nicht. Bei klassischen Backends liegt der erste Engpass fast nie in der Orchestrierung, sondern bei Datenbankzugriffen, Datenmodell, Caching, Synchronität, Locks, Hot Partitions, großen Nutzlasten oder fehlendem Backpressure. Meine Gegenfrage ist deshalb: Welche Komponente skaliert heute nicht?

„Wir haben Microservices." Fünf Services brauchen keinen Cluster, nur weil sie Microservices heißen, zehn auch nicht automatisch. Unter ECS bekommt jeder Service eigene Ressourcen, eigene IAM-Rechte, ein eigenes Deployment und eine eigene Skalierung, und über Service Connect finden sie sich gegenseitig. Die richtige Frage ist nicht „Haben wir Microservices?", sondern: Welche Anforderung unserer Service-Landschaft lässt sich mit ECS nicht mehr sinnvoll abbilden?

Ob es überhaupt mehrere Dienste sein müssen, ist eine Frage davor: Vom Monolithen zu Microservices.

Wann Kubernetes seine Komplexität verdient

Der Punkt, an dem meine Entscheidung kippt, ist keine Zahl an Requests und keine Zahl an Containern. Es ist der Moment, in dem ich nicht mehr hauptsächlich einzelne Anwendungen betreibe, sondern eine gemeinsame Plattform für viele Anwendungen und Teams.

Mit dreißig und mehr Services, mehreren Teams mit eigenen Release-Zyklen, verschiedenen Arten von Workloads, gemeinsamen Standards, zentralen Policies und Menschen, deren Aufgabe die Plattform ist, ändert sich die Rechnung. Dann lohnen sich ein einheitlicher Deployment-Mechanismus, eine gemeinsame Policy-Ebene, standardisierte Workload-Definitionen und Self-Service für die Teams. Dann erzeugt Kubernetes nicht mehr Komplexität, sondern organisiert vorhandene. Bei fünf Services erzeugt die Plattform womöglich mehr Komplexität, als sie beseitigt. Bei fünfzig kann sie das Gegenteil tun.

Dazu kommen Anforderungen, bei denen die größere Plattform ihren Wert schnell zeigt: besondere Scheduling-Regeln, eigene Operatoren, anspruchsvolle zustandsbehaftete Workloads, weitgehende Netzwerk- und Policy-Vorgaben, Standardisierung über mehrere Infrastrukturumgebungen oder Werkzeuge, die Kubernetes voraussetzen.

Und schließlich die Organisation. Betreibt im Haus bereits ein Plattformteam Kubernetes produktiv, mit Monitoring, Deployment, Security Policies und geregelten Upgrades, dann ist Kubernetes dort nicht neu. Dann kann ein eigener ECS-Weg für meine Anwendung der kompliziertere sein, und ich würde nicht „ECS ist einfacher" sagen. Die vorhandene Organisation gehört zum System. Umgekehrt führe ich Kubernetes nie ein, weil zwei Entwickler es gern lernen würden. Das ist ein schöner Nebeneffekt, aber kein Architekturgrund.

Deshalb sage ich nicht, ECS sei besser als Kubernetes. Ich sage: Kubernetes muss ein Problem lösen, das ECS nicht ausreichend löst. Gibt es dieses Problem, kann Kubernetes die bessere Entscheidung sein. Gibt es es nicht, kaufe ich Plattformkomplexität ohne Gegenleistung.

Für ein gewachsenes System, das bisher auf einem Server liegt, stellt sich dieselbe Frage mit anderen Vorzeichen: Muss das Altsystem nach Kubernetes?

Kosten: mehr als der Preis einer vCPU

Ein Vergleich landet schnell bei Tabellen mit vCPU- und RAM-Preisen. Das ist nötig, aber für eine Architekturentscheidung zu wenig. Ich betrachte mindestens drei Blöcke:

  Compute-Kosten
+ Plattformkosten
+ Betriebskosten

Fargate kann bei konstant hoher Auslastung teurer sein als gut ausgelastete EC2-Kapazität. Dafür kaufe ich weniger Infrastrukturarbeit, und für unterbrechbare Worker gibt es Fargate Spot. Kubernetes erlaubt es unter Umständen, Workloads dichter zu packen und Compute stärker zu optimieren. Dafür kommen eine Gebühr je Cluster für den Control Plane, der jährliche Upgrade-Takt und eine mächtigere Plattform dazu, die jemand betreibt.

Die Kennzahl, die mich interessiert, ist deshalb nicht der Preis einer vCPU, sondern: Was kostet es uns, diese Anwendung zwölf Monate zuverlässig zu betreiben? Darin stecken Entwicklerzeit, Updates, Bereitschaft, Fehlersuche und Wissen.

Wo in gewachsenen AWS-Setups das Geld tatsächlich verschwindet, steht in Schlechte Architektur schickt keine Alerts.

Ein Beispiel, und dasselbe Unternehmen drei Jahre später

Eine Anwendung auf AWS mit einer öffentlichen API, einem Payment-Service, einem Reporting-Service und einem Worker, dazu PostgreSQL, Redis und SQS. Alle Services sind zustandslos, das Team hat sechs Entwickler und kein Plattformteam. Die Anwendung soll hochverfügbar laufen und automatisch skalieren.

Ich sehe hier keinen Grund für Kubernetes. Meine erste Architektur wäre:

                  ALB
                   |
          +--------+--------+
          |                 |
     API Service     Payment Service      Reporting Service
     ECS/Fargate       ECS/Fargate           ECS/Fargate

                  SQS
                   |
                 Worker
               ECS/Fargate

           RDS + ElastiCache (Multi-AZ)

Deployment über CI/CD, Infrastruktur über Terraform, Observability über OpenTelemetry, Auto Scaling anhand sinnvoller Metriken, Multi-AZ dort, wo der Zustand liegt. Das ist eine vollständige Produktionsumgebung. Was würde Kubernetes hier zusätzlich lösen? Lautet die Antwort nur „dann wären wir auf Kubernetes", führe ich es nicht ein.

Jetzt dasselbe Unternehmen drei Jahre später. Aus sechs Entwicklern sind sechzig geworden, aus vier Workloads achtzig, acht Teams deployen unabhängig. Die Plattform soll gemeinsame Regeln für Netzwerk, Security, Observability, Secrets, Deployments und Ressourcen durchsetzen. Ein Plattformteam existiert, einige Workloads haben besondere Scheduling-Anforderungen, mehrere zentrale Werkzeuge setzen Kubernetes voraus.

Jetzt sieht dieselbe Entscheidung völlig anders aus. Eine gemeinsame Plattform, auf der alle Teams nach denselben Regeln arbeiten, ersetzt dutzende Einzellösungen. Jetzt verdient Kubernetes seine Komplexität. Die Grenze ist nicht die Zahl der Requests und nicht die Zahl der Zertifizierungen im Team, sondern die Frage, ob ich eine Anwendung betreibe oder eine Plattform für viele.

Wenn Fargate nicht reicht

Fargate hat Grenzen, und sie sind konkret: keine GPUs, keine privilegierten Container, keine Daemons auf dem Host, eine Obergrenze für CPU und Speicher je Task. Wer auf eine davon stößt, braucht deshalb nicht automatisch Kubernetes.

Der nächste Schritt ist oft ECS auf EC2: dasselbe Service-Modell, dieselben Task Definitions, aber eigene Instanzen mit GPU, mehr Speicher oder einem Agenten, der auf jedem Host laufen muss. Die Plattformfrage stellt sich erst, wenn die Anforderungen über das hinausgehen, was ECS überhaupt abbildet.

Die Entscheidung als Tabelle

Aber auch diese Tabelle würde ich nicht allein entscheiden lassen. Die wichtigste Frage steht nicht darin.

Die Frage, mit der ich anfange

Wenn jemand sagt „Wir sollten Kubernetes einsetzen", frage ich nicht nach der Distribution. Ich frage: Welches konkrete Problem unserer Anwendung löst Kubernetes, das wir mit ECS Fargate nicht sinnvoll lösen können?

Darauf gibt es sehr gute Antworten. „Wir betreiben 120 Services mit zwölf Teams." „Unser internes Plattformmodell basiert darauf." „Wir brauchen Operatoren für einen zentralen Teil unserer Infrastruktur." „Wir betreiben dieselben Workloads tatsächlich in mehreren Kubernetes-Umgebungen." Alles gut. „Das ist der Industriestandard" reicht mir nicht. „Damit sind wir skalierbar" auch nicht. Und „Vielleicht brauchen wir es später" erst recht nicht.

Das gilt besonders bei der Modernisierung. Läuft eine Anwendung heute auf einer einzelnen virtuellen Maschine, versuche ich nicht, sie direkt auf Kubernetes zu bringen. Der sinnvolle Weg ist oft:

1 Server
   ↓
reproduzierbarer Container
   ↓
ECS Fargate
   ↓
mehrere Tasks
   ↓
automatische Deployments
   ↓
Auto Scaling

Und vielleicht endet die Reise dort. Das ist kein Zwischenzustand, der irgendwann „richtig" gemacht werden muss, es kann die endgültige Architektur sein. Braucht die Organisation später doch eine Kubernetes-Plattform, ist ein sauber containerisierter, zustandsloser Service wesentlich leichter dorthin zu bringen als das ursprüngliche Altsystem. Ich verliere also wenig. Ich verschiebe nur eine Entscheidung auf den Zeitpunkt, an dem ich genug weiß, um sie vernünftig zu treffen.

Was eine Anwendung vorher loswerden muss, damit sie mehrfach laufen kann, steht in Sessions, Uploads, Konfiguration.

Kubernetes wähle ich, wenn sich die Anforderungen verändert haben: viele Teams, viele unterschiedliche Workloads, ein echtes Plattformteam, ein Ökosystem, das Kubernetes voraussetzt, besondere Scheduling- oder Policy-Anforderungen, oder eine tatsächlich benötigte einheitliche Plattform über mehrere Umgebungen. Dann zahlt die Plattform ihre Komplexität zurück. Vorher nicht.

Meine Voreinstellung ist deshalb nicht die mächtigste Plattform, die ich einsetzen könnte, sondern die kleinste, die das Problem zuverlässig löst.

Wer gerade vor dieser Entscheidung steht, findet das Vorgehen auf der Seite zur AWS-Migration.