--- title: "EKS Version Rollback: Kubernetes-Upgrades auf AWS endlich rückgängig machen" description: EKS Version Rollback macht Kubernetes-Upgrades reversibel – 7 Tage, kein Aufpreis. Was zurückgesetzt wird, was nicht, und was das für Ihre Upgrade-Strategie bedeutet. image: https://dmoove.com/hubfs/blog/agent-images/eks-version-rollback-featured-040110.jpg --- [Zum Inhalt springen](https://dmoove.com/blog/eks-version-rollback-kubernetes-upgrade#main-content) [![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo.svg)](https://dmoove.com/) Menü - Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/amazon-quick-ki) - [Migration & DevOps](https://dmoove.com/migration-devops) - Lösungen - [GuardAudit](https://dmoove.com/dmoove-guardaudit) - [Cloud Kosten optimieren](https://dmoove.com/cloud-kosten-optimieren) - [EC2 Image Builder](https://dmoove.com/ec2-image-builder) - [Case Study](https://dmoove.com/case-study-kubernetes-cluster) - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) [Termin buchen](https://dmoove.com/meetings/yannick-tresch) 1. [Blog](https://dmoove.com/blog) 2. [Cloud Computing](https://dmoove.com/blog/tag/cloud-computing) Cloud Computing # EKS Version Rollback: Kubernetes-Upgrades auf AWS endlich rückgängig machen [Yannick Tresch](https://dmoove.com/blog/author/yannick-tresch) 16\. September 2026 · Min. Lesezeit ![Abstrakte Darstellung eines Rollback-Mechanismus: Ein kreisförmiger Pfeil bildet ein Sicherheitsnetz unter einem Cluster vernetzter Knoten – symbolisch für den EKS Version Rollback](https://dmoove.com/hs-fs/hubfs/blog/agent-images/eks-version-rollback-featured-040110.jpg?width=1200&height=750&name=eks-version-rollback-featured-040110.jpg) Wer einen Amazon-EKS-Cluster auf eine neue Kubernetes-Version aktualisiert hat, kannte bisher nur eine Richtung: vorwärts. Lief nach dem Upgrade ein Admission-Webhook nicht mehr, reagierte ein Controller auf die neue API anders als erwartet oder brach ein Add-on unter dem neuen kubelet zusammen, blieb als Ausweg entweder ein Support-Ticket oder der Neuaufbau des Clusters mit anschließender Workload-Migration. Seit dem 1. Juli 2026 gibt es eine dritte Option: den **EKS Version Rollback**. Innerhalb von sieben Tagen nach einem In-Place-Upgrade kann die Control Plane auf die vorherige Minor-Version zurückgesetzt werden – ohne Aufpreis, ohne Cluster-Neuaufbau. Dieser Artikel erklärt, was das Feature genau tut, wo seine Grenzen liegen und was es für eine sinnvolle Upgrade-Strategie bedeutet. ## Was der EKS Version Rollback zurücksetzt – und was nicht ![Schematische Darstellung der Rollback-Verantwortlichkeiten: AWS-verwaltete Control-Plane-Komponenten auf der einen Seite, vom Betreiber verwaltete Datenebene auf der anderen](https://dmoove.com/hubfs/blog/agent-images/eks-version-rollback-inline-040121.jpg) Der Rollback bewegt die von AWS verwaltete Control Plane von Version N zurück auf N-1. Laut [AWS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) werden dabei zurückgesetzt: - Die Kubernetes-API-Server-Version - Control-Plane-Komponenten und deren Konfiguration - Die Platform-Version (auf die aktuellste Platform-Version der vorherigen Kubernetes-Version) Ausdrücklich *nicht* zurückgesetzt werden: - **EKS-Add-ons** – deren Versionen bleiben unverändert und müssen separat verwaltet werden - **Managed Node Groups** – diese müssen vor dem Control-Plane-Rollback manuell auf N-1 zurückgesetzt werden - **Self-managed Nodes und Hybrid Nodes** – liegen vollständig in der Verantwortung des Betreibers - **Fargate-Pods** – für Fargate-Worker-Nodes wird kein automatisches Rollback unterstützt (dazu mehr im nächsten Abschnitt) - **Persistent Volumes und etcd-Daten** – alle Workload-Daten bleiben erhalten Das Shared-Responsibility-Modell gilt also auch hier: AWS übernimmt die Control Plane, der Betreiber ist für die Datenebene, Add-ons und Anwendungskompatibilität verantwortlich. Wer das vor dem ersten Rollback-Versuch nicht eingeplant hat, erlebt eine unangenehme Überraschung. ## Wie der Rollback-Prozess abläuft Bevor der eigentliche Rollback startet, prüft EKS automatisch die **Rollback Readiness Insights** – eine Reihe automatisierter Checks, die API-Kompatibilität, Version-Skew zwischen Control Plane und Nodes, Add-on-Kompatibilität und den allgemeinen Cluster-Zustand bewerten. Wer die Checks kennt und die Situation bereits eingeschätzt hat, kann sie mit dem Flag `--force` überspringen. Der Rollback-Befehl selbst ist identisch mit dem Upgrade-Befehl – nur mit der vorherigen Version als Ziel: ``` aws eks update-cluster-version \ --name my-cluster \ --kubernetes-version 1.34 \ --region eu-central-1 ``` Alternativ steht der EKS-Console-Workflow zur Verfügung: Cluster auswählen → Tab „Update history" → Rollback initiieren. ### EKS Auto Mode: vollständig automatisierter Node-Rollback Für Cluster, die im **EKS Auto Mode** betrieben werden, geht der Rollback einen Schritt weiter. EKS koordiniert dabei zuerst den Rollback der Worker-Nodes – gesteuert durch Karpenter und unter Berücksichtigung konfigurierter Pod-Disruption-Budgets – bevor die Control Plane zurückgesetzt wird. Der Cluster bleibt während des gesamten Prozesses im Status `ACTIVE` und bedient weiterhin Traffic. Laut [AWS-Ankündigung vom 1. Juli 2026](https://aws.amazon.com/blogs/aws/upgrade-amazon-eks-clusters-with-confidence-using-kubernetes-version-rollbacks/) dauerte der Control-Plane-Rollback in einem Demo-Cluster etwa 20 Minuten – vergleichbar mit einem normalen Upgrade. Wie lange der Prozess in der Praxis dauert, hängt von der Cluster-Größe und den konfigurierten Disruption-Budgets ab. ### Managed Node Groups: manueller Schritt zuerst Bei Clustern mit Managed Node Groups muss der Betreiber die Node Groups *vor* dem Control-Plane-Rollback auf die Zielversion zurücksetzen. Der Grund: Kubernetes erlaubt keine Worker-Nodes, die eine neuere Version als die Control Plane führen. Der entsprechende Befehl: ``` aws eks update-nodegroup-version \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --kubernetes-version 1.34 \ --region eu-central-1 ``` Das Node-Group-Update respektiert die konfigurierten Update-Einstellungen (`maxUnavailable`, Update-Strategie). ## Die Grenzen, die man kennen muss Der EKS Version Rollback ist ein nützliches Sicherheitsnetz – aber kein universelles Undo. Wer die folgenden Einschränkungen nicht kennt, riskiert, das Fenster zu verpassen oder in eine Situation zu geraten, in der der Rollback schlicht nicht möglich ist. **7-Tage-Fenster, hart begrenzt.** Das Rollback-Fenster beginnt mit dem Abschluss des Upgrades und endet nach sieben Tagen. Danach ist kein Rollback mehr möglich – weder mit noch ohne `--force`. Wer ein Upgrade am Freitagabend einspielt und erst am übernächsten Montag ein Problem bemerkt, hat möglicherweise noch Zeit. Wer zwei Wochen wartet, nicht mehr. **Nur eine Minor-Version zurück (N→N-1).** Multi-Version-Rollbacks werden nicht unterstützt. Wer von 1.33 auf 1.34 und dann auf 1.35 aktualisiert hat, kann nur auf 1.34 zurück, nicht auf 1.33. Außerdem muss der Cluster durch ein In-Place-Upgrade auf die aktuelle Version gekommen sein – ein Cluster, der von Anfang an auf Version N erstellt wurde, hat keinen Rollback-Pfad. **Kein Rollback nach automatischem Upgrade am Ende des Extended Support.** Wenn AWS einen Cluster am Ende des Extended-Support-Zeitraums automatisch aktualisiert, ist kein Rollback möglich. Wer hingegen am Ende des Standard-Supports automatisch aktualisiert wurde, kann zurückrollen – muss aber vorher die Upgrade-Policy auf `EXTENDED` setzen. **Fargate: kein automatisches Node-Rollback.** EKS kann Fargate-Pods nicht automatisch auf eine ältere kubelet-Version zurücksetzen. Laufen Fargate-Pods auf derselben Version wie die Control Plane, löst das nach dem Rollback einen `ERROR`-Status im kubelet-Version-Skew-Insight aus. Der empfohlene Workaround laut [AWS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html): betroffene Pods vor dem Control-Plane-Rollback löschen, damit sie nach dem Rollback mit der zurückgesetzten Version neu starten. **IaC-Timeouts.** Wer EKS-Cluster über Terraform oder CloudFormation verwaltet, sollte wissen, dass diese Tools eigene Client-seitige Timeouts haben, die kürzer sein können als das 7-Tage-Rollback-Fenster. Ein Rollback-Vorgang, der länger als das Tool-Timeout dauert, kann zu inkonsistenten IaC-Zuständen führen. Das ist kein Showstopper, aber ein Punkt, den man vor dem ersten Rollback in der Produktion durchdenken sollte. **EKS-Features, die nur auf der neuen Version verfügbar sind.** Hat man nach dem Upgrade ein Feature aktiviert, das auf der vorherigen Version nicht unterstützt wird, schlägt der Rollback fehl – und dieser Check lässt sich auch mit `--force` nicht umgehen. ## Was das für Ihre Upgrade-Strategie bedeutet Der EKS Version Rollback verändert die Risikorechnung bei Kubernetes-Upgrades – aber er ersetzt keine sorgfältige Vorbereitung. AWS selbst formuliert es in den [Best Practices](https://docs.aws.amazon.com/eks/latest/best-practices/rollback-cluster-upgrades.html) klar: „Rollback complements testing, it does not replace it." Konkret ergeben sich drei Konsequenzen für den Betrieb: **Blue/Green-Cluster als reinen Rollback-Mechanismus überdenken.** Wer bisher parallele Cluster hauptsächlich deshalb betrieben hat, um im Notfall auf die alte Version zurückwechseln zu können, kann diesen Ansatz für In-Place-Upgrades neu bewerten. Ein In-Place-Upgrade mit Rollback-Option kostet weniger Infrastruktur, behält denselben API-Endpunkt und OIDC-Provider und ist operativ einfacher – sofern die Einschränkungen des Rollback-Fensters akzeptabel sind. **Früher upgraden, statt Extended Support zu zahlen.** Extended Support kostet laut [AWS-Preisseite](https://aws.amazon.com/de/eks/pricing/) $0,60 pro Cluster und Stunde statt $0,10 im Standard-Support. Die Differenz von $0,50 pro Stunde summiert sich bei einem Cluster, der rund um die Uhr läuft, auf über $4.000 pro Jahr – und das pro Cluster, unabhängig von der Node-Anzahl. Das Rollback-Feature nimmt einen der häufigsten Gründe für verzögerte Upgrades weg: die Angst, nach dem Upgrade nicht mehr zurückzukönnen. Wer früher upgradet, bleibt im Standard-Support und spart die Mehrkosten. **Rollback als Sicherheitsnetz einplanen, nicht als Routine.** Das 7-Tage-Fenster ist für Probleme gedacht, die erst unter Produktionslast sichtbar werden – ein inkompatibler Webhook, ein Controller, der eine deprecated API noch aufruft, ein Node-Treiber, der gegen das neue kubelet bricht. Es ist kein Ersatz für Pre-Upgrade-Tests in einer Nicht-Produktionsumgebung und kein Backup-Mechanismus für Workload-Daten. ## Was Sie jetzt tun sollten Wenn Sie EKS-Cluster betreiben, sind drei Schritte sinnvoll: Prüfen Sie zunächst, welche Ihrer Cluster noch auf Versionen laufen, die sich im Extended Support befinden oder kurz davor stehen. Der Rollback macht das Upgrade-Risiko beherrschbarer – aber er ändert nichts daran, dass ein Upgrade auf eine Standard-Support-Version die günstigere Option ist. Testen Sie den Rollback-Prozess in einer Nicht-Produktionsumgebung, bevor Sie ihn in der Produktion brauchen. Das schließt den Node-Group-Rollback, die Add-on-Kompatibilitätsprüfung und – falls Sie Fargate nutzen – den Pod-Lösch-Workaround ein. Ein Rollback, den man noch nie durchgeführt hat, ist kein Sicherheitsnetz. Passen Sie Ihre Upgrade-Playbooks an: Das 7-Tage-Fenster sollte explizit als Bake-Period eingeplant sein, in der Monitoring-Dashboards, Admission-Webhooks und kritische Controller aktiv beobachtet werden. Wer das Fenster ungenutzt verstreichen lässt, hat den Vorteil des Features nicht genutzt. Wie Sie Ihre EKS-Cluster systematisch auf dem aktuellen Stand halten und dabei Breaking Changes sicher navigieren, beschreibt unser Artikel [Kubernetes v1.37 „Garhwal": Was EKS-Betreiber vor dem nächsten Upgrade wissen müssen](https://dmoove.com/blog/kubernetes-v1-37-garhwal-eks-upgrade-guide). Wer den Ingress-NGINX-Abkündigungspfad noch vor sich hat, findet in unserem Beitrag zur [Ingress-NGINX-Migration auf EKS und der Kubernetes Gateway API](https://dmoove.com/blog/ingress-nginx-migration-eks-gateway-api) eine strukturierte Anleitung. Yannick Tresch In diesem Artikel Fragen zu Ihrer Plattform? 30 Minuten, direkt mit dem Gründer. [Termin buchen](https://dmoove.com/meetings/yannick-tresch) Weiterlesen ## Weitere Artikel. - ### [![Schematische Darstellung eines kontinuierlichen Cloud-Analyse-Kreislaufs mit vernetzten Knoten und Dokumenten-Icons – symbolisiert den AWS Well-Architected Agent](https://dmoove.com/hs-fs/hubfs/blog/agent-images/aws-well-architected-agent-preview-featured-040119.png?width=800&height=500&name=aws-well-architected-agent-preview-featured-040119.png) Cloud Computing AWS Well-Architected Agent: Kontinuierliche Cloud-Optimierung statt jährlichem Review 24\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/aws-well-architected-agent-cloud-optimierung) - ### [![Serverrack mit geöffnetem Einschub, aus dem ein Netz gleichzeitiger HTTP-Verbindungen strömt – symbolisch für Lambda Web Functions und Multi-Concurrency](https://dmoove.com/hs-fs/hubfs/blog/agent-images/lambda-web-functions-serverless-http-featured-040109.png?width=800&height=500&name=lambda-web-functions-serverless-http-featured-040109.png) Cloud Computing Lambda Web Functions: AWS startet einen neuen Serverless-Typ für HTTP-Workloads 15\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/lambda-web-functions-serverless-http) - ### [![Kalenderseite mit dem 2. Dezember, umkreist in Rot, neben drei ineinandergreifenden Zahnrädern mit Schloss-Symbol – symbolisch für die EU AI Act Dezember 2026 Compliance-Fristen](https://dmoove.com/hs-fs/hubfs/blog/agent-images/eu-ai-act-dezember-2026-neue-verbote-featured-205033.png?width=800&height=500&name=eu-ai-act-dezember-2026-neue-verbote-featured-205033.png) Cloud Computing EU AI Act Dezember 2026: Zwei neue Verbote und eine Kennzeichnungspflicht – was Unternehmen jetzt tun müssen 13\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/eu-ai-act-dezember-2026-neue-verbote) ![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo-white.svg) DMoove Solutions GmbH Damaschkestraße 23 10711 Berlin Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/de/amazon-quick-ai-essentials) - [Migration & DevOps](https://dmoove.com/migration-devops) Unternehmen - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) - [Termin buchen](https://dmoove.com/meetings/yannick-tresch) - [LinkedIn](https://www.linkedin.com/company/dmoove) Rechtliches - [Impressum](https://dmoove.com/impressum) - [Datenschutz](https://dmoove.com/datenschutz) © 2026 DMoove Solutions GmbH ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Yannick Tresch", "url" : "https://dmoove.com/blog/author/yannick-tresch" }, "dateModified" : "2026-09-16T06:15:28.526Z", "datePublished" : "2026-09-16T06:15:28.000Z", "headline" : "EKS Version Rollback: Kubernetes-Upgrades auf AWS endlich rückgängig machen", "image" : [ "https://dmoove.com/hubfs/blog/agent-images/eks-version-rollback-featured-040110.jpg" ], "mainEntityOfPage" : { "@id" : "https://dmoove.com/blog/eks-version-rollback-kubernetes-upgrade", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://dmoove.com/hubfs/dmo_logo450.png" }, "name" : "DMoove Solutions GmbH" } } ``` ```json { "@context" : "https://schema.org", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://dmoove.com/blog", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/tag/cloud-computing", "name" : "Cloud Computing", "position" : 2 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/eks-version-rollback-kubernetes-upgrade", "name" : "EKS Version Rollback: Kubernetes-Upgrades auf AWS endlich rückgängig machen", "position" : 3 } ] } ```