What Is Amazon EKS Pricing?
Amazon EKS charges a flat fee of $0.10 per hour for each cluster's control plane (approx. $72/month). In addition to this, you pay for the underlying AWS resources (EC2 instances, Fargate, EBS volumes, load balancers) used to run your worker nodes and application. Extended support for older Kubernetes versions costs $0.60 per hour.
Understanding EKS pricing is critical for organizations to estimate their cloud expenses accurately and avoid unexpected costs. AWS offers multiple operational modes for EKS, each with its own cost structure. Users need to evaluate the pricing implications of using standard clusters, managed node groups, auto scaling options, and optional add-ons. Analyzing these components upfront ensures effective budget planning and enables cost optimization.
This is part of a series of articles about Kubernetes pricing.
In this article:
- Understanding AWS EKS Pricing Components
- Hidden and Add-On Amazon EKS Costs
- Amazon EKS Pricing Examples
- 6 Ways to Reduce and Optimize Amazon EKS Costs
Understanding AWS EKS Pricing Components
Let's review the key cost components of Amazon EKS clusters.
Amazon EKS Cluster Pricing
Amazon EKS charges a per-cluster hourly fee for every EKS cluster. The price depends on the Kubernetes version support tier used by the cluster:
- Clusters running a Kubernetes version under standard support cost $0.10 per cluster per hour.
- A Kubernetes version stays in standard support for the first 14 months after it is released in Amazon EKS.
- After standard support ends, the version enters extended support for the next 12 months.
- Extended support costs $0.60 per cluster per hour. This includes the standard $0.10 hourly fee plus an extra $0.50 per cluster per hour.
This pricing applies to the EKS cluster itself. Users still pay separately for the AWS resources used by their workloads, such as EC2 instances, EBS volumes, public IPv4 addresses, or Fargate compute.
Amazon EKS Provisioned Control Plane Pricing
Amazon EKS Provisioned Control Plane lets users reserve a defined amount of control plane capacity for a cluster. This option is intended for workloads that need stable control plane performance, faster response to traffic spikes, or support for larger-scale Kubernetes operations.
Pricing is based on the selected control plane scaling tier. The charge is hourly and applies in addition to the standard EKS cluster fee. There are no upfront fees or long-term commitments:
- The XL tier costs $1.65 per cluster per hour.
- The 2XL tier costs $3.40 per cluster per hour.
- The 4XL tier costs $6.90 per cluster per hour.
- The 8XL tier costs $13.90 per cluster per hour.
Users can move between scaling tiers or return to the standard control plane. For tiers larger than 8XL, AWS requires users to contact their account team for pricing.
Amazon EKS Auto Mode
Amazon EKS Auto Mode pricing applies to clusters where EKS Auto Mode is enabled. The charge is based on the type and duration of the Amazon EC2 instances that EKS Auto Mode launches and manages. This fee is separate from the EC2 instance price. Users pay the normal EC2 cost for the underlying instances, while EKS Auto Mode adds its own management charge.
EKS Auto Mode is billed per second, with a one-minute minimum. The charge is independent of the EC2 purchase option, so it applies whether the instances use On-Demand pricing, Reserved Instances, Compute Savings Plans, or Spot Instances. Organizations that plan to use EKS Auto Mode for more than 150 nodes must contact their AWS account team for pricing information.
Amazon EKS Capabilities Pricing
Amazon EKS Capabilities pricing applies when specific capabilities are enabled on an EKS cluster. Pricing has two hourly parts: a base charge for each enabled capability and a usage charge based on the number of resources managed by that capability:
- For Argo CD in US East (Ohio), the base charge is $0.02771 per Argo CD capability hour. The usage charge is $0.00136 per Argo CD application hour. Each application is counted per target cluster deployment, so one application deployed to five clusters counts as five applications.
- For AWS Controllers for Kubernetes (ACK), the base charge is $0.004482 per ACK capability hour. The usage charge is $0.000045 per ACK resource hour.
- For Kubernetes Resource Orchestrator (KRO), the base charge is $0.004482 per KRO capability hour. The usage charge is $0.000045 per KRO RGD instance hour.
- All EKS capabilities charges are billed hourly. There are no upfront fees or minimum commitments.
Amazon EKS Hybrid Nodes Pricing
Amazon EKS Hybrid Nodes let users connect on-premises or edge infrastructure to Amazon EKS clusters. This allows Kubernetes workloads to use non-AWS infrastructure while keeping cluster management in Amazon EKS.
Pricing is based on vCPU-hours reported to Kubernetes:
- Billing starts when a hybrid node joins the cluster and stops when the node is removed.
- In bare metal environments with hyperthreading enabled, each physical CPU core reports two vCPUs to Kubernetes, and billing uses the reported vCPU count.
Hybrid Nodes pricing is tiered by aggregate monthly vCPU-hour usage in the same AWS Region:
- The first 576,000 monthly vCPU-hours cost $0.020 per vCPU-hour.
- The next 576,000 cost $0.014 per vCPU-hour.
- The next 4,608,000 monthly vCPU-hours cost $0.010 per vCPU-hour.
- The next 5,760,000 cost $0.008 per vCPU-hour.
- Usage above 11,520,000 monthly vCPU-hours costs $0.006 per vCPU-hour.
If consolidated billing is used through AWS Organizations, these tiers apply across accounts in the organization for the same Region. Users planning to run hybrid nodes on machines larger than 32 vCPUs per machine must contact their AWS account team.
EKS Anywhere Pricing
Amazon EKS Anywhere is open source software that runs Kubernetes clusters on hardware in a data center or edge environment. The software itself is available as open source, but AWS sells Enterprise Subscriptions for support and additional capabilities:
- An Amazon EKS Anywhere Enterprise Subscription provides support for licensed EKS Anywhere clusters. It also gives access to EKS Anywhere Curated Packages, which add functions such as load balancing, observability, and auto scaling.
- AWS Enterprise Support or AWS Enterprise On-Ramp Support is required before purchasing an EKS Anywhere Enterprise Subscription.
- Subscriptions can be purchased through the Amazon EKS console, API, or AWS CLI.
- Pricing is flat per cluster and does not depend on cluster size. A one-year term costs $24,000 per cluster, billed at $2,000 per month. A three-year term costs $18,000 per cluster per year, billed at $1,500 per month.
- Users can include one or more EKS Anywhere cluster licenses in a single subscription purchase.
- Subscriptions can be configured to renew automatically, and they can be canceled within the first seven days at no charge.
Hidden and Add-On Amazon EKS Costs
Beyond the basic core components, here are additional costs you might not be aware of, which are also related to your EKS clusters.
Storage Costs
Running workloads on Amazon EKS often requires persistent storage, which comes with additional costs. These costs typically arise from using Amazon EBS volumes, Amazon EFS (Elastic File System), or S3 buckets for object storage. Pricing for these storage services is based on the amount of storage provisioned, the type of storage (for example, SSD vs. HDD), and IOPS requirements. If workloads require high-performance storage or large capacities, storage costs can surpass the base EKS cluster fee.
Storage costs also include backup, snapshot, and data transfer charges. For example, creating regular EBS snapshots for disaster recovery or compliance can lead to additional monthly charges. Organizations should monitor storage usage, delete unused volumes, and right-size storage classes to avoid unnecessary expenses. Understanding the full scope of storage costs helps prevent budget overruns in EKS environments.
Data Transfer Costs
Data transfer costs in Amazon EKS are often overlooked, but they can impact your overall AWS bill. AWS charges for data transferred out of EKS clusters to the internet, between Availability Zones, and sometimes between AWS services in different Regions. For applications with high outbound traffic or cross-zone communication, these fees can accumulate and become a significant portion of total costs.
Architect EKS workloads to minimize unnecessary data transfer. For example, keep traffic within the same Availability Zone where possible, or use AWS PrivateLink for service-to-service communication to reduce costs. Regularly review data transfer patterns and adjust network topology to control these expenses in EKS deployments.
NAT Gateway Costs
Amazon EKS clusters that need internet access from private subnets typically use NAT Gateways. AWS charges for both the hourly usage of each NAT Gateway and the amount of data processed through them. In high-traffic environments or clusters with multiple private subnets, NAT Gateway charges can add up quickly.
To reduce NAT Gateway costs, consider consolidating traffic through fewer gateways or using NAT instances for lower-throughput requirements. Monitor NAT Gateway usage and review network architecture to identify cost-saving opportunities. Since NAT Gateway charges are not included in EKS control plane or node pricing, factor them into total cost of ownership calculations for EKS.
CloudWatch Logging and Monitoring
Amazon CloudWatch is commonly used for logging and monitoring EKS clusters, but its costs are separate from EKS pricing. CloudWatch charges are based on the volume of logs ingested, metrics stored, and dashboards created. High-frequency logging, verbose application logs, or extensive custom metrics can increase costs, especially in large or dynamic EKS environments.
Organizations should implement log retention policies, filter unnecessary logs, and aggregate metrics to control CloudWatch expenses. Using log sampling or third-party logging solutions can also reduce costs. Regularly review CloudWatch usage and optimize log and metric collection to avoid unexpected charges while maintaining sufficient observability for EKS workloads.
Amazon EKS Pricing Examples
Example 1: EKS Cluster Pricing With Standard and Extended Support
An EKS cluster runs the same Kubernetes version for 26 months without a control plane upgrade. For the first 14 months, the version is under standard support, costing $0.10 per cluster per hour. After that, it enters extended support for 12 months at $0.60 per cluster per hour.
To see the cost difference concretely: during the 14 months of standard support, the cluster costs roughly $1,022 in total cluster fees (14 × 730 hours × $0.10). During the 12 months of extended support, that rises to $5,256 (12 × 730 hours × $0.60), more than five times the cost for two fewer months. Averaged across the full 26-month period, the effective rate is $0.33 per cluster per hour.
Example 2: EKS Hybrid Nodes Pricing for Multiple Business Units
Three business units use EKS Hybrid Nodes, each on a dedicated EKS cluster under standard Kubernetes version support, giving each a monthly cluster charge of $73 (730 hours × $0.10).
Business Unit 1 runs 8 nodes at 8 vCPUs each, generating 46,720 vCPU-hours and a node charge of $934.40. Business Unit 2 runs 4 nodes at 16 vCPUs each, generating 46,720 vCPU-hours and a node charge of $934.40. Business Unit 3 runs 6 nodes at 4 vCPUs each, generating 17,520 vCPU-hours and a node charge of $350.40.
Combined, the three units consume 110,960 vCPU-hours for the month. Since this is well below the first tier ceiling of 576,000 monthly vCPU-hours, all usage is billed at $0.02 per vCPU-hour. The total monthly EKS bill is $2,438.20, made up of $219 in cluster charges and $2,219.20 in node charges.
Example 3: Amazon EKS Auto Mode Pricing Example
A containerized application runs on Amazon EKS Auto Mode in the US West (Oregon) Region. The application has frontend pods, backend pods, and batch processing pods. EKS Auto Mode selects a mix of EC2 instances to meet these workload requirements.
The selected instances are c6a.2xlarge, c6a.4xlarge, m5a.2xlarge, and m5a.xlarge. Their combined EC2 cost is $1.434 per hour. EKS Auto Mode adds a separate management fee of $0.17208 per hour for those instances.
Over a month, this equals $1,046.82 in EC2 instance costs and $125.62 in EKS Auto Mode fees. This example shows that EKS Auto Mode pricing is added on top of the underlying EC2 cost rather than replacing it.
6 Ways to Reduce and Optimize Amazon EKS Costs
1. Right-Size Worker Nodes and Pod Requests
Overprovisioned worker nodes and inflated pod resource requests are common sources of wasted EKS spending. Kubernetes schedules pods based on requested CPU and memory, not actual usage. If requests are set too high, clusters may scale out unnecessarily, leaving large portions of node capacity unused while still generating EC2 costs.
Teams should regularly analyze actual resource consumption and adjust requests and limits accordingly. Tools such as Kubernetes metrics server, Prometheus, Vertical Pod Autoscaler (VPA), KEDA, and Goldilocks can help identify inefficient allocations. Using smaller instance types, mixed instance groups, or Graviton-based instances can also improve cost efficiency.
Cluster autoscaling should be configured to remove unused nodes automatically. Combining accurate pod sizing with autoscaling reduces idle infrastructure and maintains better workload density across the cluster.
2. Use Spot Instances for Fault-Tolerant Workloads
Amazon EC2 Spot Instances can reduce EKS compute costs because they use spare AWS capacity at discounted prices. Spot pricing is often 70–90% lower than standard On-Demand pricing, making it suitable for workloads that can tolerate interruptions.
Stateless applications, batch jobs, CI/CD pipelines, background workers, and data processing tasks are strong candidates for Spot usage. Kubernetes node groups can mix Spot and On-Demand instances so critical workloads remain stable while fault-tolerant workloads use lower-cost capacity.
To improve reliability, use multiple instance types and Availability Zones in Spot node groups. Kubernetes features such as Pod Disruption Budgets and Cluster Autoscaler help workloads recover automatically when Spot interruptions occur.
3. Optimize Load Balancers and Ingress
Each Kubernetes service of type LoadBalancer in EKS typically provisions a dedicated AWS load balancer. In large environments, unnecessary or duplicated load balancers can create substantial monthly costs, especially when using Application Load Balancers or Network Load Balancers.
Using a centralized ingress controller allows multiple applications to share a single load balancer instead of provisioning one per service. The AWS Load Balancer Controller supports routing multiple applications through shared load balancers using host-based or path-based routing rules.
Remove unused load balancers and review idle ingress resources regularly. Internal-only services should avoid internet-facing load balancers unless external access is required. Optimizing ingress architecture reduces both load balancer charges and related data transfer costs.
4. Identify Idle and Underutilized Resources
Unused Kubernetes resources often continue generating AWS charges even when applications are no longer active. Idle EC2 nodes, unattached EBS volumes, orphaned load balancers, unused Elastic IPs, and inactive namespaces are common examples of waste in EKS environments.
Regular cost and utilization reviews help identify resources that can be deleted or consolidated. AWS Cost Explorer, AWS Compute Optimizer, Kubecost, and Kubernetes monitoring tools can track inefficient resource usage across clusters.
Automating cleanup processes improves cost control. Organizations can use lifecycle policies, scheduled shutdowns for non-production environments, and namespace expiration rules to reduce unnecessary spending. Continuous monitoring is important because Kubernetes environments change frequently as workloads scale and teams deploy new services.
5. Upgrade Kubernetes Versions Before Extended Support
Amazon EKS increases cluster pricing once a Kubernetes version moves from standard support to extended support. The hourly cluster fee rises from $0.10 to $0.60 per cluster hour, which can increase costs across multiple clusters.
Regular Kubernetes upgrades help organizations avoid these additional charges while also improving security, stability, and feature availability. Establishing a predictable upgrade schedule reduces the risk of clusters remaining on unsupported versions for long periods.
Test upgrades in staging environments before production rollout to reduce operational risk. Teams should also monitor the Amazon EKS release calendar and plan upgrades early enough to avoid rushed migrations near support deadlines.
6. Use Karpenter for Smarter Node Provisioning
Karpenter can help reduce Amazon EKS costs by provisioning compute capacity based on actual pod requirements rather than relying only on predefined node groups. It evaluates pending pods and launches right-sized EC2 instances that match workload needs, which can improve bin packing, reduce idle capacity, and speed up scaling.
Unlike traditional Cluster Autoscaler configurations that depend heavily on Auto Scaling Groups, Karpenter can choose from a broader range of instance types, sizes, Availability Zones, architectures, and capacity types. This flexibility allows teams to use a more diverse mix of On-Demand, Spot, and Graviton-based instances while maintaining application availability.
Karpenter is especially useful for dynamic or variable workloads because it can quickly add capacity when pods cannot be scheduled and consolidate underutilized nodes when demand drops. Teams should configure NodePools with appropriate instance requirements, disruption controls, consolidation policies, and workload constraints to balance cost savings with reliability.
Optimizing EKS Costs with PerfectScale
EKS gives you a powerful platform for running containerized workloads, but the pricing model means that inefficient resource configurations translate directly into higher bills. Overprovisioned CPU and memory requests cause clusters to scale out more than necessary, keeping EC2 nodes running at low utilization while costs accumulate. PerfectScale by DoiT eliminates this waste by continuously analyzing actual workload consumption across your EKS clusters and autonomously rightsizing CPU and memory requests and limits — without requiring manual tuning or engineering time.
Unlike recommendation-only tools that generate suggestions teams rarely have capacity to act on, PerfectScale applies optimizations automatically while keeping guardrails in place to protect performance and availability. It detects and remediates resiliency risks like OOM kills, CPU throttling, and pod evictions in real time, so cost savings don't come at the expense of stability. The result is a tighter, better-utilized cluster that spends less on unnecessary EC2 capacity while maintaining the reliability your workloads require.