Skip to main content
In this lesson we’ll cover AWS Elastic Kubernetes Service (EKS): what it is, why you would use a managed Kubernetes service, the worker node options, and practical steps to create and connect to an EKS cluster.

​
What is EKS?

Amazon EKS is a managed Kubernetes service on AWS. “Managed” means AWS operates and maintains the Kubernetes control plane for you — the API server, scheduler, controller manager, and etcd — including availability, scaling, and backups. You remain responsible for the compute that runs your pods unless you choose a serverless compute option such as Fargate.
A slide titled "What is EKS?" explaining Amazon EKS as a managed Kubernetes service, with colored boxes noting AWS manages the control plane, provisioning/maintenance of master nodes, control plane processes, and scaling/backups. A diagram on the right shows the Kubernetes control plane (API server, scheduler, controller manager, etcd) and worker node layout.
Why choose a managed service like EKS over running Kubernetes yourself?
  • Running and scaling a Kubernetes control plane is complex: installing and maintaining control plane components, ensuring high availability across Availability Zones, performing backups and upgrades, and scaling the control plane are operationally heavy tasks.
  • Security and operational best practices for the control plane add extra overhead. Using EKS reduces this burden because AWS manages many control-plane security and availability responsibilities.
  • EKS integrates tightly with many AWS services (IAM for authentication and authorization, Secrets Manager, ELB/ALB, S3, CloudWatch), simplifying adoption of AWS-specific features and operational workflows.
A presentation slide titled "Why EKS?" showing three points: running and scaling Kubernetes can be difficult, securing Kubernetes increases operational overhead, and tight integration with other AWS services. Below each point are visuals: Kubernetes icons, a padlock, and AWS service icons (S3, IAM, Secrets Manager, Load Balancer).

​
Worker node options

Although AWS manages the control plane, worker nodes that run your pods require separate consideration. EKS supports three primary compute options to match different management preferences:
A presentation slide titled "Worker Nodes" with a note that "EKS does not manage worker nodes, it is up to you to setup the worker nodes." Below are three colored boxes labeled 01 Self-managed nodes, 02 Managed node group, and 03 Fargate.
Summary: For full control of the underlying EC2 instances choose self-managed nodes. For EC2-based nodes managed by EKS choose managed node groups. For a serverless experience (no EC2 instances to manage) choose Fargate.
Below is a quick comparison of the three options.

​
Self-managed nodes

When using self-managed nodes you provision EC2 instances yourself, install and configure Kubernetes worker components (kubelet, kube-proxy), choose and configure a container runtime, manage OS updates and security patches, and ensure nodes register with the cluster. This gives maximum control but also maximum operational responsibility.
A presentation slide titled "Self-managed Nodes" that lists responsibilities like manually provisioning EC2 instances, installing Kubernetes worker processes, applying updates/patches, and registering nodes with the control plane. Below those points is a diagram of a worker node showing AWS/EC2 icons and components labeled kubelet, kube-proxy, and container runtime.

​
Managed node groups

Managed node groups automate provisioning and lifecycle management of EC2 worker nodes for EKS. Node groups run EKS-optimized AMIs and are created into Auto Scaling groups that EKS can manage. This reduces much of the operational overhead compared to fully self-managed EC2 nodes.
An infographic titled "Managed Node Group" that lists features of AWS EKS managed node groups (automates EC2 provisioning and lifecycle, uses EKS‑optimized images, single API management, nodes in Auto Scaling groups). Below is a diagram of worker nodes showing the create → update → terminate lifecycle.

​
Fargate

Fargate for EKS provides a serverless compute option: you do not provision or manage EC2 worker nodes. When pods are scheduled onto Fargate, AWS provisions and manages the compute resources for those pods and charges at pod-level resource granularity. Fargate is ideal when you want to eliminate node management.
A presentation slide about AWS Fargate describing it as a serverless container service that creates worker nodes on demand and integrates with EKS. The right side shows a diagram of EKS/Fargate and multiple worker servers with Docker whale icons.

​
Creating an EKS cluster — key inputs and considerations

When creating an EKS cluster, plan for the following inputs and configuration:
  • Cluster name and Kubernetes version.
  • An IAM role for the EKS control plane (EKS service role).
  • Compute configuration: self-managed nodes, managed node groups, or Fargate.
  • Storage classes, PersistentVolume options, and any required secrets.
  • The VPC and subnets where the cluster and worker nodes will run.
  • Security groups and network configuration to control traffic to and from the cluster.
A presentation slide titled "Creating EKS Cluster" with bullet points for setup steps (cluster name/k8s version, IAM role, nodes, storage, secrets, VPC/subnets, security group). To the right is a simple AWS diagram showing an EKS icon linking to S3/other services and a VPC containing two AZs with worker node icons.

​
Creating worker nodes

For node groups, select instance types and set minimum, desired, and maximum capacity. Associate the node group with the EKS cluster so nodes automatically join the cluster and register with the control plane.
A presentation slide titled "Creating Worker Nodes" with bullet steps: create node group, select instance type, and define min/max number of nodes. To the right is a diagram showing a Worker containing a Node Group with two instance (chip) icons.

​
Connecting to your EKS cluster (kubectl)

To interact with an EKS cluster using kubectl, your kubeconfig must include the cluster endpoint and credentials. The AWS CLI provides a helper to update kubeconfig:
This command configures a kubeconfig context that kubectl uses to communicate with the EKS control plane.

​
How to create an EKS cluster

There are multiple ways to create an EKS cluster depending on your preference for UI, CLI, or Infrastructure as Code:
  • AWS Management Console: step-through creation, optionally sets up worker nodes, and can configure kubeconfig for you.
  • eksctl: a focused CLI that simplifies cluster creation and lifecycle operations.
  • Infrastructure as Code (IaC): use Terraform, Pulumi, or AWS CloudFormation to define clusters and node groups for repeatability and version control.
A slide titled "Different Ways to Create Cluster" listing three options: AWS Console, eksctl, and IaC (Terraform/Pulumi). There's a small © Copyright KodeKloud note at the bottom.

​
Best-practice tips

  • Prefer managed node groups or Fargate unless you specifically require host-level access.
  • Keep the control plane Kubernetes version up to date and follow the EKS deprecation schedule.
  • Use AWS IAM Authenticator and Kubernetes RBAC to control cluster access.
  • Integrate with AWS services (CloudWatch, Secrets Manager, ALB/ELB) using the official AWS integrations for EKS.

Watch Video