Introduction to EKS
Supported Versions: Amazon EKS standard support 1.34–1.37; extended support 1.31–1.33 (checked October 12, 2026) Last Updated: October 12, 2026
Amazon Elastic Kubernetes Service (EKS) is a managed service for running Kubernetes on AWS. In this chapter, we will explore the basic concepts of EKS, its architecture, and the differences from standard Kubernetes.
EKS and Kubernetes
EKS is a managed service that provides standard Kubernetes APIs. For detailed information about the basic concepts and operation of Kubernetes, refer to the Introduction to Kubernetes document.
Key Benefits of EKS
- Managed Control Plane: AWS manages the availability and scalability of the Kubernetes control plane
- Enhanced Security: Authentication and authorization through integration with AWS IAM
- AWS Service Integration: Seamless integration with other AWS services (ELB, ECR, IAM, etc.)
- Various Compute Options: EC2-based nodes, EKS Auto Mode, Fargate and Hybrid Nodes. Bottlerocket is a node operating system, not a separate compute service
- Auto Scaling: Auto scaling support through Cluster Autoscaler, Karpenter, etc.
- Managed Node Groups: Automated node lifecycle management
EKS Architecture and Components
The overall architecture of Amazon EKS is as follows:
Control Plane
EKS provides a highly available control plane. The control plane runs across multiple availability zones and consists of the following components:
- API Server: Exposes the Kubernetes API and handles interaction with the cluster.
- etcd: A distributed key-value store that stores the cluster state.
- Controller Manager: Runs controllers that manage the cluster state.
- Scheduler: Assigns pods to nodes.
In EKS, these control plane components are managed by AWS, so users don't need to manage them directly.
Data Plane
The EKS data plane can be configured with the following options:
- Managed Node Groups: EC2 node groups whose provisioning and replacement workflow AWS manages. Operators select and initiate node version/AMI updates; a control plane upgrade does not automatically update these nodes.
- Self-Managed Nodes: EC2 instances managed directly by the user.
- AWS Fargate: Per-Pod compute selected through Fargate profiles. Operators still manage workload configuration and resource requests.
- EKS Auto Mode: AWS manages EC2 node provisioning, scaling and updates plus supported networking, load balancing and block storage capabilities.
- Hybrid Nodes: Customer-managed on-premises/edge machines connect to an AWS-hosted EKS control plane; reliable connectivity is required.
Networking
On conventional EC2-based EKS nodes, Amazon VPC CNI is the default and allocates VPC addresses to ordinary Pods. hostNetwork Pods share node networking. Auto Mode manages its own networking capability, while Hybrid Nodes use a compatible on-premises CNI rather than Amazon VPC CNI.
Differences Between Standard Kubernetes and EKS
Management Responsibility
- Self-managed Kubernetes: Operators manage the control plane and data plane; other managed distributions may divide responsibility differently.
- EKS: AWS manages the control plane. Data plane responsibility depends on the compute option. Workload security, identity, configuration, availability and data protection remain customer responsibilities.
Networking
- Standard Kubernetes: You can choose from various CNI plugins.
- EKS: Conventional EC2-based clusters default to Amazon VPC CNI. Alternative CNIs and Auto Mode/Hybrid Nodes have different feature and support constraints.
Load Balancing
- Standard Kubernetes: A separate controller must be installed to use
LoadBalancertype services. - EKS: On a conventional cluster, install and authorize AWS Load Balancer Controller for NLB Services and ALB Ingresses; the legacy controller can create Classic Load Balancers. Auto Mode provides managed NLB/ALB integration with its own classes and supported configuration. A Service type alone does not identify the controller. Fargate supports ALB/NLB IP targets.
Storage
- Standard Kubernetes: Various storage drivers must be installed and configured manually.
- EKS: On a conventional cluster, install the EBS CSI driver/add-on and grant its IAM permissions. Auto Mode has managed EBS support with provisioner
ebs.csi.eks.amazonaws.com, distinct fromebs.csi.aws.com. EFS and FSx integrations have separate prerequisites; EBS volumes cannot be mounted by Fargate or Hybrid Nodes.
EKS Cost Structure
The costs incurred when operating an EKS cluster are as follows:
- EKS Control Plane Cost: An hourly fee is charged per cluster, with different standard/extended-support pricing and additional charges for optional provisioned control plane tiers.
- Compute Costs:
- EC2 instances (managed or self-managed nodes)
- Fargate (charged based on pod runtime and resource usage)
- Storage Costs: Costs for storage services such as EBS, EFS, FSx
- Network Costs: Data transfer, NAT gateways, public IPv4 addresses and load balancer usage costs
- Managed Capability Costs: Auto Mode, EKS Capabilities and Hybrid Nodes have their own charges in addition to the relevant cluster/infrastructure costs.
Cost Optimization Strategies
- Use Spot Instances: Compare current Spot prices and interruption tolerance; advertised savings are not a workload-level guarantee.
- Evaluate Fargate: Compare provisioned Pod sizes, running time, feature limits and operational effort with EC2. Low application utilization alone does not guarantee savings.
- Configure Auto Scaling: Automatically scale nodes up and down as needed.
- Locality Routing: Where supported, prefer same-zone traffic while retaining adequate capacity and failover. Routing and load balancer settings determine any transfer savings.
- EKS Auto Mode: Evaluate automatic scaling and consolidation savings together with the Auto Mode management charge.
- Hybrid Nodes: Evaluate existing on-premises capacity together with per-vCPU Hybrid Nodes charges and connectivity/operations costs. This feature is not a synonym for mixing EC2 instance types.
Integration with AWS Services
EKS integrates with the following AWS services:
- IAM: IAM identities authenticate to the cluster; EKS access entries authorize through access policies and/or Kubernetes RBAC groups. Pod Identity and IRSA separately grant workloads AWS permissions.
- VPC: Provides networking infrastructure.
- CloudWatch: Provides monitoring and logging.
- ALB/NLB: Provides load balancing.
- ECR: Provides container image registry.
- EBS/EFS/FSx: Provides persistent storage.
- AWS App Mesh: AWS ended support on September 30, 2026, and the App Mesh console and resources are no longer accessible. Existing integrations must migrate; do not select it for a new deployment.
- AWS Certificate Manager: Manages SSL/TLS certificates.
- AWS Secrets Manager: Securely stores and manages sensitive information.
- AWS SageMaker: Runs machine learning workloads.
- AWS Bedrock: Leverages generative AI models.
EKS Best Practices
- Cluster Design:
- Deploy nodes across multiple availability zones
- Select appropriate instance types
- Establish node group strategy
- Security:
- Apply the principle of least privilege
- Implement network policies
- Apply Pod Security Standards using Pod Security Admission and/or admission policies; the PodSecurityPolicy API was removed in Kubernetes 1.25
- Image scanning and vulnerability management
- Networking:
- Proper subnet design
- Security group configuration
- Leverage Locality Routing
- Monitoring and Logging:
- Enable CloudWatch Container Insights
- Configure control plane logging
- Leverage Prometheus and Grafana
- Upgrade Strategy:
- Plan regular upgrades
- Consider blue/green deployment strategy
- Perform testing before upgrades
Official references
- EKS version lifecycle
- Compute and shared responsibilities
- AWS Load Balancer Controller
- EBS CSI and Auto Mode
- Hybrid Nodes
- Fargate considerations
- App Mesh support notice
- EKS pricing
- Pod Security Admission
Quiz
To test what you learned in this chapter, try the Amazon EKS Introduction Quiz.
