AWS EKS version upgrade from 1.33 to 1.34 using Terraform

In this article I have covered AWS EKS version cluster in-place from 1.33 to 1.34, ec2 instance type update using Terraform for self-managed nodes.

Series: AWS EKS Version Upgrade (7 articles)

1
Benefits of Regular AWS EKS Version Upgrades
…
3
AWS EKS version upgrade from 1.33 to 1.34 using Terraform This article
4
AWS EKS version upgrade to 1.33 and AL2023 AMI

Naveena Ravi

Published Apr 24, 2026

Last modified Oct 18, 2026

In this article I have covered AWS EKS version cluster in-place from 1.33 to 1.34, ec2 instance type update using Terraform for self-managed nodes. we have covered the benefits of upgrade in this article AWS Kubernetes - FinOps with Upgrade | AWS Builder Center

WE have already updated our ec2 instances to AL2023 AMI Family and shared it in our previous article. AWS EKS version upgrade to 1.33 and AL2023 AMI | AWS Builder Center

As part of our standard Kubernetes maintenance, we are upgrading our AWS EKS clusters to 1.34 version. AWS EKS version upgrade is a zero-downtime upgrade using karpenter, we can read more in this article Zero Downtime during AWS EKS Version upgrade | AWS Builder Center .

Additionally, we are updating the instance type for optimal cost savings. We got the instance recommendation from the product. This helped us reduce the FinOps cost by 35% for the EKS. However, these changes must be reviewed with Cloud Architects for compatibility reviews.

IAC Changes done

PRE-Validate the EKS current version.

1
aws eks describe-cluster --name sample --query cluster.version --output text

PRE-Validate EKS nodes.

1
kubectl get nodes

Identify compatible AWS AMI for EKS version. Adapted from Retrieve recommended Amazon Linux AMI IDs - Amazon EKS

1
2
3
4
5
6
7
8
/*
aws ssm get-parameter --name /aws/service/eks/optimized-ami/<kubernetes-version>/<ami-typ>/recommended/image_id  --region <region-code> --query "Parameter.Value" --output text

sample:

*/

aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.34/amazon-linux-2023/x86_64/standard/recommended/image_id --region us-west-2 --query "Parameter.Value" --output text

Update the EKS version.

1
2
3
4
resource "aws_eks_cluster" "example" {
name = "sample"
version = "1.34"
}

Update image_id in aws_launch_template resource (update the AMI we identified above as image_id).
Update addon_version for each aws_eks_addon resource we want to update like vpc_cni , kube_proxy, coredns , etc.
They are upgraded to following versions:

1
2
3
4
5
6
coredns    = "v1.13.2-eksbuild.4"

vpc_cni    = "v1.21.1-eksbuild.7"

kube_proxy = "v1.34.6-eksbuild.2"

ebs_csi    = "v1.58.0-eksbuild.1"

efs_csi    = "v2.0.2-eksbuild.1"

s3_csi     = "v2.5.0-eksbuild.1".

karpenter changes:
instance-family was updated to r6a from i4i. No other changes in specification files required. More on Karpenter Implementation can be read here Manage Karpenter using AWS EKS Blueprint addons | AWS Builder Center
We got upgrade insights error for next version upgrade to 1.35. We resolved it by upgrading the addons Amazon GuardDuty EKS Runtime Monitoring and Amazon EKS Pod Identity Agent to latest versions.

How was the deployment done?

We announce downtime for the clusters upgrade, even though it is rolling update.
Ensure Backup is taken for the Data based on product guidelines.
AWS EKS Cluster changes were updated using Terraform and GitHub Actions. This automatically updated the master node.
Next Karpenter changes were updated using Terraform and GitHub Actions. This automatically updates the worker nodes in rolling update strategy. In current update the instance type was updated.
We can change the instance types without changing the AMI types. If they are compatible Karpenter will do the changes automatically.
After upgrade and testing, we communicate to stakeholders and close the downtime announced.

# terraform # kubernetes # amazon-eks # containers # IaC