EKS Pricing in 2026: The $438/Month Trap and How to Avoid It

Amazon EKS charges $73/month per cluster before a single pod runs. Most AWS services charge for what you use — EKS charges whether you're using it or not.

That's the first number to internalize. Teams running dev, staging, and production clusters are paying $219/month in control plane fees before any workloads exist. And that's the cheap version. Let your Kubernetes version fall behind schedule and the same three clusters cost $1,314/month just in cluster fees — nothing else changed except the version number.

Amazon EKS pricing now has 5+ distinct billing layers. This guide covers all of them.

As of 2025, EKS added three new billing dimensions that most pricing guides still haven't caught up to: EKS Provisioned Control Plane (GA November 2025), EKS Capabilities for managed Argo CD, ACK, and KRO (GA November 2025), and EKS Hybrid Nodes (GA December 2024). If you've enabled any of these, you're paying for dimensions that most EKS pricing articles don't even mention.

This guide covers every billing dimension with exact dollar amounts, three worked cost scenarios, and practical strategies to bring the bill down. For a quick estimate of your specific setup, use the EKS pricing calculator to model it directly.

All pricing reflects AWS US East (N. Virginia) rates from the official EKS pricing page as of March 2026. Rates vary by region.

What Does an EKS Cluster Actually Cost?

Every EKS cluster pays a flat per-hour fee for the managed control plane, regardless of whether any nodes are running. No upfront cost, no minimum term — just a metered charge from the moment the cluster exists.

Here's the range depending on your Kubernetes version support status:

That delta — $73 vs $438 — is where most unexpected EKS bills come from. The jump is 6x. It's also automatic, which means teams that aren't actively tracking Kubernetes version lifecycles get hit without warning.

AWS Outposts local clusters pay the same $0.10/hr standard rate but don't have extended support at all. If you're on Outposts, version upgrade timelines matter even more because your only option when standard support ends is to upgrade.

Standard Support: $0.10/hr ($73/month)

Standard support covers the first 14 months after EKS releases a given Kubernetes version. Kubernetes releases three minor versions per year, which gives you a rolling window to stay current.

$73/month feels manageable in isolation. But it multiplies fast. Three clusters across dev, staging, and production means $219/month in control plane fees alone. Five clusters across two teams is $365/month. At ten clusters, you're paying $730/month before a single container runs.

This is the calculus that pushes teams toward shared multi-tenant clusters over time — and it's the right one from a cost perspective.

Extended Support: $0.60/hr ($438/month)

Extended support kicks in at month 15 automatically unless you upgrade. The $0.60/hr rate applies for the remaining 12 months of the support window, through month 26 from the EKS version release date.

I keep seeing teams get hit by this because their default Terraform configuration enables extended support silently. Clusters created via the AWS Console default to auto-upgrade at the end of standard support — which sounds helpful but can break things if you haven't tested the upgrade. Clusters created via CLI or IaC default to extended support enabled instead of auto-upgrading. So a Terraform-managed cluster on an aging Kubernetes version quietly moves to $438/month when month 15 arrives.

The fix isn't to fight the defaults — it's to treat version upgrades as scheduled quarterly work, not emergencies.

The Version Lifecycle Trap (26-Month Average Cost)

Here's the math on what staying put actually costs. If a cluster runs the full 26-month support lifecycle without ever upgrading (14 months at $0.10/hr + 12 months at $0.60/hr), the average control plane cost over that period is $0.33/hr — about $241/month per cluster on average.

That's more than 3x the $73/month floor, and entirely avoidable.

The cost-efficient move is simple: upgrade before month 15. Set a calendar reminder when you create a cluster. Better yet, pin your Kubernetes version in Terraform with an upgrade deadline comment so the intent is visible in code review:

resource "aws_eks_cluster" "main" {
  name    = "production"
  # Upgrade to 1.32 before 2026-10-01 to avoid extended support ($438/month)
  version = "1.31"
  ...
}

That comment costs nothing and prevents a $365/month surprise.

EKS Compute Options: Pricing for Each Approach

The control plane fee is your fixed overhead. Compute is where EKS costs actually scale — and it's the dominant line item for almost every cluster. There are four ways to run EKS workloads, and each has different pricing mechanics.

You can mix these in a single cluster, which is often the right cost strategy. Stateful system pods on On-Demand EC2, batch jobs on Spot, and short-lived CI jobs on Fargate — each priced optimally for its workload type.

Managed and Self-Managed EC2 Node Groups

With managed or self-managed EC2 node groups, there is no EKS-specific fee on top of EC2. You pay the standard EC2 instance rate plus EBS volumes, public IPv4 addresses ($0.005/hr per address since February 2024), and cross-AZ data transfer.

This is the compute model with the most pricing flexibility. Spot Instances are available here with up to 90% savings for stateless, interruptible workloads. EC2 Instance Savings Plans and Reserved Instances offer up to 72% for stable baseline nodes. Compute Savings Plans (up to 66%) give flexibility across instance families and regions.

For a concrete example: ten m5.xlarge On-Demand nodes at $0.192/hr each running 730 hours = $1,401.60/month in compute alone, before any other charges.

AWS Fargate for EKS

Fargate provides serverless pods — no EC2 instances to manage. Billing starts when your container image begins downloading and stops at pod termination, rounded to the nearest second with a 1-minute minimum.

US East (N. Virginia) Linux/x86 rates:

Each pod gets 20 GB of ephemeral storage included. Linux/ARM (Graviton) Fargate runs about 20% cheaper than x86 — if your container images support ARM, that's a free cost reduction by changing one line in your pod spec.

Supported Fargate vCPU configurations: 0.25, 0.5, 1, 2, 4, 8, and 16 vCPU with matched memory ranges.

One thing that trips up teams coming from ECS: Fargate Spot is not available for EKS pods. It's an ECS-only feature. If you're planning on Fargate Spot to reduce costs on EKS workloads, that option doesn't exist. Compute Savings Plans do apply to Fargate (up to 50%), which helps for predictable Fargate workloads.

EKS Auto Mode

Auto Mode adds a per-instance management fee on top of regular EC2 costs — approximately 12% of the EC2 On-Demand price. It handles node provisioning, scaling, AMI patching, and node replacement automatically using a Karpenter-based system.

The full pricing breakdown, including when this fee pays for itself, is in the dedicated section below.

EKS Hybrid Nodes

Hybrid Nodes lets you connect on-premises or other cloud VMs to an EKS control plane in AWS. Billing is per vCPU-hour reported to Kubernetes, tiered by monthly volume. The full tiered pricing table is in the Hybrid Nodes section.

EKS Auto Mode Pricing: The 12% Surcharge Explained

EKS Auto Mode adds two charges per managed instance: the regular EC2 instance cost plus an Auto Mode management fee. Both are billed per second with a 1-minute minimum.

The management fee is approximately 12% of the EC2 On-Demand price for that instance type. Here's the official pricing example from AWS (US West Oregon) showing four instances:

How the Management Fee is Calculated

Monthly example with all four instances running 730 hours:

• EC2 total: $1,046.82
• Auto Mode management fees: $125.62
• EKS cluster fee: $73.00
• Total: $1,245.44/month

The fee appears as a separate line item on your AWS bill. A few important things to know:

The ~12% figure comes from the four x86 instances in the official pricing example. AWS does not publish a complete public fee table by instance type — for GPU, Graviton, or other instance families, use the AWS Pricing Calculator to get the precise rate for your specific configuration.

Savings Plans and Reserved Instances reduce the EC2 instance portion of your bill, but the Auto Mode management fee is always charged at the On-Demand rate regardless of your EC2 purchase commitment. This partially offsets the "buy Savings Plans" strategy when running Auto Mode at scale.

Auto Mode also has operational constraints worth knowing: 150 nodes maximum across your entire AWS organization (contact AWS above this limit), 21-day maximum node lifetime (nodes are automatically replaced), no custom AMIs, and no SSH or SSM access to the managed nodes.

Auto Mode vs Self-Managed Nodes: When Does It Pay Off?

Auto Mode saves your team the time spent on node provisioning configuration, AMI patching schedules, upgrade management, and bin-packing optimization. Self-managed Karpenter does all the same things but requires you to own the setup and ongoing maintenance.

For a 4-node cluster with $1,046 in monthly EC2 spend, the Auto Mode fee is $125/month. If your team spends roughly 2 hours per month managing node lifecycle at $60/hr in loaded engineer cost, Auto Mode pays for itself on economics alone — and that's before counting the cognitive overhead of keeping up with AMI releases.

Auto Mode is not worth it when: your workloads require custom AMIs, your compliance environment needs SSH access to nodes, or you're approaching the 150-node organization limit. At scale, self-managed Karpenter with its full configuration flexibility and no management fee delivers better economics.

EKS Provisioned Control Plane: The High-Performance Add-On

EKS Provisioned Control Plane (GA November 2025) is an optional add-on that reserves dedicated control plane capacity. It's charged in addition to the standard $0.10/hr cluster fee — not instead of it.

Most teams don't need this. But if you're running large-scale GitOps with frequent Argo CD sync cycles, rapid Karpenter scaling decisions, or a platform with CI/CD systems hammering the Kubernetes API, the shared standard control plane can become a bottleneck. API rate limiting during high-churn periods (mass deployments, large-scale autoscaling events) is real, and it's often difficult to diagnose because it looks like slow deployments rather than a pricing decision.

Pricing Tiers: XL to 8XL

These are add-on costs. Running XL all month means $0.10 standard + $1.65 add-on = $1.75/hr = $1,277/month for the control plane alone. Requires EKS v1.28 or higher, and the capacity specs above apply to EKS v1.30+.

What You Get for the Premium

The standard control plane is shared with no guaranteed capacity. During high-churn periods — mass deployments, aggressive autoscaling, large Helm releases — you can hit API rate limits that appear as slow or stalled operations.

Provisioned Control Plane gives you dedicated API concurrency seats and a defined pod scheduling rate. At XL, that's 1,700 concurrent API seats and 167 pods scheduled per second. At 8XL, 13,600 seats and 400 pods/sec.

The SLA also upgrades to 99.99% for Provisioned Control Plane clusters versus 99.95% for standard. In absolute terms: 99.99% SLA allows 52 minutes of downtime per year, while 99.95% allows 4.38 hours per year. For enterprise platforms with SLA obligations to their own customers, this difference is a real contract conversation.

You can switch tiers or return to standard at any time in minutes with no downtime. Available in all commercial, GovCloud, and China regions. So the risk of trying it is low — the risk of not trying it when you're hitting control plane limits is higher.

See the Provisioned Control Plane documentation for the full capacity specification matrix.

My take: most teams under 50 nodes on standard support don't need this. Consider it when control plane API throttling starts showing up in your deployment metrics, or when your platform team has a formal SLA requirement that demands 99.99%.

EKS Capabilities Pricing: Argo CD, ACK, and KRO

EKS Capabilities (GA November 2025) are managed integrations that run on AWS-owned infrastructure. The three available Capabilities are Argo CD, ACK (AWS Controllers for Kubernetes), and KRO (Kubernetes Resource Orchestrator).

Each Capability has two billing components: a base hourly rate just for having it enabled, plus a per-resource hourly usage charge. Zero competitors have covered these rates in depth — if you've enabled any of them, here's what you're actually paying.

Worked example: full stack (100 Argo CD Apps + 1,000 ACK resources + 1,000 KRO RGD instances), 730 hrs/month, US East N. Virginia:

That $211.70/month is on top of your control plane fee, compute, and networking. It's not a small number for what is essentially operational overhead for GitOps tooling.

The alternative is self-managing open-source Argo CD on your own cluster nodes. No direct software cost, but you own upgrades, HA configuration, and incident response. The managed Capability makes economic sense when your team's time is worth more than $131/month — for most production teams, that's a reasonable trade.

EKS Capabilities pricing is only confirmed for US East (N. Virginia). Regional price variations are possible but not publicly documented. Also not available in GovCloud or China regions.

EKS Hybrid Nodes: Pricing for On-Premises Kubernetes

EKS Hybrid Nodes (GA December 2024) lets you connect on-premises or other cloud VMs to an EKS control plane running in AWS. The EKS-managed control plane handles orchestration; your on-premises hardware runs the actual pods.

Billing is per vCPU-hour reported to Kubernetes, using a tiered pricing model that rewards volume. Usage is aggregated across your AWS Organization, so large organizations automatically benefit from volume discounts.

Worked example: 100 nodes with 16 vCPU each, running 730 hours/month = 1,168,000 vCPU-hours.

• First 576,000 vCPU-hrs at $0.020 = $11,520
• Next 576,000 vCPU-hrs (the remaining 592,000 capped at tier 2) at $0.014 = $8,064
• Remaining 16,000 vCPU-hrs at $0.010 = $160
• Total Hybrid Nodes fee: $19,744/month

For bare metal servers with hyperthreading enabled, billing is based on the reported vCPU count — which is 2x the physical core count. A 16-core server with hyperthreading reports 32 vCPUs and bills accordingly.

Machines with more than 32 vCPU per node: contact the AWS account team. Not available in GovCloud or China regions.

Hidden Costs That Inflate Your EKS Bill

The EKS pricing page lists the EKS-specific charges. It says nothing about cross-AZ data transfer, NAT Gateway, public IPv4, EBS volumes, load balancers, or CloudWatch — all of which appear on your actual bill.

These secondary costs typically add 20-40% on top of EC2 compute. For teams new to EKS, this gap between "estimated compute cost" and "actual AWS bill" is the #1 source of surprise.

Cross-AZ Data Transfer

Pod-to-pod traffic crossing Availability Zones is billed at $0.01/GB in each direction. This sounds small until you have microservices spread across AZs communicating at scale.

A cluster processing 100 GB/day of east-west traffic between pods in different AZs pays roughly $60/month in data transfer alone. At 500 GB/day, that's $300/month — real money that doesn't appear anywhere in the EKS pricing documentation.

The fix: topology-aware routing keeps pod-to-pod traffic within the same AZ when possible. Both Karpenter and Auto Mode support topologySpreadConstraints in pod specs. This is often a zero-cost optimization once configured correctly.

NAT Gateway and Public IPv4

Pods in private subnets route internet-bound traffic through NAT Gateways. AWS charges $0.045/hr per NAT Gateway ($32.85/month fixed) plus $0.045/GB of data processed. A production setup with two NAT Gateways processing 500 GB/month of outbound traffic adds up to: $65.70 (hourly) + $22.50 (data) = $88.20/month.

High-traffic clusters can easily spend $200-400/month on NAT Gateway alone. The mitigation: deploy VPC endpoints for S3, ECR, Secrets Manager, and SSM. Traffic to those services routes directly through AWS's private network instead of through NAT — eliminating data processing charges for those calls.

Every public IPv4 address costs $0.005/hr ($3.60/month) since the February 2024 pricing change. A cluster with 10 nodes each having a public IP, plus two NAT Gateway EIPs, plus one load balancer EIP adds $46.80/month just in IP address charges.

For detailed NAT Gateway optimization strategies, see reduce NAT Gateway costs.

EBS Volumes, Load Balancers, and CloudWatch

Each worker node typically has an EBS root volume: gp3 storage runs $0.08/GB-month. A 50 GB root volume per node = $4/node/month. At 20 nodes, that's $80/month in EBS alone before any persistent volumes for applications.

Application Load Balancers created by the AWS Load Balancer Controller cost $0.0225/hr ($16.43/month fixed) plus LCU charges based on traffic. Teams with many small services often create one ALB per service — 10 services means $164.30/month in ALB fixed fees. A single ALB with path-based routing for multiple services is significantly cheaper.

CloudWatch Container Insights provides pod-level metrics and logs, but it's not free. For a medium-sized cluster with detailed logging enabled, CloudWatch costs typically run $100-300/month as a rough estimate depending on log volume and query frequency. Container Insights metrics plus log ingestion plus Insights queries all bill separately. See CloudWatch pricing for the full breakdown.

For ECR image storage and transfer costs that pair with EKS workloads, see Amazon ECR pricing.

Real-World EKS Cost Scenarios

Abstract pricing tables are useful. What a real aws eks cost looks like at different scales is more useful. Here are three complete amazon eks pricing scenarios using actual rates, so you can benchmark against your own setup.

Small Startup Cluster (2 t3.medium Nodes, Standard Support)

A single team running a development or early-stage production environment. Single-AZ deployment (no cross-AZ data transfer), low NAT Gateway traffic, minimal monitoring.

This is close to the practical minimum for a functional EKS cluster. It's not production-hardened (no HA, no multi-AZ), but it's a real working cluster budget for early-stage teams.

Mid-Size Team Cluster (8 m5.xlarge Nodes, Mixed Spot/On-Demand)

A production cluster with proper HA, multi-AZ distribution, a load balancer, and mix of On-Demand (system/stateful workloads) and Spot (stateless batch).

The Spot discount on four nodes saves roughly $391/month versus running all eight On-Demand. The control plane fee is less than 7% of total cost here.

Enterprise Auto Mode Cluster (4 Nodes: c6a.2xlarge + c6a.4xlarge + m5a.2xlarge + m5a.xlarge)

Using the official AWS pricing example as the base, extended with realistic networking and storage.

If this cluster also runs EKS Capabilities (Argo CD with 100 apps), add $131.40/month to get ~$1,653/month total.

For a custom estimate on your actual cluster configuration, use the EKS pricing calculator.

How to Reduce Your EKS Costs

The biggest wins in EKS cost optimization come from four areas: EC2 purchase strategy, Kubernetes version management, networking topology, and pod resource right-sizing. Not all of them require significant effort — some are configuration changes you can make in an afternoon.

If you're looking for the cheapest way to run EKS: a single cluster on standard support with 2 small On-Demand nodes in one AZ, basic CloudWatch, and no Capabilities runs around $178/month — that's the floor for a functional cluster. From there, every optimization below reduces the cost of scaling up.

The EKS Best Practices Guide cost optimization section is the authoritative AWS reference for these strategies if you want to go deeper than what's covered here.

Spot Instances and Karpenter

EC2 Spot offers up to 90% discount versus On-Demand with a 2-minute interruption notice. For stateless, fault-tolerant workloads — batch jobs, CI runners, stateless microservices — this is the single largest cost reduction available.

Karpenter handles Spot more efficiently than the legacy Cluster Autoscaler because it selects from a wide pool of instance types (reducing the chance that any one type loses capacity), supports the price-capacity-optimization allocation strategy, and automatically consolidates pods onto fewer nodes to terminate underused instances.

The pattern that works: On-Demand nodes for stateful and system workloads, Spot for batch and stateless. Mix 15-20 compatible instance types in your Karpenter NodePool to reduce interruption risk across the entire pool.

Savings Plans and Reserved Instances

For your predictable baseline compute — the minimum node count running 24/7 — Compute Savings Plans or EC2 Instance Savings Plans significantly cut On-Demand costs.

The standard strategy: Compute Savings Plans for your predictable floor capacity plus Spot for burst above that floor. This combination typically delivers 50-70% compute savings compared to pure On-Demand.

Important: if you're running Auto Mode, Savings Plans apply to the underlying EC2 instance cost but not the ~12% management fee. Factor this in when calculating your expected savings.

Graviton Nodes and Right-Sizing

Graviton (ARM) EC2 instances typically run 20% cheaper than x86 equivalents with roughly 40% better price-performance for cloud-native workloads. For Fargate, Linux/ARM is about 20% cheaper than Linux/x86.

The requirement: your container images need to support linux/arm64. Most common container images publish multi-arch versions today. For images you build yourself, adding --platform linux/amd64,linux/arm64 to your Docker build is usually sufficient.

Right-sizing pod resource requests is the highest-leverage optimization because it compounds through your entire compute cost. A pod requesting 500m CPU that actually uses 50m blocks that CPU slot from other pods. At cluster scale, overprovisioning by 5x means running 5x more nodes than necessary.

Tools worth using: Goldilocks or VPA in recommendation mode to get right-sizing suggestions per workload, KRR (Kubernetes Resource Recommender) for CLI-based analysis against Prometheus metrics, and Kubecost for cost-impact estimates alongside the recommendations. The AWS-optimized Kubecost bundle is available at no additional charge on EKS. Also consider AWS Billing split cost allocation data — it provides Kubernetes-native cost breakdowns (by namespace, pod, and label) directly in the AWS Billing Console with no additional tooling required.

Kubernetes Version Management (Avoiding Extended Support)

This is the simplest optimization with a clear dollar value attached. Staying on standard support versus drifting into extended support saves $365/month per cluster ($438 - $73). For three clusters, that's $1,095/month saved by treating version upgrades as scheduled quarterly work.

If you manage EKS via Terraform, the version pinning pattern matters. Pinning is good hygiene — it prevents surprise upgrades — but it also means you need an explicit process to bump versions before month 15:

resource "aws_eks_cluster" "main" {
  name = "production"
  # UPGRADE DEADLINE: Kubernetes 1.31 extended support starts 2026-11-01
  # Run upgrade runbook before that date to stay on $73/month
  version = "1.31"

  # Prevent auto-enrollment into extended support on CLI-created clusters
  upgrade_policy {
    support_type = "STANDARD"
  }

  role_arn = aws_iam_role.cluster.arn
  vpc_config { ... }
}

Setting support_type = "STANDARD" on the upgrade policy explicitly opts the cluster out of extended support — Amazon EKS will automatically upgrade the cluster to the next supported Kubernetes version at the end of standard support instead of silently transitioning to the $0.60/hr rate. This is the IaC equivalent of the Console's auto-upgrade behavior.

Networking Cost Reduction

Topology-aware routing is often the easiest networking win. Configure topologySpreadConstraints to keep pod-to-pod traffic within the same AZ. Karpenter and Auto Mode both support this. Combined with co-locating related services in the same AZ via node affinity rules, you can eliminate cross-AZ data transfer charges for high-throughput internal services.

For traffic to AWS services (S3, ECR, Secrets Manager, SSM), VPC endpoints route traffic through AWS's private network instead of through your NAT Gateway. This eliminates data processing charges for those service calls — often the highest-volume NAT Gateway traffic in a cluster that pulls container images from ECR frequently.

See VPC pricing and NAT Gateway costs for the detailed breakdown on what's worth putting behind a VPC endpoint.

IaC Cost Governance with Terraform

The best time to catch a cost regression is before it deploys. I've seen teams accidentally spin up Provisioned Control Plane clusters, enable Capabilities without understanding the pricing, and leave extended support enabled in their Terraform defaults — all of which show up as billing surprises weeks later.

A few patterns worth encoding in your IaC:

• Enforce Graviton instance types in module variables with x86 as an opt-in override requiring a comment
• Flag large instance types (anything above 8xlarge) with a required justification variable
• Pin Kubernetes versions with upgrade deadlines in comments as shown above
• Gate Capabilities and Provisioned Control Plane on explicit boolean flags with false as the default

If you want to catch these patterns before they merge rather than after they deploy, CloudBurn scans Terraform and CloudFormation for EKS cost anti-patterns directly in CI. The same rules also run against your live AWS account to surface what's already running against you.

Key Takeaways

Amazon EKS pricing has more dimensions than most guides cover. Here's what actually matters for your aws eks cost in 2026:

1. The floor is $73/month per cluster — before nodes, before pods. For multi-cluster environments (dev/staging/prod), multiply by three minimum.
2. The extended support trap is real and automatic — the $0.10/hr to $0.60/hr jump (6x) catches Terraform-managed clusters especially hard because CLI/IaC defaults enable extended support rather than auto-upgrading.
3. Auto Mode adds ~12% on your EC2 costs — and Savings Plans don't discount that surcharge, only the underlying EC2 portion. Factor this in when modeling the ROI.
4. Provisioned Control Plane and Capabilities are 2025 additions most guides haven't covered — if you run GitOps at scale or have enabled Argo CD/ACK/KRO as managed Capabilities, budget for these explicitly.
5. Networking costs add 20-40% on top of compute — cross-AZ data transfer and NAT Gateway charges are the most common surprise on real EKS bills.

The most effective optimization sequence: right-size pod resource requests first (fixes bin-packing efficiency), add Spot via Karpenter (up to 90% on stateless compute), buy Compute Savings Plans for your baseline (up to 66%), and stay current on Kubernetes versions (avoids the extended support cliff).

For related cost breakdowns that pair with this guide: ECR image storage and transfer costs, VPC pricing and NAT Gateway costs, and Compute Savings Plans for the full commitment strategy.

Frequently Asked Questions