.png)
Extended Support fees are hitting home for Enterprise Platform Teams. Amazon EKS and Google GKE customers often ask us: Why are Extended Support fees so high?
Going beyond the sticker shock of the 6x premium for Extended Support, let’s go deeper into the underlying costs AWS and GCP are offloading as they maintain older versions of Kubernetes.
Extended Support differs from standard support by covering older Kubernetes versions that no longer receive mainstream updates, patches, and security fixes. This added layer of maintenance—often involving manual backporting and dependency testing—leads to significantly higher operational costs for providers like AWS EKS and Google GKE.
Kubernetes evolves rapidly; new releases often include API and architecture changes that don’t exist in older versions. Backporting a security fix from, say, v1.31 to v1.26 isn’t a simple cherry-pick – the code and APIs may have diverged. Moreover, patches may rely on modern frameworks or features that older versions lack. EKS and GCP engineers essentially rewrite fixes to fit the old codebase. This is like fitting a new engine into an old car – it requires expertise and careful modifications.
Older Kubernetes versions drag along outdated dependencies (e.g. older networking plugins, container runtimes). Over time, these underlying components also change architecturally. Ensuring a patch doesn’t break compatibility with an old CNI plugin adds significant overhead in development and testing. This dependency drift makes patching exponentially harder, because fixes might require updating components that the old Kubernetes version wasn’t designed to work with.
Most bug and security fixes require you to upgrade a component, and sometimes the whole cluster, to a newer version. But you often can’t simply bump a dependency in an old Kubernetes version without risking safety. To make matters worse, older versions of Kubernetes have different APIs and security defaults. So, if a critical bug is found in a core Kubernetes component, AWS and GCP have to either backport the fix or validate a newer version of the component with the older kube-apiserver – both paths are labor-intensive.
Compliance standards like PCI-DSS, HIPAA, SOC 2, and FedRAMP mandate timely security patches and upgrades. For example, PCI-DSS Requirement 6.2 requires installing critical security patches within 30 days of release. These rules don’t make exceptions for “legacy” software – running an out-of-support Kubernetes version can put you out of compliance overnight. With a cluster in Extended Support, cloud providers attempt to maintain compliance by continuing security updates, but the process becomes fraught with complexity. Every new patch must be applied in that 30-day window, which is an operational nightmare on an outdated version that might require extensive testing or even multiple attempts to get the fix right. The compliance burden thus shifts onto the cloud provider.
Software engineers hate backporting fixes to older versions because it’s an exercise in frustration. Instead of working on innovative improvements to Kubernetes, these engineers are forced to wrestle with deprecated APIs and brittle dependencies, often finding that a simple patch in a newer version breaks in unexpected ways on an older one. All of this pain and no support from the upstream Kubernetes community makes this work tedious and lonely. To make things worse, managers rarely celebrate backports the way they do for new features; fixing something in an old version isn’t glamorous, it’s just a necessary evil. At Amazon, we used to describe it as “fighting entropy” rather than creating something new, which makes it a deeply unsatisfying part of their job.
In my opinion, the 6x Extended Support fee isn’t just a cash grab from EKS and GKE teams; it's compensation for the real costs and risks described above. Both EKS and GKE would prefer customers upgrade regularly (for everyone’s benefit), but EKS extended support and GKE extended support are offered as a safety net – one that requires heavy lifting to sustain. The high fee also serves as a financial incentive to nudge organizations toward upgrading rather than comfortably stagnating on old versions.
If you’re struggling with Kubernetes upgrades, Chkk can help. We’ve enabled some of the world’s largest enterprises to successfully complete 4-5 EKS, GKE, and AKS upgrades per year—100% disruption-free—saving them millions in Extended Support fees and eliminating the risk of Forced Upgrades by cloud providers.
Extended Support fees are hitting home for Enterprise Platform Teams. Amazon EKS and Google GKE customers often ask us: Why are Extended Support fees so high?
Going beyond the sticker shock of the 6x premium for Extended Support, let’s go deeper into the underlying costs AWS and GCP are offloading as they maintain older versions of Kubernetes.
Extended Support differs from standard support by covering older Kubernetes versions that no longer receive mainstream updates, patches, and security fixes. This added layer of maintenance—often involving manual backporting and dependency testing—leads to significantly higher operational costs for providers like AWS EKS and Google GKE.
Kubernetes evolves rapidly; new releases often include API and architecture changes that don’t exist in older versions. Backporting a security fix from, say, v1.31 to v1.26 isn’t a simple cherry-pick – the code and APIs may have diverged. Moreover, patches may rely on modern frameworks or features that older versions lack. EKS and GCP engineers essentially rewrite fixes to fit the old codebase. This is like fitting a new engine into an old car – it requires expertise and careful modifications.
Older Kubernetes versions drag along outdated dependencies (e.g. older networking plugins, container runtimes). Over time, these underlying components also change architecturally. Ensuring a patch doesn’t break compatibility with an old CNI plugin adds significant overhead in development and testing. This dependency drift makes patching exponentially harder, because fixes might require updating components that the old Kubernetes version wasn’t designed to work with.
Most bug and security fixes require you to upgrade a component, and sometimes the whole cluster, to a newer version. But you often can’t simply bump a dependency in an old Kubernetes version without risking safety. To make matters worse, older versions of Kubernetes have different APIs and security defaults. So, if a critical bug is found in a core Kubernetes component, AWS and GCP have to either backport the fix or validate a newer version of the component with the older kube-apiserver – both paths are labor-intensive.
Compliance standards like PCI-DSS, HIPAA, SOC 2, and FedRAMP mandate timely security patches and upgrades. For example, PCI-DSS Requirement 6.2 requires installing critical security patches within 30 days of release. These rules don’t make exceptions for “legacy” software – running an out-of-support Kubernetes version can put you out of compliance overnight. With a cluster in Extended Support, cloud providers attempt to maintain compliance by continuing security updates, but the process becomes fraught with complexity. Every new patch must be applied in that 30-day window, which is an operational nightmare on an outdated version that might require extensive testing or even multiple attempts to get the fix right. The compliance burden thus shifts onto the cloud provider.
Software engineers hate backporting fixes to older versions because it’s an exercise in frustration. Instead of working on innovative improvements to Kubernetes, these engineers are forced to wrestle with deprecated APIs and brittle dependencies, often finding that a simple patch in a newer version breaks in unexpected ways on an older one. All of this pain and no support from the upstream Kubernetes community makes this work tedious and lonely. To make things worse, managers rarely celebrate backports the way they do for new features; fixing something in an old version isn’t glamorous, it’s just a necessary evil. At Amazon, we used to describe it as “fighting entropy” rather than creating something new, which makes it a deeply unsatisfying part of their job.
In my opinion, the 6x Extended Support fee isn’t just a cash grab from EKS and GKE teams; it's compensation for the real costs and risks described above. Both EKS and GKE would prefer customers upgrade regularly (for everyone’s benefit), but EKS extended support and GKE extended support are offered as a safety net – one that requires heavy lifting to sustain. The high fee also serves as a financial incentive to nudge organizations toward upgrading rather than comfortably stagnating on old versions.
If you’re struggling with Kubernetes upgrades, Chkk can help. We’ve enabled some of the world’s largest enterprises to successfully complete 4-5 EKS, GKE, and AKS upgrades per year—100% disruption-free—saving them millions in Extended Support fees and eliminating the risk of Forced Upgrades by cloud providers.
.png)
.png)
.png)
.jpg)
