Why eksctl Is the Underrated, Killer Tool for EKS

Setting up EKS the "proper" way usually means hundreds of lines of Terraform HCL or CDK constructs. You write the cluster resource, the node group, the OIDC provider for IAM Roles for Service Accounts, the aws-auth ConfigMap, the VPC CNI addon, the CoreDNS addon, the kube-proxy addon, the launch template, the security groups, the IAM roles, the IAM policies. You wire it all together with references and depends_on blocks. You debug it for a week.

Or you write a 30-line YAML file and run eksctl create cluster -f cluster.yaml. Fifteen minutes later you have a fully working EKS cluster with managed node groups, IRSA configured, addons installed, and kubectl already pointed at it.

That's eksctl. It's been around since 2018, it's maintained by Weaveworks (now part of the CNCF ecosystem), and most teams either don't know about it or dismiss it as a "getting started" tool. It's not. It's a production-grade tool that happens to also be simple.

What eksctl actually does

eksctl is a CLI that manages the full lifecycle of EKS clusters. Under the hood, it generates and manages CloudFormation stacks. That's important — it's not doing anything magical. It's creating the same AWS resources you'd create manually, just without making you write the CloudFormation or Terraform yourself.

A basic cluster config:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: us-east-1
  version: "1.29"

managedNodeGroups:
  - name: default
    instanceType: m6i.large
    desiredCapacity: 3
    minSize: 1
    maxSize: 5
    volumeSize: 50

Run eksctl create cluster -f cluster.yaml and you get:

A VPC with public and private subnets across 3 AZs
NAT gateways
The EKS control plane
A managed node group with the specified instance type and scaling
The OIDC provider (for IRSA)
CoreDNS, kube-proxy, and VPC CNI addons
Your kubeconfig updated to point at the new cluster

That's about 300 lines of Terraform you didn't have to write.

It's not just for cluster creation

This is the misconception. People think eksctl is a bootstrapping tool — create the cluster, then manage everything else with Terraform or Helm. In reality, eksctl handles most of the Day 2 operations that make EKS painful.

Nodegroup management

Need to change instance types? Add a GPU node group? Scale up for a load test?

# Add a new node group
eksctl create nodegroup -f cluster.yaml --include=gpu-nodes

# Delete an old node group (drains nodes first)
eksctl delete nodegroup --cluster=my-cluster --name=old-nodes

# Scale a node group
eksctl scale nodegroup --cluster=my-cluster --name=default --nodes=5

When you delete a node group, eksctl drains the nodes first. When you create a replacement, it waits for the new nodes to be ready before draining the old ones. Zero-downtime node group replacement is built in.

IAM Roles for Service Accounts (IRSA)

IRSA is the right way to give pods AWS permissions, but setting it up manually involves creating an OIDC provider, an IAM role with a trust policy that references the OIDC provider's ARN and the service account's namespace/name, and a Kubernetes service account annotated with the role ARN. It's 4 resources across 2 systems with a trust policy that's easy to get wrong.

eksctl does it in one command:

eksctl create iamserviceaccount \
  --cluster=my-cluster \
  --name=s3-reader \
  --namespace=default \
  --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve

This creates the IAM role with the correct trust policy, creates the Kubernetes service account, and annotates it. Done.

Cluster upgrades

EKS version upgrades are notoriously tedious. You upgrade the control plane, then upgrade each node group, then upgrade the addons, and each step has prerequisites and ordering constraints.

# Upgrade control plane
eksctl upgrade cluster --name=my-cluster --version=1.30 --approve

# Upgrade node groups (creates new, drains old)
eksctl upgrade nodegroup --name=default --cluster=my-cluster

# Upgrade addons
eksctl utils update-coredns --cluster=my-cluster --approve
eksctl utils update-kube-proxy --cluster=my-cluster --approve
eksctl utils update-aws-node --cluster=my-cluster --approve

eksctl handles the ordering and waits for each step to complete. Compare that to the 15-step runbook you'd need with Terraform, where you change the version, run plan, apply, wait, change the next thing, plan, apply, wait.

Addon management

EKS addons (CoreDNS, kube-proxy, VPC CNI, EBS CSI driver, etc.) can be declared in the cluster config:

addons:
  - name: vpc-cni
    version: latest
    attachPolicyARNs:
      - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
  - name: coredns
    version: latest
  - name: kube-proxy
    version: latest
  - name: aws-ebs-csi-driver
    version: latest
    attachPolicyARNs:
      - arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy

Using eksctl alongside Terraform or CDK

Here's the part most people miss: you don't have to go all-in on eksctl. If you already manage your EKS cluster with Terraform or CDK, eksctl can still handle the operations that are painful in those tools.

This is actually a great way to dip your toes in.

Terraform for infra, eksctl for EKS operations

Your Terraform manages the VPC, RDS, Elasticache, IAM policies, and other infrastructure. Your EKS cluster might even be created by Terraform. But you use eksctl for the EKS-specific operations that Terraform handles poorly:

Node group rolling updates — eksctl creates the new node group, waits for it to be ready, drains the old nodes, and deletes the old group. In Terraform, you either get a big-bang replacement or write custom lifecycle rules.
IRSA setup — one eksctl command vs. 3-4 Terraform resources with a finicky trust policy JSON.
Cluster upgrades — eksctl handles the multi-step upgrade sequence. In Terraform, you change the version and pray the apply doesn't timeout.
Quick nodegroup experiments — need to test a new instance type or add spot instances? eksctl create nodegroup is faster than a Terraform PR cycle.

eksctl operates on existing clusters by name. It doesn't care how the cluster was created. Point it at your Terraform-managed cluster and it works:

# Works on any existing EKS cluster, regardless of how it was created
eksctl create nodegroup --cluster=my-terraform-cluster --name=spot-nodes \
  --instance-types=m6i.large,m5.large --spot --nodes=3

The only caveat: eksctl creates its own CloudFormation stacks for the resources it manages. These stacks are independent of your Terraform state. That's actually fine — it means there's no state conflict. eksctl manages its resources, Terraform manages its resources, and they coexist peacefully.

Gradual adoption

A practical path:

Start by using eksctl for one-off operations on your existing cluster (add a nodegroup, set up IRSA)
If you like it, use eksctl for your next cluster upgrade instead of doing it manually in Terraform
For new clusters in non-production environments, try creating the whole thing with eksctl
Decide whether to standardize on eksctl for EKS or keep the hybrid approach

The hybrid approach is perfectly valid long-term. Many teams use Terraform for everything except EKS-specific operations, where eksctl's purpose-built commands are simply better.

It's just CloudFormation

This is the underappreciated design choice. eksctl generates CloudFormation stacks, which means:

You can inspect what it creates — look at the stacks in the CloudFormation console, see every resource, read the template.
Drift detection works — CloudFormation tracks whether someone manually changed a resource.
Rollbacks are built in — if a stack update fails, CloudFormation rolls back to the previous state.
You can manually fix things — if eksctl creates something wrong, you can update the CloudFormation stack directly or import it into Terraform.

It's not a black box. It's a code generator for a well-understood infrastructure tool.

What eksctl doesn't do

eksctl is opinionated, and those opinions won't match every environment:

Custom VPC topologies — eksctl can create a VPC for you or use an existing one, but if you need unusual subnet configurations or transit gateway attachments, manage the VPC separately and pass the subnet IDs to eksctl.
Multi-cluster fleet management — eksctl manages one cluster at a time. If you're running 20 clusters across 5 regions, you'll want a wrapper or a different tool for orchestration.
Application deployment — eksctl manages the cluster infrastructure, not what runs on it. Use Helm, ArgoCD, or Flux for application deployments.
State locking — unlike Terraform, eksctl doesn't have a remote state lock. If two people run eksctl against the same cluster simultaneously, you could get conflicts. In practice, CloudFormation's own stack locking prevents most issues.

Install

# macOS
brew install eksctl

# Windows
scoop install eksctl

# Linux
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_Linux_amd64.tar.gz"
tar -xzf eksctl_Linux_amd64.tar.gz -C /usr/local/bin

The bottom line

eksctl isn't a "getting started" tool you graduate from. It's a purpose-built tool for EKS that handles the hard parts — nodegroup lifecycle, IRSA wiring, version upgrades, addon management — with a fraction of the code and complexity of general-purpose IaC tools.

You don't have to choose between eksctl and Terraform. Use both. Let Terraform manage your VPCs, databases, and IAM policies. Let eksctl manage the EKS-specific operations where it excels. The two coexist cleanly because eksctl's CloudFormation stacks are independent of your Terraform state.

If you've been writing 500 lines of Terraform HCL to do what 30 lines of eksctl YAML can do, give it a try. Start with one nodegroup operation on an existing cluster. You'll wonder why you waited.

Published by Yaw Labs.