EKS Capabilities: Managed Argo CD, ACK und kro im Überblick

Das Problem: Wer betreibt eigentlich Argo CD?

Jedes Platform-Engineering-Team, das EKS ernsthaft betreibt, kennt die Situation: Argo CD läuft im Cluster, weil es laufen muss. Aber wer kümmert sich um das Upgrade von Argo CD selbst? Wer stellt sicher, dass die Replica-Counts stimmen, wenn der Cluster wächst? Wer pflegt die SSO-Konfiguration, wenn sich das Identity-Provider-Setup ändert? Und wer debuggt, warum Argo CD in einem Multi-Account-Setup plötzlich keinen Zugriff mehr auf einen privaten Spoke-Cluster hat?

Diese Arbeit ist kein Produkt. Sie ist Overhead – und sie wächst mit jeder weiteren Cluster-Instanz. Genau hier setzt Amazon EKS Capabilities an. AWS hat das Feature am 30. November 2025 zur re:Invent angekündigt und gleichzeitig allgemein verfügbar gemacht – in den kommerziellen AWS-Regionen, nicht in GovCloud und China. Es bringt drei der häufigsten Platform-Engineering-Werkzeuge als vollständig verwaltete Dienste auf EKS: Argo CD, AWS Controllers for Kubernetes (ACK) und Kube Resource Orchestrator (kro).

Was EKS Capabilities sind – und was sie nicht sind

Der entscheidende Unterschied zu einem gewöhnlichen EKS-Add-on liegt darin, wo der Controller läuft. Bei EKS Capabilities läuft die Controller-Software nicht auf Ihren Worker Nodes, sondern in AWS-eigener Infrastruktur außerhalb Ihres Clusters. In Ihrem Cluster landen nur die Custom Resource Definitions (CRDs) und die Ressourcen, die Sie selbst anlegen. Die Reconciliation-Logik, das Scaling, das Patching und die Lifecycle-Verwaltung des Controllers übernimmt AWS.

Was das konkret bedeutet: Ihre Worker Nodes müssen keinen direkten Zugriff auf Git-Repositories oder Helm-Registries haben, weil die Argo-CD-Capability diesen Zugriff aus der AWS-verwalteten Infrastruktur heraus übernimmt. Und Sie verlieren keine Node-Kapazität an Platform-Komponenten, die auf jedem Cluster laufen müssen, aber keinen Geschäftswert erzeugen.

Was EKS Capabilities nicht sind: ein Ersatz für EKS selbst, ein Cluster-Autoscaler oder ein Netzwerk-Plugin. Sie sind eine Schicht oberhalb des Clusters, die spezifische Betriebsaufgaben abnimmt – nicht mehr und nicht weniger. Pro Cluster kann jeweils eine Capability jedes Typs aktiviert werden.

Die drei Capabilities im Überblick

Argo CD ist die Capability, die für die meisten Teams den größten unmittelbaren Unterschied macht. Sie liefert GitOps-basiertes Continuous Deployment: Argo CD überwacht ein Git-Repository und hält den Cluster-Zustand mit dem dort definierten Soll-Zustand synchron. In der managed Version entfällt das Betreiben der Argo-CD-Infrastruktur selbst. AWS übernimmt Scaling, Upgrades und die Verbindung zu Remote-Clustern.

AWS Controllers for Kubernetes (ACK) ermöglicht es, AWS-Ressourcen – S3-Buckets, RDS-Datenbanken, SQS-Queues, IAM-Rollen und mehr – über native Kubernetes-APIs zu verwalten. ACK bringt über 200 CRDs für mehr als 50 AWS-Services mit. Statt Terraform oder CloudFormation für die Infrastruktur und Kubernetes für die Applikation zu kombinieren, können Teams beides über denselben deklarativen Workflow steuern. Unterstützt werden dabei nur Controller, die upstream als Generally Available gelten.

kro (Kube Resource Orchestrator) ist das jüngste der drei Werkzeuge und das abstrakteste. Es erlaubt Platform-Teams, eigene Kubernetes-APIs zu definieren, die mehrere Ressourcen – Kubernetes-native und AWS-Ressourcen via ACK – zu wiederverwendbaren Bausteinen zusammenfassen. Ein Entwickler-Team kann dann eine Datenbank-plus-Service-plus-IAM-Rolle als einzelne Custom Resource anfordern, ohne die darunterliegenden Details zu kennen. kro ist ein Subprojekt von Kubernetes SIG Cloud Provider und damit nicht AWS-exklusiv: Die Definitionen (ResourceGraphDefinitions) sind portabel, die AWS-Abhängigkeit liegt bei ACK, nicht bei kro selbst.

Was sich konkret ändert: Betrieb, Netzwerk, Authentifizierung

Wer von selbst verwaltetem Argo CD auf die EKS Capability umsteigt, sollte drei Unterschiede kennen, bevor er migriert.

Netzwerk: Die Capability kann über EKS Access Entries auf vollständig private EKS-Cluster zugreifen, ohne VPC Peering oder spezielle Netzwerkkonfiguration; IRSA oder Cross-Account-Rollen sind dafür nicht nötig. AWS verwaltet die Konnektivität zwischen der Argo-CD-Capability und privaten Remote-Clustern automatisch. Für Teams, die Argo CD heute in einem Multi-Account-Setup mit aufwändiger Netzwerkkonfiguration betreiben, ist das ein erheblicher Unterschied.

Authentifizierung: Die Capability unterstützt ausschließlich AWS IAM Identity Center als SSO-Provider. Wer heute einen anderen OIDC-Provider direkt in Argo CD konfiguriert hat, muss diesen über AWS Identity Center föderieren oder die Migration entsprechend planen. Die drei RBAC-Rollen (Admin, Editor, Viewer) sind fest vorgegeben; die Konfiguration erfolgt über den Parameter rbacRoleMapping, nicht über die argocd-rbac-cm ConfigMap.

Einschränkungen: Nicht verfügbar sind unter anderem Config Management Plugins (CMPs), der Notifications-Controller, UI-Extensions sowie der direkte Zugriff auf argocd-params und die meisten ConfigMap-Einstellungen. Der Sync-Timeout ist auf 120 Sekunden festgelegt und kann nicht geändert werden. In Custom Health Checks sind die Standard-Lua-Bibliotheken dauerhaft deaktiviert; Skripte, die davon abhängen, verhalten sich ggf. anders als im selbst verwalteten Setup. Als Deployment-Ziele werden nur EKS-Cluster unterstützt (per Cluster-ARN), und alle Application-, ApplicationSet- und AppProject-Ressourcen müssen in dem einen Namespace liegen, den Sie beim Anlegen der Capability festlegen. Wer heute stark angepasste Argo-CD-Konfigurationen betreibt, sollte die offizielle Vergleichsseite sorgfältig lesen, bevor er migriert. Bestehende Application- und ApplicationSet-Manifeste funktionieren im Kern weiter, weil die CRDs identisch mit Upstream Argo CD sind – die destination.server-Felder müssen Sie aber auf Cluster-Namen oder EKS-Cluster-ARNs umstellen.

Selbst verwaltete Lösungen und EKS Capabilities können im selben Cluster koexistieren. Wer schrittweise migriert, muss sicherstellen, dass jede Application nur von einer der beiden Instanzen verwaltet wird; der in der AWS-Dokumentation beschriebene Migrationspfad skaliert die selbst verwalteten Controller vor dem Umzug auf null Replicas, um Konflikte zu vermeiden.

EKS Capabilities vs. EKS Auto Mode: zwei Ebenen, eine Richtung

Die Frage kommt regelmäßig: Was ist der Unterschied zwischen EKS Auto Mode und EKS Capabilities – und brauche ich beides?

EKS Auto Mode adressiert die Datenebene: Node-Provisioning, Scaling, Patching, Load Balancing, Storage. Wer Auto Mode aktiviert, übergibt AWS die Verantwortung für die EC2-Instanzen, auf denen die Workloads laufen. EKS Capabilities adressieren die Controller-Ebene: die Platform-Werkzeuge, die auf dem Cluster laufen und Deployments, AWS-Ressourcen und Abstraktionen verwalten.

Beide Konzepte reduzieren operativen Aufwand, aber auf unterschiedlichen Schichten. Sie schließen sich nicht aus – im Gegenteil: Capabilities funktionieren mit jedem EKS-Compute-Typ, also auch mit Auto Mode, Managed Node Groups, selbst verwalteten Nodes oder Hybrid Nodes. Ein Cluster mit Auto Mode und aktivierten Capabilities hat weder selbst verwaltete Nodes noch selbst verwaltete Platform-Controller. Wer heute nur eines von beiden einsetzt, verliert nichts; wer beides kombiniert, reduziert den Betriebsaufwand auf beiden Ebenen gleichzeitig. Ergänzend zu den neueren Cluster-Mechanismen auf EKS: EKS Version Rollback: Kubernetes-Upgrades auf AWS endlich rückgängig machen.

Was es kostet – und wann es sich lohnt

EKS Capabilities werden nach zwei Komponenten abgerechnet: einem Grundpreis pro aktivierter Capability pro Stunde und einem Nutzungspreis pro verwalteter Ressource pro Stunde. Es gibt keine Mindestlaufzeit und keine Vorabkosten.

Konkret (Preise für US East, N. Virginia; andere Regionen können abweichen): Die Argo-CD-Capability kostet 0,03 USD pro Stunde als Grundpreis – das sind rund 21,90 USD pro Monat. Dazu kommen 0,0015 USD pro Argo-CD-Application pro Stunde, wobei jede Application pro Ziel-Cluster gezählt wird und jede von einem ApplicationSet generierte Application einzeln zählt. Bei 100 Applications ergibt das weitere 109,50 USD pro Monat, insgesamt also rund 131,40 USD. Die ACK-Capability und die kro-Capability haben jeweils einen Grundpreis von 0,005 USD pro Stunde (rund 3,65 USD/Monat), zuzüglich 0,00005 USD pro verwalteter ACK-Ressource bzw. kro-RGD-Instanz pro Stunde. Das AWS-Preisbeispiel mit 100 Applications, 1.000 ACK-Ressourcen und 1.000 kro-Instanzen kommt damit auf rund 211,70 USD pro Monat. Die aktuellen Preise sind auf der AWS EKS Pricing-Seite veröffentlicht.

Ob sich das lohnt, hängt davon ab, was das Team heute für den Betrieb der selbst verwalteten Alternativen aufwendet. Ein AWS-Referenzbeispiel für eine vollständige Deployment-Guidance mit zwei Clustern, allen drei Capabilities, einer EC2-Instanz, Load Balancern, ElastiCache und weiteren Services kommt auf rund 500 USD pro Monat (Stand März 2026, us-east-1) – wobei der Capability-Anteil (Argo CD, ACK, kro) dabei nur etwa 32 USD ausmacht. Der Löwenanteil sind Cluster-Gebühren, ElastiCache, Netzwerk und Monitoring, die unabhängig von den Capabilities anfallen.

Die eigentliche Frage ist nicht, ob diese Beträge für verwaltete Controller günstig sind. Die Frage ist, wie viele Stunden das Platform-Team heute damit verbringt, Argo-CD-Upgrades zu koordinieren, Multi-Cluster-Netzwerke zu debuggen und Controller-Versionen zu pflegen – und was diese Zeit kostet. Für Teams mit einem Cluster und einem dedizierten Platform-Engineer, der Argo CD gut kennt, ist der Mehrwert gering. Für Teams mit fünf oder mehr Clustern über mehrere AWS-Accounts, die keinen dedizierten Argo-CD-Spezialisten haben, ist er erheblich.

Was Sie jetzt tun können

EKS Capabilities lässt sich auf einem bestehenden Cluster aktivieren, ohne die laufenden Workloads zu unterbrechen. Eine Migration von selbst verwaltetem Argo CD kann schrittweise erfolgen, weil beide Varianten im selben Cluster koexistieren können – solange jede Application nur von einer Instanz verwaltet wird. Ein sinnvoller Einstieg: Aktivieren Sie die Argo-CD-Capability zunächst auf einem Nicht-Produktions-Cluster, migrieren Sie eine einzelne Application und vergleichen Sie das Betriebsbild mit dem bisherigen Setup.

Wenn Sie mehrere EKS-Cluster betreiben und sich fragen, welche Kombination aus Auto Mode, Capabilities und selbst verwalteten Komponenten für Ihre Situation die richtige ist, sprechen Sie uns an. Die Antwort hängt von Ihrer Cluster-Anzahl, Ihrem Team-Setup und Ihren Compliance-Anforderungen ab – und die lassen sich nicht aus einer Pricing-Tabelle ablesen.

Zur Beobachtbarkeit von EKS-Clustern siehe außerdem unseren Beitrag zu Amazon CloudWatch Omni.