Great news… Amazon has launched EKS extended support so your clusters will now be fully supported for 26 months, instead of 14 months.
But extended support requires significant changes to your engineering and budget plans in 2024.
In this blog, I’ll highlight the top 5 changes that you should be aware of.
EKS extended support introduces a 6X increase in EKS usage fees.
Here is a high-level math of how much you will pay based on the size of your fleets:
Expect your EKS bill to be 6X higher starting April 2024, if your clusters are running an older Kubernetes version (i.e. a version falling outside of EKS standard support window).
EKS standard support is provided by Amazon for 14 months after a version’s release. EKS extended support for a Kubernetes version begins immediately after the end of standard support, and ends after the next 12 months. For example, standard support for version 1.24 in Amazon EKS already ended on January 31, 2024. EKS extended support for version 1.24 began on February 1, 2024 and will end on January 31, 2025.
The only way to avoid extended support is to upgrade your clusters.
5 versions have entered or will enter EKS extended support in 2024: 1.23, 1.24, 1.25, 1.26, 1.27. For in-place upgrades, you can’t skip versions when upgrading. So you are basically stuck with in-place upgrades, going +1 version bump on each cluster with each upgrade.
You have to compress 18 months of work into 6 months.
If you don’t upgrade even during the EKS extended support window, your clusters will be auto-upgraded to the next version. Auto-upgrades can happen at any time after the end of EKS extended support date and you won't receive any notification before the auto-upgrade.
Auto-upgrades will cause application disruptions as more than 10 APIs used by existing applications are removed as you upgrade from v1.23 to v1.28.
Past a certain point (usually one year), the Kubernetes community stops releasing common vulnerabilities and exposures (CVE) patches and discourages CVE submission for unsupported versions. This means that vulnerabilities specific to an older version of Kubernetes that you are running might not even be reported.
Your clusters can be exposed with no notice and no remediation options in the event of a vulnerability.
With the above 5 reasons in mind, you have to accept that your current Platform, DevOps, SRE teams will have to handle these changes as you won’t be able to hire and train more developers fast enough to tackle this problem in 2024.
Let Chkk make your upgrades 3X faster and 100% disruption-free.
Chkk has helped many customers with their Kubernetes upgrades. Upgrading Kubernetes clusters and add-ons is a complex, error-prone, and time-consuming process. Currently, teams spend weeks researching unknown dependencies and discovering incompatibilities, followed by extensive efforts to seek approvals, notify team members, and address API deprecations and removals with application teams. They then carefully execute upgrades across development, staging, and production environments to avoid disruptions.
Chkk creates a comprehensive and up-to-date upgrade technical specification for a cluster, its add-ons, and associated infrastructure components. The Preverified Upgrade Plan, contextualized to the current state, provides a detailed description of the changes, the reasons behind them, and the recommended upgrade path. It lists the current versions and configurations of the control plane, nodes, IAM roles, all add-ons, deprecated and removed APIs, and other application and cloud dependencies. It also suggests recommended versions and configurations, including relevant release notes and references back to the sources. This approach reduces research time by up to 75%, cutting down weeks of preparation work to days.
The Preverified Upgrade Plan also contains a detailed sequence of steps that standardizes the upgrade process and allows experts to delegate individual tasks. Chkk also verifies these steps on a digital twin of your infrastructure, executing the prescribed sequence to validate that the plan works as expected. Each step is accompanied by automated preflight and post-flight checks to validate the correctness and health of the system, de-risking the upgrade process. With Chkk, you perform timely and safe upgrades, resulting in better conformity, fewer incidents, lower operational loads, improved team productivity, and 1000s of hours saved in post-incident break-fix work.
Great news… Amazon has launched EKS extended support so your clusters will now be fully supported for 26 months, instead of 14 months.
But extended support requires significant changes to your engineering and budget plans in 2024.
In this blog, I’ll highlight the top 5 changes that you should be aware of.
EKS extended support introduces a 6X increase in EKS usage fees.
Here is a high-level math of how much you will pay based on the size of your fleets:
Expect your EKS bill to be 6X higher starting April 2024, if your clusters are running an older Kubernetes version (i.e. a version falling outside of EKS standard support window).
EKS standard support is provided by Amazon for 14 months after a version’s release. EKS extended support for a Kubernetes version begins immediately after the end of standard support, and ends after the next 12 months. For example, standard support for version 1.24 in Amazon EKS already ended on January 31, 2024. EKS extended support for version 1.24 began on February 1, 2024 and will end on January 31, 2025.
The only way to avoid extended support is to upgrade your clusters.
5 versions have entered or will enter EKS extended support in 2024: 1.23, 1.24, 1.25, 1.26, 1.27. For in-place upgrades, you can’t skip versions when upgrading. So you are basically stuck with in-place upgrades, going +1 version bump on each cluster with each upgrade.
You have to compress 18 months of work into 6 months.
If you don’t upgrade even during the EKS extended support window, your clusters will be auto-upgraded to the next version. Auto-upgrades can happen at any time after the end of EKS extended support date and you won't receive any notification before the auto-upgrade.
Auto-upgrades will cause application disruptions as more than 10 APIs used by existing applications are removed as you upgrade from v1.23 to v1.28.
Past a certain point (usually one year), the Kubernetes community stops releasing common vulnerabilities and exposures (CVE) patches and discourages CVE submission for unsupported versions. This means that vulnerabilities specific to an older version of Kubernetes that you are running might not even be reported.
Your clusters can be exposed with no notice and no remediation options in the event of a vulnerability.
With the above 5 reasons in mind, you have to accept that your current Platform, DevOps, SRE teams will have to handle these changes as you won’t be able to hire and train more developers fast enough to tackle this problem in 2024.
Let Chkk make your upgrades 3X faster and 100% disruption-free.
Chkk has helped many customers with their Kubernetes upgrades. Upgrading Kubernetes clusters and add-ons is a complex, error-prone, and time-consuming process. Currently, teams spend weeks researching unknown dependencies and discovering incompatibilities, followed by extensive efforts to seek approvals, notify team members, and address API deprecations and removals with application teams. They then carefully execute upgrades across development, staging, and production environments to avoid disruptions.
Chkk creates a comprehensive and up-to-date upgrade technical specification for a cluster, its add-ons, and associated infrastructure components. The Preverified Upgrade Plan, contextualized to the current state, provides a detailed description of the changes, the reasons behind them, and the recommended upgrade path. It lists the current versions and configurations of the control plane, nodes, IAM roles, all add-ons, deprecated and removed APIs, and other application and cloud dependencies. It also suggests recommended versions and configurations, including relevant release notes and references back to the sources. This approach reduces research time by up to 75%, cutting down weeks of preparation work to days.
The Preverified Upgrade Plan also contains a detailed sequence of steps that standardizes the upgrade process and allows experts to delegate individual tasks. Chkk also verifies these steps on a digital twin of your infrastructure, executing the prescribed sequence to validate that the plan works as expected. Each step is accompanied by automated preflight and post-flight checks to validate the correctness and health of the system, de-risking the upgrade process. With Chkk, you perform timely and safe upgrades, resulting in better conformity, fewer incidents, lower operational loads, improved team productivity, and 1000s of hours saved in post-incident break-fix work.
.png)
.png)
.png)
.png)
.jpg)
