TL;DR

• July 23, 2025: v1.30 moves from standard to extended support.
  
  
• July 24, 2025: v1.27 reaches end-of-life and at risk of being forced upgraded soon after.
  
  
• Extended‑support clusters cost 6× more ($0.60 vs $0.10 per cluster‑hour).
  If you’re still running 1.27—or even 1.30—prioritize your upgrade to avoid downtime and unexpected costs. 

EKS Users: Brace for a Double‑impact Week

This week is a big one for Amazon EKS users. EKS version 1.27 is officially reaching end-of-life (EOL) on July 24, 2025, and EKS version 1.30 has just entered Extended Support as of July 23, 2025. In practical terms, if you have EKS clusters on v1.30, you’ll now incur a 500% higher control plane cost (extended support surcharge) for those clusters. And if any clusters are still on v1.27, they are now out of support, meaning AWS may force upgrade them soon with no notice. 

Why EKS v1.30 Moving to Extended Support Matters

• 6× price hike – immediately. AWS bills clusters in Extended Support at $0.60 per cluster‑hour versus $0.10 in Standard Support—a 500 % increase.
  For a 100‑cluster fleet that’s an extra ≈ $438,000 per year in control‑plane fees alone.
  
  
• The clock is ticking. You now have 12 months to get off v1.30 before it, too, is forcibly upgraded.

Why EKS v1.27 EOL is High-Risk

• Auto‑upgrade threat. After tomorrow AWS can upgrade v1.27 clusters to v1.28 (or the oldest supported version) without notice, risking downtime and breaking changes. As per EKS release page, “Automatic updates can happen at any time after the end of extended support date. You won’t receive any notification before the update.”
  
  
• Security blind spot. Once EOL hits, community CVE patches for 1.27 stop flowing; zero‑day risk rises sharply.
  
  
• Billing doesn’t go away until you move. You keep paying the 6× surcharge until the moment the control plane lands on a standard support version.

What You Should Do This Week

1. Audit every cluster: confirm control‑plane and node versions, plus managed add‑on versions.
   
   
2. Prioritize upgrade paths:
   
   
   1. v1.27 → 1.28 immediately to escape EOL.
      
      
   2. v1.30 → 1.31 or newer within the next 6 months to avoid another surcharge cycle.
      
      
3. Schedule add‑on & workload validation for each hop (API removals, Helm charts, CRDs, admission‑webhooks, IAM roles).
   
   
4. Budget review: surface the new per‑cluster cost to finance and leadership; tie upgrade work to direct cost savings.

Chkk Can Help Accelerate and De-Risk Your EKS Upgrades

Upgrading Kubernetes clusters and add-ons involves weeks of research into compatibility, identifying API deprecations, scheduling downtime, and coordinating across teams – all before you even execute the upgrade itself. If you’re feeling the pressure from these EOL deadlines (and the hefty fees), Chkk can help.

Chkk has helped many EKS, GKE, and AKS customers speed up and streamline their Kubernetes upgrades. With Chkk’s Preverified Upgrade Plans, you get a comprehensive, up-to-date technical guide for your cluster’s upgrade – including a breakdown of all required changes, deprecated APIs, add-on updates, and the recommended target versions. 

Start for Free or Book a Demo to see how Chkk accelerates and derisks upgrades of clusters and OSS projects running on them (e.g. Istio, Postgres, Kafka, Keycloak, etc.).