Amazon EKS 1.36 Upgrades and Rollbacks: The 7-Day Safety Window

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, version-pin worksheet.

Reproduce this — Download the checklist and worksheet. Record upgrade completion UTC; deadline = +168 hours. Fill node/add-on pins before production upgrade.

What changed in 1.36 — and who cares

This post is the upgrade + rollback operating model, not a feature tour. For ECS vs EKS placement, see the container orchestration decision guide. For control-plane billing during extended support, see EKS pricing.

The 7-day rollback contract (July 2026)

AWS documents rollback in the EKS user guide and the containers blog announcement.

Hard prerequisites (none bypassed by --force):

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 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.

# 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

Pair node drain with Pod Disruption Budgets — 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:

# 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:

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 + worksheet; 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 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, AWS rollback announcement, EKS Kubernetes versions — verify 1.36 availability in your region before scheduling.