<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Amazon EKS on Cloudkaramchari</title><link>https://www.cloudkaramchari.com/tags/amazon-eks/</link><description>Recent content in Amazon EKS on Cloudkaramchari</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>cloudkaramchari</copyright><lastBuildDate>Fri, 10 Jul 2026 00:00:00 +0530</lastBuildDate><atom:link href="https://www.cloudkaramchari.com/tags/amazon-eks/index.xml" rel="self" type="application/rss+xml"/><item><title>Amazon EKS Kubernetes Version Rollback: How to Undo a Bad Cluster Upgrade</title><link>https://www.cloudkaramchari.com/blog/amazon-eks-kubernetes-version-rollback-guide/</link><pubDate>Fri, 10 Jul 2026 00:00:00 +0530</pubDate><guid>https://www.cloudkaramchari.com/blog/amazon-eks-kubernetes-version-rollback-guide/</guid><description>
&lt;h1 id="amazon-eks-kubernetes-version-rollback-how-to-undo-a-bad-cluster-upgrade">Amazon EKS Kubernetes Version Rollback: How to Undo a Bad Cluster Upgrade&lt;/h1>
&lt;p>On July 1, 2026, AWS shipped something EKS operators have wanted for years: the ability to actually undo a Kubernetes control plane upgrade. Until now, &lt;code>aws eks update-cluster-version&lt;/code> was a one-way door — if you upgraded from 1.32 to 1.33 and something broke (a deprecated API your controller depends on, a webhook that stopped working, an add-on that silently regressed), your only real options were to fix forward or rebuild the cluster. Most teams dealt with this by over-investing in bake periods, staggered upgrade waves, and month-long sign-off processes before touching production.&lt;/p></description></item></channel></rss>