AWS just made Kubernetes versioning an explicit line item on your bill. In their updated lifecycle table for EKS 1.30–1.36, AWS confirms two things that change how platform teams must operate: extended support is an opt‑in, billable mode (you must set the cluster upgrade policy to EXTENDED), and EKS Upgrade Insights evaluates a 30‑day rolling window of audit logs — meaning deprecated‑API flags can stick around for up to a month after you fix them.
For production clusters running constrained upgrade schedules (hello, enterprise clusters), extended support being a paid feature forces you to treat version policy as a first‑class configuration. It isn’t just about risk mitigation anymore; it’s about cost. If you leave a cluster on an older supported version past its standard support cutoff, you either accept the upgrade work or opt into extended support and pay. Newer versions follow their own standard and extended timelines — check the official EKS lifecycle table for exact end dates and pricing, and plan accordingly.
The 30‑day false‑positive trap
EKS Upgrade Insights inspects audit logs for deprecated API usage and surfaces upgrade blockers. Because it analyzes a rolling 30‑day window of activity, findings can remain visible for that window after you remediate the calls that generated them. In practice that means:
- CI/CD gates that block control‑plane upgrades on a zero‑finding policy may still fail for up to 30 days after remediation.
- Short‑term remediation sprints that assume instant clearing are likely to be noisy and could lead to unnecessary rollbacks.
Actionable approach: treat Upgrade Insights as a signal, not the single source of truth for gating upgrades. Bake the 30‑day window into your automation (for example, ignore findings older than X days when approving upgrades), or run your own deprecation scanners against manifests/Helm charts and resource inventories to get an immediate assessment. If you depend on Upgrade Insights alone, expect gaps between what you fixed and what the UI/API surfaces during that rolling window.
This change dovetails with broader ecosystem moves: some cluster and tooling projects are shifting supported defaults and deprecation timelines around these Kubernetes releases, so check individual tool release notes and align your lifecycle automation accordingly.
Lambda SnapStart and Bedrock — the operational context
AWS also nudged serverless and AI patterns this week. Lambda’s SnapStart improvements for Java were highlighted alongside recommendations to pair SnapStart with provisioned concurrency. That’s sensible: SnapStart reduces initialization cost by snapshotting the execution environment, while provisioned concurrency gives consistent tail latency. For JVM‑based, high‑throughput APIs, treat provisioned concurrency as the steady‑state predictor and SnapStart as a way to shrink cold starts and reduce JVM initialization variance.
On generative AI, Bedrock updates emphasize guardrails, model variants, and policy tooling. Production AI needs multi‑layer controls (IAM scoping, logging, prompt validation) rather than a single checkbox. Model selection, lineage, and prompt‑validation pipelines now belong in your platform playbook.
Opinion: AWS is forcing platform discipline — and that’s overdue
Making extended support opt‑in and billable is annoying, but it’s also the right call. The alternative is vendors quietly promising soft support while teams accumulate technical debt until a security or compliance event forces a costly emergency upgrade. By putting lifecycle choices on the configuration table (and the invoice), AWS makes version management operationally visible. Teams that ignore this will incur surprise billing and risk; teams that bake version policy into GitOps and cost dashboards will win.
If you run EKS at scale, treat cluster upgrade policy as a configuration you manage, not a checkbox you click once a year. Reconcile Upgrade Insights with your own scanners, add a 30‑day grace to gates, and include extended‑support choices in your runbook and cost forecasts. This week’s changes aren’t just new docs — they’re a reminder that Kubernetes lifecycle is now an architectural decision with real dollars and measurable operational consequences.
Sources
- Amazon EKS Kubernetes versions and lifecycle (updated table for 1.30–1.36)
- End-of-life schedule for Amazon EKS Kubernetes releases
- Update existing cluster to a new Kubernetes version on Amazon EKS
- EKS Upgrade Insights: False positives persist for 30 days after fixing deprecated APIs
- Zero downtime during AWS EKS version upgrade (AWS Builder pattern)