What does EKS stand for and what does it do?

EKS stands for Elastic Kubernetes Service. It is a managed Kubernetes service from AWS that runs and operates the Kubernetes control plane - the API server, etcd, and scheduler - on your behalf. You manage the worker nodes (or let Fargate manage them), while AWS handles control plane availability, patching, and upgrades.

What is the difference between EKS node groups and EKS Fargate?

Node groups are EC2 instances you manage - you choose the instance type, set autoscaling policies, and are responsible for node-level patching. Fargate is serverless: you define your pods and AWS runs them on infrastructure you never see or manage. Fargate is simpler operationally but costs more and has limitations around storage and privileged containers.

How much does Amazon EKS cost?

EKS charges $0.10 per hour per cluster for the managed control plane, plus the cost of the EC2 instances or Fargate compute running your pods. A small cluster with two t3.medium nodes costs roughly $100-$150 per month in us-east-1. Add EKS to your Terraform or eksctl config for cost management.

When should I use EKS instead of self-managed Kubernetes?

Use EKS (or another managed Kubernetes service) when running Kubernetes in production on AWS. Self-managing the control plane - running etcd, the API server, and the scheduler yourself - is operationally expensive and rarely justified unless you have specific compliance requirements. For most teams, the $72/month control plane fee is worth the operational savings.

What is Amazon EKS?

Running Kubernetes in production means running an API server, a scheduler, a controller manager, and etcd - all at high availability, all kept up to date, all monitored for failures. Amazon EKS does all of that for you. You focus on your workloads; AWS operates the control plane.

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that runs a certified, upstream-compatible Kubernetes control plane on AWS infrastructure. It integrates natively with IAM for RBAC, VPC networking for pod network isolation, ECR for container registry, and ALB/NLB for load balancing.

How EKS Is Structured

An EKS cluster has two layers: the control plane (managed by AWS) and the data plane (your worker nodes).

The control plane runs in an AWS-managed account. You never SSH into the API server or manage etcd. AWS guarantees a multi-AZ, highly available control plane and handles Kubernetes version upgrades when you trigger them. You interact with it through kubectl, the AWS console, or Terraform.

The data plane is where your workloads run. You have two options:

Managed Node Groups: EC2 instances provisioned and joined to the cluster automatically. You choose the instance type and define autoscaling boundaries. Managed node groups handle node AMI updates and graceful draining during updates. You are responsible for the underlying EC2 costs.

EKS Fargate: AWS runs your pods on serverless infrastructure. You define a Fargate Profile specifying which pod namespaces and labels should run on Fargate. No node management, no instance sizing - just pod specs and resource requests. Fargate costs more per vCPU and GB of memory than equivalent EC2, but eliminates node-level operational overhead entirely.

Creating an EKS Cluster with eksctl

eksctl is the official CLI for EKS, written by Weaveworks. It wraps the AWS API calls needed to create a cluster into simple commands:

# Install eksctl (macOS)
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

# Create a cluster with a managed node group
eksctl create cluster \
  --name cloudpros-prod \
  --region eu-west-2 \
  --version 1.30 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 5 \
  --managed \
  --asg-access \
  --with-oidc

# Verify the cluster is running
kubectl get nodes

# Create a Fargate profile for a specific namespace
eksctl create fargateprofile \
  --cluster cloudpros-prod \
  --name fp-serverless \
  --namespace serverless-workloads

The --with-oidc flag creates an OpenID Connect provider for the cluster, which is required for IAM Roles for Service Accounts (IRSA) - the secure way to give pods AWS permissions without storing credentials in pods.

EKS with Terraform

For production environments, managing EKS through Terraform gives you infrastructure-as-code control over the cluster configuration, node groups, and add-ons:

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "cloudpros-prod"
  cluster_version = "1.30"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  cluster_endpoint_public_access = true

  eks_managed_node_groups = {
    general = {
      instance_types = ["t3.medium"]
      min_size       = 1
      max_size       = 5
      desired_size   = 2

      labels = {
        Environment = "production"
        Team        = "platform"
      }
    }
  }

  enable_cluster_creator_admin_permissions = true

  tags = {
    Environment = "production"
    Terraform   = "true"
  }
}

EKS vs Self-Managed Kubernetes on EC2

The question of whether to use EKS or run your own Kubernetes on EC2 is mostly settled in favour of EKS for teams on AWS. The self-managed path requires running your own etcd cluster (typically 3 nodes for HA), managing TLS certificate rotation, handling control plane upgrades manually, and building your own failure recovery procedures. The cost of that operational work far exceeds EKS's $0.10/hour control plane charge for almost every team.

The one scenario where self-managed makes sense is a specific compliance requirement that prohibits delegating control plane operation to AWS - which is rare but does occur in certain regulated industries.

IAM and RBAC Integration

EKS uses a custom aws-auth ConfigMap (and the newer EKS Access Entries API) to map IAM identities to Kubernetes RBAC roles. When an engineer runs kubectl, their IAM identity is validated first; then the Kubernetes API applies RBAC policies. This means you can manage cluster access through IAM without maintaining separate Kubernetes user certificates - a significant security and operational simplification.