Amazon EKS
Managed Kubernetes on AWS: the managed control plane, node options (managed node groups, self-managed, Fargate, Auto Mode, Hybrid Nodes), access entries and Pod Identity, networking and load balancers, scaling, versions, cost, and monitoring.
8 min read · Last reviewed · SAA-C03
Sign in to bookmark tutorials and track what you have read.
On this page
What it is
Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service. AWS runs the Kubernetes control plane for you, the API (Application programming interface)A defined way for one program to ask another for data or actions, such as a set of HTTPS requests and responses. Every AWS service is controlled through its API, which the console, the CLI, and the SDKs call for you.Glossary entry servers and the etcd database, across three AZ (Availability Zone)An isolated location within an AWS Region, made up of one or more data centers with their own power, cooling, and networking. The AZs in a Region are linked by fast, low-latency connections, so spreading resources across them protects against the failure of one site.Glossary entry, scales it, patches it, and replaces unhealthy instances. You run your workloads on nodes that you choose, and you work with the cluster using standard Kubernetes tools such as kubectl and Helm.
EKS is certified Kubernetes-conformant, so applications and tools built for Kubernetes run on it unchanged. Choose it when a team already uses Kubernetes, needs the Kubernetes ecosystem, or wants to run the same platform across AWS, other clouds, and On-premisesIn data centers or offices that you run yourself, rather than in the cloud. Hybrid architectures connect on-premises systems to AWS, for example through AWS Direct Connect or a VPN.Glossary entry. If you don't need Kubernetes, Amazon ECS is usually simpler.
Compute options for nodes
| Option | You manage | Notes |
|---|---|---|
| EKS Auto Mode | Almost nothing: AWS provisions, scales, patches, and replaces the nodes | Built on Karpenter; also manages load balancing, storage, and networking add-ons. An extra per-instance fee |
| Managed node groups | The node group settings; EKS creates and updates the EC2 instances in an Auto Scaling group | Supports GPU (Graphics processing unit)A processor with thousands of small cores that run many calculations in parallel. GPUs speed up machine learning, graphics, and video work; EC2 instance families such as P and G include them.Glossary entry, Arm, Windows, Spot. An update to a new AMI (Amazon Machine Image)A template for launching EC2 instances: the operating system, software, and settings to copy onto the new instance's volumes, plus who may launch it. AMIs come from AWS, AWS Marketplace, or the community, or you create your own from an instance.Glossary entry launches new nodes and drains the old ones, respecting pod disruption budgets |
| Self-managed nodes | Everything about the EC2 instances | Most control, most work |
| AWS Fargate | Nothing below the pod; a Fargate profile chooses which pods run there | Each pod gets its own isolation boundary. No DaemonSets, privileged containers, GPUs, or EBS volumes; SubnetA range of IP addresses in a VPC, inside one Availability Zone. A subnet is public when its route table sends internet traffic to an internet gateway, and private when it does not.Glossary entry only; EFS works |
| EKS Hybrid Nodes | Your own on-premises or edge servers, joined to a cluster whose control plane is in AWS | Needs a reliable connection (Direct Connect or VPN (Virtual private network)An encrypted tunnel over a public network, such as the internet, that joins networks or devices as if they were directly connected. AWS Site-to-Site VPN connects networks; AWS Client VPN connects individual users.Glossary entry); charged per vCPU-hour |
| EKS on AWS Outposts | Self-managed nodes on an AWS-owned, AWS-managed Outposts rack in your data center | A local cluster runs the AWS-managed control plane on the Outpost too, so it keeps working when the link to AWS is cut and suits data residency; an extended cluster keeps the control plane in the AWS RegionA separate geographic area where AWS runs its services, such as us-east-1 in Northern Virginia, made up of several Availability Zones. Most resources live in one Region; you choose Regions for latency, data residency, and the services you need.Glossary entry |
You can mix options in one cluster. Node versions are not upgraded automatically when the control plane is: upgrade managed node groups and self-managed nodes yourself (Auto Mode handles its own nodes).
Security, resilience, performance, and cost
Security
- Who can use the cluster: IAM PrincipalA person or workload that can make requests to AWS, such as an IAM user, a role session, the root user, a federated user, or an AWS service. Resource-based policies name the principals they allow.Glossary entry reach the Kubernetes API through access entries (recommended), managed with the EKS API and console, combined with Kubernetes RBAC (Role-based access control)Granting permissions to roles, such as administrator or developer, and giving people the roles they need, instead of granting permissions to each person. IAM roles and IAM Identity Center permission sets follow this model.Glossary entry or access policies. The older
aws-authConfigMap still works, but access entries are the recommended method. - What pods can do in AWS: give each application its own IAM role through EKS Pod Identity (recommended: no OIDC (OpenID Connect)A sign-in standard built on OAuth 2.0 that lets an application learn who a user is from a trusted identity provider, through a signed ID token. IAM accepts OIDC providers, so that, for example, a GitHub Actions workflow can assume an IAM role.Glossary entry provider to manage, and one trust principal,
pods.eks.amazonaws.com, for all clusters) or IAM roles for service accounts (IRSA), which uses an OIDC provider and also works on Fargate. EKS Pod Identity does not support pods on Fargate, so use IRSA there. Don't rely on the node's IAM role for applications, and restrict pods' access to the instance metadata service. - API endpoint: public by default, protected by IAM and RBAC. You can restrict it to allowed CIDR (Classless Inter-Domain Routing)A notation for a range of IP addresses: an address, a slash, and the number of fixed leading bits, such as 10.0.0.0/16 for 65,536 addresses. VPCs and subnets are defined by CIDR blocks; the smaller the number after the slash, the larger the range.Glossary entry ranges, add private access so node traffic stays in the VPC, or make it private only.
- Encryption: all Kubernetes API data, including Secrets, is envelope encrypted with AWS KMS by default (Kubernetes 1.28 and later), using an AWS owned key or your own Customer managed keyA KMS key that you create, own, and manage: you control its key policy, rotation, and deletion. AWS managed keys, in contrast, are created and managed for you by an AWS service.Glossary entry.
- Network: the Amazon VPC CNI gives pods IP (Internet Protocol)The protocol that addresses and routes packets between networks. Each device has an IP address: IPv4 addresses look like 192.0.2.1, and IPv6 addresses are longer, like 2001:db8::1.Glossary entry addresses from the VPC, and Security groupA stateful virtual firewall for network interfaces, such as an EC2 instance's, whose rules can only allow traffic. Return traffic for allowed connections is allowed automatically, and a rule can refer to another security group instead of IP addresses.Glossary entry for pods can apply security groups to individual pods.
Resilience
- The control plane runs across three Availability Zones, with at least two API server instances and three
etcdinstances, and has an SLA (Service level agreement)A provider's commitment to a level of service, such as a monthly uptime percentage, and what customers receive if it is missed, usually service credits.Glossary entry. - Spread nodes and pods across Availability Zones: use node groups in several subnets, and Kubernetes topology spread constraints and pod disruption budgets.
- Kubernetes Deployments replace failed pods; store state in EBS (through the EBS CSI driver), EFS, or managed databases.
- An EBS volume lives in one Availability Zone and is normally attached to one node, so it suits a single pod's block storage. When pods in several zones must read and write the same files, use Amazon EFS through the EFS CSI driver: a Regional file system that many pods mount at once (also on Fargate, where EBS isn't available).
Performance
- Pods: the Horizontal Pod Autoscaler adds pods on metrics such as CPU; the Vertical Pod Autoscaler right-sizes their requests.
- Nodes: Karpenter launches right-sized EC2 instances for pending pods in under a minute; the Cluster Autoscaler scales Auto Scaling groups; EKS Auto Mode does this for you.
- Load balancing: a Kubernetes Ingress creates an Application Load Balancer, and a Service of type
LoadBalancercreates a Network Load Balancer, through the AWS Load Balancer Controller or Auto Mode. IP targets route straight to pods, and are required for Fargate.
Cost
- Cluster fee: per cluster per hour, $0.10 in standard support and $0.60 in extended support.
- Kubernetes versions: standard support lasts 14 months after a version's EKS release, and extended support adds 12 months at the higher fee. After that, the control plane is upgraded automatically. Upgrade regularly to avoid the extended support charge.
- Compute: pay for EC2 instances, Fargate pods, Auto Mode's per-instance fee, or Hybrid Nodes per vCPU-hour. Save with Spot instances (through Karpenter or managed node groups), Savings Plans, and Graviton. Fargate Spot is not available on EKS.
Monitoring
- Control plane logs (API server, audit, authenticator, controller manager, scheduler) go to CloudWatch Logs; each type is off by default.
- CloudWatch Container Insights, Amazon Managed Service for Prometheus, and Amazon Managed Grafana give metrics and dashboards; the EKS console has an observability dashboard.
- AWS CloudTrail records EKS API calls; Kubernetes audit logs record calls to the Kubernetes API.
EKS or ECS?
| Amazon EKS | Amazon ECS | |
|---|---|---|
| Orchestrator | Kubernetes, standard and portable | AWS's own, simpler |
| Control plane | Managed by AWS; hourly cluster fee | Managed by AWS; no charge |
| Tools | kubectl, Helm, and the Kubernetes ecosystem | AWS console, CLI, CloudFormation, CDK |
| Choose when | You need Kubernetes or portability across environments | You want the simplest AWS-native option |
Reverse mindmap: when the question points here
- Yes, when the question says
- Run existing Kubernetes workloads on AWS leads to Amazon EKS
- Managed Kubernetes control plane across Availability Zones leads to Amazon EKS
- Use kubectl, Helm, and Kubernetes tools leads to Amazon EKS
- Choose the nodes
- Least node management leads to EKS Auto Mode or Fargate
- Pods isolated with no servers leads to Fargate profile
- GPU or DaemonSet workloads leads to Managed node groups
- Roll out new AMIs by draining and replacing nodes leads to Managed node group update
- Kubernetes in our data center on AWS-managed hardware, through disconnects leads to EKS local cluster on Outposts
- On-premises servers as nodes of an EKS cluster leads to EKS Hybrid Nodes
- Secure it
- Give a pod its own AWS permissions leads to EKS Pod Identity or IRSA
- Give an IAM role access to the cluster leads to Access entry
- API server reachable only from the VPC leads to Private endpoint
- Encrypt Kubernetes Secrets with your own key leads to Customer managed KMS key
- Run it well
- Add nodes quickly for pending pods leads to Karpenter
- Shared files for pods in several Availability Zones leads to Amazon EFS with the EFS CSI driver
- Expose an app through an ALB leads to Ingress with the AWS Load Balancer Controller
- Avoid extra cost for old versions leads to Upgrade before extended support
- No, when the question says
- Simplest container option without Kubernetes leads to Amazon ECS
- Kubernetes on premises without an AWS connection leads to EKS Anywhere
Key takeaways
- EKS runs the Kubernetes control plane for you across three Availability Zones; you choose how nodes run.
- Node options: Auto Mode (AWS manages nodes), managed node groups, self-managed nodes, Fargate (no DaemonSets, GPUs, or EBS), and Hybrid Nodes on premises.
- Use access entries for cluster access and EKS Pod Identity (or IRSA) for pod permissions; Kubernetes API data is envelope encrypted with KMS by default.
- Karpenter or Cluster Autoscaler scale nodes; HPA scales pods; Ingress creates ALBs and Services create NLBs.
- Pay $0.10 per cluster-hour, or $0.60 in extended support after 14 months; control plane logs are off by default.
Sources
- Amazon EKS User Guide: What is Amazon EKS?
- Amazon EKS User Guide: Manage compute resources by using nodes
- Amazon EKS User Guide: Simplify node lifecycle with managed node groups
- Amazon EKS User Guide: Update a managed node group for your cluster
- Amazon EKS User Guide: Simplify compute management with AWS Fargate
- Amazon EKS User Guide: Amazon EKS Hybrid Nodes overview
- Amazon EKS User Guide: Deploy Amazon EKS on-premises with AWS Outposts
- Amazon EKS User Guide: Grant IAM users and roles access to Kubernetes APIs
- Amazon EKS User Guide: Learn how EKS Pod Identity grants pods access to AWS services
- Amazon EKS User Guide: Cluster API server endpoint
- Amazon EKS User Guide: Default envelope encryption for all Kubernetes API data
- Amazon EKS User Guide: Understand resilience in Amazon EKS clusters
- Amazon EKS User Guide: Use Kubernetes volume storage with Amazon EBS
- Amazon EKS User Guide: Use elastic file system storage with Amazon EFS
- Amazon EKS User Guide: Scale cluster compute with Karpenter and Cluster Autoscaler
- Amazon EKS User Guide: Route application and HTTP traffic with Application Load Balancers
- Amazon EKS User Guide: Understand the Kubernetes version lifecycle on EKS
- Amazon EKS User Guide: Send control plane logs to CloudWatch Logs
- Amazon EKS pricing