This chapter dives deep into Amazon Elastic Kubernetes Service (EKS) for the DVA-C02 exam. You will learn how EKS simplifies running Kubernetes on AWS, its core components, and how to deploy and manage containerized applications at scale. EKS appears in approximately 5-10% of exam questions, often in scenarios involving container orchestration, CI/CD pipelines, and integration with other AWS services. Mastering EKS is crucial for developers building microservices architectures on AWS.
Jump to a section
Imagine you are hosting a symphony concert. You need to coordinate dozens of musicians, each with their own instrument, sheet music, and timing. Without a conductor, chaos ensues—musicians start at different times, instruments clash, and the performance fails. An orchestra conductor solves this by providing a unified beat, cueing sections, and ensuring everyone plays in harmony. Amazon EKS is like hiring a world-class conductor for your Kubernetes orchestra. Instead of building your own podium, hiring musicians, and managing sheet music distribution, EKS provides the conductor (control plane) for free—it manages the Kubernetes master nodes, handles API server scaling, and ensures etcd data is replicated and backed up. You, the developer, only need to bring your worker nodes (the musicians) and deploy your containerized applications (the sheet music). The conductor (EKS) automatically adjusts tempo (scales control plane) and handles failures (replaces unhealthy master components). Just as a conductor doesn't play an instrument, EKS's control plane doesn't run your application pods—it orchestrates them. This separation allows you to focus on composing your music (writing microservices) while EKS ensures the orchestra plays in perfect sync.
What is Amazon EKS and Why It Exists
Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that reduces the complexity of running Kubernetes control planes on AWS. Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and management of containerized applications. However, managing the Kubernetes control plane—which includes the API server, etcd, scheduler, and controller manager—requires significant operational overhead. EKS eliminates this by providing a highly available, scalable, and secure control plane managed by AWS. You only pay for the worker nodes (EC2 instances or Fargate) and any additional resources you use.
EKS is certified Kubernetes conformant, meaning it passes the Cloud Native Computing Foundation (CNCF) conformance tests. This ensures that applications running on EKS are fully compatible with standard Kubernetes tooling (e.g., kubectl, Helm). For the DVA-C02 exam, understanding EKS's role in the AWS container ecosystem—alongside ECS and Fargate—is essential.
How EKS Works Internally
EKS separates the control plane from the data plane. The control plane runs in an AWS-managed account, while the data plane (worker nodes) runs in your AWS account. The control plane consists of: - API Server: The front-end for Kubernetes, handling all REST API requests. It is automatically scaled by AWS across three Availability Zones (AZs) within a region for high availability. - etcd: A distributed key-value store that holds all cluster data. AWS manages etcd with automatic backups and encryption at rest using AWS KMS. - Scheduler: Assigns pods to nodes based on resource requirements and constraints. - Controller Manager: Runs controllers that handle replication, endpoints, and other cluster-level functions.
Worker nodes can be EC2 instances (managed by node groups) or AWS Fargate (serverless). Node groups are Auto Scaling groups of EC2 instances that register with the EKS cluster. Fargate runs pods directly without managing underlying instances.
Key Components, Values, and Defaults
Cluster Endpoint: The API server endpoint (e.g., https://<cluster-id>.gr7.us-east-1.eks.amazonaws.com). By default, it is public, but you can enable private access.
Cluster Security Group: Controls traffic to the API server. Default rules allow inbound HTTPS from the internet (if public) and from worker nodes.
Node IAM Role: Required for nodes to interact with EKS and pull images from ECR. The managed policy AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, and AmazonEC2ContainerRegistryReadOnly are typically attached.
Pod Execution Role (Fargate): Required for Fargate pods to assume an IAM role.
Kubernetes Version: EKS supports multiple versions simultaneously (e.g., 1.27, 1.28). You must upgrade within the supported window.
Default Pod Networking: Each pod gets an IP address from the VPC subnet via the Amazon VPC CNI plugin. This allows pods to have the same IP as a VPC network interface, enabling direct communication with other VPC resources.
Storage: EBS CSI driver for block storage, EFS CSI driver for shared file storage, and FSx for Lustre for high-performance computing.
Configuration and Verification Commands
To create an EKS cluster using eksctl:
eksctl create cluster --name my-cluster --region us-east-1 --nodegroup-name standard-workers --node-type t3.medium --nodes 3 --nodes-min 1 --nodes-max 4To verify cluster status:
kubectl cluster-info
kubectl get nodes
aws eks describe-cluster --name my-cluster --region us-east-1To update kubeconfig:
aws eks update-kubeconfig --region us-east-1 --name my-clusterHow EKS Interacts with Related Technologies
IAM: EKS integrates with IAM for authentication via the aws-auth ConfigMap. Users and roles mapped in this ConfigMap can access the cluster.
ECR: EKS nodes pull container images from ECR. The node IAM role must have permission.
VPC: EKS clusters run within a VPC. Subnet tags (e.g., kubernetes.io/cluster/<cluster-name>: shared) are required for load balancers.
ALB/NLB: AWS Load Balancer Controller provisions ALBs for Ingress resources and NLBs for Services of type LoadBalancer.
CloudWatch: Container logs can be sent to CloudWatch Logs via Fluentd or CloudWatch agent.
Secrets Manager/SSM: Secrets can be mounted as volumes or environment variables using the Secrets Store CSI driver.
Security Best Practices
Restrict public access to the API server endpoint; use private endpoint if possible.
Enable audit logging to CloudWatch Logs for all API calls.
Use IAM roles for service accounts (IRSA) to grant fine-grained permissions to pods.
Encrypt secrets at rest using KMS (EKS supports envelope encryption for etcd).
Regularly update Kubernetes versions and apply security patches.
Monitoring and Logging
Amazon CloudWatch Container Insights: Collects metrics (CPU, memory, network) and logs from pods and nodes.
Prometheus/Grafana: Open-source monitoring stack can be deployed on EKS.
kubectl top: Shows resource usage of nodes and pods.
Common Deployment Patterns
Microservices: Deploy multiple small services that communicate via service discovery (CoreDNS) or service mesh (App Mesh, Istio).
CI/CD: Use CodePipeline, CodeBuild, and CodeDeploy to build and deploy containers to EKS. ArgoCD or Flux for GitOps.
Batch Jobs: Use Kubernetes Jobs and CronJobs for batch processing.
Stateful Workloads: Use StatefulSets with EBS or EFS for databases (e.g., PostgreSQL on EBS).
Scaling
Horizontal Pod Autoscaler (HPA): Scales pods based on CPU/memory or custom metrics.
Vertical Pod Autoscaler (VPA): Adjusts pod resource requests.
Cluster Autoscaler: Scales worker node groups based on pending pods.
Fargate: Automatically scales pods without managing nodes.
Cost Optimization
Use Spot Instances for worker nodes (via node groups or Karpenter).
Right-size pods with appropriate resource requests/limits.
Use Fargate for burstable or unpredictable workloads.
Delete unused clusters and resources.
Troubleshooting
Pod stuck in Pending: Often due to insufficient resources or taints/tolerations. Check kubectl describe pod.
Node not ready: Check kubelet logs, IAM role, and VPC connectivity.
Cannot pull image: Verify ECR permissions and Docker credentials.
Load balancer not created: Check subnet tags and service annotations.
Integration with AWS Developer Tools
AWS CodeBuild: Can build Docker images and push to ECR.
AWS CodeDeploy: Supports EKS via blue/green deployments.
AWS App Mesh: Service mesh for observability and traffic control.
AWS X-Ray: Distributed tracing for microservices.
Exam Relevance
For DVA-C02, focus on:
Differences between ECS and EKS.
How to authenticate to EKS (kubectl, aws eks get-token).
IAM roles for service accounts (IRSA).
Using ConfigMap aws-auth for RBAC.
Storage options (EBS, EFS, FSx).
Load balancing (NLB vs ALB).
Updating kubeconfig.
Troubleshooting common issues.
Create an EKS Cluster
Use eksctl, AWS CLI, or CloudFormation to create a cluster. eksctl is the simplest: `eksctl create cluster --name my-cluster --region us-east-1`. This provisions a control plane spanning three AZs, creates a CloudFormation stack for VPC, subnets, and security groups, and sets up a default node group. The API server endpoint is created with a public DNS name. The process takes 10-15 minutes. AWS manages the control plane's etcd backups, API server scaling, and health checks. You cannot SSH into control plane nodes.
Configure kubectl
Update your kubeconfig to point to the new cluster using `aws eks update-kubeconfig --region us-east-1 --name my-cluster`. This command retrieves the cluster endpoint and certificate authority data from AWS and merges it into your kubeconfig. It also sets up authentication using the `aws eks get-token` command, which generates a bearer token based on your AWS credentials (IAM user or role). Verify connectivity with `kubectl cluster-info`.
Add Worker Nodes
If you didn't create node groups with the cluster, add them manually. Use `eksctl create nodegroup --cluster my-cluster --nodegroup-name standard-workers --node-type t3.medium --nodes 3`. This creates an Auto Scaling group of EC2 instances that automatically register with the cluster. Each node runs the EKS-optimized AMI, which includes kubelet, Docker, and the AWS CNI plugin. Nodes are assigned an IAM role with policies for EKS, ECR, and CloudWatch. The node group can be scaled manually or with Cluster Autoscaler.
Deploy an Application
Create a deployment YAML file (e.g., nginx-deployment.yaml) and apply it with `kubectl apply -f nginx-deployment.yaml`. The scheduler assigns pods to nodes based on resource requests. The kubelet on each node pulls the image from ECR (or Docker Hub) and starts the container. The AWS CNI plugin assigns a VPC IP address to each pod from the subnet CIDR. Verify with `kubectl get pods -o wide`. Expose the deployment as a Service (e.g., LoadBalancer) to make it accessible.
Scale and Monitor
Enable Horizontal Pod Autoscaler: `kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10`. The HPA controller queries metrics from the metrics server (must be deployed separately) and adjusts replicas. For monitoring, deploy CloudWatch Container Insights using a quick setup script or Helm. This sends cluster metrics and logs to CloudWatch. Use `kubectl top pods` to view current resource usage. If using Cluster Autoscaler, it adds/removes nodes based on pending pods.
Scenario 1: Microservices Migration A fintech company runs 50 microservices on-premises using Kubernetes. They migrate to EKS to reduce operational overhead. They use eksctl to create a cluster with node groups of m5.large instances. Each microservice is deployed as a Deployment with resource requests/limits. They use AWS Load Balancer Controller for ingress to route traffic to services. They enable IRSA so each pod can assume an IAM role to access DynamoDB and S3. They deploy Prometheus and Grafana for monitoring. Performance: 10k requests/second with 99th percentile latency under 200ms. Common issues: misconfigured IAM roles causing pods to fail to access AWS services, and forgetting to tag subnets for load balancer discovery.
Scenario 2: Batch Processing with Fargate A media company runs video transcoding jobs on EKS. They use Fargate for serverless pods to avoid managing worker nodes. They create a Fargate profile that selects namespaces and labels. Jobs are submitted as Kubernetes Jobs; each job runs a container that pulls raw video from S3, transcodes using FFmpeg, and uploads the result. Fargate automatically scales pods based on job queue. They use CloudWatch Events to trigger jobs via a custom scheduler. Cost: they pay only for vCPU and memory used during job execution. Issues: cold start latency (10-20 seconds) for Fargate pods, and hitting Fargate limits (e.g., max 4 vCPU, 30 GB memory per pod).
Scenario 3: CI/CD Pipeline
A SaaS startup uses EKS for staging and production environments. They use CodePipeline to build Docker images on code commit, push to ECR, and deploy to EKS using kubectl commands in CodeBuild. They use blue/green deployments with AWS CodeDeploy. They use Helm charts to manage releases. They have separate clusters for staging and production to isolate workloads. They use Cluster Autoscaler to handle traffic spikes. Common misconfigurations: not updating kubeconfig in CodeBuild, incorrect IAM permissions for CodeBuild to interact with EKS, and missing aws-auth ConfigMap entries for the CodeBuild role.
Exam Objective Coverage DVA-C02 Domain 1: Development with AWS Services. Objective 1.1: Develop containerized applications on AWS using ECS or EKS. Key sub-objectives: (a) Choose between ECS and EKS based on requirements, (b) Create and configure an EKS cluster, (c) Deploy applications using kubectl, (d) Integrate with IAM, ECR, and VPC, (e) Implement CI/CD pipelines for EKS.
Most Common Wrong Answers 1. Choosing ECS over EKS for portability: Many candidates think ECS is more portable, but EKS uses standard Kubernetes, which is more portable across clouds. 2. Mistaking Fargate for EC2 launch type: For EKS, Fargate runs pods without nodes, but some think it requires node groups. Fargate is a separate compute option. 3. IAM role confusion: Candidates often attach IAM roles directly to pods instead of using IRSA. The correct way is to use service accounts annotated with IAM roles. 4. Security group management: They think they must manage security groups for pods. In reality, the AWS CNI plugin uses the node's security group.
Specific Numbers and Values - Default pod limit per node: 110 (varies by instance type). - EKS control plane is highly available across 3 AZs by default. - etcd backups: AWS automatically backs up etcd every 5 minutes. - API server endpoint: public by default, can be made private. - Supported Kubernetes versions: typically 3-4 at a time; must upgrade within 12 months of release. - Fargate pod limits: 4 vCPU, 30 GB memory, 20 ENIs per account per region. - EKS cluster creation takes 10-15 minutes.
Edge Cases - Private clusters: If you create a private cluster, you must have a bastion host or VPN to access kubectl. - IPv6: EKS supports IPv6 clusters (dual-stack). - Windows containers: EKS supports Windows worker nodes. - Bottlerocket OS: An open-source Linux distribution optimized for containers; can be used as AMI.
How to Eliminate Wrong Answers - If a scenario mentions 'portability across clouds', EKS is the answer. - If it mentions 'serverless containers', choose Fargate. - If it mentions 'IAM roles for pods', look for IRSA or service account annotations. - If it mentions 'load balancer', consider ALB for HTTP and NLB for TCP.
EKS provides a managed Kubernetes control plane across 3 AZs for high availability.
Worker nodes can be EC2 (via node groups) or Fargate (serverless pods).
Authentication uses IAM via the aws-auth ConfigMap; IRSA for pod-level permissions.
Default pod networking uses AWS VPC CNI, giving each pod a VPC IP address.
EKS cluster endpoint is public by default; can be made private for security.
Fargate pods have limits: max 4 vCPU, 30 GB memory, 20 ENIs per account per region.
EKS supports both Linux and Windows containers, and IPv6 clusters.
Storage options include EBS, EFS, FSx for Lustre, and local instance store.
These come up on the exam all the time. Here's how to tell them apart.
Amazon ECS
AWS-native container orchestration, simpler to learn.
Uses task definitions and services; no Kubernetes knowledge needed.
Control plane is fully managed; no extra cost.
Launch types: EC2 and Fargate.
Less portable; tightly coupled to AWS.
Amazon EKS
Standard Kubernetes, portable across clouds and on-premises.
Requires Kubernetes knowledge; uses pods, deployments, services.
Control plane is managed but you pay $0.10 per hour per cluster.
Compute options: EC2 (node groups) and Fargate (profiles).
Highly portable; can migrate to other Kubernetes clusters.
Mistake
EKS is just a managed version of Kubernetes with no differences.
Correct
EKS manages the control plane, but it also integrates deeply with AWS services (IAM, VPC, ECR, CloudWatch). The control plane is fully managed, but you still manage worker nodes (unless using Fargate).
Mistake
You can SSH into EKS control plane nodes.
Correct
Control plane nodes are managed by AWS and are not accessible. You cannot SSH into them. Only worker nodes (EC2) can be accessed if you configure key pairs.
Mistake
Fargate pods run on the same worker nodes as EC2 pods.
Correct
Fargate runs each pod in its own isolated microVM. There are no shared worker nodes. Fargate pods cannot coexist with EC2 pods on the same node; they are separate.
Mistake
You need to install the Kubernetes dashboard separately on EKS.
Correct
EKS does not come with the dashboard pre-installed. You must deploy it manually if needed. AWS provides CloudWatch and other tools for monitoring.
Mistake
EKS clusters can only use EBS for persistent storage.
Correct
EKS supports multiple storage options: EBS (block), EFS (file), FSx for Lustre (high-performance), and local instance store. The choice depends on workload requirements.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You authenticate using IAM credentials. First, update your kubeconfig with `aws eks update-kubeconfig`. This configures kubectl to use the `aws eks get-token` command to generate a bearer token. The token is valid for 15 minutes. The IAM user or role must be mapped in the `aws-auth` ConfigMap to have Kubernetes RBAC permissions.
ECS is AWS's native container orchestration service, simpler to use but less portable. EKS runs standard Kubernetes, which is more portable across clouds and on-premises. For the exam, if the scenario emphasizes portability or Kubernetes-specific features (e.g., Helm, custom controllers), choose EKS. If it emphasizes simplicity and AWS integration, choose ECS.
Yes. You can create node groups with Spot Instances by specifying a mixed instances policy or using Karpenter. Spot Instances can be interrupted, so use pod disruption budgets and handle interruptions gracefully. Fargate does not support Spot.
Use IAM roles for service accounts (IRSA). Create an IAM role with a trust policy that allows the OIDC provider associated with your EKS cluster to assume it. Annotate the Kubernetes service account with the IAM role ARN. Pods using that service account will inherit the IAM role's permissions.
EKS uses the Amazon VPC CNI plugin for Kubernetes. Each pod receives an IP address from the VPC subnet (secondary IP of the node's ENI). This allows pods to communicate directly with other VPC resources (RDS, EC2) using standard VPC networking. It also enables security group rules for pods.
You can update the control plane using the AWS Management Console, CLI, or eksctl. For example: `eksctl upgrade cluster --name my-cluster --version 1.28`. Worker nodes must be updated separately by replacing them with new AMIs or using managed node group updates. You cannot skip minor versions.
The `aws-auth` ConfigMap in the kube-system namespace maps IAM users/roles to Kubernetes RBAC groups. Without this mapping, IAM entities cannot perform any Kubernetes operations. You can edit it with `kubectl edit configmap aws-auth -n kube-system`.
You've just covered Amazon EKS for Developers — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?