Kubernetes Cost Optimisation: EKS, AKS and GKE Licensing and Compute Savings

Kubernetes promised to optimise infrastructure utilisation. In practice, most enterprise Kubernetes deployments run at 15–25% actual CPU utilisation while enterprises pay for 100% of provisioned capacity. The managed Kubernetes services from AWS (EKS), Azure (AKS), and Google Cloud (GKE) add platform fees on top of the compute you're already overpaying for. Combined with the cost of the underlying node compute, enterprises running Kubernetes at scale routinely waste $500K–$5M annually in avoidable costs. This guide shows you where those costs come from and how to negotiate and optimise them away.

The Kubernetes Cost Problem

Kubernetes adoption typically follows a familiar pattern: the platform delivers real benefits for workload portability, scaling, and operational consistency. But the cost benefits promised during the evaluation phase rarely materialize. Here's why.

Cluster sprawl is endemic. Most enterprises end up with multiple Kubernetes clusters: separate clusters for development, staging, and production environments; per-team or per-business-unit clusters; sometimes even separate clusters for different application components. Each cluster carries a fixed control plane cost — even if the cluster is only 5% utilised. With 10–15 clusters running across an enterprise, that fixed cost adds up fast: a fleet of 12 EKS clusters costs $10,500 per year in control plane fees alone, before any node compute charges.

Node pools are chronically overprovisioned. Application teams request nodes with peak capacity assumptions ("we might need this much CPU"), not actual usage patterns. In most enterprises we audit, the gap between provisioned and utilised capacity is stark: a cluster provisioned with 100 vCPU of capacity regularly runs at 12–18 vCPU of actual usage. This 80–85% waste is then applied across thousands of nodes, compounding into massive infrastructure overspend.

Idle namespaces accumulate. Development teams spin up workloads for experimentation, then leave them running indefinitely when they move to other work. Staging environments stay at production scale between release cycles. Archive workloads and proof-of-concept projects continue running with no business value. In typical audits, 20–30% of Kubernetes compute capacity delivers no measurable business value.

The dev/test cluster problem. Development and testing environments are often provisioned at production scale for parity, then run sporadically — a cluster that's active 10 hours per week but sized for 24/7 production use. Consolidating dev/test workloads onto shared clusters or using namespace-level isolation instead of cluster-level isolation can reduce this category of waste by 60–75%.

Across these factors, the typical outcome: 30–40% of enterprise Kubernetes compute spend delivers no business value. The remaining 60–70% of spend is usually 30–40% overprovisioned. Combined, this means most Kubernetes deployments operate with effective waste rates of 50–60% — similar to the underutilisation rates seen in traditional VM infrastructure, despite Kubernetes's efficiency promises.

EKS Pricing: What AWS Charges for Kubernetes

AWS Elastic Kubernetes Service (EKS) charges you on two separate dimensions: the control plane fee and the compute (worker node) fee.

EKS Control Plane: AWS charges $0.10 per cluster per hour — which totals $876 per cluster per year. This fee is non-negotiable in standard pricing; it applies to every EKS cluster regardless of how much or how little capacity the cluster uses. There is no AWS Reserved Instance or Savings Plan discount applicable to the control plane cost. If you run 10 EKS clusters, you pay $8,760 per year in control plane fees before any nodes are provisioned.

EKS Node Compute (EC2 or Fargate): Worker nodes run on EC2 instances (or on EKS Fargate for serverless workloads). The node compute cost is charged at standard EC2 pricing: on-demand rates, Reserved Instance discounts, Savings Plans, or Spot Instance rates. The control plane does not include the cost of the nodes themselves — you pay separately for whatever EC2 capacity you provision. A typical medium-scale EKS deployment (50–100 vCPU of provisioned capacity) might run $5,000–$15,000 per month in node compute costs, depending on instance types and the percentage of Spot utilisation.

EKS Fargate: AWS also offers EKS Fargate, a serverless compute option where you pay per vCPU-hour for the actual CPU consumed, rather than provisioning full instances. Fargate pricing is roughly 30–40% higher than on-demand EC2 pricing for equivalent compute. Fargate is cost-effective for highly variable workloads where the flexibility justifies the premium, but most production Kubernetes workloads are cheaper on EC2 instances with Reserved Instances or Savings Plans.

EKS Anywhere and On-Premises Costs: AWS EKS Anywhere (which runs EKS control planes on-premises) charges $0.50 per vCPU per month for management fees — plus the cost of your on-premises infrastructure. For a cluster with 100 provisioned vCPU, that's an additional $6,000 per year in AWS management fees on top of your infrastructure costs.

Extended Support: For older Kubernetes versions, AWS charges an EKS Extended Support fee of $0.60 per vCPU per hour for nodes running unsupported versions — a significant penalty for not staying current. Running an older cluster (say, Kubernetes 1.24 after it reaches end-of-life) can double or triple the node compute cost.

Reducing EKS Costs: The most effective approaches are (1) consolidating clusters to reduce fixed control plane costs; (2) rightsizing node pools and using Spot Instances for eligible workloads; (3) applying EDP discounts to your node compute costs; and (4) using reserved capacity (EC2 Reserved Instances or Savings Plans) for your base node pool capacity.

AKS Pricing: What Azure Charges for Kubernetes

Azure Kubernetes Service (AKS) has a different cost structure than EKS. Azure offers a free tier for the control plane on the Standard service tier — you do not pay a separate control plane fee for Standard AKS clusters. However, Azure charges for node compute using standard Azure VM pricing, and some features (Container Insights, the uptime SLA) incur additional costs.

AKS Free Tier (Standard): No control plane fee. You only pay for the worker nodes (VMs). This makes the entry-level cost of AKS lower than EKS, all else equal. However, the Azure VMs themselves are priced higher per vCPU than equivalent EC2 instances in most regions — so the node compute cost may or may not offset the free control plane.

AKS Standard Tier with Uptime SLA: If you require a 99.95% uptime SLA, Azure charges an additional fee (around $0.08–$0.15 per cluster per hour, depending on region). This brings AKS closer to feature parity with EKS's guaranteed control plane.

AKS Node Pools: Worker nodes run on Azure Virtual Machines at standard Azure VM pricing. Spot VMs provide discounts similar to AWS Spot Instances (60–80% off pay-as-you-go rates). You can have multiple node pools within a single AKS cluster, enabling different pricing strategies for different workload types (critical workloads on reserved VMs, non-critical workloads on Spot).

Container Insights: Azure's Container Insights monitoring service adds per-GB data ingestion costs, typically $1–$3 per cluster per day. This monitoring is more expensive than the control plane fee itself for very small clusters.

Azure Reserved Instances (RIs): Azure RIs apply to AKS node pools. You can commit to 1-year or 3-year terms for 20–35% discount off pay-as-you-go pricing. Azure also offers Azure Hybrid Benefit discounts for workloads using existing Microsoft licenses.

Reducing AKS Costs: The primary levers are (1) leveraging the free control plane by consolidating clusters; (2) using Spot VMs for non-critical workloads; (3) applying Azure Reserved Instances or Savings Plans to base node capacity; and (4) right-sizing node pools based on actual utilisation data.

GKE Pricing: What Google Cloud Charges for Kubernetes

Google Kubernetes Engine (GKE) offers the most flexible pricing structure of the three major managed Kubernetes services. Google's approach is designed to be transparent about which costs are Kubernetes-specific and which are compute costs.

GKE Standard vs Autopilot: GKE Standard is the traditional model where you manage node pools; the control plane is free. GKE Autopilot is a managed nodes service where Google manages the node pool sizing and you pay per vCPU-hour consumed (similar to Fargate). Autopilot is simpler operationally but typically 20–30% more expensive than Standard for sustained workloads.

GKE Control Plane: The control plane is free for Standard clusters. GKE Enterprise (formerly Anthos) adds paid features (multi-cloud management, policy enforcement) at premium pricing, typically $1–$2 per cluster per day.

GKE Node Compute (Standard): You pay standard Compute Engine pricing for the VMs in your node pools. Google's Compute Engine pricing is generally 10–20% lower than equivalent EC2 or Azure VM pricing in the US regions. You can use Committed Use Discounts (CUDs) for 1-year or 3-year commitments (typically 25–37% off on-demand).

Spot VMs: Google offers Spot VMs for up to 60–91% discount off on-demand pricing. Spot VMs have similar interruption characteristics to AWS Spot Instances. Additionally, Google offers Spot Pods, where Kubernetes can schedule individual pods onto preemptible capacity — providing fine-grained Spot utilisation within a Standard cluster.

Reducing GKE Costs: The primary approaches are (1) using the free control plane advantage (GKE Standard is cheaper than EKS or AKS for control plane costs alone); (2) leveraging Spot VMs or Spot Pods for variable capacity; (3) applying CUDs to base node pool capacity; and (4) consolidating workloads across fewer clusters.

Node Rightsizing: The Biggest Kubernetes Cost Win

The single highest-ROI optimization in most Kubernetes environments is node rightsizing: ensuring that your node pools are provisioned based on actual usage, not peak assumptions.

The CPU and Memory Utilisation Gap: Kubernetes allows application teams to specify resource requests (the minimum guaranteed capacity for a pod) and limits (the maximum the pod will consume). In practice, most teams either leave requests unset (defaulting to zero, causing Kubernetes to pack pods too densely) or set requests at peak capacity assumptions (causing massive overprovisioning). A typical audit reveals: workloads requesting 40 vCPU that actually use 8–12 vCPU; workloads requesting 32GB memory that actually use 4–6GB.

The Utilisation Reality: Once pods are rightsized, most Kubernetes clusters run at 15–25% actual CPU utilisation. This is not wasteful per se — Kubernetes benefits from spare capacity for scaling and fault tolerance. But the issue is not the utilisation; it's the cost model. If your cluster costs $100K per year but only uses 20% of provisioned capacity, you're effectively paying $500K for the capacity you're using. That's a 5x markup on compute cost due to overprovisioning.

Vertical Pod Autoscaler (VPA) and Horizontal Pod Autoscaler (HPA): VPA automatically adjusts pod resource requests based on actual usage, and HPA automatically adds or removes replicas based on demand. Using VPA to right-size requests and HPA to handle variability can reduce node pool size by 30–50% without affecting application performance.

Rightsizing Tools: Specialized tools (Kubecost, CAST AI, Spot.io) monitor actual pod utilisation and recommend node pool optimisations. These tools typically identify 30–40% of node pool capacity as unneeded — savings that persist over time because they're driven by architectural changes (fewer, right-sized nodes), not one-time cleanup.

Spot/Preemptible Nodes: 60–90% Savings for Stateless Workloads

Spot Instances (AWS), Spot VMs (Azure and Google Cloud), and Preemptible VMs (Google Cloud) provide 60–90% discounts off on-demand pricing. The tradeoff: these instances can be interrupted by the cloud provider with minimal notice (typically 2 minutes for AWS Spot, 30 seconds for Google Preemptible).

What Workloads Are Suitable for Spot/Preemptible: Batch processing jobs, rendering pipelines, CI/CD build workloads, data science workloads, and any application that can gracefully handle termination and restart. Avoid Spot for latency-sensitive workloads, stateful applications (databases, caches), and workloads where brief interruptions create user-facing incidents.

Interruption Rates and Risk Management: Spot/Preemptible interruption rates vary by instance type, availability zone, and time of day — typically ranging from 2–5% per month for well-chosen instance types to 15–20% for high-demand types during peak usage periods. Kubernetes tooling (using multiple instance types across multiple availability zones, graceful pod eviction) reduces effective interruption impact to tolerable levels.

Typical Savings: An enterprise running 50% of their stateless workloads on Spot/Preemptible instances can reduce compute costs by 30–40% overall. Some workloads are 100% eligible for Spot (batch jobs, build pipelines) and can realise 60–90% cost reductions.

Cluster Consolidation: Reducing Fixed Control Plane Costs

Each Kubernetes cluster carries a fixed control plane cost: $876/year for EKS, $0 for AKS Standard (but potential Azure VM sizing penalties), and $0 for GKE Standard. Beyond the control plane fee, each cluster also requires a minimum set of system components (kube-system, kube-public namespaces), monitoring, networking, and operational overhead.

The Cluster Sprawl Math: An enterprise with 15 Kubernetes clusters (not unusual for large organisations) pays at minimum: $13,140/year in EKS control plane fees alone. If those clusters average 20 vCPU provisioned capacity each (300 vCPU total), and each cluster carries 5 vCPU of system overhead (75 vCPU total), the overhead approaches 25% of total capacity before any application workload is considered.

Namespace Isolation vs Cluster Isolation: In many cases, Kubernetes namespace-level isolation is sufficient for multi-team or multi-environment separation. Consolidating a dev cluster, staging cluster, and production cluster into a single cluster with separate namespaces and network policies can reduce fixed overhead by 60–70%. RBAC (role-based access control) and network policies provide security boundaries comparable to cluster-level isolation.

Multi-Tenancy and Cost Models: A shared cluster with per-team or per-environment resource quotas, combined with FinOps platform tooling (Kubecost, etc.) to track per-namespace costs, enables cost accountability without the penalty of cluster sprawl. Teams see their costs and can optimise, without the infrastructure overhead.

Typical Savings: Consolidating 15 clusters into 3–4 clusters can reduce fixed infrastructure overhead by 40–60%, freeing up 30–40 vCPU of provisioned capacity and reducing operational complexity.

Reserved Capacity for Kubernetes Node Pools

Just as with EC2, Azure VMs, and Compute Engine VMs, you can commit to 1-year or 3-year reserved capacity for Kubernetes node pools.

AWS EKS and EC2 Reserved Instances: EC2 Reserved Instances apply to the instances used as EKS nodes. A 3-year reserved instance provides up to 72% discount off on-demand pricing (or up to 60% for 1-year terms). The commitment model is straightforward: you commit to a certain instance type and size for a fixed term, and AWS applies the discount to matching instances in your EKS clusters.

Azure RIs for AKS: Azure Reserved Instances work similarly: commit to 1-year or 3-year terms for 20–35% discount. Azure's discount structure is less aggressive than AWS, but includes flexibility to change instance types within a family (sometimes) and is combined with other discounts (Hybrid Benefit, Savings Plans).

Google CUDs (Committed Use Discounts): Google Committed Use Discounts provide 25–37% discount for 1-year or 3-year commitments on Compute Engine machines, storage, and network. CUDs are available at both machine type and vCPU family levels, providing some flexibility.

Commitment Strategy for Kubernetes: The question is: what percentage of your node pool capacity should be committed versus Spot? A typical model: 60–70% of base capacity reserved, 20–30% Spot for variable workloads, 10% on-demand buffer. For stable workloads where you can forecast minimum capacity 12 months out, 3-year terms provide the best cost reduction. For unpredictable workloads, 1-year terms are safer.

EKS vs AKS vs GKE Cost Comparison

Negotiating Kubernetes Costs as Part of Your EA/EDP/CUD Strategy

Most enterprises don't realise they can negotiate Kubernetes platform fees in the context of larger cloud contracts. If you have $5M+ annual AWS spend, you qualify for AWS EDP (Enterprise Discount Program), which applies a percentage discount across all AWS services — including EKS control plane and EC2 node compute. The same applies to Azure EA (Enterprise Agreement) discounts and Google Cloud commitment discounts.

Incorporating Kubernetes Growth into EDP Leverage: Your Kubernetes growth trajectory is one of the highest-value negotiation levers in AWS EDP deals. If your company is growing Kubernetes spend from $500K/year to $2M+/year over 3 years, AWS wants to capture that growth. This growth trajectory should factor into your EDP discount negotiation: "We're committing to $X million across AWS, with this growth profile in Kubernetes. What discount do you provide?" EDP discounts typically range from 5–25% depending on scale and term length.

Combining FinOps Optimisation with Commercial Negotiation: The mistake most enterprises make: they optimise (rightsizing, Spot instances, consolidation) and expect savings to flow through automatically. But cloud vendors price EDP and commitment discounts based on baseline consumption — if you optimise your way down to $1M/year spend, your EDP discount is negotiated on $1M, not the $1.5M you were previously spending. The better approach: (1) understand your optimised cost baseline; (2) negotiate EDP/commitment discounts on that baseline; (3) execute optimisations; (4) realise the full savings.

Kubernetes Costs in Multi-Cloud Negotiations: If you run Kubernetes across AWS, Azure, and Google Cloud, you can use this multi-cloud footprint as negotiation leverage. "We're evaluating our Kubernetes strategy across EKS, AKS, and GKE. To consolidate on your platform, we'd need X% discount." AWS, Azure, and Google all have incentive structures to consolidate workloads, and this is one of the strongest negotiation positions available.

Kubernetes Cost Optimisation: The Path Forward

The typical enterprise Kubernetes deployment is leaving 25–40% of cost reduction on the table through a combination of overprovisioned nodes, cluster sprawl, and incomplete commitment strategies. The good news: most of these savings are straightforward to realise once you understand the cost model and commit to the consolidation and rightsizing work.

The path: (1) Audit actual utilisation across your Kubernetes fleet; (2) Right-size node pools and consolidate clusters; (3) Commit to reserved capacity and Spot strategies appropriate for your workload mix; (4) Negotiate EDP/EA/CUD discounts with your cloud vendors based on your optimised baseline and multi-cloud footprint; (5) Implement cost governance (Kubecost, cost allocation, per-team chargeback) so costs don't drift upward once optimisations are in place.

Enterprises that execute this pathway typically reduce Kubernetes costs by 30–40% without any changes to application logic or platform capabilities — pure infrastructure and commercial optimisation. If your organisation is running multiple Kubernetes clusters across multiple cloud providers, this cost reduction opportunity is likely your highest-ROI cloud investment today.