This chapter covers Amazon Elastic Kubernetes Service (Amazon EKS), a managed Kubernetes service that simplifies running containerized applications on AWS. For the CLF-C02 exam, this topic falls under Domain 3: Cloud Technology Services, Objective 3.1 (Define the core AWS services and their use cases). While container services are a smaller portion of the exam (approximately 5-8% of total questions), understanding EKS is crucial for distinguishing between AWS compute options. You will learn what EKS is, how it differs from self-managed Kubernetes and Amazon ECS, and the key concepts tested on the exam.
Jump to a section
Imagine you're a music producer organizing a huge concert with multiple bands. Each band has its own instruments, sheet music, and setup. Managing them all manually — setting up stages, tuning instruments, coordinating start times — would be a nightmare. Amazon EKS is like hiring a world-class conductor who handles all that for you. The conductor (EKS control plane) decides which band plays when, ensures the stage (EC2 or Fargate) is ready, and automatically replaces any musician who falls ill (failed container). The conductor also manages the sheet music (Kubernetes manifests) and keeps the audience (users) happy by ensuring the show goes on without interruption. You, the producer, only need to write the sheet music and decide which bands to hire; the conductor takes care of everything else. But unlike a human conductor, EKS's conductor is replicated across multiple availability zones for high availability, and if the conductor's podium fails, another one takes over instantly. This is exactly how Amazon EKS manages Kubernetes clusters: you provide the container images and configuration, and EKS runs the Kubernetes control plane across multiple AZs, automatically scaling and healing the cluster.
What is Amazon EKS and What Problem Does It Solve?
Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service that makes it easy to run Kubernetes on AWS without needing to install, operate, and maintain your own Kubernetes control plane or worker nodes. Kubernetes is an open-source container orchestration platform that automates deploying, scaling, and managing containerized applications. However, setting up and managing a Kubernetes cluster is complex and time-consuming. You must handle the control plane (the brains of the cluster), etcd (key-value store), API server, scheduler, and controller managers, plus ensure high availability and security. EKS abstracts this complexity by providing a fully managed control plane that is highly available across multiple Availability Zones (AZs). AWS automatically handles patching, scaling, and upgrades of the control plane, so you can focus on deploying and managing your applications.
How Amazon EKS Works
EKS consists of two main components: the control plane and worker nodes.
Control Plane: The Kubernetes control plane is managed by AWS. It runs in a separate VPC that AWS owns and is spread across multiple AZs for high availability. The control plane includes the Kubernetes API server, etcd (encrypted at rest), scheduler, and controller manager. AWS automatically scales the control plane based on load and performs upgrades with no downtime. You cannot access the control plane nodes directly; you interact via the Kubernetes API (kubectl) or the AWS Management Console.
Worker Nodes: These are the EC2 instances or Fargate tasks that run your containerized applications. You can choose to run worker nodes on:
Amazon EC2: You provision EC2 instances that register with the EKS cluster. You manage the instances (patching, scaling) or use managed node groups where AWS handles scaling and updates.
AWS Fargate: A serverless compute engine that runs containers without managing underlying instances. You define a Fargate profile, and EKS schedules pods on Fargate automatically. This reduces operational overhead but may have limitations (e.g., no daemonsets).
EKS also integrates with other AWS services: - Amazon ECR for container image storage. - IAM for authentication (via aws-iam-authenticator or IAM roles for service accounts). - VPC for networking using the Amazon VPC CNI plugin (assigns IP addresses from your VPC to pods). - ALB/NLB for load balancing via the AWS Load Balancer Controller. - CloudWatch for logging and metrics. - AWS Shield and AWS WAF for security.
Key Tiers, Configurations, and Pricing
Pricing: EKS charges per cluster per hour (currently $0.10 per hour for each cluster, prorated to the second). You also pay for the underlying resources (EC2 instances, Fargate vCPU/memory, EBS volumes, etc.). There is no upfront cost or minimum commitment.
Cluster Types: - Standard clusters with EC2 worker nodes. - Fargate clusters where all pods run on Fargate. - Outposts clusters for on-premises.
Versions: EKS supports multiple Kubernetes versions; you can choose the version when creating a cluster. AWS supports each version for 12 months after release.
Node Groups: - Managed node groups: AWS manages the EC2 instances (launch templates, scaling, updates). - Self-managed nodes: You manage the instances manually.
Networking: EKS uses the Amazon VPC CNI plugin for networking. Each pod gets an IP address from your VPC subnet, enabling direct communication with other services. You must ensure sufficient IP addresses in your subnets.
Security: - IAM roles for service accounts (IRSA): Allows pods to assume IAM roles. - Pod security policies (deprecated in newer versions) or OPA/Gatekeeper. - Encryption at rest for etcd.
Comparison to On-Premises or Self-Managed Kubernetes
On-premises Kubernetes requires you to provision servers, install Kubernetes, configure networking, storage, monitoring, and manage high availability. You are responsible for patching, upgrades, and security. With EKS, AWS handles the control plane, reducing operational burden. However, you still manage worker nodes (unless using Fargate). EKS also integrates seamlessly with other AWS services, which is harder to replicate on-premises.
When to Use Amazon EKS vs Alternatives
Use EKS when you need Kubernetes portability (e.g., hybrid cloud) or have existing Kubernetes expertise. It's ideal for complex microservices that require Kubernetes features like custom resource definitions (CRDs), Helm charts, or advanced scheduling.
Use Amazon ECS if you want a simpler, AWS-native container orchestration that is easier to set up and manage, especially if you don't need Kubernetes portability.
Use AWS Fargate (with either ECS or EKS) to avoid managing servers entirely.
Use AWS Lambda for event-driven, short-lived functions, not long-running containers.
The exam often tests the difference between ECS and EKS: ECS is AWS-proprietary, while EKS is managed Kubernetes (open-source).
Create an EKS Cluster
You start by creating an EKS cluster using the AWS Management Console, CLI, or infrastructure as code (CloudFormation, Terraform). You specify the Kubernetes version, the VPC and subnets (at least two subnets in different AZs for high availability), and optionally enable logging. AWS then provisions a highly available control plane across three AZs. The control plane is managed by AWS and is not visible in your account. This process typically takes 10-15 minutes. You also need to create an IAM role for the EKS cluster (AmazonEKSClusterPolicy) that allows EKS to call other AWS services on your behalf.
Configure kubectl for Your Cluster
After the cluster is active, you configure kubectl (the Kubernetes command-line tool) to communicate with your cluster. You use the AWS CLI command `aws eks update-kubeconfig --region region --name cluster-name`. This creates or updates a kubeconfig file with the cluster endpoint and authentication details. Authentication is handled by the aws-iam-authenticator, which maps IAM users/roles to Kubernetes RBAC users. You must also create an IAM role or user that has permission to call the EKS API (e.g., AmazonEKSClusterPolicy).
Add Worker Nodes (EC2 or Fargate)
You need worker nodes to run your pods. For EC2, you create a managed node group: specify the instance type, desired/min/max size, and a node group role (AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, AmazonEC2ContainerRegistryReadOnly). AWS launches EC2 instances that automatically join the cluster. For Fargate, you create a Fargate profile: specify a namespace selector, and pods scheduled in that namespace run on Fargate without managing instances. You also need to set up subnets for Fargate (private subnets with a NAT gateway if the pods need internet access).
Deploy a Sample Application
With the cluster ready, you deploy a sample application using a Kubernetes deployment manifest. For example, you create a YAML file for an nginx deployment with 3 replicas, then run `kubectl apply -f deployment.yaml`. Kubernetes schedules the pods on available worker nodes. You can expose the deployment via a LoadBalancer service, which triggers the AWS Load Balancer Controller to provision an ALB or NLB. The service gets a DNS name, and you can access the application. You can also use `kubectl get pods` to verify the pods are running.
Monitor and Scale the Cluster
You can monitor cluster and pod metrics using CloudWatch Container Insights, which collects metrics like CPU, memory, network, and disk. You can enable horizontal pod autoscaling (HPA) based on CPU/memory or custom metrics, and cluster autoscaling (using the Kubernetes Cluster Autoscaler or Karpenter) to add/remove worker nodes based on pod resource requests. For Fargate, scaling is automatic — you don't need to manage nodes. You also set up logging for the control plane (API server, audit, authenticator, scheduler, controller manager) to CloudWatch Logs.
Scenario 1: Migrating a Legacy Monolith to Microservices on Kubernetes A financial services company wants to break a monolithic application into microservices to improve scalability and deployment frequency. They choose EKS because their development team has Kubernetes experience and they want to avoid vendor lock-in. They use EKS with managed node groups (EC2) to run their services. The team uses Helm charts for packaging and AWS CodePipeline for CI/CD. They benefit from automatic control plane upgrades and integration with AWS services like RDS for databases and ElastiCache for caching. Cost is driven by the EKS cluster fee ($0.10/hour) plus EC2 instances. They use Spot Instances for stateless services to reduce costs by up to 70%. A common mistake is not properly configuring pod resource requests/limits, leading to inefficient node utilization and higher costs.
Scenario 2: Running Batch Processing Jobs with EKS and Fargate A media processing company runs video transcoding jobs that are intermittent and bursty. They choose EKS with Fargate to avoid provisioning and managing EC2 instances. They deploy a Kubernetes job that processes videos from an S3 bucket. Fargate automatically provisions the right amount of vCPU and memory for each pod. They use IAM roles for service accounts to grant pods access to S3. Cost is based on Fargate vCPU and memory per second, which is higher than EC2 for sustained workloads but cost-effective for bursty jobs. A pitfall is hitting Fargate limits (e.g., max 4 vCPU, 30 GB memory per pod) or not setting appropriate pod resource requests, causing over-provisioning.
Scenario 3: Hybrid Cloud with EKS on AWS Outposts A retail company has latency-sensitive applications that must run on-premises due to data residency requirements. They use Amazon EKS on AWS Outposts, which extends the EKS control plane and worker nodes to their data center. This gives them a consistent Kubernetes experience across cloud and on-premises. They manage the Outposts hardware but AWS manages the EKS control plane. They use local storage and networking. Misconfiguration often occurs when networking between Outposts and the parent AWS Region is not properly set up, causing connectivity issues.
What CLF-C02 Tests on EKS The CLF-C02 exam tests your understanding of Amazon EKS as a managed Kubernetes service. You should know:
EKS is a managed service for running Kubernetes on AWS.
EKS manages the control plane; you manage worker nodes (EC2) or use Fargate.
EKS is different from Amazon ECS (AWS-proprietary container orchestration).
EKS integrates with IAM, VPC, CloudWatch, and other AWS services.
Pricing: per cluster per hour + resources.
Common Wrong Answers and Why Candidates Choose Them 1. "EKS is a serverless container service." (Wrong: EKS is not serverless by default; Fargate is the serverless option for EKS. Candidates confuse managed with serverless.) 2. "EKS requires you to manage the control plane." (Wrong: EKS manages the control plane. Candidates think managed means you still have to do some management.) 3. "EKS only supports Fargate." (Wrong: EKS supports EC2 and Fargate. Candidates may have heard Fargate is serverless and assume it's the only option.) 4. "EKS is cheaper than ECS." (Wrong: Both have similar pricing per cluster; EKS has a $0.10/hour fee, ECS has no cluster fee but you pay for resources. Candidates may confuse cost models.)
Specific Terms That Appear on the Exam - "Control plane" (managed by AWS) - "Worker nodes" (EC2 or Fargate) - "Amazon EKS" vs "Amazon ECS" - "AWS Fargate" (serverless compute for containers) - "kubectl" (Kubernetes CLI) - "Amazon ECR" (container registry) - "IAM roles for service accounts" (IRSA)
Tricky Distinctions - ECS vs EKS: ECS is AWS-native, EKS is managed Kubernetes (open-source). The exam may ask which service is best for portability (EKS). - Fargate vs EC2: Fargate is serverless (no node management), EC2 requires managing instances. - EKS vs self-managed Kubernetes on EC2: EKS manages control plane; self-managed you manage everything.
Decision Rule for Multi-Choice Questions If a question asks about running Kubernetes on AWS with minimal operational overhead for the control plane, choose Amazon EKS. If it asks about a service that is AWS-proprietary and simpler for container orchestration, choose Amazon ECS. If the question mentions "serverless containers" without specifying orchestration, consider Fargate (which can be used with both ECS and EKS).
Amazon EKS is a managed Kubernetes service that runs the control plane across multiple AZs for high availability.
EKS supports both EC2 and Fargate worker nodes; EC2 gives more control, Fargate is serverless.
Pricing: $0.10 per hour per cluster plus resources (EC2, Fargate, storage).
EKS integrates with IAM (IRSA), VPC (CNI), CloudWatch, ALB/NLB, and ECR.
EKS is ideal for organizations that need Kubernetes portability or have existing Kubernetes expertise.
On the exam, distinguish EKS (managed Kubernetes) from ECS (AWS-native) and from self-managed Kubernetes on EC2.
Common wrong answer: calling EKS serverless (it's managed, but not serverless unless using Fargate).
EKS control plane is fully managed; you do not have access to control plane nodes.
These come up on the exam all the time. Here's how to tell them apart.
Amazon EKS (Managed Kubernetes)
Uses open-source Kubernetes (portable across clouds)
Managed control plane; you manage worker nodes or use Fargate
Charges $0.10 per cluster per hour
Requires Kubernetes expertise (kubectl, YAML manifests)
Supports custom resource definitions (CRDs) and Helm charts
Amazon ECS (AWS-Native Container Orchestration)
AWS-proprietary orchestration (vendor lock-in)
Fully managed; you define tasks and services
No cluster fee; pay for resources (EC2/Fargate)
Simpler to set up with AWS console and CLI
Native integration with AWS services (CloudWatch, IAM, etc.)
EKS with EC2 Worker Nodes
You manage EC2 instances (patching, scaling, upgrades)
You pay for EC2 instances (per hour) + EKS cluster fee
Supports all Kubernetes features (daemonsets, privileged pods)
You can use Spot Instances for cost savings
You control instance types and capacity
EKS with AWS Fargate
AWS manages the underlying infrastructure (serverless)
You pay per vCPU and memory per second (no EC2 cost)
Limited to Fargate-supported features (no daemonsets, max 4 vCPU per pod)
No Spot Instances; pricing is higher than EC2 for sustained workloads
You define Fargate profiles; pods are scheduled automatically
Mistake
Amazon EKS is a serverless container service.
Correct
EKS is a managed Kubernetes service, not serverless by itself. You can use AWS Fargate with EKS to run serverless containers, but EKS also supports EC2 worker nodes.
Mistake
You must manage the Kubernetes control plane in EKS.
Correct
AWS fully manages the control plane (API server, etcd, scheduler, etc.). You only manage worker nodes or use Fargate.
Mistake
EKS only supports Fargate for compute.
Correct
EKS supports both EC2 (managed or self-managed node groups) and Fargate. You can mix both in the same cluster.
Mistake
EKS is more expensive than running Kubernetes on EC2 yourself.
Correct
EKS adds a $0.10/hour cluster fee, but you save operational costs of managing the control plane. For many, total cost of ownership is lower with EKS.
Mistake
EKS and ECS are the same service.
Correct
EKS is managed Kubernetes (open-source); ECS is AWS's proprietary container orchestration. They have different APIs, features, and use cases.
Amazon EKS is a managed Kubernetes service that allows you to run open-source Kubernetes on AWS. Amazon ECS is AWS's proprietary container orchestration service. EKS is portable across clouds (Kubernetes standard), while ECS is tightly integrated with AWS. EKS charges a $0.10/hour cluster fee; ECS has no cluster fee but charges for resources. On the exam, choose EKS when portability is key, and ECS for simpler, AWS-native orchestration.
Yes, Amazon EKS supports Windows containers for worker nodes running Windows Server 2019 or 2022. You can create managed node groups with Windows AMIs. However, the control plane is always Linux-based. Windows containers have some limitations, such as no support for Fargate and certain Kubernetes features like HostProcess containers. For the exam, know that EKS supports both Linux and Windows worker nodes.
The EKS control plane is deployed across three Availability Zones (AZs) in a region. If one AZ fails, the control plane continues to operate from the other two. Worker nodes can be distributed across multiple AZs for application high availability. You should also use multiple subnets in different AZs when creating the cluster. The exam may ask about this: EKS control plane is highly available by default.
A managed node group is a set of EC2 instances that AWS manages: it handles patching, scaling, and updates using a launch template. You only specify the instance type, desired size, and IAM role. A self-managed node group requires you to manually create and join EC2 instances to the cluster, and you are responsible for patching and updates. Managed node groups reduce operational overhead.
Yes, you can use AWS Fargate with EKS by creating a Fargate profile. Pods that match the profile's namespace selectors run on Fargate, which is serverless. You do not manage any EC2 instances. However, Fargate has limitations: no daemonsets, no privileged containers, and a maximum of 4 vCPU and 30 GB memory per pod. For the exam, know that Fargate is an option for EKS compute.
Authentication to EKS uses IAM. You use the AWS CLI to update your kubeconfig, which configures kubectl to use the aws-iam-authenticator. IAM users or roles are mapped to Kubernetes RBAC users. You can also use IAM roles for service accounts (IRSA) to give pods fine-grained permissions. The exam may ask about IRSA as a security feature.
The Amazon VPC Container Network Interface (CNI) plugin is the default networking plugin for EKS. It assigns an IP address from your VPC subnet to each pod, allowing pods to communicate directly with other AWS services and on-premises networks via VPC routing. This eliminates the need for overlay networking. On the exam, know that EKS uses VPC CNI for native VPC networking.
You've just covered Amazon EKS Overview — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?