--- title: Amazon EKS 1.36 Upgrades and Rollbacks: The 7-Day Safety Window description: EKS Kubernetes 1.36 is available with user namespaces GA and mutating admission policies. Since July 2026 you can roll back an in-place control-plane upgrade within 7 days at no extra charge — but only N→N-1, and Fargate or strict PDBs can block you. url: https://www.factualminds.com/blog/amazon-eks-1-36-upgrade-rollbacks-2026/ datePublished: 2026-08-03T00:00:00.000Z dateModified: 2026-08-03T00:00:00.000Z author: palaniappan-p category: Serverless & Containers tags: amazon-eks, kubernetes, eks-upgrade, devops, aws, containers --- # Amazon EKS 1.36 Upgrades and Rollbacks: The 7-Day Safety Window > EKS Kubernetes 1.36 is available with user namespaces GA and mutating admission policies. Since July 2026 you can roll back an in-place control-plane upgrade within 7 days at no extra charge — but only N→N-1, and Fargate or strict PDBs can block you. **August 3, 2026:** Amazon EKS ships **Kubernetes 1.36** as a supported version. Headline upstream features include **user namespaces (GA)**, **mutating admission policies**, and **in-place pod vertical scaling** — useful for multi-tenant isolation and tighter admission control, but only if your controllers and webhooks survive the version boundary. Since **July 2026**, EKS also ships **version rollback**: revert an in-place control-plane upgrade to the **previous minor** within **7 days**, **at no additional charge**. AWS preserves etcd state; workloads keep running. That changes the upgrade risk calculus — but only if you plan for constraints most teams discover on day six. Artifacts: [upgrade-rollback checklist](https://www.factualminds.com/examples/architecture-blog-2026/eks-1-36-upgrade-rollbacks/upgrade-rollback-checklist.md), [version-pin worksheet](https://www.factualminds.com/examples/architecture-blog-2026/eks-1-36-upgrade-rollbacks/version-pin-worksheet.md). > **Reproduce this** — Download the [checklist](https://www.factualminds.com/examples/architecture-blog-2026/eks-1-36-upgrade-rollbacks/upgrade-rollback-checklist.md) and [worksheet](https://www.factualminds.com/examples/architecture-blog-2026/eks-1-36-upgrade-rollbacks/version-pin-worksheet.md). Record upgrade completion UTC; deadline = **+168 hours**. Fill node/add-on pins before production upgrade. ## What changed in 1.36 — and who cares | Feature | Why it matters | Who breaks without planning | | --------------------------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------- | | **User namespaces (GA)** | Stronger pod-level isolation for multi-tenant SaaS | Teams running privileged pods or hostPath volumes expecting host UID mapping | | **Mutating admission policies** | CEL-driven mutation without webhook latency tax | Platforms with overlapping Validating/MutatingWebhookConfiguration chains | | **In-place pod vertical scaling** | Resize CPU/memory without restart for supported workloads | Batch jobs sized statically; HPA/VPA configs that assume recreate-only | This post is the **upgrade + rollback operating model**, not a feature tour. For ECS vs EKS placement, see the [container orchestration decision guide](/blog/aws-ecs-vs-eks-container-orchestration-decision-guide/). For control-plane billing during extended support, see [EKS pricing](/blog/amazon-eks-pricing-control-plane-addons-auto-mode/). ## The 7-day rollback contract (July 2026) AWS documents rollback in the [EKS user guide](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) and the [containers blog announcement](https://aws.amazon.com/blogs/containers/announcing-amazon-eks-rollback-for-safe-and-reliable-management-of-cluster-upgrades/). **Hard prerequisites (none bypassed by `--force`):** | Rule | Detail | | -------------------- | ---------------------------------------------------------------------------- | | **7-day window** | Initiate rollback within **7 days** of upgrade completing | | **In-place only** | Cluster must have been **upgraded** to current version — not created at 1.36 | | **N → N-1 only** | One minor step back (1.36 → 1.35), not 1.36 → 1.34 | | **Supported target** | Previous version still on EKS support calendar | | **ACTIVE cluster** | No concurrent update in flight | | **Extended support** | Roll back into extended N-1 → set upgrade policy **`EXTENDED`** first | **What rollback reverts:** API server version, control-plane components, platform version. **Auto Mode nodes** roll back automatically before the control plane. **What rollback does not revert:** etcd data, running pod specs, add-on versions (you manage separately), self-managed/MNG nodes (you align), Fargate kubelet versions (not supported — delete pods). ### Rollback vs forward-fix ``` Within 7 days AND kubelet skew fixable in < SLO budget? YES → Roll back control plane to N-1 (after node prep if needed) NO → Forward-fix (patch webhook, pin add-on, revert Helm) — clock keeps ticking Past 7 days? → Rollback closed — upgrade forward or rebuild cluster ``` Use the [version-pin worksheet](https://www.factualminds.com/examples/architecture-blog-2026/eks-1-36-upgrade-rollbacks/version-pin-worksheet.md) so on-call knows which side of this tree you are on without digging through Slack. ## Rollback Readiness insights vs `--force` After upgrade, EKS surfaces **`ROLLBACK_READINESS`** insights — API compatibility, kubelet/kube-proxy skew, add-on versions, and (Auto Mode) PDB / disruption budget checks. | Insight status | Rollback allowed? | | ----------------- | --------------------------------------------- | | PASSING / WARNING | Yes | | ERROR / UNKNOWN | Blocked until fixed, or bypass with `--force` | ```bash # Context: AWS CLI v2, cluster my-cluster, us-east-1, post-upgrade day 2 aws eks list-insights \ --cluster-name my-cluster \ --region us-east-1 \ --filter '{"categories":["ROLLBACK_READINESS"]}' ``` **Opinionated take:** We recommend baking the **control plane 24–72 hours** before recycling worker nodes to the new kubelet version. If you upgrade control plane **and** nodes in the same change window, you consume rollback optionality while skew checks and application errors are still surfacing. Rollback is a **safety net**, not a replacement for staging. > **What broke (pattern, not a cited client)** — Platform team upgraded control plane **and** managed node groups to **1.36** in one maintenance window. Day 3: mutating webhook timeouts against the new admission API shape. Rollback insight: MNG kubelet at **1.36**, control plane rollback to **1.35** blocked by **kubelet skew ERROR**. Required a node-group downgrade before control-plane rollback could start. **Lesson:** sequential upgrade (control plane → bake → nodes) keeps the 7-day window actionable. ## Node mode cheat sheet | Mode | Rollback prep | | ------------------------- | ------------------------------------------------------------ | | **EKS Auto Mode** | AWS handles node rollback before control plane | | **Managed node groups** | `update-nodegroup-version` to N-1 **before** control plane | | **Self-managed / hybrid** | You patch AMI/kubelet — plan runbook | | **Fargate** | Delete pods at current version or accept `--force` skew risk | Pair node drain with [Pod Disruption Budgets](/blog/kubernetes-pod-disruption-budgets-eks-zero-downtime/) — **`minAvailable: 100%`** on small replica counts blocked node downgrades in multiple rollback dry runs we documented in the checklist. ## Executing control-plane rollback After nodes match N-1 (or Auto Mode prep completes), initiate rollback: ```bash # Context: within 7-day window, cluster ACTIVE, target previous minor (example 1.35) aws eks update-cluster-version \ --name my-cluster \ --kubernetes-version 1.35 \ --region us-east-1 # Monitor until ACTIVE (~15–30 min typical) aws eks describe-cluster \ --name my-cluster \ --region us-east-1 \ --query 'cluster.{status:status,version:version,platformVersion:platformVersion}' ``` Add **`--force`** only with written risk acceptance — it skips insight gates, not prerequisites. After rollback, downgrade incompatible add-ons and re-run `aws eks start-insights-refresh` before declaring the cluster healthy. ## IaC timeouts vs the 7-day window Your Terraform or CloudFormation pipeline can **time out before** EKS rollback expires: | Tool | Typical apply timeout | EKS rollback window | | ------------------ | ------------------------- | ---------------------- | | **CloudFormation** | **36 hours** stack update | **168 hours (7 days)** | | **Terraform** | **24 hours** default | **168 hours (7 days)** | If IaC fails mid-upgrade but the cluster reaches ACTIVE, the rollback clock still runs. Keep a **manual CLI rollback** path in the runbook and sync IaC pins after rollback — otherwise the next apply re-upgrades you. ## Extended Support if you roll back Rolling from **1.36** back to **1.35** when **1.35** sits in extended support triggers the **$0.60/cluster-hour** all-in rate (~**$438/month** per cluster vs ~**$73/month** standard) until you upgrade forward again. Set **`EXTENDED`** upgrade policy before rollback; FinOps should treat rollback-to-extended as a ** deliberate cost trade** against prod outage. ## What to Do This Week 1. **Download artifacts** — [checklist](https://www.factualminds.com/examples/architecture-blog-2026/eks-1-36-upgrade-rollbacks/upgrade-rollback-checklist.md) + [worksheet](https://www.factualminds.com/examples/architecture-blog-2026/eks-1-36-upgrade-rollbacks/version-pin-worksheet.md); pre-fill add-on version rows for one pilot cluster. 2. **Upgrade staging first** — validate deprecated APIs and webhook chains against **1.36**; record upgrade UTC for deadline math. 3. **Production: control plane only** — wait **24–72h** bake; watch `ROLLBACK_READINESS` insights daily. 4. **Align nodes after bake** — MNG/self-managed per skew policy; Auto Mode after bake or let AWS handle on rollback. 5. **Document manual rollback** — CLI command + FinOps note for extended-support premium; do not rely on IaC timeout alone. ## What This Post Doesn't Cover - **Greenfield cluster creation at 1.36** — rollback unavailable; use cluster backup/restore patterns instead. - **Application-level rollback** — Helm releases, database migrations, and feature flags are your problem; EKS rollback does not revert them. - **Cross-account / multi-cluster fleet orchestration** — no opinion on Argo CD/Flux upgrade waves; see [GitOps on EKS](/blog/aws-gitops-eks-argocd-flux-2026/) for pipeline patterns. - **1.36 feature enablement runbooks** — user namespaces and mutating admission policies need separate hardening guides we have not benchmarked on FactualMinds infrastructure yet. **Sources:** [EKS rollback documentation](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html), [AWS rollback announcement](https://aws.amazon.com/blogs/containers/announcing-amazon-eks-rollback-for-safe-and-reliable-management-of-cluster-upgrades/), [EKS Kubernetes versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) — verify 1.36 availability in your region before scheduling. ## FAQ ### When can I roll back an EKS cluster after upgrading to 1.36? Only within 7 calendar days of completing an in-place minor-version upgrade, and only by one minor version (e.g. 1.36 → 1.35). The cluster must be ACTIVE, the previous version must still be supported on EKS, and the cluster must have been upgraded in-place — clusters created directly at 1.36 cannot roll back. Rollback is free; AWS reverts the control plane while preserving etcd data and running workloads. ### When should I NOT rely on EKS rollback instead of staging? Never treat rollback as a substitute for non-prod validation. Rollback does not undo bad Helm values, misconfigured webhooks, or application bugs — it only reverts the Kubernetes API server version. If more than 7 days pass, if you need to skip two minors (N→N-2), or if an EKS feature enabled at 1.36 is incompatible with 1.35, rollback is unavailable or fails regardless of --force. Staging on a clone cluster remains mandatory. ### What breaks rollback for Fargate workloads? EKS cannot automatically roll back Fargate pod kubelet versions. If Fargate pods run the same Kubernetes version as the upgraded control plane, Rollback Readiness insights report kubelet version skew as ERROR and block rollback. Workaround: delete Fargate pods before control-plane rollback and redeploy after, or use --force and accept undefined behavior until pods are replaced. ### Does --force bypass the 7-day rollback window? No. --force only bypasses Rollback Readiness insight checks (ERROR, WARNING, UNKNOWN). It does not override the 7-day deadline, the in-place upgrade requirement, the single-version (N→N-1) limit, incompatible EKS feature checks, or Auto Mode disruption controls (PDBs, do-not-disrupt annotations). Teams that --force without fixing skew often discover the failure mode after the rollback starts, not before. ### What happens to Extended Support billing if I roll back? If the previous version (N-1) is in extended support, you must set the cluster upgrade policy to EXTENDED before rollback succeeds. Extended Support bills $0.60/cluster-hour all-in (~$438/month per cluster) versus $0.10/hour (~$73/month) on standard support — a 6× control-plane multiplier. Rolling back from 1.36 into an extended 1.35 is cheaper than running broken prod, but FinOps should expect the premium until you upgrade forward again. ### Who rolls back worker nodes — AWS or me? Depends on node mode. EKS Auto Mode: AWS rolls back Auto Mode nodes automatically before the control plane. Managed node groups: you must call update-nodegroup-version to N-1 before control-plane rollback. Self-managed and hybrid nodes: you own AMI/kubelet alignment. Fargate: you delete and redeploy pods — AWS does not roll back Fargate kubelet versions. --- *Source: https://www.factualminds.com/blog/amazon-eks-1-36-upgrade-rollbacks-2026/*