Kubernetes 1.34 reaches end of life upstream on 27 October. If you run a managed cluster on AWS, Google Cloud or Azure, that date almost certainly does not apply to you, and treating it as your deadline will either cost you money or leave you unsupported. The three providers run three different clocks, and more importantly, they fail in three different directions when you miss one.
The upstream date is a reference point, not a deadline
The Kubernetes project supports the three most recent minor releases and gives each roughly a year of patches. Right now that means 1.37, released in September, 1.36 and 1.35. Version 1.34 drops off the list on 27 October. Version 1.35 follows on 28 February 2027, and 1.36 on 28 June 2027.
Those dates govern what the project itself will patch. They are not what your bill or your support contract responds to, because every managed service layers its own window on top, and every one of those windows is longer than upstream and starts from a different day.
Three clocks, three failure modes
On Amazon EKS, every version gets 14 months of standard support from the day it lands on EKS, then 12 months of extended support. Version 1.34 arrived on EKS on 2 October 2025, so standard support runs until 2 December 2026, five weeks past the upstream date. Version 1.37 only became available on 1 October this year.
The part that catches people is what happens next. Extended support on EKS is enabled by default, and the price goes from $0.10 per cluster per hour to $0.60. That is roughly $73 a month per cluster becoming roughly $438. Nothing breaks, nothing needs approving, and no one has to click anything. The cluster keeps running and the invoice grows by six times.
Version 1.33 left standard support on EKS on 29 July. Anyone still sitting on it has been paying the higher rate for over two months. For a team with twenty clusters that is around $7,300 a month that nobody chose to spend.
Azure fails the other way. On AKS, community support runs about twelve months from general availability. Version 1.33 ended in July 2026 and 1.34 ends in November 2026. There is a further year of long term support available, but you have to be on the Premium tier and you have to turn it on yourself. Miss it and you do not get a surprise invoice. You get a cluster that is quietly out of support, which is worse, because an invoice at least shows up somewhere a human reads.
Google Cloud sits in between. GKE gives most versions around 16 months of standard support, with roughly another year available through the Extended release channel. Version 1.33 left standard support on 12 August 2026 and can run on the Extended channel until 12 June 2027. Version 1.34 has until 25 January 2027. As on Azure, the extension is a choice you make rather than one made for you.
The dates, side by side
Version | Upstream end of life | EKS standard support ends | GKE standard support ends | AKS community support ends |
|---|---|---|---|---|
1.33 | Passed | 29 Jul 2026 | 12 Aug 2026 | Jul 2026 |
1.34 | 27 Oct 2026 | 2 Dec 2026 | 25 Jan 2027 | Nov 2026 |
1.35 | 28 Feb 2027 | 27 Mar 2027 | 11 Apr 2027 | Mar 2027 |
1.36 | 28 Jun 2027 | 2 Aug 2027 | 9 Aug 2027 | Jun 2027 |
1.37 | 28 Oct 2027 | 1 Dec 2027 | Q4 2027 | Oct 2027 |
Why the gap exists at all
None of this is a trick. The providers extend support because upgrading a production cluster is genuinely hard and a year is genuinely not long enough for a large estate. The extension is a reasonable product.
The problem is that the three of them made opposite decisions about the default. AWS decided that nobody should ever lose patches, so it keeps you supported and charges you. Azure and Google decided that nobody should ever be billed for something they did not ask for, so they stop and wait for you. Both are defensible. Neither is what a team running clusters on more than one provider expects, and the mixed estate is where this bites hardest, because the same month of inattention produces an unexpected invoice in one account and an unsupported cluster in another.
What to check this week
This takes about ten minutes and is worth doing before the 27 October noise starts.
List every cluster you own and its version. Not the ones you remember. The ones that exist, including whatever was stood up for a demo in March and never removed.
On AWS, look at your last two EKS invoices and compare the per cluster charge against $0.10 per hour. If any cluster is at $0.60, it is on extended support and has been for a while.
On Azure, check which clusters are on the Premium tier with long term support turned on. Any 1.33 cluster without it is already unsupported.
On Google Cloud, check which release channel each cluster sits in, and whether the ones on older versions are on the Extended channel or just drifting.
Write the provider dates into whatever calendar your team actually looks at, not the upstream ones.
The upgrade itself is the hard part and no article is going to make it easier. But knowing which of the three deadlines applies to you, and whether missing it sends you a bill or quietly removes your patches, is the cheapest hour of work available this month.
Our September hiring report found Kubernetes named in a large share of infrastructure postings, which is a reasonable proxy for how many teams are now carrying this calendar whether they planned to or not.
Sources: the Kubernetes release page, the Amazon EKS version lifecycle and pricing documentation, the GKE release schedule, and the AKS supported versions calendar. All dates checked on 3 October 2026.
