Amazon EKS

What Amazon EKS actually is

Amazon Elastic Kubernetes Service is AWS's managed Kubernetes: you get a Kubernetes control plane that AWS runs, patches and scales, and you supply the worker capacity as EC2 instances, Fargate pods, or EKS Auto Mode's managed compute. It went into preview at re:Invent in November 2017 and became generally available on June 5, 2018 — the press release from that day covers US East (N. Virginia) and US West (Oregon); the service now runs across essentially the whole AWS footprint. The appeal is narrow and clear: keep standard Kubernetes, drop the operational burden of running etcd, API servers and version upgrades yourself.

"Standard Kubernetes" is doing real work in that sentence. EKS runs conformant, upstream Kubernetes — your manifests, operators, Helm charts and CNCF tooling work unchanged — while AWS handles the control plane across at least three Availability Zones per region, replaces unhealthy control-plane nodes, and manages etcd backups. Authentication is wired to AWS IAM (the IAM authenticator the project pioneered is now upstream), so Kubernetes identities map onto your existing AWS account model rather than a parallel one. Networking, storage and ingress plug into VPC, EBS, ECR, ALB/NLB and the rest of the platform natively.

The compute side is your choice of three shapes. Managed node groups give you EC2 (including GPU and Arm/Graviton families) with AWS handling provisioning and node repair. Fargate runs pods serverless, billed by vCPU and memory with no nodes to manage at all. EKS Auto Mode, the newer option, lets AWS manage the node lifecycle as well — clusters, scaling, patching and capacity handled behind the Kubernetes API. There is also EKS Anywhere and Hybrid Nodes for running Kubernetes on your own hardware or in your datacenter under the same umbrella.

We file EKS under managed Kubernetes. If you are comparing the raw compute underneath, our benchmarks page covers the instance side of the market.

Pricing: what you really pay

EKS pricing has two layers: the cluster fee and everything your workloads consume. The cluster fee is public and simple — $0.10 per cluster per hour during standard Kubernetes version support, which is about $73 a month per cluster. Standard support runs 14 months from a version's EKS release. After that, the version enters extended support for up to 12 more months at $0.60 per cluster per hour — roughly $438 a month, six times the base rate, applied automatically if you have not upgraded. AWS's own worked example: a cluster kept on one version for 26 months averages $0.33 per hour.

Large clusters with heavy Kubernetes API traffic can add a Provisioned Control Plane on a scaling tier: $1.65 per hour for XL up to $13.90 per hour for 8XL, on top of the cluster fee, in exchange for dedicated control-plane capacity and a 99.99% SLA. EKS Auto Mode adds a per-server management charge on top of normal EC2 pricing (third-party analysis puts the uplift around 12% of EC2 spend — treat that as an estimate, not a quote). Everything else is standard AWS pricing: EC2 or Fargate for compute, EBS for volumes, load balancers, NAT gateways, ECR storage, and inter-AZ or internet data transfer. There is no free tier for EKS itself; a cluster left running costs $73 a month before a single pod does anything.

The honest framing for budgeting: the control-plane fee is the small line. Real cost is compute, storage and data transfer — the same variables you have on any cloud. Where EKS gets expensive versus self-managed Kubernetes is the sum: the $0.10/hour fee plus managed node group overhead plus the fact that AWS pricing rewards architectural discipline (Spot instances, right-sizing, Graviton) and punishes its absence. Compared with GKE ($0.10/hour for a regional cluster) and AKS (free control plane, paid support tiers), EKS sits in the middle: not the cheapest control plane, not the most expensive.

Performance & infrastructure

There is no single EKS datacenter to measure — performance is your region, your instance types and your architecture. The infrastructure beneath is the largest public cloud available: 39 geographic regions with 124 Availability Zones as we write, plus 750+ CloudFront points of presence, 46 Local Zones and 33 Wavelength Zones for latency-sensitive workloads. Each region runs at least three physically separate AZs, and EKS spreads the control plane across all of them, which is where the availability story comes from.

The SLA, rewritten in March 2026, is one of the clearer ones in this market: 99.95% monthly uptime for the standard control plane (measured in 5-minute intervals), 99.99% for provisioned control planes (1-minute intervals), with service credits of 10%, 25% or 100% of the cluster management fee. Read the measurement clause: an interval only counts as unavailable if every request to the Kubernetes endpoint fails, so partial degradation is not credited. The credits are also calculated against the cluster fee — 10% of $73 is not compensation for a production outage. The commitment is about control-plane API availability; your application's availability is your architecture's job.

For compute, the catalog is the EC2 catalog: general purpose, compute- and memory-optimized, GPU families (g5, p5 and friends with NVIDIA device plugin support via eksctl and managed node groups), Graviton Arm instances, and Trainium for ML training. Capacity purchase options include On-Demand, Spot (up to 90% cheaper for interruptible work), On-Demand Capacity Reservations and Capacity Blocks for time-bound GPU reservations. IPv6 is supported for pod networking (available for clusters on Kubernetes 1.21 and later), and AWS Shield Standard protects every AWS customer from common network and transport layer DDoS attacks at no extra charge.

Compliance coverage is broad — SOC, ISO, FedRAMP, HIPAA and PCI attestations apply across the platform — and everything integrates with CloudWatch, X-Ray, IAM, KMS encryption, GuardDuty and the rest of the security tooling. The ecosystem of AWS-native integrations (RDS, S3, DynamoDB, SQS, Lambda via EKS add-ons) is the practical reason teams pick EKS over alternatives.

Where it falls short

The main one is total cost complexity. The cluster fee is simple; the bill is not. Inter-AZ data transfer, NAT gateways, load balancers, EBS volumes and idle nodes add up invisibly, and extended support's six-fold price jump punishes teams that let versions drift. You need a FinOps habit (or at least cost allocation tags) from day one.

Second, AWS lock-in, and it is real. EKS itself is conformant Kubernetes, so workloads port — but the moment you wire IAM roles for service accounts, ALB ingress controllers, EBS CSI drivers and CloudWatch into the fabric, your deployment layer is AWS-shaped. Multi-cloud is a bigger lift than the word "standard" suggests.

Third, the learning curve. Kubernetes is already complex; on EKS you are learning Kubernetes plus VPC networking, IAM policy, security groups and AWS CLI workflows. Teams new to either stack feel both at once. AWS's documentation is exhaustive but sprawls across dozens of services.

Finally, support costs extra. The SLA credits are automatic-ish, but human support beyond documentation and forums requires a paid AWS Support plan, and the tiers that matter for production (Business, Enterprise) are a serious line item of their own.

Who should pick this

We pick EKS for teams already committed to AWS who need production Kubernetes without operating a control plane: platform groups standardizing on containers across many services, regulated organizations that need AWS compliance artifacts, ML teams wanting GPU and Capacity Block workflows inside Kubernetes, and anyone whose alternative is hiring the ops headcount to run kube-apiserver themselves. If your infrastructure is AWS and your workload is containerized, EKS is the default answer we would start from.

We would not pick it for a small team running one or two services — plain ECS, Fargate, or even a single VM with Docker is cheaper and simpler — nor for organizations optimizing for multi-cloud portability from day one (GKE Autopilot or a distribution like Rancher deserves a look), nor for budget-critical workloads where a self-managed cluster on raw compute makes more sense and you have the skills to run it.

Key takeaways

• Managed, upstream-conformant Kubernetes: AWS runs the control plane across three AZs, handles patching, upgrades and etcd backups; you supply EC2, Fargate or Auto Mode compute.
• Generally available since June 5, 2018 (previewed at re:Invent 2017); available across 39 AWS regions and 124 Availability Zones.
• Cluster fee is $0.10/hour ($73/month) in standard support; versions enter extended support after 14 months at $0.60/hour ($438/month) — upgrade before that window closes.
• SLA: 99.95% control-plane uptime (99.99% on Provisioned Control Plane at $1.65-$13.90/hour extra), credits of 10/25/100% of the cluster fee.
• Total cost is dominated by compute, storage and data transfer, not the cluster fee; AWS Shield Standard DDoS protection and S3 come with the platform.
• Best for AWS-committed teams wanting production Kubernetes without control-plane operations; overkill for small containerized workloads.

Sources

• https://aws.amazon.com/eks/pricing/
• https://aws.amazon.com/eks/sla
• https://aws.amazon.com/about-aws/global-infrastructure/
• https://aws.amazon.com/shield/features/
• https://press.aboutamazon.com/2018/6/aws-announces-general-availability-of-amazon-eks
• https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html
• https://renovacloud.com/en/what-is-amazon-eks