EKS Optimize EOL Version

Amazon EKS clusters running end-of-life (EOL) Kubernetes versions face increased security risks and incur substantial extended support charges. This Finder identifies EKS clusters approaching or already in the extended support phase, allowing organizations to proactively plan version upgrades and avoid paying 6x higher hourly rates for outdated Kubernetes versions. By upgrading these clusters to current, supported versions, you can significantly reduce costs while improving your security posture.

Overview

Problem Statement

Amazon EKS follows the Kubernetes release cycle, with each version receiving standard support for 14 months after release, followed by an optional 12-month extended support period. Clusters running in extended support incur significantly higher costs: $0.60 per hour versus the standard $0.10 per hour rate, a 6x increase. Additionally, these outdated clusters no longer receive upstream security patches, potentially leaving your workloads vulnerable to known exploits.

Organizations often delay Kubernetes upgrades due to operational concerns, compatibility issues, or simply lacking awareness of version EOL timelines. Without proper planning, this leads to unexpected cost increases and security risks across their container ecosystem.

Solution

The EKS Optimize EOL Version Finder identifies EKS clusters running Kubernetes versions that are approaching end-of-life, highlighting those that have already entered or will soon enter the extended support phase. This advance warning provides organizations sufficient time to plan and execute upgrades to avoid the 6x price increase and security vulnerabilities associated with outdated versions.

Unlike most CloudFix Fixers, this optimization requires manual upgrades due to the complex nature of Kubernetes version migrations. However, the Finder provides all the information needed to prioritize and plan these upgrades effectively.

Benefits

By implementing this Finder’s recommendations, you can:

• Avoid the 6x cost increase ($0.60/hour vs. $0.10/hour) for extended support
• Improve security by running Kubernetes versions that receive regular security patches
• Gain access to newer Kubernetes features and improvements
• Proactively plan version upgrades before entering extended support
• Maintain compliance with security policies requiring up-to-date software

AWS Services Affected

Amazon EKS

How It Works

Finder Component

The Finder works read-only from your cost and usage data and your EKS cluster configuration, comparing each cluster’s Kubernetes version against the published AWS version lifecycle calendar. Clusters that are approaching or already in extended support appear in your CloudFix Recommendations with their current version, a target version, how close they are to end-of-life, and the potential cost savings, so you can decide which clusters to upgrade first.

Upgrade Process

While CloudFix does not automatically implement EKS version upgrades due to their complexity, organizations should follow these best practices when upgrading identified clusters:

1. Preparation Phase
   • Audit applications for deprecated API usage using tools like Kube No Trouble (kubent)
   • Update application manifests to use current API versions
   • Check compatibility of all cluster add-ons with the target Kubernetes version
   • Test the upgrade process in a non-production environment
2. Control Plane Upgrade
   • Initiate the control plane upgrade through the AWS Console or CLI
   • Monitor the upgrade progress through the EKS console or AWS CLI
   • Verify API server functionality after the upgrade completes
3. Data Plane Upgrade
   • Update managed node groups to match the new Kubernetes version
   • For self-managed nodes, create new node groups with the updated AMI version
   • Cordon and drain old nodes to migrate workloads to the new nodes
   • Verify application functionality on the upgraded node groups
4. Add-on Updates
   • Update all EKS add-ons (e.g., CoreDNS, kube-proxy, VPC CNI) to versions compatible with the new Kubernetes version
   • Update any self-managed add-ons following vendor recommendations

Remember that Kubernetes upgrades should be performed one minor version at a time (e.g., 1.23 → 1.24 → 1.25) for clusters that are multiple versions behind.

FAQ

What is the Kubernetes version lifecycle in Amazon EKS?

Amazon EKS provides a 14-month standard support period for each Kubernetes version, during which the hourly cluster cost is $0.10. After that, clusters enter a 12-month extended support period at $0.60 per hour (a 6x increase). Once a version reaches 26 months since release, it is no longer supported, and AWS may forcibly upgrade the control plane to a supported version.

Can CloudFix automatically upgrade my EKS clusters?

No, this is a Finder-only feature. EKS cluster upgrades require careful planning, testing, and execution to avoid application disruptions. CloudFix identifies clusters that need attention, but you must perform the upgrades manually following AWS best practices.

What costs are associated with running EKS clusters in extended support?

Clusters in extended support are charged $0.60 per hour instead of the standard $0.10 per hour rate. For a cluster running 24/7 over a full year, this represents an increase from $876 to $5,256 annually, a difference of $4,380 per cluster.

Will upgrading my EKS cluster cause downtime?

The control plane upgrade may cause brief API server interruptions, but normally doesn’t impact running workloads. The node upgrade process, however, requires careful planning to minimize disruption. AWS recommends using managed node groups and blue/green deployment strategies to reduce potential downtime.

What should I do if my applications use deprecated Kubernetes APIs?

Before upgrading, scan your cluster using tools like Kube No Trouble (kubent) to identify resources using deprecated APIs. Update these resources to use supported API versions for the target Kubernetes version. The Kubernetes documentation provides migration guides for each deprecated API.

How far ahead should I plan EKS version upgrades?

AWS recommends planning upgrades at least 2-3 months before a version enters extended support. This provides adequate time for testing, addressing compatibility issues, and implementing a phased upgrade approach. The EKS Optimize EOL Version Finder helps by identifying clusters well before they reach EOL.

Do I need to upgrade my node groups after upgrading the EKS control plane?

Yes. While the control plane and nodes can temporarily run different versions, AWS recommends keeping them aligned. Kubernetes supports nodes running up to two minor versions older than the control plane, but not newer versions. For optimal performance and security, update your node groups to match the control plane version.

Related Resources

• Optimize EKS Clusters Running End-of-Life Kubernetes Versions
• Amazon EKS Kubernetes versions
• Updating an Amazon EKS cluster Kubernetes version
• Amazon EKS Extended Support for Kubernetes Versions Pricing

---

Is your organization running EKS clusters on deprecated Kubernetes versions? You could be paying 6x more than necessary for cluster management while exposing your workloads to security risks.

Amazon EKS follows Kubernetes’ rapid evolution cycle, with new minor versions released approximately every four months. Each version receives 14 months of standard support at $0.10 per hour, followed by a 12-month extended support period at $0.60 per hour, a sixfold increase in the per-cluster rate.

In this comprehensive guide, we’ll walk you through everything you need to know about EKS end-of-life migrations, from understanding the version lifecycle to implementing automated upgrade strategies with CloudFix.

Understanding the EKS Version Lifecycle

Amazon EKS implements a structured lifecycle policy for Kubernetes versions designed to balance innovation with stability. Understanding this lifecycle is crucial for effective cluster management and cost optimization.

Standard Support Period

When a new Kubernetes minor version becomes available in Amazon EKS, it enters a 14-month standard support period. During this time:

• Cost: $0.10 per cluster per hour
• Security: Regular security patches and updates from the Kubernetes community
• Features: Access to all generally available Kubernetes features
• Support: Full AWS technical support

Currently, the following Kubernetes versions are in standard support:
– 1.36 (Released June 2, 2026)
– 1.35 (Released January 27, 2026)
– 1.34 (Released October 2, 2025)
– 1.33 (Released May 29, 2025)

Extended Support Period

After standard support ends, versions automatically enter a 12-month extended support period at an increased cost:

• Cost: $0.60 per cluster per hour (6× increase)
• Security: Critical security patches only
• Features: Limited to essential components
• Auto-upgrade: At the end of extended support, AWS may forcibly upgrade your control plane

Extended support versions currently available:
– 1.32 (Extended support ends March 23, 2027)
– 1.31 (Extended support ends November 26, 2026)
– 1.30 (Extended support ends July 23, 2026)

Version Timeline Table

Note: Extended support costs apply starting the day after standard support ends

Current EKS Versions Approaching End-of-Life

As of June 2026, several EKS versions require immediate attention:

🚨 Critical: EKS 1.33

• End of Standard Support: July 29, 2026 (6 weeks away)
• Cost Impact: Will enter extended support at $0.60/hour
• Action Required: Plan upgrade to 1.34 or 1.35

⚠️ High Priority: EKS 1.32

• End of Standard Support: March 23, 2026 (Already in extended support)
• Cost Impact: Currently paying $0.60/hour
• Action Required: Upgrade immediately to avoid continued overpayment

📅 Medium Priority: EKS 1.31

• End of Extended Support: November 26, 2026
• Status: In extended support until November 2026
• Action Required: Plan upgrade before extended support ends

The financial impact of delayed upgrades is significant. A single cluster running 24/7 in extended support costs an additional $4,380 per year compared to standard support.

Step-by-Step EKS Upgrade Paths

Upgrading EKS clusters requires careful planning and execution. Follow these proven methodologies to ensure smooth upgrades with minimal disruption.

Prerequisites

Before beginning any upgrade:

1. Audit Your Applications: Check for deprecated API usage with a tool such as Kube No Trouble (kubent), targeting the Kubernetes version you plan to move to.
2. Validate Cluster Health: Confirm the cluster and its API server are healthy before you start.
3. Review Upgrade Insights: In the Amazon EKS console, open your cluster’s Upgrade Insights and address any flagged issues before proceeding.

Method 1: Using eksctl (Recommended)

eksctl provides a streamlined approach to EKS upgrades with built-in validation. Make sure you are on a current eksctl release, upgrade the control plane to the next minor version, then update your managed node groups to the same Kubernetes version. For self-managed nodes, create new node groups on the new version and move workloads across.

Method 2: Using AWS CLI

For automation or integration with CI/CD pipelines, the AWS CLI lets you start the control plane version update, monitor its progress until it completes, and then roll your worker nodes onto an AMI for the new Kubernetes version (for example, by publishing a new launch template version for your Auto Scaling groups).

Method 3: Using AWS Console

For teams preferring graphical interfaces:

1. Navigate to Amazon EKS Console
2. Select your cluster
3. Click “Upgrade now”
4. Choose the target version
5. Review upgrade details and click “Upgrade”

Common Pitfalls During EKS Upgrades

Even experienced teams encounter challenges during EKS upgrades. Here are the most common pitfalls and how to avoid them.

1. Skipping Version Validation

Problem: Upgrading without checking for deprecated API usage or add-on compatibility.

Solution: Scan for deprecated APIs against the target version and confirm each add-on has a compatible version available before you start.

2. Forgetting Node Group Updates

Problem: Upgrading the control plane but leaving nodes on the old version.

Impact:
– Version skew issues
– Potential node instability
– Security vulnerabilities

Solution: After the control plane upgrade, check that every node reports the new Kubernetes version.

3. Underestimating Downtime

Problem: Assuming upgrades are zero-downtime operations.

Reality:
– Control plane upgrades: Brief API interruptions (30-60 seconds)
– Node upgrades: Requires cordon/drain operations

Best Practice: Use rolling updates protected by Pod disruption budgets so workloads stay available while nodes are replaced.

4. Ignoring Add-on Updates

Problem: CoreDNS, kube-proxy, and VPC CNI must be updated to match the new Kubernetes version.

Solution: Update each EKS add-on to the version AWS lists as compatible with your new Kubernetes version.

5. Poor Rollback Strategy

Problem: Having no plan to revert if upgrades fail.

Preparation: A control plane upgrade cannot be rolled back, so back up your cluster configuration and workload manifests first and test the upgrade in a non-production environment.

6. Network Configuration Issues

Problem: Upgrade fails due to insufficient IP addresses or security group misconfigurations.

Pre-check: Confirm the cluster’s subnets have enough free IP addresses and that security groups still allow the required traffic.

Automating EKS Lifecycle Management with CloudFix

Managing EKS version upgrades across multiple clusters can be challenging. CloudFix provides automated detection and prioritization to streamline your EKS lifecycle management.

How CloudFix EKS Optimize EOL Version Works

CloudFix’s EKS End-of-Life Optimization works read-only from your cost and usage data and your cluster configuration to find clusters running versions that are approaching or past end of standard support. Each cluster appears in your CloudFix Recommendations with a target upgrade version, its cost impact and a timeline-based priority. Because Kubernetes upgrades need application testing, you perform the upgrade yourself using the approaches above.

Key Benefits

• Cost Avoidance: Eliminate the 6x premium for extended support
• Security Improvement: Access to current security patches
• Feature Adoption: Leverage new Kubernetes capabilities
• Proactive Planning: Identify issues well in advance

Cost Implications of Running Deprecated EKS Versions

The financial impact of delayed EKS upgrades extends far beyond the obvious 6x hourly rate increase.

Direct Cost Impact

Hidden Costs of Extended Support

1. Security Overhead
2. Dedicated security team hours for vulnerability scanning
3. Emergency patching for unpatched vulnerabilities

4. Compliance audit remediation

5. Operational Complexity

6. Limited access to new features
7. Increased troubleshooting time

8. Additional monitoring requirements

9. Performance Degradation

10. Older Kubernetes versions lack performance optimizations
11. No access to container runtime improvements
12. Reduced efficiency compared to newer versions

Cost Optimization Strategies

1. Proactive Upgrade Planning
2. Schedule upgrades during standard support

3. Avoid extended support premiums entirely

4. Batch Processing

5. Group clusters by version

6. Leverage automation for multiple upgrades

7. Phased Rollouts

8. Staging environment testing first
9. Progressive deployment to production

ROI of Timely Upgrades

The extended support premium applies to every cluster, every hour, so it scales with the size of your fleet: upgrading on time removes it across the board. Staying on supported versions also keeps clusters on the releases that receive regular security patches, and spares your team the emergency upgrades that tend to follow an end-of-life date.

FAQ: EKS End-of-Life Migration

Q: How far in advance should I plan EKS upgrades?

A: Plan at least 2-3 months before a version enters extended support. This provides time for:
– Testing in non-production environments
– Addressing application compatibility issues
– Scheduling maintenance windows
– Training teams on new features

Q: Will upgrading my EKS cluster cause application downtime?

A:
– Control plane upgrade: May cause 30-60 second API interruptions
– Node upgrade: Requires careful planning with cordon/drain
– Best practice: Use rolling updates and blue/green deployments

Q: Can I skip versions during EKS upgrades?

A: Yes, but with limitations. Kubernetes allows upgrades up to three minor versions at once:

Plan for a sequence of upgrades when a cluster is several versions behind (for example, 1.30 to 1.31 to 1.32 to 1.33), testing at each step.

Q: What happens if I don’t upgrade before extended support ends?

A:
1. AWS automatically enrolls your cluster in extended support
2. You pay the $0.60/hour rate
3. Your cluster may be forcibly upgraded at the end of extended support
4. You lose control over the upgrade timing

Q: How do I handle applications using deprecated Kubernetes APIs?

A:
1. Use tools like kube-no-trouble to identify deprecated APIs
2. Update application manifests to use current API versions
3. Test in staging before production changes
4. Vendor-specific deprecation notices may require application updates

Q: Are there any costs associated with EKS upgrades?

A:
– Direct costs: No additional charges for standard support upgrades
– Indirect costs: May require temporary worker nodes during cordon/drain
– Extended support: $0.60/hour applies when using older versions

Pro Tip: CloudFix automatically detects EKS clusters approaching end-of-life and creates prioritized upgrade plans. We handle the complex coordination across accounts while you focus on feature development.

Automate your EKS lifecycle management →

Q: How do I upgrade Fargate nodes?

A: Fargate nodes are automatically updated when you delete and redeploy Pods: once the control plane is upgraded, recreate the Pods (or redeploy their manifests) and they come back on the new version.

Q: What’s the impact on AWS service integrations during upgrades?

A: Most AWS services remain compatible, but verify:
– ALB Ingress Controller versions
– CloudWatch agent compatibility
– AWS Load Balancer Controller
– EBS CSI driver versions

Conclusion: Proactive EKS Lifecycle Management

Managing EKS end-of-life cycles is not just about cost optimization. It’s about security, operational efficiency, and maintaining access to the latest Kubernetes innovations.

By implementing the strategies outlined in this guide and leveraging tools like CloudFix for automated detection, your organization can:

1. Eliminate unnecessary costs by avoiding extended support premiums
2. Enhance security by staying current with security patches
3. Improve operational efficiency with streamlined upgrade processes
4. Maintain compliance with security policies requiring up-to-date software

Start by auditing your current EKS clusters today. Check which versions are approaching end-of-life and begin planning your upgrade path. With proactive management, you can transform EKS version upgrades from reactive fire drills to scheduled, predictable operational tasks.

---

Ready to eliminate EKS waste and optimize your Kubernetes costs? Schedule a CloudFix assessment to identify all areas of AWS cost optimization in your environment.

Every cluster you upgrade before extended support begins stops paying the extended support premium. Across a fleet of clusters, that adds up quickly.

See our pricing →

Looking for more Kubernetes optimization guides? Explore our other resources:
– Cutting AWS Costs: EBS Volume Snapshot Archiving – Save 27% on storage costs
– DynamoDB Standard vs IA: Cost Optimization – Optimize database spending
– AWS Reserved Instance Policy Changes – Navigate 2026 billing updates

Last updated: June 2026

---

Related Articles

• AWS Cost Optimization: The Complete Guide to Lowering Your Cloud Bill (2026)
• AWS Cost Optimization Tools: The Complete Comparison Guide (2026)
• Amazon MQ Pricing & Rightsizing: Cut Broker Costs by 30-60%
• CloudFix Finder/Fixer: Kinesis Analytics Optimize Logs
• Autoscale Amazon Kinesis Streams for AWS Cost Savings