What Is Amazon EKS? Kubernetes, Rented

Amazon EKS (Elastic Kubernetes Service) is AWS's managed Kubernetes service — AWS runs the Kubernetes control plane (the API server, the etcd database, the scheduler) across three Availability Zones, and you connect worker nodes to run your containerized applications. But here is the part almost nobody tells you: EKS is not Kubernetes with the hard parts removed. It is Kubernetes with exactly one hard part removed — the control plane. The node upgrades, the security patching, the storage drivers, the pod networking, the autoscaling configuration: all still yours. What AWS takes off your plate is the part most likely to die at 3 AM. What you keep is everything you touch on a Tuesday afternoon.

That distinction — control plane managed, everything else yours — is the single most misunderstood fact about EKS, and it shapes every cost, every operational decision, and every 3 AM page you will ever get from this service. Kubernetes itself is an open-source system with dozens of interlocking components. AWS takes the hardest-to-run set of those components (the API server, the etcd database, the scheduler, the controller manager) and runs them for you, across three Availability Zones, with automatic replacement of unhealthy instances. That is genuinely valuable — running etcd yourself is the kind of thing that ages platform engineers prematurely. But the nodes where your containers actually execute? The pod networking? The load balancer integration? The storage drivers? Those are still your problem in standard EKS, and the recent EKS Auto Mode exists precisely because enough people hit that wall that AWS built a product around it.

Also Read:

   1. What is AWS Config? The clerk who records every change  

   2. Best laptops to run local LLMs in 2026 - honest RAM tiers  

   3. What is Amazon Macie? The archivist who reads your buckets  

   4. What is AWS KMS? Who holds the keys to your data  

   5. What is AWS Secrets Manager? Passwords out of your code  

   6. What is AWS WAF? The bouncer for your website  

   7. What is Amazon Route 53? DNS in plain English 

The second thing worth internalizing: EKS is certified Kubernetes-conformant. This is not marketing language — it is a specific certification from the Kubernetes community meaning your existing Kubernetes manifests, Helm charts, operators, and tooling work on EKS without modification. If you know Kubernetes, you know 90% of EKS. The remaining 10% is the AWS-specific parts: IAM integration, VPC networking, node provisioning. That 90/10 split is why EKS is the right choice for teams already invested in the Kubernetes ecosystem and a steep learning curve for teams that are not.

Kubernetes in 60 Seconds (For the Reader Who Skipped That Meeting)

You cannot understand EKS without a working mental model of Kubernetes, and most explanations of Kubernetes are written by people who have forgotten what not knowing it feels like. Here is the version that fits in one section.

You have containers — packaged applications with everything they need to run. Kubernetes is the system that decides where those containers run, how many of them run, and what to do when one dies. You describe what you want in YAML files ("run 3 copies of this container, keep at least 2 alive at all times"), hand those files to Kubernetes, and Kubernetes continuously reconciles reality against your description. Container died? Kubernetes notices and starts a new one. Traffic spiked? Kubernetes (with the right configuration) can run more copies. Node ran out of memory? Kubernetes evicts containers and reschedules them elsewhere.

The system doing all this deciding has two halves:

• The control plane — the brain. The API server (the front door everything talks to), etcd (the database storing cluster state), the scheduler (deciding which node runs which container), and the controller manager (noticing when reality drifts from your YAML and fixing it).
• The data plane (worker nodes) — the muscle. Actual machines (or VMs, or serverless compute) that run your containers. Each node runs an agent called kubelet that talks to the control plane and manages containers on that specific machine.

Running the control plane yourself is the hard part. Etcd is a distributed database with its own quirks, the API server needs certificates and load balancing, and version upgrades of the whole assembly are delicate surgery. This is the part EKS takes off your plate. The nodes — where your code actually runs — are the part EKS gives you multiple options for, ranging from "you manage everything" to "AWS manages everything."

The Control Plane vs. Worker Nodes: What You Rent vs. What You Run

This split is the architecture of EKS, and every decision you make about the service flows from understanding which half you are responsible for.

The control plane: what AWS runs for you

Every EKS cluster gets its own dedicated control plane — no sharing with other clusters or other AWS accounts. The setup runs at least two API server instances and three etcd instances spread across three Availability Zones within a region. If a control plane instance fails, EKS replaces it, using a different Availability Zone if needed. This multi-AZ placement is what backs the API server availability SLA.

You never see or log into these machines. They run in an EKS-managed VPC, separate from yours, and EKS actively monitors and adjusts control plane instances to maintain performance. The practical benefit: the components of Kubernetes most likely to take a cluster down at 3 AM (etcd quorum loss, API server overload) are AWS's problem, not yours.

How the control plane talks to your nodes (and who pays for it)

There is one piece of plumbing worth knowing even at a beginner level: the EKS control plane connects to your worker nodes through network interfaces created in your VPC. Traffic flows both ways — the control plane instructs your nodes, and your nodes report back. You are charged standard AWS data transfer rates on your side of that connection (traffic into your nodes from the control plane, and traffic out from your nodes to the control plane). EKS absorbs the data transfer cost on its side. In practice this charge is small compared to your compute bill, but it explains a line item on the invoice that otherwise looks mysterious.

The worker nodes: your five options

Where your containers actually run — and this is where EKS gives you more choices than almost any other AWS service, because there is no single right answer. The node types, from most-managed to least-managed:

1. EKS Auto Mode — AWS manages both the control plane and the nodes. Auto Mode uses a Karpenter-based system to automatically provision EC2 instances in response to pod requests, running on Bottlerocket AMIs with pre-installed add-ons. Nodes have a 21-day maximum lifetime, after which they are automatically replaced with fresh ones. This is the closest EKS gets to "Kubernetes where you manage almost nothing."
2. AWS Fargate — serverless compute for pods. You do not manage nodes at all; you specify what each pod needs (CPU, memory), and AWS provisions the compute for that specific pod. Best for teams that want Kubernetes APIs without wanting to think about machines.
3. Karpenter — a flexible, high-performance Kubernetes cluster autoscaler that launches right-sized compute in response to changing load. You run Karpenter yourself (it is not AWS-managed in standard EKS), but it automates node provisioning with more intelligence than the traditional Cluster Autoscaler, and it consolidates underutilized nodes away.
4. Managed node groups — AWS manages a collection of EC2 instances for you: automated provisioning, lifecycle updates, and health checks. You still choose instance types and sizing, and custom kubelet arguments are supported for advanced CPU and memory management policies. The middle ground — automation where it counts, control where you want it.
5. Self-managed nodes — you run and maintain the EC2 instances yourself, with full control over managing, scaling, and maintaining them. For teams with specific compliance, licensing, or customization needs that the managed options cannot accommodate.

There is a sixth option that does not fit the spectrum cleanly: EKS Hybrid Nodes, which lets you use your own on-premises or edge hardware as nodes in an EKS cluster. The control plane stays in AWS; your data center provides the muscle. This is the modern answer to "we have servers in a closet and also want Kubernetes" — and we cover it in depth in its own section below.

EKS Auto Mode: Kubernetes With the Training Wheels Welded On

Auto Mode is the newest significant addition to EKS, and it deserves its own section because it changes the equation for who EKS is for.

In standard EKS, AWS manages the control plane and you manage everything else — nodes, storage drivers, networking configuration, load balancer controllers, autoscaling. That means even with a managed Kubernetes control plane, you still need someone who understands Kubernetes well enough to configure it properly. Auto Mode eliminates most of that remaining work. The infrastructure it manages for you includes:

• Compute autoscaling — nodes appear when pods need them and disappear when they do not, using a Karpenter-based system that provisions right-sized EC2 instances automatically.
• Networking — pod IP address assignment and network policies are built-in components rather than add-ons you install and configure.
• Load balancing — integration with Elastic Load Balancing is handled as a core capability, not something you wire up yourself.
• DNS — local DNS services for the cluster are managed.
• Storage — EBS CSI drivers are pre-installed, and Auto Mode automatically creates storage classes using EBS volumes.
• GPU support — GPU plug-ins are included.

The security model is also different. Auto Mode nodes use immutable AMIs — locked-down Bottlerocket images with SELinux mandatory access controls and read-only root file systems. You cannot modify these nodes, even as the AWS root user: IAM-enforced restrictions block operations that could compromise AWS's ability to operate them, including changing the instance profile or attaching and detaching network interfaces. Nodes are automatically replaced after a maximum of 21 days (a limit you can reduce but not extend), which means your fleet is constantly cycling onto fresh, patched software without you scheduling anything.

The trade-off is cost. Auto Mode charges a premium on top of the EC2 instances it launches for you — billed per-second with a one-minute minimum, on top of the regular EC2 instance price. You can still use Spot Instances, Reserved Instances, and Savings Plans for the underlying compute, but the Auto Mode fee itself is independent of the instance purchase option.

EKS Capabilities: Argo CD, ACK, and kro

Beyond the cluster itself, EKS offers managed "Capabilities" — AWS-operated versions of popular Kubernetes ecosystem tools that you would otherwise install and maintain yourself. These install Kubernetes APIs (as Custom Resource Definitions) in your cluster while running the controllers and components on AWS-owned infrastructure, separate from your cluster, with automated patching, scaling, and monitoring of their lifecycle.

Argo CD (GitOps deployment)

Argo CD implements declarative, GitOps-based continuous deployment: your Git repository is the source of truth, and Argo CD continuously syncs your clusters to match it. Commit a change to your manifests, and Argo CD deploys it. Someone manually edits a resource in the cluster? Argo CD detects the drift and reverts it. You can use it to manage applications on a single cluster or across multiple clusters from one Argo CD resource, with automated deployment from Git repositories whenever changes are committed.

AWS Controllers for Kubernetes (ACK)

ACK lets you manage AWS resources using Kubernetes APIs — S3 buckets, RDS databases, IAM roles, DynamoDB tables, Lambda functions, and more (50+ services). You define an AWS resource as a Kubernetes custom resource, and ACK creates and manages the actual AWS resource for you. This is powerful for teams that live in Kubernetes and want to provision cloud infrastructure the same way they provision workloads — one toolchain, one workflow, one mental model.

kro (Kube Resource Orchestrator)

kro lets platform teams create custom Kubernetes APIs that compose multiple resources into higher-level abstractions. A developer who needs "a database, a cache, a load balancer, and a service account" should not have to write five separate resource definitions — kro lets the platform team wrap that pattern into one purpose-built API with appropriate guardrails. Self-service infrastructure with organizational standards baked in.

All three Capabilities are billed hourly — a base rate for each enabled capability plus usage charges based on the quantity of resources managed. They are opt-in; a basic EKS cluster runs fine with zero Capabilities enabled.

Common Use Cases: What People Actually Run on EKS

The documented use cases for EKS cluster around a few patterns:

• High-availability applications — workloads spread across multiple Availability Zones with Elastic Load Balancing, so a single-AZ failure does not take the application down.
• Microservices architectures — dozens or hundreds of small services that need service discovery, scaling, and lifecycle management, using Kubernetes-native patterns with AWS Cloud Map or Amazon VPC Lattice.
• Machine learning workloads — training, inference, fine-tuning, and retrieval-augmented generation pipelines on GPU-enabled nodes, with compatibility for TensorFlow, PyTorch, and MXNet. EKS is a common substrate for self-hosted model serving where latency matters.
• CI/CD pipelines — automated build, test, and deployment infrastructure, especially with Argo CD for GitOps-based deployment.
• Batch and big data — Spark and Hadoop workloads on Spot Instances for cost efficiency, taking advantage of unused EC2 capacity at discounted prices.
• Hybrid deployments — the same Kubernetes clusters, features, and tooling running on-premises (via Hybrid Nodes or EKS Anywhere) and in the cloud, for teams modernizing gradually rather than migrating wholesale.
• Platform engineering — building internal developer platforms where multiple teams share cluster infrastructure with appropriate isolation and self-service capabilities.

The pattern across all of these: multiple containers, multiple services, a need for coordination. If your workload is a single long-running application in one container, this list is telling you something.

Getting Started: One Command to a Running Cluster

The fastest path to a working EKS cluster uses eksctl — a command-line tool purpose-built for creating and managing EKS clusters. One command produces a running cluster with default settings, and it automatically creates several resources that you would have to set up manually through the AWS Console — which is exactly why it is the recommended starting point.

Prerequisites

• AWS CLI installed and configured with credentials that have EKS permissions
• kubectl — the standard Kubernetes command-line client
• eksctl — the EKS-specific CLI

Create the cluster

For a cluster with managed Linux nodes:

eksctl create cluster --name my-cluster --region us-east-1

For a cluster running on Fargate (serverless compute):

eksctl create cluster --name my-cluster --region us-east-1 --fargate

Cluster creation takes several minutes. When it finishes, the last line of output confirms the cluster is ready, and eksctl writes a kubectl configuration file to ~/.kube/config on your machine — meaning kubectl is now pointed at your new cluster and ready to accept commands.

Verify it works

kubectl get nodes

This lists the worker nodes attached to your cluster. If you see nodes in "Ready" status, the cluster is functional and accepting workloads.

Pricing: The Fee That Never Sleeps (and the $0.60 Trap)

EKS pricing has one fee everyone talks about, one fee almost nobody sees coming, and a long tail of compute costs that dwarf both.

The headline fee: $0.10 per cluster per hour

Every EKS cluster costs $0.10 per hour for the control plane, as long as it exists. That is roughly $72 per month, per cluster. This fee is charged whether the cluster is running one pod or ten thousand, whether it is a production workhorse or a weekend experiment you forgot to delete. There is no free tier, no paused state, no discount for low utilization. The clock runs from cluster creation to cluster deletion.

The fee covers the control plane running across three Availability Zones — the API servers, the etcd instances, the automated replacement of unhealthy components. That is what you are renting.

The trap: extended support at $0.60 per hour

A Kubernetes version receives standard support for 14 months after it releases in EKS. After that, it enters extended support for the next 12 months — and the cluster fee jumps from $0.10 per hour to $0.60 per hour. Six times the cost, automatically, because you did not upgrade in time.

Let that sink in with the numbers AWS itself publishes: a team that creates a cluster on a Kubernetes version and runs it for the full 26 months (14 standard + 12 extended) pays an average of $0.33 per hour over that period — more than triple what they would have paid by upgrading on time. A single cluster drifting into extended support costs roughly $432 per month instead of $72. An organization with five forgotten clusters hits $2,160 per month on control-plane fees alone.

The fix is upgrade discipline. The Kubernetes community releases minor versions on average once every four months, and EKS follows the upstream release and deprecation cycle. A regular upgrade cadence keeps you in the standard support window indefinitely. The version lifecycle is documented and the upgrade path is a first-class EKS operation — but it is yours to execute, not something EKS does for you (Auto Mode handles node updates, not control plane version upgrades).

Provisioned Control Plane: paying more for a bigger brain

For workloads that demand more from the control plane — large-scale AI training, high-performance computing, massive data processing with huge node counts — EKS offers Provisioned Control Plane: pre-provisioned control plane capacity in defined scaling tiers, so the control plane is instantly ready for traffic spikes instead of scaling up reactively. The tiers run from XL at $1.65 per cluster per hour up to 8XL at $13.90 per cluster per hour, charged in addition to the standard cluster fee. You can change tiers or return to standard at any time. For most teams this is irrelevant — the default control plane scales fine — but if you are running thousands of nodes in one cluster, control plane throughput becomes the bottleneck this solves.

Auto Mode and Hybrid Nodes pricing

Auto Mode charges on top of the EC2 instances it launches — per-second billing with a one-minute minimum, calculated by instance duration and type. The fee is independent of whether you bought the underlying instances on-demand, as Spot, or with Reserved Instances and Savings Plans.

Hybrid Nodes are billed per vCPU per hour based on the resources your on-premises nodes report to Kubernetes, with tiered pricing that drops as aggregate usage grows: $0.020 per vCPU-hour for the first 576,000 monthly vCPU-hours, stepping down through $0.014, $0.010, and $0.008 to $0.006 above 11.5 million vCPU-hours. For bare metal with hyperthreading, each physical core reports two vCPUs, and billing follows the reported count.

Fargate pricing (when you go serverless)

With Fargate, pricing is calculated based on the vCPU and memory resources each pod uses, from the time you start downloading the container image until the pod terminates — rounded up to the nearest second, with a one-minute minimum charge. You pay per pod, not per node, which makes Fargate economical for spiky or small workloads and expensive for dense, always-on ones.

The part that actually costs money: your worker nodes

On top of the control-plane fee, you pay for whatever AWS resources your workloads consume. EC2 instances for the nodes, EBS volumes for storage, IPv4 addresses for networking, data transfer for cross-AZ traffic. For most teams, the compute dwarfs the control-plane fee within days — a cluster running ten modest instances is spending more on EC2 in a day than the control plane costs in a week.

Savings Plans and Reserved Instances apply to the compute portion (the EC2 instances running your nodes), which is the largest line item for most teams. The control-plane fee does not participate in any discount program — it is flat, per cluster, per hour, forever.

Hybrid Nodes and EKS Anywhere: Kubernetes When Your Servers Are Not in AWS

Two offerings extend EKS beyond AWS's own hardware, and they answer different versions of the same question: "what if the control plane is in the cloud but the compute is not?"

EKS Hybrid Nodes lets you use your on-premises and edge infrastructure as nodes in an Amazon EKS cluster. Your machines join the cluster, the AWS-hosted control plane orchestrates them, and you get unified Kubernetes management across cloud and on-premises from one place. Billing starts when nodes join the cluster and stops when they are removed, priced per vCPU per hour on a tiered scale. This is the modern shape of hybrid Kubernetes: the part that is hard to run (the control plane) is rented, and the part you already own (the servers) keeps working. One quirk worth knowing: you are charged the Hybrid Nodes fee even if you use EC2 instances as your hybrid node infrastructure — the fee follows the node, not the hardware location.

EKS Anywhere is for the opposite extreme: fully self-contained, air-gapped environments where nothing can depend on a cloud connection. EKS Anywhere automates Kubernetes cluster lifecycle management entirely on your own infrastructure — including the control plane, which runs on your hardware, not AWS's. You lose the "rented control plane" benefit entirely, but you keep the tooling, the operational consistency, and the support model. For regulated environments, edge deployments, and factories with no reliable WAN link, this is the only version of EKS that applies.

The decision between them is simple: if your data center can reach AWS, Hybrid Nodes gives you a managed control plane with your own compute. If it cannot, EKS Anywhere gives you AWS's operational tooling with everything running on the ground.

EKS vs. ECS: The Question Every AWS Team Eventually Asks

AWS offers two ways to run containers at scale, and the choice is not obvious. The core distinction:

• ECS (Elastic Container Service) is AWS's own container orchestrator. Proprietary, deeply integrated with AWS services, conceptually simpler. Task definitions and services rather than pods and deployments. No control-plane fee.
• EKS is managed Kubernetes. Open-source, certified conformant, portable across clouds and on-premises. Kubernetes-native concepts throughout. $0.10/hour control-plane fee.

The decision usually comes down to three questions:

1. Does your team already know Kubernetes? If yes, EKS meets you where you are. If no, ECS has a smaller learning curve and less conceptual overhead — you can be productive in ECS in days, where EKS assumes familiarity with a large ecosystem of concepts and tooling.
2. Do you need portability? Kubernetes is the industry-standard abstraction — an application designed for EKS runs on GKE (Google), AKS (Azure), or any vanilla Kubernetes cluster. An application designed for ECS is an AWS application. If multi-cloud or a future migration is on the table, EKS is the hedge; ECS is the commitment.
3. Are you hiring? The Kubernetes talent pool is large and growing — it is the shared language of container orchestration. ECS expertise is AWS-specific. Teams that expect to hire or rotate staff often choose EKS for the transferable skillset.

The cost difference is real but often overstated. The EKS control plane at roughly $72/month matters at small scale and vanishes into noise at large scale — a cluster running dozens of nodes spends more than that on compute in a day. The real cost of EKS is operational: Kubernetes has more moving parts, more configuration surface area, and more ways to do something subtly wrong. ECS trades that flexibility for simplicity, and which trade is right depends on your team, not on the technology.

When EKS Is the Wrong Choice (The Honest Section)

Most EKS content is written by people selling EKS or teaching EKS. This section is written for the reader who is about to spend six months on a system they did not need.

You have fewer than 10 services

Kubernetes solves the problem of coordinating many containers across many machines. If you are running five services on three machines, that coordination problem is small enough to solve with a load balancer and a deployment script. EKS on five services is a Ferrari for a grocery run — technically functional, financially puzzling.

Your team has no Kubernetes experience and no plans to acquire it

Even with Auto Mode, you will encounter Kubernetes concepts: pods, services, deployments, manifests, kubectl. If nobody on the team wants to learn this vocabulary and nobody is hiring for it, EKS is an expensive way to feel modern. ECS, or even plain EC2 with a container runtime, delivers the same outcome with less cognitive overhead.

Your workload is a single long-running application

A monolith that scales vertically (bigger machine) rather than horizontally (more machines) does not need orchestration. EKS adds value when workloads are numerous, ephemeral, or dynamically scaled. A single database-backed application that runs continuously gains nothing from being wrapped in Kubernetes, and pays operational tax for the privilege.

You cannot commit to the upgrade treadmill

Kubernetes versions age out of standard support every 14 months. Upgrades are a scheduled, tested, repeated operational activity. If your team cannot or will not do that — if upgrades happen "when we get around to it" — you will accumulate extended-support fees and, eventually, unsupported clusters running software with known security issues. This is a people problem, not a technology problem, and no AWS feature solves it.

IT Admin: EKS in the Enterprise

For platform and infrastructure teams evaluating or operating EKS at fleet scale, several concerns dominate.

IAM integration: who can do what

EKS access control uses both Kubernetes RBAC (role-based access control) and AWS IAM. IAM identities (users and roles) map to Kubernetes permissions, which means your existing AWS identity infrastructure extends into the cluster. For workloads that need AWS access, IAM Roles for Service Accounts and EKS Pod Identity let individual pods assume specific IAM roles — no more storing long-lived AWS credentials in environment variables.

Multi-cluster sprawl and cost

Every EKS cluster bills hourly before it does anything. Teams that create separate clusters per environment (dev, staging, prod), per team, or per business unit multiply that fee quickly. The counter-argument — cluster isolation for security or blast-radius reasons — is sometimes valid. The honest accounting is: are the isolation benefits worth the per-cluster fee, plus the operational overhead of maintaining multiple upgrade cadences?

For many organizations, the answer is fewer clusters with namespace-based isolation, not more clusters with hard boundaries. Kubernetes namespaces provide soft isolation within a cluster; separate clusters provide hard isolation. The right granularity depends on compliance requirements and team structure.

Observability: knowing what is happening

EKS clusters generate telemetry through Prometheus, CloudWatch, CloudTrail, and the ADOT (AWS Distro for OpenTelemetry) Operator, with an observability dashboard for monitoring cluster health. For production operations, the minimum viable observability stack is: node and pod resource metrics (for capacity planning), control-plane API logs (for debugging), and application-level metrics (for knowing when customers are affected). Teams that skip observability discover problems from customers rather than dashboards.

Security posture

EKS integrates with AWS security services: GuardDuty for threat detection against EKS clusters, IAM for access control, KMS for encryption, VPC for network isolation. The shared responsibility model puts the control plane on AWS and everything else on you — node security, pod security policies, image scanning, secrets management. For regulated environments, the security best practices documentation is the starting point, not an optional read.

Troubleshooting: The Problems Every EKS Operator Eventually Hits

Problem 1: Pods stuck in "Pending" — no nodes to schedule on

Symptom: kubectl get pods shows Pending status; kubectl describe pod shows something like "0/3 nodes are available: 3 Insufficient cpu."

Cause: Your nodes do not have enough capacity for the pod's resource requests. Either the node group is too small, or Karpenter/Auto Mode is not scaling fast enough, or the pod's resource requests are larger than any single node can accommodate.

Fix: Scale the node group up, or if using Karpenter or Auto Mode, check that the NodePool configuration allows large-enough instance types. For pods requesting more CPU than any node provides, split the workload or use larger instances.

Problem 2: ImagePullBackOff — cannot pull container images

Symptom: Pods report ImagePullBackOff or ErrImagePull status.

Cause: The node cannot pull the container image. Usually one of three things: the image does not exist (typo in the tag), the registry requires authentication that is not configured, or there is a network issue between the node and the registry.

Fix: Verify the image name and tag. For private ECR images, ensure the node's IAM role has ECR pull permissions. For other private registries, configure image pull secrets on the pod or service account.

Problem 3: Nodes NotReady after an upgrade

Symptom: After upgrading the Kubernetes version, some nodes show NotReady status.

Cause: The nodes' kubelet version no longer matches the upgraded control plane — the nodes have not been brought up to the new version yet.

Fix: Upgrade the node groups to match the control plane version. With managed node groups, this is an EKS operation; with self-managed nodes, it is a rolling replacement process you orchestrate yourself.

Problem 4: The bill is much higher than expected

Symptom: Monthly AWS cost exceeds projections by hundreds or thousands of dollars.

Cause: One of four usual suspects: clusters in extended support ($0.60/hour instead of $0.10), forgotten non-production clusters running 24/7, over-provisioned nodes relative to actual workload, or cross-AZ data transfer from chatty inter-pod communication.

Fix: Check each cluster's Kubernetes version in the EKS console or with the AWS CLI, delete unused clusters, right-size node groups based on actual utilization metrics, and consider consolidating workloads to reduce cross-AZ traffic. For interruptible workloads, Spot Instances for nodes can cut compute costs substantially.

Problem 5: Cannot connect to the cluster (API timeout)

Symptom: kubectl commands hang or return connection refused.

Cause: The network path from your location to the EKS API endpoint is blocked, or the IAM principal does not have cluster access configured in the cluster's access configuration.

Fix: Verify network connectivity (VPN, security groups, VPC endpoints if using PrivateLink). For IAM issues, check that the principal is mapped to a Kubernetes RBAC group in the cluster's access entries.

Frequently Asked Questions

What is Amazon EKS?

Amazon EKS (Elastic Kubernetes Service) is AWS's managed Kubernetes service. AWS runs the Kubernetes control plane — API server, etcd, scheduler — across multiple Availability Zones, and you connect worker nodes to run your containerized applications. It is certified Kubernetes-conformant, so existing Kubernetes tooling and manifests work without modification.

How much does Amazon EKS cost?

Every EKS cluster costs $0.10 per hour for the control plane (roughly $72/month), plus whatever your worker nodes and related AWS resources cost. If a Kubernetes version ages past 14 months without an upgrade, the fee increases to $0.60 per hour. EKS Auto Mode adds per-instance charges on top of EC2 pricing.

What is the difference between EKS and Kubernetes?

Kubernetes is the open-source container orchestration system. EKS is AWS's managed version of it — you rent the control plane (API server, etcd, scheduler) from AWS instead of running those components yourself, and you connect worker nodes that run in your AWS account. EKS is certified Kubernetes-conformant, so applications designed for Kubernetes run on EKS without modification.

What is the difference between EKS and ECS?

ECS is AWS's proprietary container orchestrator — simpler, deeply AWS-integrated, no control-plane fee. EKS is managed Kubernetes — open-source, portable across clouds, $0.10/hour per cluster. EKS suits teams that know Kubernetes or need portability; ECS suits teams that want simplicity and are committed to AWS.

What is EKS Auto Mode?

EKS Auto Mode extends AWS's management beyond the control plane to include the worker nodes. It automatically provisions EC2 instances based on pod demands, uses immutable Bottlerocket AMIs with security hardening, replaces nodes after a maximum of 21 days, and includes managed components for networking, load balancing, DNS, storage, and GPU support that would otherwise be add-ons you configure yourself.

Does EKS automatically upgrade Kubernetes versions?

No. The control plane stays on whatever Kubernetes version you created it with until you initiate an upgrade. Kubernetes versions receive standard support for 14 months, then extended support (at $0.60/hour instead of $0.10/hour) for 12 more months. Upgrades are an operational responsibility — plan for a regular cadence.

What are worker nodes in EKS?

Worker nodes are the machines (EC2 instances, Fargate compute, or your own hardware with Hybrid Nodes) where your containers actually run. The EKS control plane schedules workloads onto these nodes. You choose how the nodes are managed: fully automated (Auto Mode), serverless (Fargate), self-managed autoscaling (Karpenter), AWS-managed lifecycle (managed node groups), or fully self-managed.

Can I run EKS on-premises?

Partially. EKS Hybrid Nodes lets you use your own on-premises hardware as worker nodes in an EKS cluster — the control plane stays in AWS, your data center provides the compute. For fully self-contained, air-gapped environments, EKS Anywhere automates Kubernetes cluster lifecycle management entirely on your own infrastructure, without an AWS-hosted control plane.

What is eksctl?

eksctl is a command-line tool for creating and managing EKS clusters. It is the fastest way to get a working cluster — one command (eksctl create cluster) provisions the control plane, node groups, and networking with sensible defaults, and it handles automatically many resources that require manual setup through the AWS Console.

Do I need to know Kubernetes to use EKS?

For standard EKS, yes — you will encounter pods, services, deployments, and kubectl daily. EKS Auto Mode reduces the infrastructure management but not the conceptual vocabulary. If no one on your team wants to learn Kubernetes concepts, ECS or a simpler deployment model is a better fit than EKS.

Can I use EKS with Fargate?

Yes. Fargate is a serverless compute option for EKS pods — you specify what each pod needs (vCPU and memory), and AWS provisions the compute for that pod without you managing any EC2 instances. You pay per-pod, per-second, based on the resources consumed, with a one-minute minimum. Good for teams that want Kubernetes APIs without node management.

How many EKS clusters should I run?

It depends on your isolation requirements. Separate clusters provide hard isolation (security, blast radius, compliance) but multiply the hourly fee and the operational overhead. Many teams run fewer clusters with Kubernetes namespace-based isolation instead. The right granularity is driven by compliance requirements and team structure, not by a single correct number.

What happens if I do not upgrade Kubernetes on EKS?

After 14 months on a version, the cluster enters extended support and the hourly fee jumps from $0.10 to $0.60 — roughly $432/month instead of $72. After extended support ends, the version is no longer supported at all and may have unpatched security vulnerabilities. Upgrade discipline is a core operational requirement of running EKS.

Can I use Docker images with EKS?

Yes. EKS runs OCI-compatible container images, which includes Docker images. You store images in Amazon ECR (Elastic Container Registry) or any container registry your nodes can reach, and reference them in your Kubernetes manifests.

What is the EKS control plane SLA?

The EKS control plane runs across multiple Availability Zones with automatic replacement of unhealthy components, and AWS publishes an API server endpoint availability SLA. The specifics are in the AWS Service Level Agreement for EKS. The SLA covers the control plane, not your worker nodes or application availability.

Is EKS certified Kubernetes conformant?

Yes. EKS is certified Kubernetes-conformant, meaning it passes the Kubernetes community's conformance tests. Your existing Kubernetes manifests, Helm charts, operators, and tooling work on EKS without modification. If you know Kubernetes, the learning curve for EKS is the AWS-specific parts (IAM integration, VPC networking, node provisioning), not Kubernetes itself.

Wrapping Up: Kubernetes, Rented, With the Fine Print Attached

Amazon EKS is what the tagline says — Kubernetes, rented — but the rental agreement has fine print worth reading. You rent the brain and never stop paying for it. You supply (or rent, at additional cost) the muscle. And unless you opt into Auto Mode, most of the operational work of running Kubernetes is still yours: the upgrades, the node security, the storage and networking configuration, the 3 AM pages when something drifts out of spec.

The two takeaways if you take away nothing else: first, the control-plane fee never stops, and it multiplies sixfold if you let a Kubernetes version age past 14 months — build upgrade discipline into your team's calendar before you build the cluster. Second, EKS is the right tool when you have enough containers that coordinating them manually hurts more than learning Kubernetes does — not before, and not after you have already solved the problem a simpler way.

Jake, for what it is worth, is staying on his single EC2 instance for now. Ethan's verdict: "The best infrastructure decision is the one that matches your actual problem. EKS is a brilliant answer to a question you are not asking yet. Ask it in a year, when you have fifteen services and no one to babysit them — EKS will be here, waiting, at $0.10 an hour."

Revision note. Written September 2026, covering Amazon EKS including Auto Mode, Hybrid Nodes, and EKS Anywhere as currently offered. Pricing evolve with each Kubernetes release cycle — verify against the EKS pricing page before budgeting. If you are staring down your first EKS bill wondering why it is higher than the tutorial suggested, you are in good company, and the fact that you read the fine print before the next cluster instead of after puts you ahead of most teams running Kubernetes in production.