Wenn du Container zu AWS migrierst, wirst du dir diese Frage schon früh stellen. Amazon bietet dir zwei Hauptwege, um Container auszuführen: ECS (Elastic Container Service) und EKS (Elastic Kubernetes Service). Beide bringen deine Container in Produktion zum Laufen. Beide sind in den Rest von AWS integriert. Aber sie basieren auf sehr unterschiedlichen Konzepten – und die Wahl, die du hier triffst, wird den Workflow deines Teams auf Jahre hinaus prägen.
Dieser Artikel schlüsselt auf, was die einzelnen Dienste tatsächlich bieten, wie sie sich technisch vergleichen lassen, wann du welchen Dienst bevorzugen solltest und wie sie mit Multi-Tenancy umgehen. Am Ende wirst du diese Entscheidung mit Sicherheit treffen können, anstatt zu raten.
Was ECS und EKS tatsächlich sind
Sowohl ECS als auch EKS sind Container-Orchestrierungsdienste von AWS..
ECS ist der eigene Container-Orchestrierungsdienst von Amazon. Er wurde von AWS für AWS entwickelt und läuft ausschließlich auf AWS. Du beschreibst deine Anwendung als Task-Definition, sagst ECS, wie viele Instanzen laufen sollen, und der Dienst kümmert sich darum, diese Container auf der Rechenleistung zu platzieren, die richtige Anzahl am Leben zu halten und ausgefallene Container zu ersetzen.
EKS EKS ist die verwaltete Kubernetes-Version von Amazon. Kubernetes ist ein Open-Source-Orchestrierungssystem, das ursprünglich von Google entwickelt wurde und heute von der Cloud Native Computing Foundation betreut wird. Bei EKS übernimmt AWS den Betrieb und die Patching-Prozesse der Kubernetes-Control-Plane für dich, aber im Hintergrund nutzt du weiterhin echtes Kubernetes. Das bedeutet: Dieselben YAML-Dateien, dasselbe Befehlszeilen-Tool (kubectl) und dasselbe Ökosystem an Tools, die auf jedem anderen Kubernetes-Cluster funktionieren – egal ob auf Googles GKE, Microsofts AKS oder einem Cluster auf deiner eigenen Hardware.
Dieser Unterschied ist bedeutender, als es auf den ersten Blick scheint. ECS bindet dich fest an AWS. EKS bietet dir hingegen eine gewisse Portabilität, da die von dir definierten Workloads theoretisch überall dort laufen können, wo auch Kubernetes läuft.
Container-Orchestrierung
Bevor wir die beiden Dienste weiter vergleichen, hilft es zu verstehen, was Container-Orchestrierung eigentlich tut – denn das ist genau die Aufgabe, die beide Dienste im Hintergrund erledigen.
Wenn du Container in nennenswertem Umfang betreibst, kannst du sie nicht einfach manuell auf einem Server starten und auf das Beste hoffen. Du brauchst ein System, das Folgendes übernimmt:
- Entscheiden, auf welcher physischen oder virtuellen Maschine jeder Container ausgeführt werden soll
- Container neu starten, die abstürzen oder Health-Checks nicht bestehen
- Die Anzahl der laufenden Instanzen je nach Auslastung automatisch hoch- oder herunterskalieren
- Netzwerktraffic an die richtigen Container leiten
- Neue Versionen ohne Ausfallzeiten ausrollen
- Secrets, Konfigurationen und Speicher für jeden Container verwalten
Dieses „Etwas“ ist der Orchestrator. Sowohl ECS als auch EKS versuchen genau dieses Problem zu lösen, verfolgen aber unterschiedliche Ansätze in Bezug darauf, wie viel Kontrolle du erhältst, wie viel Komplexität du verwalten musst und wie viel du lernen musst, um sie effektiv zu nutzen.
Technische Fähigkeiten
Hier zeigen sich die echten Unterschiede – und das ist der Punkt, an dem sich die meisten Teams entweder in Kubernetes verlieben oder entscheiden, dass es mehr Aufwand ist, als sie eigentlich brauchen.
EKS und Kubernetes: Leistungsstark, aber du bezahlst dafür mit Komplexität
EKS bietet dir die vollständige Kubernetes-API. Das umfasst Pods, Deployments, Services, Ingress Controller, ConfigMaps, Secrets, Custom Resource Definitions und ein riesiges Ökosystem an Add-ons für Logging, Monitoring, Service Mesh und Sicherheit. Wenn du dir einen Container-Anwendungsfall vorstellen kannst, hat wahrscheinlich schon jemand ein Kubernetes-Tool dafür gebaut.
Einer der stärksten Gründe für EKS ist heute Karpenter, der AWS-eigene Open-Source-Node-Autoscaler für Kubernetes. Karpenter beobachtet deine ausstehenden Pods und stellt in Sekundenschnelle genau die richtigen Instanztypen und -größen bereit, anstatt sich auf feste Instanzgruppen zu verlassen. Wenn die Nachfrage sinkt, kann es Workloads auf weniger Nodes konsolidieren und berücksichtigt dabei automatisch Spot-Preise. Im Vergleich zum älteren Cluster Autoscaler reagiert Karpenter schneller und ist deutlich besser darin, Workloads effizient auf der verfügbaren Kapazität zu platzieren.
ECS bietet ebenfalls Autoscaling – sowohl für die Anzahl der laufenden Tasks (Service Autoscaling) als auch für die zugrundeliegende Rechenleistung, wenn du EC2 nutzt (über Capacity Provider), oder komplett ohne Konfigurationsaufwand, wenn du Fargate einsetzt. Es funktioniert gut und lässt sich spürbar einfacher einrichten. Allerdings bietet es nicht die gleiche feingranulare Kontrolle über Bin Packing und die Auswahl der Instanzen, die Karpenter EKS-Nutzern ermöglicht. Wenn deine Workloads in Form und Größe stark variieren und du versuchst, im großen Maßstab das Maximum an Kosteneffizienz herauszuholen, hat EKS mit Karpenter einen echten technischen Vorteil.
Resource-Requests und -Limits: Ein leistungsstarker Weg zur Optimierung großflächiger Systeme
Kubernetes zwingt dich dazu, für jeden Container in Resource-Requests und -Limits zu denken. Ein Request ist die Menge an CPU und Arbeitsspeicher, die dein Container laut deinen Angaben für das Scheduling benötigt, um platziert zu werden. Ein Limit ist die Obergrenze, die der Container nicht überschreiten darf.
Das klingt nach einem kleinen Detail, hat im großen Maßstab aber eine enorme Wirkung. Wenn deine Requests im Vergleich zu dem, was deine Container tatsächlich verbrauchen, zu hoch angesetzt sind, lässt dein Cluster-Autoscaler (oder Karpenter) Nodes laufen, die größtenteils im Leerlauf sind – und du zahlst am Ende für Kapazität, die du nie nutzt. Das ist einer der häufigsten und teuersten Fehler, den Teams machen, sobald sie zu Kubernetes wechseln: Nodes laufen bei 5 bis 10 Prozent Auslastung, weil jedes Team „zur Sicherheit“ großzügige Requests festgelegt hat und es keinen Anlass gab, diese Zahlen je wieder zu überprüfen.
Richtig umgesetzt kann das Anpassen von Requests und Limits anhand echter Nutzungsdaten die Rechenkosten drastisch senken – teilweise um weit mehr als die Hälfte –, ohne dass eine einzige Zeile Anwendungscode angefasst werden muss. Das ist ein Hebel, den Kubernetes dir bietet und den du aktiv verwalten musst. ECS verfügt über ein äquivalentes Konzept durch CPU- und Arbeitsspeicher-Einstellungen in der Task-Definition; da ECS-Tasks jedoch gewöhnlich grober bemessen sind und Teams häufiger weniger, dafür größere Dienste betreiben, fällt diese Art der feingranularen Optimierung im täglichen Betrieb meist weniger ins Gewicht – schlichtweg weil es weniger Stellschrauben gibt.
YAML-Konfigurationen vs. Task-Definitionen
In EKS wird fast alles in YAML definiert. Deployments, Services, ConfigMaps, Ingress-Regeln und Autoscaling-Richtlinien sind allesamt YAML-Dateien, die mit kubectl auf den Cluster angewendet werden. Das bietet dir enorme Flexibilität und sorgt dafür, dass alles versionierbar und in einem Pull-Request überprüfbar ist. Es bedeutet aber auch, dass dein Team Kubernetes-YAML tatsächlich verstehen muss, was eine eigene Lernkurve mit sich bringt – einschließlich Dingen wie der Empfindlichkeit gegenüber Einrückungen, API-Versionen und der Frage, wie verschiedene Ressourcennypen zueinander in Beziehung stehen.
In ECS ist das Äquivalent die Task-Definition – eine JSON- (oder konsolengesteuerte) Beschreibung deines Container-Images, deiner CPU und deines Arbeitsspeichers, des Netzwerkmodus, der Umgebungsvariablen und der Logging-Konfiguration. Task-Definitionen sind einfacher zu lesen und zu schreiben, insbesondere für Teams, die mit Kubernetes-Konzepten noch nicht vertraut sind. Es gibt weniger einzustellen, aber auch weniger, was man falsch konfigurieren kann. Für Teams ohne dedizierte Infrastructure Engineers ist diese Einfachheit oft der entscheidende Faktor.
Nutzung
Sobald du den technischen Vergleich hinter dir hast, lautet die eigentliche Frage in der Praxis: Wer wird das Ganze im Alltag überhaupt betreiben?
ECS ist einfacher zu bedienen
ECS passt besser zu dir, wenn du in einem kleinen Team arbeitest oder kein dediziertes Platform-Engineering-Team hast. Du kannst es an einem Nachmittag von null zu einem laufenden, auto-skalierenden Dienst mit Load Balancing schaffen – besonders wenn du Fargate nutzt und dich nie um die zugrundeliegenden Server kümmern musst. Der AWS-Support deckt ECS direkt als AWS-Kerndienst ab. Wenn also etwas schiefgeht, grenzt du den Fehler gemeinsam mit dem AWS-eigenen Support-Team ein, anstatt herausfinden zu müssen, ob das Problem in Kubernetes selbst, in einem Add-on oder in deiner eigenen Konfiguration liegt.
Das macht ECS zu einer hervorragenden Wahl für Startups, kleine bis mittlere Unternehmen und jedes Team, das einen Managed Service sucht, um den man sich nicht ständig kümmern muss. Du gibst zwar etwas Flexibilität auf, erhältst im Gegenzug aber einen deutlich geringeren betrieblichen Aufwand.
EKS ist komplexer, aber besser für große Teams und Isolierung
EKS verlangt dir am Anfang etwas mehr ab. Du solltest die grundlegenden Kubernetes-Konzepte verstehen, Add-ons verwalten, den Cluster und die Node Groups regelmäßig aktualisieren und ein gewisses Maß an internen Tools oder Dokumentation bereitstellen. So können deine Anwendungsteams den Cluster nutzen, ohne selbst zu Kubernetes-Experten werden zu müssen.
Dafür erhältst du eine Plattform, die hervorragend mit organisatorischer Komplexität skaliert. Große Unternehmen mit vielen Teams, zahlreichen Services und unterschiedlichen Compliance- oder Isolierungsanforderungen neigen eher zu EKS, da Kubernetes dir starke Grundbausteine (Primitives) bietet, um Workloads voneinander zu isolieren, Deployment-Muster über Teams hinweg zu standardisieren und ein riesiges Ökosystem an Tools für Observability, Security-Scanning und Policy-Enforcement einzubinden. Wenn du damit rechnest, Dutzende von Teams und Hunderte von Services auf derselben Infrastruktur zu betreiben, ist EKS die zusätzliche Komplexität in der Regel wert.
Multi-Tenancy (Mandantenfähigkeit)
Multi-Tenancy (Mandantenfähigkeit) bedeutet, Workloads von mehreren Teams, Kunden oder Umgebungen auf einer gemeinsamen Infrastruktur zu betreiben und sie gleichzeitig sauber voneinander zu trennen. Sowohl ECS als auch EKS können das, allerdings unterscheiden sich die Mechanismen dafür stark.
Multi-Tenancy in ECS
Die Multi-Tenancy in ECS erfolgt in der Regel auf der Ebene von Clustern, Services und AWS-Accounts. Ein gängiges Muster ist ein ECS-Cluster pro Umgebung (Staging, Produktion) oder pro Geschäftsbereich, wobei die Services innerhalb des Clusters logisch voneinander getrennt werden. Die Isolierung zwischen verschiedenen Tenants wird hauptsächlich über IAM-Rollen, Sicherheitsgruppen (Security Groups) und separate Task-Definitionen durchgesetzt, statt über ein dediziertes Namespace-Konzept. Für eine strengere Isolierung nutzen viele Teams einfach separate AWS-Accounts pro Tenant, die über AWS Organizations miteinander verknüpft sind. Das umgeht die Notwendigkeit einer feingranularen Isolierung innerhalb des Clusters vollständig.
Multi-Tenancy in EKS
Kubernetes bietet dir dafür ein integriertes Konzept: den Namespace. Jedes Team, jeder Kunde oder jede Umgebung kann einen eigenen Namespace erhalten – inklusive eigener Ressourcenkontingente (Resource Quotas), Netzwerkrichtlinien (Network Policies) und rollenbasierter Zugriffskontrolle (RBAC), die steuert, wer was sehen oder verändern darf. Das macht es möglich, viele Tenants innerhalb eines einzelnen Clusters zu betreiben und dennoch eine echte Trennung zwischen ihnen durchzusetzen.
Namespaces und Resource Quotas
Namespaces alleine sind nur eine organisatorische Abgrenzung. Damit Multi-Tenancy tatsächlich funktioniert, kombinierst du Namespaces mit ResourceQuotas (die begrenzen, wie viel CPU, Arbeitsspeicher und Anzahl an Objekten ein Namespace verbrauchen darf) und LimitRanges (die Standard- und Höchstwerte für Ressourcenanforderungen pro Container festlegen). Ohne diese Einschränkungen kann ein einziger rechenintensiver Tenant unbemerkt den Großteil der Cluster-Kapazität verbrauchen und alle anderen ausbremsen.
Netzwerkrichtlinien
Standardmäßig kann jeder Pod in einem Kubernetes-Cluster mit jedem anderen Pod kommunizieren – was in einem Multi-Tenant-Setup selten das ist, was du möchtest. Network Policies ermöglichen es dir, den Datenverkehr so einzuschränken, dass beispielsweise Workloads im Namespace „client-a“ Workloads in „client-b“ überhaupt nicht erreichen können, selbst wenn sie auf denselben physischen Nodes laufen. Dies wird durch das von dir verwendete CNI-Plugin durchgesetzt, sodass die konkreten Funktionen davon abhängen, welches Networking-Add-on in deinem Cluster läuft.
RBAC und Zugriffskontrolle
Rrollenbasierte Zugriffskontrolle (RBAC) bestimmt, welche Benutzer und Service-Accounts Ressourcen lesen, erstellen oder ändern dürfen und in welchen Namespaces dies möglich ist. Ein gut durchdachtes RBAC-Setup sorgt dafür, dass ein Entwickler eines Teams seine eigenen Services deployen und debuggen kann, ohne jemals die Berechtigungen zu haben, den Namespace eines anderen Teams anzutasten – geschweige denn die zentrale Konfiguration des Clusters.
Isolierung auf Node-Ebene
Für Tenants, die stärkere Garantien als eine Isolierung auf Software-Ebene benötigen, bieten beide Dienste eine Trennung auf Node-Ebene. In ECS kannst du bestimmte EC2-Instanzen oder Fargate-Profile für spezielle Workloads reservieren. In EKS kannst du Taints, Tolerations und Node Selector nutzen, um sicherzustellen, dass sensible oder strengen Compliance-Vorgaben unterliegende Workloads nur auf den für sie reservierten Nodes landen. Dadurch werden sie selbst innerhalb desselben Clusters physisch von anderen Tenants getrennt.
Für welchen solltest du dich entscheiden
Wenn dein Team klein ist, deine Workloads relativ einfach sind und du schnell vorankommen willst, ohne ein eigenes Platform-Team einzustellen, ist ECS sehr wahrscheinlich die richtige Wahl. Es hält dir den Rücken frei und lässt AWS den Großteil des betrieblichen Aufwands tragen.
Wenn du Dutzende von Diensten über mehrere Teams hinweg betreibst, Portabilität zwischen verschiedenen Cloud-Anbietern benötigst oder eine feingranulare Kontrolle über Skalierung, Isolierung und Kostenoptimierung verlangst, lohnt sich bei EKS die Investition in die Lernkurve und den betrieblichen Aufwand. Das Kubernetes-Ökosystem, Tools wie Karpenter und die Möglichkeit, Resource Requests und Limits auf granularer Ebene anzupassen, geben dir Stellschrauben an die Hand, die ECS in diesem Maße einfach nicht bietet.
Hier gibt es keine universell richtige Antwort. Die richtige Wahl hängt von der Größe deines Teams, deinen Compliance-Anforderungen und der betrieblichen Komplexität ab, die du bereit bist, im Austausch für Flexibilität in Kauf zu nehmen. Am wichtigsten ist es, die Entscheidung bewusst zu treffen – basierend darauf, wo deine Organisation heute tatsächlich steht und wohin sie sich realistischerweise entwickelt, anstatt Kubernetes nur deshalb zu wählen, weil es die populärere Option ist.