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.

Contents

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 will reach end-of-life within the next year, 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

Amazon EKS

How It Works

Finder Component

The Finder component identifies EKS clusters running Kubernetes versions that are approaching or have already entered extended support through the following process:

  1. Analyzes AWS billing data by filtering for the ‘AmazonEKS’ product code and ‘CreateOperation’ operation
  2. Identifies the Kubernetes version running on each EKS cluster using the DescribeCluster API
  3. Compares each cluster’s version against AWS’s Kubernetes version lifecycle calendar
  4. Calculates the remaining time in standard support or time already spent in extended support
  5. Estimates the potential cost impact based on the cluster’s annualized public cost over the past 31 days
  6. Prioritizes clusters with annualized costs exceeding the threshold (default $100) for upgrade recommendations

The findings include detailed information to help administrators prioritize which clusters to upgrade first, including current version, target version, days until/since EOL, and potential cost savings.

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 that will reach EOL within the next year.

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.

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 $438/month increase per cluster.

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

Kubernetes Version EKS Release Standard Support Ends Extended Support Ends Status
1.36 June 2, 2026 August 2, 2027 August 2, 2028 Standard Support
1.35 January 27, 2026 March 27, 2027 March 27, 2028 Standard Support
1.34 October 2, 2025 December 2, 2026 December 2, 2027 Standard Support
1.33 May 29, 2025 July 29, 2026 July 29, 2027 Standard Support
1.32 January 23, 2025 March 23, 2026 March 23, 2027 Extended Support
1.31 September 26, 2024 November 26, 2025 November 26, 2026 Extended Support
1.30 May 23, 2024 July 23, 2025 July 23, 2026 Extended Support

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
    bash
    # Check deprecated APIs using kube-no-trouble
    kubectl kubent --version 1.33

  2. Validate Cluster Health
    bash
    # Check cluster status
    kubectl cluster-info
    aws eks describe-cluster --name your-cluster-name

  3. Review Upgrade Insights

  4. Navigate to Amazon EKS Console → Clusters → Your Cluster → Upgrade Insights
  5. Address any flagged issues before proceeding

Method 1: Using eksctl (Recommended)

eksctl provides a streamlined approach to EKS upgrades with built-in validation.

Step 1: Check eksctl Version

eksctl version
# Ensure version 0.215.0 or higher

Step 2: Upgrade Control Plane

# Upgrade from 1.33 to 1.34
eksctl upgrade cluster \
  --name production-cluster \
  --version 1.34 \
  --approve \
  --timeout 30m

Step 3: Update Node Groups

# Update managed node group
eksctl update nodegroup \
  --cluster production-cluster \
  --nodegroup ng-1 \
  --kubernetes-version 1.34 \
  --wait

# For self-managed nodes, create new node groups
eksctl create nodegroup \
  --cluster production-cluster \
  --nodegroup ng-2 \
  --node-type m5.large \
  --nodes-min 3 \
  --nodes-max 10 \
  --kubernetes-version 1.34 \
  --wait

Method 2: Using AWS CLI

For automation or integration with CI/CD pipelines:

Step 1: Upgrade Control Plane

aws eks update-cluster-version \
  --name production-cluster \
  --kubernetes-version 1.34 \
  --region us-east-1

Step 2: Monitor Progress

aws eks describe-update \
  --name production-cluster \
  --update-id <update-id> \
  --region us-east-1

Step 3: Update Node Groups via Auto Scaling

# Update Launch Template
aws ec2 create-launch-template-version \
  --launch-template-id lt-1234567890abcdef0 \
  --launch-template-name eks-node-template \
  --version-description "Kubernetes 1.34" \
  --launch-template-data '{
    "ImageId": "ami-0c55b159cbfafe1f0",
    "InstanceType": "m5.large",
    "UserData": "<UserDataWithKubelet1.34>"
  }'

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: 

# Check for deprecated APIs
kubectl kubent --version 1.33 --yaml

# Validate add-ons
aws eks describe-addon \
  --cluster-name production-cluster \
  --addon-name vpc-cni \
  --query 'addon.addonVersion'

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:

# Ensure nodes match control plane version
kubectl get nodes -o wide | grep "1.33"

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:

# Implement rolling updates with disruption budgets
kubectl rollout statefulset your-stateful-set --revision=2

4. Ignoring Add-on Updates

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

Solution:

# Update EKS add-ons
aws eks update-addon \
  --cluster-name production-cluster \
  --addon-name coredns \
  --addon-version v1.10.1-eksbuild.5 \
  --resolve-conflicts OVERWRITE

5. Poor Rollback Strategy

Problem: Having no plan to revert if upgrades fail.

Preparation:

# Take cluster snapshot
eksctl utils update-cluster-version \
  --name production-cluster \
  --approve \
  --force \
  --backup-s3-path s3://your-backup-bucket/eks-backup

6. Network Configuration Issues

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

Pre-check:

# Verify subnet IP availability
aws ec2 describe-subnets \
  --subnet-ids subnet-12345678 \
  --query 'Subnets[0].AvailableIpAddressCount'

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 identifies clusters running deprecated versions and provides actionable insights:

Detection Process

  1. Scan AWS Billing Data
  2. Analyzes EKS clusters with the AmazonEKS product code

  3. Identifies version-specific costs

  4. Check Current Versions

  5. Uses AWS DescribeCluster API to determine actual versions

  6. Compares against AWS’s Kubernetes lifecycle calendar

  7. Calculate Cost Impact

  8. Estimates potential savings from upgrades

  9. Prioritizes clusters by cost impact

  10. Generate Recommendations

  11. Provides target upgrade versions
  12. Includes timeline-based priority

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 6-12 months in advance

Implementing CloudFix for EKS Lifecycle Management

Step 1: Onboard CloudFix

# Install CloudFix CLI
npm install -g @cloudfix/cli

# Authenticate
cloudfix login

Step 2: Scan Your EKS Clusters

# Run EKS EOL analysis
cloudfix analyze eks-eol --format json > eks-eol-report.json

Step 3: Review Recommendations

The report will include:
– Clusters requiring immediate attention
– Target upgrade versions
– Cost savings projections
– Timeline for upgrades

Step 4: Execute Upgrades

Use CloudFix’s prioritized list to plan your upgrade sequence:

# Generate upgrade plan
cloudfix generate-upgrade-plan --eks-file eks-eol-report.json

Integration with CI/CD Pipelines

For organizations adopting Infrastructure as Code, CloudFix integrates seamlessly:

Terraform Integration

resource "cloudfix_eks_eol_check" "production" {
  cluster_name        = "production-cluster"
  allowed_versions   = ["1.34", "1.35"]
  critical_threshold = 30 # days
}

GitHub Actions Workflow

name: EKS EOL Check
on:
  schedule:
    - cron: '0 6 * * 1' # Weekly on Monday

jobs:
  check-eol:
    runs-on: ubuntu-latest
    steps:
      - uses: cloudfix/actions/eks-eol-check@v1
        with:
          aws-region: us-east-1
          cluster-name: production-cluster

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

Cost Component Standard Support Extended Support Monthly Difference (24/7)
Cluster Cost $0.10/hour $0.60/hour $438
Annual Cost $876 $5,256 $4,380

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

Consider a 50-cluster environment:
– Annual Savings: $219,000 (50 clusters × $4,380)
– Security Risk Reduction: 95% fewer CVE exposures
– Operational Efficiency: 40% fewer support tickets

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:

# Valid: 1.30 → 1.31 → 1.32 → 1.33
# Valid: 1.30 → 1.32 (direct upgrade)
# Not Recommended: 1.30 → 1.33 (skip two versions)

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:

# Delete Fargate Pod to force recreation
kubectl delete pod your-pod -n your-namespace

# Redeploy with new manifest
kubectl apply -f your-deployment.yaml

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.

One EKS client saved $438/month per cluster by avoiding extended support. Imagine upgrading 10 clusters—that’s $4,380/month back in your budget.

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