The upgrade story for EKS 1.36 isn't just a version bump — it's a test-automation pivot. AWS shipped Kubernetes 1.36 support across all regions (including GovCloud) and published Upgrade Insights guidance that turns an always-on analysis engine into the recommended preflight for cluster upgrades.
That matters because AWS didn't just drop images; EKS Distro images and artifacts for 1.36 are published to the ECR Public Gallery and to the EKS Distro GitHub repo's releases, and AWS's lifecycle docs continue to define supported Kubernetes minor versions with standard and extended support windows. In short: the clocks you plan around haven't changed, but the way AWS expects you to upgrade has.
Upgrade Insights is the interesting bit. It's a free, continuously running analysis that looks at API usage, resource types, and likely compatibility issues so you don't rely solely on manual smoke tests that miss API or resource deprecations. The containers blog frames Upgrade Insights as an "always-on" capability you should use to accelerate testing and verification — which is exactly how platform engineers should treat it: not optional telemetry, but the first gate in an automated upgrade pipeline.
AWS's operational pattern is explicit. The guidance lays out an automation stack built around scheduled EventBridge rules, small Lambda (or other serverless) handlers that call the EKS APIs, correlation with AWS Health events, and exporting findings into a developer workflow (for example a Git repo or issue tracker) to trigger CI jobs or canary rollouts. That combination is concise and practical: EventBridge for cadence, lightweight compute for orchestration and diffs, Upgrade Insights for compatibility signals, and your repo/CI for human-reviewed gating and rollouts.
This is the right call. The alternative has been teams writing bespoke compatibility test suites that rarely exercise edge-case API usage (CRDs, operator webhooks, admission flows), producing false confidence. Upgrade Insights gives a standardized signal set you can consume programmatically — fewer ad-hoc scripts, more auditable gates.
But two caveats. First, Upgrade Insights is a signal, not a silver bullet: it will catch API deprecations and surface resource-level risks, but it cannot execute your full integration test matrix against every operator or proprietary webhook. Teams must still wire real canaries and smoke tests into the pipeline. Second, automation introduces a new failure mode: if your EventBridge + Lambda logic blindly promotes clusters based on a green Upgrade Insights report, you can still roll forward into runtime failures under load. Treat the Insights output as a precondition, not an approval stamp.
Operational details you need in your checklist right now:
- Pin to the EKS platform line published for your account/region (platform version strings look like 1.
-eks- ). Track platform-line numbers from the EKS release notes rather than only upstream Kubernetes minor versions. - Use scheduled EventBridge rules to call a Lambda (or other runner) that fetches Upgrade Insights results and compares them to your policy (for example, deny upgrades if X critical API uses remain). Audit findings to a Git repo or ticketing system so engineers have a single source of truth.
- Keep upgrade windows in mind: follow the AWS lifecycle documentation for exact standard and extended support windows, and don't rely on extended support as a long-term safety net for drift-heavy clusters with many CRDs.
If you want a practical next step: add a nightly EventBridge job that records Upgrade Insights findings to a repo (PR with structured findings), trigger CI that runs a focused operator smoke-suite against a temporary 1.36 test cluster, and gate manual promotion for production clusters on both signals. That pattern gives you auditable evidence and avoids the "I thought it was fine" Slack meltdown the moment a control-plane change hits a critical operator.
AWS has given platform teams two pieces: images and opinionated automation patterns. Ignore one at your peril. Teams that adopt Upgrade Insights as a first-class artifact in their upgrade pipelines will shorten verification cycles and reduce surprise rollouts; teams that treat it as optional will keep rebuilding brittle test scaffolding. Expect this to become the baseline — if your upgrade playbook doesn't at least consume Upgrade Insights within weeks, you're doing it wrong.
Sources
- Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.36 (AWS News Blog)
- Amazon Elastic Kubernetes Service – AWS News Blog (Compute category feed entry for 1.36)
- Review release notes for Kubernetes versions on standard support in Amazon EKS
- Understand the Kubernetes version lifecycle on Amazon EKS
- Accelerate the testing and verification of Amazon EKS upgrades with Upgrade Insights
- Amazon EKS version lifecycle (endoflife.date, aligned with AWS version data)
- How to get notified when new EKS platform versions are available (AWS re:Post)