---
title: Amazon EKS Pricing: Control Plane, Extended Support, Auto Mode
description: EKS control planes are $73/month per cluster. Stay on a Kubernetes version beyond its 14-month standard support and Extended Support bills $0.60/cluster-hour ($438/month per cluster), a 6× multiplier vs standard. EKS Auto Mode adds a ~12% markup over standard EC2 + EBS for managed compute simplicity. The compute side (Karpenter, Spot, Graviton) is where most of the bill lives.
url: https://www.joinhorizon.co/blog/amazon-eks-pricing-control-plane-addons-auto-mode/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: kevin-w
category: Cost Optimization & FinOps
tags: amazon-eks, eks-pricing, aws-pricing, cost-optimization, finops, kubernetes
---

# Amazon EKS Pricing: Control Plane, Extended Support, Auto Mode

> EKS control planes are $73/month per cluster. Stay on a Kubernetes version beyond its 14-month standard support and Extended Support bills $0.60/cluster-hour ($438/month per cluster), a 6× multiplier vs standard. EKS Auto Mode adds a ~12% markup over standard EC2 + EBS for managed compute simplicity. The compute side (Karpenter, Spot, Graviton) is where most of the bill lives.

import PricingHeroStats from '~/components/blog/PricingHeroStats.astro';
import PricingDimensionTable from '~/components/blog/PricingDimensionTable.astro';
import BillSurpriseCallout from '~/components/blog/BillSurpriseCallout.astro';
import PricingDecisionCard from '~/components/blog/PricingDecisionCard.astro';
import PricingCalculatorCta from '~/components/blog/PricingCalculatorCta.astro';

Amazon EKS bills two things directly: the control plane ($0.10 per cluster hour, $73/month in standard support) and Extended Support ($0.60 per cluster hour, $438/month when the Kubernetes version is past its standard-support window). Everything else lives on adjacent services: EC2 for nodes, EBS for persistent volumes, ELB for ingress, CloudWatch Logs for container logs, ECR for images. The EKS control plane is almost always the smallest line in an EKS bill; the operational decisions (Kubernetes upgrade cadence, Karpenter adoption, Spot strategy) are what determine whether your monthly EKS spend is dramatically more or dramatically less than a comparable ECS or EC2 workload.

> **Amazon EKS pricing** bills the control plane per cluster-hour plus worker compute, add-ons, and observability separately. In us-east-1 (June 2026), the control plane costs $0.10/hour (~$73/month). Most surprises come from worker-node fleets and CloudWatch log volume, not the control plane line itself.

| Line             | us-east-1          | Relative weight   |
| ---------------- | ------------------ | ----------------- |
| Control plane    | $0.10/hr (~$73/mo) | Small vs compute  |
| Worker EC2       | Instance hours     | Dominant          |
| Extended Support | Premium on old K8s | $18K+/mo at scale |
| Auto Mode        | ~12% on compute    | New 2025+ option  |

<PricingHeroStats
  stats={[
    { value: '$0.10', label: 'Control plane / hour', note: '$73/month flat, independent of cluster size' },
    {
      value: '$0.60',
      label: 'Extended Support / hour',
      note: '$438/month total when past standard support (vs $0.10 standard)',
    },
    { value: '~12%', label: 'EKS Auto Mode markup', note: 'Over standard EC2 + EBS for managed compute' },
    {
      value: 'EC2',
      label: 'Where most of the bill lives',
      note: 'Karpenter, Spot, Graviton control the worker fleet cost',
    },
  ]}
  caption="us-east-1 list prices, June 2026. Verify against the AWS EKS pricing page for your region. Source: [AWS Pricing page](https://aws.amazon.com/eks/pricing/), us-east-1, retrieved June 2026."
/>
<PricingCalculatorCta blogSlug="amazon-eks-pricing-control-plane-addons-auto-mode" />

This post is the bill story. For Karpenter vs Cluster Autoscaler cost optimization, see our [Karpenter comparison post](https://www.joinhorizon.co/blog/karpenter-vs-cluster-autoscaler-eks-cost-optimization/). For the broader EKS production architecture, [Karpenter-based cost-optimized autoscaling](https://www.joinhorizon.co/blog/how-to-deploy-eks-karpenter-cost-optimized-autoscaling/) covers the deployment side.

## The EKS billing dimensions

<PricingDimensionTable
  title="EKS pricing breakdown: us-east-1, June 2026"
  intro="Control plane and Extended Support are EKS-direct; everything else bills on adjacent AWS services consumed by the cluster."
  region="us-east-1"
  dimensions={[
    {
      name: 'EKS control plane',
      unitPrice: '$0.10 / hour',
      example: 'One cluster',
      monthly: '$73',
      note: 'Flat, independent of cluster size',
      highlight: true,
    },
    {
      name: 'EKS Extended Support',
      unitPrice: '$0.60 / hour',
      example: 'Cluster behind on Kubernetes version',
      monthly: '$438',
      note: 'All-in rate vs $73/month standard support',
      highlight: true,
    },
    {
      name: 'EC2 worker nodes',
      unitPrice: 'Standard EC2 rates',
      example: '50 × m6i.xlarge on-demand',
      monthly: '~$7,000',
      note: 'Karpenter + Spot for major savings',
      highlight: true,
    },
    {
      name: 'Fargate-on-EKS',
      unitPrice: '$0.04048/vCPU-hr + $0.004445/GB-hr',
      example: '100 pods × 1 vCPU / 2 GB',
      monthly: '~$3,600',
      note: '25 to 40% more than equivalent EC2',
    },
    {
      name: 'EKS Auto Mode',
      unitPrice: '~12% markup on EC2 + EBS',
      example: 'Managed compute layer',
      monthly: 'Per fleet size',
      note: 'Bundles Karpenter, EBS CSI, load balancer controller',
    },
    {
      name: 'EBS for persistent volumes',
      unitPrice: 'Standard EBS rates ($0.08/GB-month gp3)',
      example: '5 TB cluster storage',
      monthly: '~$400',
      note: 'See [EBS pricing](https://www.joinhorizon.co/blog/amazon-ebs-pricing-orphaned-volumes-snapshots/)',
    },
    {
      name: 'ELB for ingress',
      unitPrice: 'ALB at $0.0225/hour + LCU',
      example: '1 ALB per ingress',
      monthly: '~$20+ each',
      note: 'AWS Load Balancer Controller; consolidate ingresses',
    },
    {
      name: 'CloudWatch Logs from container logs',
      unitPrice: '$0.50 / GB ingested',
      example: '20 GB/day container logs',
      monthly: '~$300/month per cluster',
      note: 'Often the largest hidden EKS line',
      highlight: true,
    },
    {
      name: 'Container Insights',
      unitPrice: 'Per metric per cluster + Logs ingestion',
      example: 'Per cluster (production)',
      monthly: '$500–$2,000 per cluster',
      note: 'Disable on non-prod clusters',
    },
    {
      name: 'ECR image storage and pulls',
      unitPrice: '$0.10/GB storage + cross-region transfer',
      example: 'Container image catalog',
      monthly: 'See [ECR pricing](https://www.joinhorizon.co/blog/amazon-ecr-pricing-storage-replication-pull-through/)',
      note: 'Lifecycle policies are essential',
    },
    {
      name: 'EKS Pod Identity',
      unitPrice: 'Free',
      example: 'Modern IAM-for-pods primitive',
      monthly: '$0',
      note: 'Migration target from IRSA',
    },
  ]}
  footnote="The control plane is the smallest line in almost every EKS bill. Worker fleet (EC2), CloudWatch Logs, and Container Insights are where the savings live."
/>

_If you only audit one dimension first, optimize **worker nodes (Karpenter/Spot/Graviton)**. The control plane is rarely the bill driver._

## The Extended Support trap

![Architecture diagram of an EKS cluster on standard support and one on extended support](../../assets/images/blog/amazon-eks-pricing-control-plane-addons-auto-mode-support.webp)

_Figure: the support window in the article. The rows are alternatives. A current Kubernetes version stays on standard support. An older version moves to extended support. The charge stays in the article. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/amazon-eks-pricing-control-plane-addons-auto-mode/support.drawio)._

The single most consequential EKS bill spike happens silently: when a cluster falls out of standard support for its Kubernetes version. EKS provides 14 months of standard support for each minor version. After that, the cluster enters Extended Support at **$0.60/cluster-hour**, a 6× multiplier that takes the cluster cost from $73/month to $438/month.

For organizations with many clusters and inconsistent upgrade discipline, this is a real bill line:

<PricingDimensionTable
  title="Extended Support cost across cluster counts"
  intro="Same monthly cost per cluster; what differs is how many clusters fell behind."
  region="us-east-1"
  dimensions={[
    {
      name: '10 clusters, all on supported versions',
      unitPrice: '$73 × 10',
      example: 'Disciplined upgrade cadence',
      monthly: '$730',
      note: 'Baseline EKS control plane cost',
    },
    {
      name: '10 clusters, 5 on Extended Support',
      unitPrice: '$73 × 5 + $438 × 5',
      example: 'Mixed compliance',
      monthly: '$2,555',
      note: '3.5× the disciplined cost',
    },
    {
      name: '50 clusters, all on Extended Support',
      unitPrice: '$438 × 50',
      example: 'Worst case',
      monthly: '$21,900',
      note: '6× the baseline penalty',
      highlight: true,
    },
    {
      name: '50 clusters, all current',
      unitPrice: '$73 × 50',
      example: 'Goal state',
      monthly: '$3,650',
      note: 'Savings vs worst case: $18,250/mo',
    },
  ]}
  footnote="Extended Support is avoided through operational hygiene. A quarterly upgrade cadence prevents the multiplier entirely."
/>

<BillSurpriseCallout
  variant="surprise"
  title="Cluster fleet missed the Kubernetes upgrade window"
  amount="+$365/month per stale cluster, indefinitely"
>
  Extended Support starts the moment a cluster's Kubernetes version exits the 14-month standard window. There is no
  warning beyond the announcement in the EKS console. Build a quarterly upgrade cadence into the platform team's
  roadmap; subscribe to EKS version deprecation notifications via EventBridge; treat upgrades as a release-grade event
  with rollback plan. Letting the cadence slip is the single most expensive EKS operational mistake.
</BillSurpriseCallout>

## EKS Auto Mode: a 12% premium for managed compute

![Architecture diagram of an EKS node group you manage and EKS Auto Mode managed compute as alternatives](../../assets/images/blog/amazon-eks-pricing-control-plane-addons-auto-mode-automode.webp)

_Figure: Auto Mode in the article. The rows are alternatives. A node group is compute you operate. Auto Mode is compute EKS operates. The premium stays in the article. Karpenter provisioning is an earlier diagram. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/amazon-eks-pricing-control-plane-addons-auto-mode/automode.drawio)._

EKS Auto Mode is the managed compute primitive AWS introduced to abstract the worker node, autoscaler, CSI driver, load balancer controller, and IAM management. It bills approximately 12% on top of the underlying EC2 + EBS resource costs.

The break-even is operational maturity:

- **Teams without strong Karpenter or Kubernetes operations expertise**: Auto Mode is worth it. The 12% premium pays for not having to operate Karpenter, EBS CSI driver, ALB controller, and IAM-for-pods independently.
- **Teams with strong existing Karpenter operations**: the 12% premium is value-free. The team is already running tight cost optimization on bare EC2 + Karpenter; Auto Mode doesn't add anything beyond what they already have.

The decision applies when you spin up new clusters. Migrating existing well-optimized clusters is rarely worth it.

## The compute side of the bill

The EKS control plane is a small line. The worker fleet is where bills go up or down by an order of magnitude.

The three highest-impact compute optimizations:

1. **Karpenter for consolidation.** Karpenter packs pods onto fewer, larger nodes than Cluster Autoscaler typically does. Saves 20 to 40% on the worker fleet cost. See our [Karpenter comparison](https://www.joinhorizon.co/blog/karpenter-vs-cluster-autoscaler-eks-cost-optimization/).

2. **Spot instances for non-critical workloads.** Spot pricing is 60 to 90% cheaper than on-demand. Configure Karpenter with mixed Spot + On-Demand NodePools; tag pods with Spot tolerance based on workload criticality. Stateful workloads (databases on EKS) stay on-demand; stateless app pods go Spot.

3. **Graviton (ARM) nodes.** Graviton instances run 20 to 40% cheaper than equivalent x86 instances. Container workloads with multi-arch images can run on Graviton as is; the migration is one Karpenter NodePool config change.

A 50-node cluster moving from on-demand x86 + Cluster Autoscaler to Karpenter + Spot + Graviton typically cuts the compute bill by 60 to 80%.

## CloudWatch Logs as a quiet EKS cost

A common pattern: container workloads on EKS ship every container's stdout/stderr to CloudWatch Logs via FluentBit or AWS for Fluent Bit. The agent is free; the ingestion at $0.50/GB compounds with deployment frequency.

A busy 50-node cluster with 200 pods producing 100 MB/day each generates 20 GB/day per cluster, or $300/month per cluster in CloudWatch Logs ingestion alone. Multi-cluster organizations easily land at $3K to $10K/month on container logs.

The mitigations:

1. **Ship container logs to S3 via Firehose** instead of CloudWatch Logs. S3 is $0.023/GB-month, while CloudWatch Logs charges $0.50/GB at ingestion plus $0.03/GB-month for storage.
2. **CloudWatch Logs retention to 14 days** for application container logs.
3. **FluentBit ExcludePath** to drop healthcheck endpoints, /metrics endpoints, and other noise.
4. **Sample DEBUG logs** at the application level before they reach FluentBit.

See our [CloudWatch pricing post](https://www.joinhorizon.co/blog/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/) for the broader observability cost story.

## When to use EKS vs alternatives

<PricingDecisionCard
  headline="EKS for Kubernetes-required workloads with strong operations team; ECS for simpler container orchestration; Fargate-on-EKS for operational simplicity when workloads fit the model."
  useWhen={[
    'Multi-team platform workloads where Kubernetes-native primitives (CRDs, operators, Istio, etc.) deliver real value',
    'Workloads with existing Kubernetes investment (Helm charts, operators, runbooks) that would cost more to migrate than maintain',
    'Multi-cloud or hybrid workloads where Kubernetes is the abstraction layer',
    'Karpenter-based fleet management for cost-optimized autoscaling: needs Kubernetes operations capability',
    'EKS Auto Mode for new clusters when the operations team is not Kubernetes-deep',
    'EKS Hybrid Nodes for regulated workloads with on-premises compute requirements',
  ]}
  avoidWhen={[
    'Simple stateless containerized workloads where ECS would suffice: consider [ECS Express Mode](https://www.joinhorizon.co/blog/amazon-ecs-express-mode/) or [Fargate & ECS task pricing](https://www.joinhorizon.co/blog/amazon-fargate-ecs-task-pricing-2026/) before paying for a control plane',
    'Single-service or single-team workloads: ECS or App Runner is operationally simpler',
    'Workloads on stale Kubernetes versions: Extended Support is a 6× multiplier that compounds monthly',
    'Multi-cluster sprawl when consolidation would work: each cluster is $73/month',
    'CloudWatch Logs for container logs without retention and FluentBit hygiene: quiet 5-figure monthly bill',
  ]}
  footnote="EKS is rarely the wrong primitive when Kubernetes is genuinely the right abstraction. The bill problems are upgrade discipline, compute strategy, and observability hygiene."
/>

## A 30-day EKS bill cleanup plan

**Week 1: Upgrade audit.** List every EKS cluster: `aws eks list-clusters --region <r>` per region. For each, check Kubernetes version against the EKS version support table. Flag any cluster within 60 days of standard support exit. Schedule upgrade work; the saving is $365/month per cluster prevented from entering Extended Support.

**Week 2: Container logs hygiene.** Audit container log ingestion volume per cluster (CloudWatch `IncomingBytes` filtered by log group prefix). For the top 3 high-volume clusters, apply FluentBit ExcludePath rules and route lower-value logs to S3 via Firehose.

**Week 3: Compute strategy review.** For each cluster, verify Karpenter is in use (not Cluster Autoscaler) and that Spot is enabled for non-critical workloads. Evaluate Graviton migration for clusters with multi-arch image support.

**Week 4: Cluster consolidation evaluation.** Identify low-utilization clusters (under 30% average node utilization). Plan consolidation into shared multi-tenant clusters where the operational and security model supports it.

## More in this series

Part of the **AWS Service Pricing** series (June 2026).

- Previous: [Part 18](https://www.joinhorizon.co/blog/amazon-aurora-pricing-io-optimized-serverless-v2-global/)
- Next: [Part 20](https://www.joinhorizon.co/blog/amazon-cloudfront-pricing-regional-tiers-requests-security/)
- Browse all: [Cost Optimization & FinOps category](https://www.joinhorizon.co/category/cost-optimization-and-finops/)
- FinOps pillar: [FinOps shift-left: cost feedback in the pull request](https://www.joinhorizon.co/blog/aws-finops-shift-left-engineering-cost-ownership/)

## What this post doesn't cover

- **Karpenter operational patterns in depth**: covered in our [Karpenter vs Cluster Autoscaler comparison](https://www.joinhorizon.co/blog/karpenter-vs-cluster-autoscaler-eks-cost-optimization/).
- **EKS Hybrid Nodes / Outposts** in depth: specialized hybrid-cloud use cases; covered in hybrid architecture content.
- **Service mesh on EKS** (Istio, App Mesh deprecation, VPC Lattice): covered in our [service mesh post](https://www.joinhorizon.co/blog/service-mesh-traffic-shifting-vpc-lattice-istio-eks/).
- **GitOps with ArgoCD / Flux**: operational architecture covered in our [GitOps for EKS guide](https://www.joinhorizon.co/blog/aws-gitops-eks-argocd-flux-2026/).

## If you only do one thing this week

Audit every cluster's Kubernetes version against the EKS standard-support window. Run `aws eks list-clusters --region <r>` per region, then `aws eks describe-cluster --name <name>` for each to get the version. Cross-reference against the EKS Kubernetes version support calendar. Any cluster within 60 days of exiting standard support needs an upgrade plan. Extended Support is silent; the bill arrives 14 months after the version goes out of standard support and persists until the cluster is upgraded. Quarterly cluster upgrade cadence prevents this entirely; missing the cadence is the single most expensive EKS operational mistake.

For the worker-fleet cost optimization (Karpenter, Spot, Graviton, consolidation), the [Karpenter vs Cluster Autoscaler post](https://www.joinhorizon.co/blog/karpenter-vs-cluster-autoscaler-eks-cost-optimization/) covers the compute side in depth.

## FAQ

### Why does Extended Support cost 6× the standard control plane?
Extended Support bills $0.60/cluster-hour total ($438/month) vs $0.10/hour ($73/month) in standard support, a 6× multiplier. AWS publishes the all-in Extended Support rate, not a separate add-on line. The pricing is designed to push teams to upgrade Kubernetes versions on cadence. Each minor version of Kubernetes has 14 months of standard support; after that, the cluster enters Extended Support for another 12 months at the premium rate. Organizations with 50 clusters that miss the upgrade window can see EKS costs jump from $3,650/month to $21,900/month, a $18,250/month penalty for falling behind. The fix is operational: a quarterly Kubernetes upgrade cadence prevents the penalty entirely.

### Is EKS Auto Mode worth the 12% markup?
EKS Auto Mode bundles Karpenter, EBS CSI driver, load balancer controller, pod identity, and managed node lifecycle into a single managed service that adds approximately 12% on top of the underlying EC2 + EBS costs. For teams without strong Kubernetes operational expertise, the markup pays for itself in reduced operational burden: fewer upgrades to manage, fewer add-ons to configure, fewer security patches to apply. For teams with strong Karpenter experience already running tight cost optimization, Auto Mode is a premium without commensurate value. The decision depends on operational maturity more than on strict cost optimization.

### Why is the EKS control plane the smallest line in most EKS bills?
Because compute dominates. A typical production EKS cluster runs 50 to 500 worker nodes; each node is an EC2 instance billing $40 to $2,000/month depending on size. The 50-node cluster might have $8K to $50K/month in compute alongside the $73/month control plane. The control plane is the smallest line by orders of magnitude. Cost optimization for EKS is primarily about worker-node strategy (Karpenter for consolidation, Spot for non-critical workloads, Graviton for 20 to 40% saving) and add-on hygiene (CloudWatch Logs from FluentBit, Container Insights, ALB per ingress). The control plane is a fixed line; the variable lines are where the savings live.

### How much does Fargate-on-EKS cost compared to EC2-backed nodes?
Fargate-on-EKS bills the standard Fargate per-vCPU-hour ($0.04048) and per-GB-hour ($0.004445) rates. The all-in cost for a workload that fits on Fargate is roughly 25 to 40% more expensive than the equivalent EC2 on-demand instance with binpacked pods, and roughly 3× more expensive than the same workload on EC2 Spot. Fargate-on-EKS is correct when operational simplicity is worth the premium (no node management, isolated execution per pod), and when the workload is bursty enough that EC2 idle time would exceed the Fargate premium. For steady production workloads on a well-sized EC2 fleet, EC2 wins on cost.

### What is the actual cost of running a CloudWatch FluentBit log forwarder on EKS?
The agent itself is free; the bill is in CloudWatch Logs ingestion at $0.50/GB. A busy 50-node cluster with 200 pods producing 100 MB/day each generates 20 GB/day, $300/month per cluster in CloudWatch Logs ingestion alone. Across a multi-cluster organization, container log ingestion can quietly run at about 4× the control plane fee for each cluster ($300 vs $73/month in this example). The mitigations: ship container logs to S3 via Firehose (much cheaper for retention), apply aggressive CloudWatch Logs retention (14 days for non-essential), sample DEBUG-level logs at the source, use FluentBit ExcludePath to drop healthcheck and noise endpoints.

### Does the EKS control plane scale with cluster size?
No. The $0.10/hour control plane fee is flat regardless of cluster size: a 5-node cluster pays the same as a 5000-node cluster. This makes cluster consolidation a cost lever: combining 10 small clusters into 1 large cluster saves $657/month on control plane fees ($73 × 10 - $73). The trade-off is blast radius and tenant isolation. Multi-tenant EKS via Namespaces, NetworkPolicies, and possibly virtual clusters can deliver tenant isolation without per-tenant clusters, but the operational model becomes more complex.

### What about EKS Hybrid Nodes / AWS Outposts EKS pricing?
EKS Hybrid Nodes (on-premises hardware joined to an EKS cluster) bills per node-hour, providing managed Kubernetes control-plane semantics for on-premises compute. Pricing is roughly aligned with Fargate per-vCPU-hour but for owned hardware. EKS on AWS Outposts uses the standard EKS control plane plus the Outposts infrastructure cost (separately billed). These are specialized use cases, primarily for regulated workloads with data-residency requirements that prevent pure AWS compute. The cost economics depend on the Outposts contract; usually higher than pure AWS compute but provides on-premises capabilities.

---

*Source: https://www.joinhorizon.co/blog/amazon-eks-pricing-control-plane-addons-auto-mode/*