# EKS 1.36 Upgrade & Rollback Checklist (August 2026)

Use this **first-party checklist** before and after an in-place EKS minor-version upgrade.
Pair with [version-pin-worksheet.md](./version-pin-worksheet.md) to track deadlines.

**Sources:** [EKS rollback user guide](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html),
[AWS containers blog — EKS rollback](https://aws.amazon.com/blogs/containers/announcing-amazon-eks-rollback-for-safe-and-reliable-management-of-cluster-upgrades/).

## Stage 0 — Pre-upgrade gates (do not skip staging)

- [ ] Target version (e.g. **1.36**) validated in **non-prod** with real workloads, not smoke tests only
- [ ] Deprecated API audit clean (`pluto`, `kubent`, or EKS upgrade insights — zero **ERROR** for target version)
- [ ] Add-on compatibility matrix filled (VPC CNI, CoreDNS, kube-proxy, EBS CSI, ingress controller)
- [ ] **PodDisruptionBudgets** reviewed — overly strict PDBs block node drain during rollback prep ([PDB guide](/blog/kubernetes-pod-disruption-budgets-eks-zero-downtime/))
- [ ] Upgrade policy documented: `STANDARD` vs `EXTENDED` — rolling back into extended support requires **EXTENDED** policy first
- [ ] IaC timeout budget noted: **CloudFormation 36h**, **Terraform default 24h** — both shorter than EKS **7-day** rollback window; plan human rollback path outside IaC apply timeout

**Rollback trigger:** Production upgrade without staging sign-off → halt; rollback is not a substitute for pre-prod validation.

## Stage 1 — Upgrade day

- [ ] Record **upgrade completion timestamp (UTC)** in [version-pin-worksheet.md](./version-pin-worksheet.md)
- [ ] Compute **rollback deadline = upgrade time + 7 days** (calendar, not business days)
- [ ] Run in-place upgrade via console, CLI, or IaC — cluster must reach **ACTIVE**
- [ ] Capture `aws eks describe-cluster --query cluster.version` output in change ticket
- [ ] **Do not recycle worker nodes yet** — opinionated default: bake control plane **24–72 hours** before node AMI/kubelet alignment so rollback window stays usable

## Stage 2 — Post-upgrade bake (24–72h minimum)

- [ ] Review **Rollback Readiness** insights (`ROLLBACK_READINESS` category) — refresh if stale (>24h)
- [ ] Monitor application SLOs, admission webhook failures, CRD/controller errors
- [ ] Confirm no blocking **ERROR** insights you cannot explain (Fargate kubelet skew, incompatible add-ons)
- [ ] If bake passes: proceed to node group / Auto Mode alignment **or** stay on prior node version until bake completes

## Stage 3 — Node alignment (after bake)

| Node mode | Your action |
| --- | --- |
| **EKS Auto Mode** | AWS rolls back Auto Mode nodes automatically when control plane rollback starts — no manual node step |
| **Managed node groups** | Roll back MNG **before** control plane via `update-nodegroup-version` |
| **Self-managed / hybrid** | You own AMI/kubelet rollback — align to N-1 before control plane rollback |
| **Fargate** | Rollback **not supported** for Fargate worker kubelet version — delete/redeploy pods or accept `--force` risk |

## Stage 4 — Rollback decision (within 7 days)

Initiate rollback only if **all** hard prerequisites pass:

- [ ] Upgrade was **in-place** (cluster not created at current version)
- [ ] Rolling back **one minor only** (N → N-1, not N-2)
- [ ] Previous version still **supported** on EKS
- [ ] Cluster status **ACTIVE** (no other update in flight)
- [ ] Within **7 days** of upgrade completion
- [ ] If target N-1 is in **extended support**: upgrade policy set to **EXTENDED** first ($0.60/cluster-hour all-in per [EKS pricing](/blog/amazon-eks-pricing-control-plane-addons-auto-mode/))

### Insight review before rollback

- [ ] List insights: `aws eks list-insights --filter '{"categories":["ROLLBACK_READINESS"]}'`
- [ ] Resolve **ERROR** / **UNKNOWN** insights **or** document explicit `--force` acceptance (insight bypass only — does **not** bypass 7-day window, N→N-1, PDB, or Auto Mode disruption controls)

## Stage 5 — Execute rollback

```bash
# Context: EKS CLI v2, cluster ACTIVE, within 7-day window, target = previous minor (e.g. 1.35)
aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.35 \
  --region us-east-1
# Add --force only after written risk acceptance — bypasses insight checks, not prerequisites
```

- [ ] Monitor status: `UPDATING` → `ACTIVE` (typically ~15–30 min for control plane)
- [ ] Re-verify add-on versions compatible with rolled-back control plane
- [ ] Update IaC version pins to match live cluster (prevent drift re-upgrade)

## When NOT to rely on rollback

- Cluster was **created** at 1.36 (never upgraded in-place) — rollback unavailable
- **>7 days** since upgrade — window closed; forward-fix or rebuild
- You need **N-2** (skipped a version during upgrade chain) — only single-step rollback
- **End-of-extended-support auto-upgrade** cluster — rollback blocked to prior version
- EKS feature enabled on current version **incompatible** with N-1 — hard fail, even with `--force`
- Team treats rollback as **license to skip staging** — operational anti-pattern; rollback preserves etcd, not bad config

## Related posts

- [ECS vs EKS decision guide](/blog/aws-ecs-vs-eks-container-orchestration-decision-guide/)
- [EKS pricing & Extended Support](/blog/amazon-eks-pricing-control-plane-addons-auto-mode/)
- [Pod Disruption Budgets on EKS](/blog/kubernetes-pod-disruption-budgets-eks-zero-downtime/)