0Pricing
AWS Solutions Architect · Lesson

EKS Control Plane and Worker Nodes

Understand what AWS manages in the EKS control plane, provision managed node groups, and connect kubectl to your cluster.

EKS Control Plane and Worker Nodes is a free AWS Solutions Architect lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AWS Solutions Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Is Amazon EKS?

Amazon Elastic Kubernetes Service (EKS) is a fully managed Kubernetes service that removes the burden of installing, operating, and maintaining the Kubernetes control plane. AWS runs, scales, and upgrades the control plane across multiple Availability Zones, providing a highly available cluster endpoint. You focus entirely on deploying and managing your application workloads.

The EKS Control Plane

The EKS control plane consists of the API server, etcd, controller manager, and scheduler — all managed by AWS. These components run in AWS-owned accounts, meaning you never SSH into them. AWS guarantees a 99.95% SLA for the EKS API endpoint and automatically replaces unhealthy control plane nodes. You pay a flat per-cluster-per-hour fee for the control plane.

Creating an EKS Cluster

You can create an EKS cluster using the AWS Console, eksctl, or CloudFormation. The cluster requires a VPC with subnets across at least two AZs and an IAM role that grants the Kubernetes control plane permission to call AWS APIs. Once created, the cluster endpoint is an HTTPS URL you configure in your kubeconfig.

# Create a cluster with eksctl (recommended for getting started)
eksctl create cluster \
  --name my-cluster \
  --region us-east-1 \
  --version 1.29 \
  --nodegroup-name standard-nodes \
  --node-type m5.large \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 5

Connecting kubectl to EKS

After creating the cluster, you update your local kubeconfig so kubectl knows how to reach the EKS API server. The AWS CLI generates the necessary entry automatically. The EKS API server uses AWS IAM for authentication — your IAM user or role is mapped to a Kubernetes RBAC identity via the aws-auth ConfigMap.

# Update kubeconfig for your EKS cluster
aws eks update-kubeconfig \
  --region us-east-1 \
  --name my-cluster

# Verify connectivity
kubectl get nodes
kubectl get pods --all-namespaces

Managed Node Groups

Managed node groups let AWS provision, register, and lifecycle-manage EC2 worker nodes on your behalf. When you request an update or replacement, EKS automatically drains pods, replaces the instance, and re-registers it — all without manual intervention. Managed node groups use Auto Scaling Groups under the hood, giving you min/max/desired capacity control and integration with Cluster Autoscaler.

# Add a managed node group to an existing cluster
eksctl create nodegroup \
  --cluster my-cluster \
  --region us-east-1 \
  --name high-mem-nodes \
  --node-type r6i.large \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 10 \
  --managed

Self-Managed Node Groups

With self-managed node groups you launch EC2 instances yourself (via CloudFormation or Terraform) and register them to the EKS cluster by running the bootstrap script. This gives maximum flexibility — you can use custom AMIs, GPU instance types, or highly customised kernel configurations — but you are fully responsible for patching, draining, and replacing nodes.

# Bootstrap script baked into the launch template
/etc/eks/bootstrap.sh my-cluster \
  --apiserver-endpoint 'https://EXAMPLE.gr7.us-east-1.eks.amazonaws.com' \
  --b64-cluster-ca 'BASE64_ENCODED_CA' \
  --kubelet-extra-args '--node-labels=role=custom'

Node IAM Role and Instance Profile

Every worker node must run with an EC2 instance profile that has three AWS-managed policies: AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, and AmazonEC2ContainerRegistryReadOnly. These allow the node to join the cluster, manage pod networking with the VPC CNI plugin, and pull images from ECR. Without these policies, nodes will fail to register.

# Attach required policies to the node role
aws iam attach-role-policy \
  --role-name EKSNodeRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy

aws iam attach-role-policy \
  --role-name EKSNodeRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy

aws iam attach-role-policy \
  --role-name EKSNodeRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly

aws-auth ConfigMap: IAM to RBAC Mapping

EKS uses the aws-auth ConfigMap in the kube-system namespace to map IAM users and roles to Kubernetes usernames and groups. When you create a cluster, only the creator's IAM identity is automatically granted admin access. To let other users or CI/CD roles access the cluster, you must add entries to this ConfigMap with the correct mapRoles or mapUsers keys.

# View and edit the aws-auth ConfigMap
kubectl describe configmap aws-auth -n kube-system

# Add a role mapping (example YAML fragment)
# mapRoles:
# - rolearn: arn:aws:iam::111122223333:role/EKSNodeRole
#   username: system:node:{{EC2PrivateDNSName}}
#   groups:
#     - system:bootstrappers
#     - system:nodes

EKS Add-Ons and Cluster Upgrades

EKS add-ons are curated, AWS-validated software components — such as the VPC CNI, CoreDNS, and kube-proxy — that EKS can install and keep up to date on your behalf. When you upgrade your cluster Kubernetes version, you update the control plane first, then update each managed node group to the matching version. EKS supports a N-1 minor version skew between control plane and nodes during the rollout window.

# List available add-ons and their versions
aws eks describe-addon-versions \
  --kubernetes-version 1.29 \
  --query 'addons[].{Name:addonName,Versions:addonVersions[0].addonVersion}' \
  --output table

# Update the VPC CNI add-on
aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name vpc-cni \
  --addon-version v1.16.0-eksbuild.1

EKS Security: Endpoint Access and Encryption

The EKS API server endpoint can be configured as public only, private only, or both. Public endpoints are secured by IAM authentication; private-only endpoints require your kubeconfig to reach the VPC via VPN or Direct Connect. You can also enable envelope encryption of Kubernetes secrets at rest using an AWS KMS key, providing an additional layer of protection for sensitive configuration data.

# Enable private endpoint and envelope encryption at cluster creation
aws eks create-cluster \
  --name secure-cluster \
  --kubernetes-version 1.29 \
  --role-arn arn:aws:iam::111122223333:role/EKSClusterRole \
  --resources-vpc-config subnetIds=subnet-xxx,securityGroupIds=sg-xxx,endpointPublicAccess=false,endpointPrivateAccess=true \
  --encryption-config '[{"provider":{"keyArn":"arn:aws:kms:us-east-1:111122223333:key/KEY_ID"},"resources":["secrets"]}]'

Cluster Autoscaler on EKS

The Cluster Autoscaler is a Kubernetes pod that watches for unschedulable pods and automatically adjusts the size of managed node group Auto Scaling Groups. When pods cannot be scheduled because of insufficient resources, Cluster Autoscaler scales up. When nodes are underutilised and their pods can be rescheduled elsewhere, it scales down. It requires IAM permissions to call the EC2 Auto Scaling API via IRSA.

# Deploy Cluster Autoscaler (abbreviated)
kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

# Add required annotation so it discovers your cluster ASGs
kubectl annotate serviceaccount cluster-autoscaler \
  -n kube-system \
  eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/ClusterAutoscalerRole

Quick Check

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

Lesson Recap

In this lesson you learned: AWS manages the EKS control plane at a 99.95% SLA, managed node groups let AWS handle node lifecycle while self-managed groups give maximum customisation, and the aws-auth ConfigMap maps IAM identities to Kubernetes RBAC for cluster access control. Next up we explore Fargate Profiles for serverless pod execution.

Frequently asked questions

Is the “EKS Control Plane and Worker Nodes” lesson free?

Yes — the full text of “EKS Control Plane and Worker Nodes” is free to read here on the web, and the AWS Solutions Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AWS Solutions Architect course, upgrade to CoddyKit PRO.

What will I learn in “EKS Control Plane and Worker Nodes”?

Understand what AWS manages in the EKS control plane, provision managed node groups, and connect kubectl to your cluster. You practise AWS Solutions Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start AWS Solutions Architect?

No prior experience is required. AWS Solutions Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “EKS Control Plane and Worker Nodes” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this AWS Solutions Architect lesson?

Yes. Every AWS Solutions Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. EKS Control Plane and Worker Nodes
  2. Fargate Profiles for Serverless Pods
  3. EKS Networking: VPC CNI and Load Balancing
  4. IAM Roles for Service Accounts (IRSA)
← Back to AWS Solutions Architect