Create Your First Amazon EKS Cluster with eksctl (AWS Beginner Guide)

Simple explanation

Amazon EKS is AWS’s managed Kubernetes service. Kubernetes is an open-source system for running containerised applications at scale. It handles scheduling, restarts, scaling, and networking across a fleet of servers. If you have not used Kubernetes before, What is Kubernetes is worth reading first.

EKS means AWS runs the Kubernetes control plane (the API server, etcd, and scheduler) for you. You manage the worker nodes that run your application containers.

eksctl is a command-line tool built specifically for EKS. One eksctl create cluster command handles provisioning the VPC, subnets, IAM roles, the EKS control plane, and a node group. Without it, you would need to do each of those steps separately and in the right order.

What you will have by the end

• A running EKS cluster in the AWS region you choose
• A managed node group with EC2 worker nodes ready to accept workloads
• kubectl configured and authenticated against the cluster
• Verified that nodes are healthy and the cluster is operational
• A config YAML file you can version-control for future cluster rebuilds

When to use this

This tutorial is the right next step if:

• You need to run containerised applications that require Kubernetes: multi-container workloads, service meshes, custom operators, or workloads that already run on Kubernetes elsewhere
• Your team is standardising on Kubernetes and you need an AWS-managed cluster to start deploying against
• You are learning EKS and want a real cluster to experiment with before committing to a production architecture
• You are migrating an existing Kubernetes workload from another provider to AWS

When not to use EKS

EKS is powerful but not the right tool for every situation.

• Running a single containerised application. Amazon ECS is significantly simpler to operate and has tighter AWS service integration. If you do not need Kubernetes specifically, ECS will get you running faster with far less overhead.
• Serverless containers. ECS with Fargate or a Lambda-based approach removes all infrastructure management entirely.
• Kubernetes on plain EC2. Self-managed Kubernetes on EC2 gives you full control but requires you to manage control plane upgrades, etcd backups, and node health yourself. For most teams, EKS makes this unnecessary.

See EKS vs ECS and EKS vs EC2 for a deeper comparison.

Prerequisites

Before running any commands, confirm the following are in place.

Installing eksctl: on macOS: brew tap weaveworks/tap && brew install weaveworks/tap/eksctl. On Linux, download the binary from the eksctl GitHub releases page. On Windows, use Chocolatey: choco install eksctl.

Before you create the cluster

Choose your region carefully. EKS clusters are regional. Create your cluster in the same region as the other AWS resources your application will use (databases, load balancers, container images). Cross-region traffic adds latency and cost. If you are unsure, start in the region where your team’s existing infrastructure lives.

Understand the ongoing cost. The control plane fee runs continuously from the moment you create the cluster until you delete it. Worker node EC2 costs are additional. For a short learning exercise, two t3.medium nodes for a few hours is inexpensive. Leaving a cluster running for a week is not free. Set a reminder to clean up.

How to clean up. When you are done, run:

eksctl delete cluster --name my-cluster --region eu-west-1

This deletes the CloudFormation stacks and all associated resources. It takes 10 to 15 minutes. Always confirm deletion completed in the AWS Console or by checking CloudFormation stacks, since partial failures can leave resources (and costs) behind.

Create your first EKS cluster with eksctl

The following command creates a complete EKS cluster with a managed node group:

eksctl create cluster \
  --name my-cluster \
  --region eu-west-1 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 4 \
  --managed

What each flag does:

• --name my-cluster — the cluster name, unique within the region
• --region eu-west-1 — the AWS region; replace with your chosen region
• --nodegroup-name standard-workers — a name for the initial node group
• --node-type t3.medium — the EC2 instance type for worker nodes; t3.medium (2 vCPU, 4 GB RAM) is a reasonable starting point for development
• --nodes 2 — the initial number of worker nodes
• --nodes-min 1 and --nodes-max 4 — the auto-scaling boundaries for the node group
• --managed — creates a managed node group, where AWS handles OS patching and node replacement

eksctl prints progress messages as it works. The full process takes roughly 15 to 20 minutes. Do not interrupt it.

What eksctl creates for you

eksctl creates a CloudFormation stack that provisions all the required infrastructure. Here is what gets built and who is responsible for what once it is running.

VPC and subnets. eksctl creates a new VPC with both public and private subnets spread across three availability zones. With the command-line approach above, worker nodes are placed in public subnets by default. For production, use a config file with privateNetworking: true so nodes are not directly reachable from the internet. See the private EKS clusters guide for the full setup.

IAM roles. Two IAM roles are created: one for the EKS control plane (so AWS can manage cluster infrastructure on your behalf) and one for the worker node group (so nodes can register with the cluster and pull images from ECR). See IAM Roles for Service Accounts for how to extend this to your application workloads.

EKS control plane. AWS provisions the Kubernetes API server, etcd datastore, and controller manager in AWS-managed infrastructure. You do not have access to these machines directly. This is what makes EKS a managed service.

Managed node group. EC2 instances are launched with the Amazon EKS-optimised AMI, which includes kubelet and the container runtime pre-configured. Nodes automatically join the cluster. Node group types and options are covered in more detail separately.

Core add-ons. CoreDNS and kube-proxy are installed automatically. These handle internal DNS resolution and network proxy rules and are required for basic cluster operation.

Configure kubectl

After eksctl finishes, it automatically updates your kubeconfig. If it did not (or if you are connecting from a different machine), run:

aws eks update-kubeconfig \
  --region eu-west-1 \
  --name my-cluster

This adds the EKS cluster as a context in your ~/.kube/config file. kubectl authenticates using your AWS CLI credentials and generates short-lived tokens automatically.

To confirm kubectl is pointing at the right cluster:

kubectl config current-context

You should see output like arn:aws:eks:eu-west-1:123456789012:cluster/my-cluster.

The EKS networking model explains how authentication and in-cluster networking work in more depth.

Verify the cluster

Run the following to confirm the cluster is healthy and nodes are ready:

# Check that both nodes are in Ready state
kubectl get nodes

# Check core system pods are running
kubectl get pods -n kube-system

# Confirm the cluster is ACTIVE via the AWS CLI
aws eks describe-cluster \
  --name my-cluster \
  --region eu-west-1 \
  --query 'cluster.status'

A healthy kubectl get nodes output looks like this:

NAME                                           STATUS   ROLES    AGE   VERSION
ip-192-168-1-10.eu-west-1.compute.internal    Ready    <none>   5m    v1.30.2-eks-1234567
ip-192-168-1-11.eu-west-1.compute.internal    Ready    <none>   5m    v1.30.2-eks-1234567

Both nodes should show Ready. If a node shows NotReady, inspect it for error events by replacing NODE_NAME with the actual node name from the output above:

kubectl describe node NODE_NAME

Look in the Events and Conditions sections at the bottom of the output.

Common errors and how to fix them

“User does not have permission to create eks:CreateCluster”

Your IAM user or role is missing EKS permissions. Attach the AmazonEKSClusterPolicy managed policy to your role, or add eks:* to a custom policy. For a minimal setup, follow the eksctl minimum IAM permissions documentation rather than broadening permissions unnecessarily.

Nodes stay in NotReady state

This is usually an IAM or security group issue. The node IAM role needs AmazonEKSWorkerNodePolicy, AmazonEKSCNIPolicy, and AmazonEC2ContainerRegistryReadOnly attached. Check the IAM role that eksctl created in the AWS Console and verify all three policies are present.

kubectl returns “error: You must be logged in to the server (Unauthorized)”

Your AWS credentials have expired or kubectl is pointing at the wrong context. Run aws sts get-caller-identity to check your credentials are valid, then re-run aws eks update-kubeconfig to refresh the kubeconfig entry.

CloudFormation stack stuck in ROLLBACK

If cluster creation fails partway through, eksctl may leave a CloudFormation stack in a failed state. Go to the CloudFormation console, find the stack named eksctl-my-cluster-cluster, and delete it manually before retrying. eksctl will not re-use a partially-created stack.

Real-world cluster creation with a config file

For anything beyond a quick test, use a cluster configuration file instead of command-line flags. This makes your cluster reproducible, version-controllable, and shareable with your team.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: production-cluster
  region: eu-west-1
  version: "1.30"

managedNodeGroups:
  - name: general-workers
    instanceType: m5.large
    minSize: 2
    maxSize: 10
    desiredCapacity: 3
    privateNetworking: true
    availabilityZones:
      - eu-west-1a
      - eu-west-1b
      - eu-west-1c

Key differences from the command-line version:

• privateNetworking: true places worker nodes in private subnets, the recommended approach for production
• availabilityZones is explicitly set, ensuring nodes are spread across AZs for resilience
• m5.large is more appropriate for production workloads than t3.medium

Save this as cluster.yaml and create the cluster with:

eksctl create cluster -f cluster.yaml

EKS vs ECS and self-managed Kubernetes

If you are choosing between EKS and ECS, the main question is whether you need Kubernetes specifically. If your team is already running Kubernetes elsewhere, EKS is the natural fit. If you are starting fresh on AWS with no Kubernetes dependency, ECS is simpler to run. See EKS vs ECS and managed vs self-managed Kubernetes for the full analysis.

What to do next after cluster creation

Once your cluster is running and nodes are healthy, the natural progression is:

1. Deploy your first application. Follow the deploying containers with kubectl guide to create a Deployment, Service, and test that your app is reachable. Understanding Kubernetes pods, Deployments, and Services first will make this much easier.

2. Set up observability. Configure logging in Kubernetes to send container logs to CloudWatch, and enable EKS cluster monitoring so you can see node metrics and alerts.

3. Harden security. Read the securing EKS clusters guide. At minimum, restrict which IAM principals can access the cluster, enable audit logging, and review your security group rules. Use IAM Roles for Service Accounts so pods can access AWS services with scoped permissions rather than inheriting node-level credentials.

4. Review networking. The EKS networking model explains how pods get IP addresses, how services are exposed, and how to configure private EKS clusters for production.

5. Manage packages with Helm. Helm is the standard way to install third-party software (ingress controllers, monitoring agents, cert-manager) onto a Kubernetes cluster.

6. Plan for upgrades. EKS Kubernetes versions follow a support window. Read the upgrading EKS clusters guide before you need to upgrade so you understand the steps involved.