Amazon EKS: pricing, extended support and how to cut the bill

Amazon Elastic Kubernetes Service (Amazon EKS) runs the Kubernetes control plane for you and bills it as one fee per cluster and per hour, but that fee is rarely the largest line of an EKS bill. In AWS's words, "When using Amazon EKS, you pay separately for the AWS resources you use to run your applications on Kubernetes worker nodes": the nodes are billed as Amazon EC2 instances, their volumes as Amazon EBS and their public addresses as Amazon VPC, and the traffic between zones as data transfer. This article explains what runs under an AWS EKS cluster, how EKS pricing works line by line, and the ways AWS documents to reduce EKS costs, priced with the list prices of the Paris Region (eu-west-3): the cluster fee and its extended support, the nodes and how Kubernetes on AWS packs Pods onto them, EKS Auto Mode, AWS Fargate and the network. Four architectures show what the levers do to whole monthly bills, and the cost section opens with an index of the levers, in the order to work through them.

What Amazon EKS is

In AWS's words, "Amazon Elastic Kubernetes Service (EKS) provides a fully managed Kubernetes service that eliminates the complexity of operating Kubernetes clusters", and "Amazon EKS is certified Kubernetes-conformant, so you can deploy Kubernetes-compatible applications without refactoring and use Kubernetes community tooling and plugins." It comes in two modes: "EKS standard: AWS manages the Kubernetes control plane when you create a cluster with EKS", and "EKS Auto Mode: Using the EKS Auto Mode feature, EKS extends its control to manage Nodes (Kubernetes data plane) as well." What each mode leaves to you is what you pay for in time, and partly in nodes:

The third row comes from an AWS whitepaper (Amazon EKS control plane): "In a standard Amazon EKS cluster, the components that perform auto-scaling, manage Elastic Network Interfaces (ENIs) and Amazon EBS devices run as Kubernetes Pods on nodes in the cluster. With Auto Mode, AWS manages these components and runs them outside of the cluster." In a standard cluster those Pods take part of the nodes you pay for. The pay model itself is short: "With Amazon EKS, there are no minimum fees or upfront commitments", and one cluster can serve several applications: "You can use a single EKS cluster to run multiple applications by taking advantage of Kubernetes namespaces and IAM security policies." The Amazon EKS Service Level Agreement commits to a Monthly Uptime Percentage for the Kubernetes endpoint of at least 99.95% "with the Standard Control Plane", and at least 99.99% with "the Provisioned Control Plane". The free tier is left out here.

How EKS works under the hood

AWS documents the EKS control plane at the level of instances, Availability Zones, network interfaces and versions. It does not say which instance types run the API servers or how it sizes them ("Amazon EKS actively monitors and adjusts control plane instances to maintain peak performance", Amazon EKS architecture), so this article does not either. Each part it does document is a line of the bill, or decides one.

The control plane: one per cluster, run by AWS

"Amazon EKS ensures every cluster has its own unique Kubernetes control plane. This design keeps each cluster's infrastructure separate, with no overlaps between clusters or AWS accounts." In the architecture page's words, "The control plane positions at least two API server instances and three etcd instances across three AWS Availability Zones within an AWS Region", and "If a control plane instance falters, Amazon EKS quickly replaces it, using a different Availability Zone if needed."

Scroll the diagram sideways →

The whitepaper adds where it runs: "The Kubernetes control plane managed by Amazon EKS runs inside an EKS-managed VPC. This control plane is single tenant, meaning that for each EKS cluster there is a unique EKS managed VPC and Kubernetes control plane." Its API server nodes "run components such as the API server, scheduler, and kube-controller-manager in an auto-scaling group", and "the etcd server nodes also run in an auto-scaling group that spans three Availability Zones."

The bill follows the split. The control plane is one hourly fee per cluster, whatever its load: "By default, Amazon EKS clusters use Standard mode, where the control plane automatically scales up and down based on your workload demands" (Amazon EKS Provisioned Control Plane). Provisioned mode is the exception, "for specialized workloads that cannot tolerate any performance variability due to control plane scaling or those requiring very high amounts of control plane capacity", and "You will be billed at the hourly rate for the particular control plane scaling tier in addition to the standard or extended support EKS hourly charges." No AWS page read for this article describes a way to pause a control plane: the fee bills for every cluster that exists, with or without nodes. Everything in the data plane is billed by the service that provides it.

How nodes reach the control plane, and who pays for that traffic

The control plane reaches your nodes through network interfaces it places in your subnets:

The networking requirements say who pays for what crosses them: "Amazon EKS absorbs the data transfer costs on the control plane side of these network interfaces. You are charged standard AWS data transfer rates for traffic on the customer side — specifically, ingress to your worker nodes from the control plane and egress from your worker nodes to the control plane." The pricing page calls it "any cross AZ traffic from nodes to the Kubernetes control plane". No AWS page gives its volume, so this article names the line and does not price it. A cluster needs (networking requirements) "at least two subnets that are in different Availability Zones", and "The subnets must each have at least six IP addresses for use by Amazon EKS. However, we recommend at least 16 IP addresses."

People reach the API server through its endpoint: "By default, this API server endpoint is public to the internet, and access to the API server is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes Role Based Access Control (RBAC)". A private cluster, without internet access, needs interface VPC endpoints for the AWS services its nodes and Pods call (Amazon EC2, Amazon ECR's ecr.api and ecr.dkr, Elastic Load Balancing, CloudWatch Logs, AWS STS and others), each billed by the hour in each zone, and an endpoint for Amazon S3, where the image layers can come through a gateway endpoint, which bills nothing (ECR VPC endpoints): see Data transfer and the network around the cluster.

Where Pods run: node groups, Karpenter, Auto Mode and Fargate

"Your Amazon EKS cluster can schedule Pods on any combination of EKS Auto Mode managed nodes, self-managed nodes, Amazon EKS managed node groups, AWS Fargate, and Amazon EKS Hybrid Nodes." Self-managed nodes "require a lot more manual maintenance". The four options AWS hosts are billed four ways:

Scroll the diagram sideways →

Managed node groups "automate the provisioning and lifecycle management of nodes (Amazon EC2 instances)", in your account, and "There are no additional costs to use Amazon EKS managed node groups, you only pay for the AWS resources you provision." They do not follow the load by themselves: "Amazon EKS doesn't automatically scale your node group in or out"; the Cluster Autoscaler can.

Karpenter, which you install and run, "launches right-sized compute resources (for example, Amazon EC2 instances) in response to changing application load in under a minute", and "There is no AWS Service Level Agreement (SLA) for Karpenter". Its controller needs nodes it does not manage (Karpenter, in the EKS Best Practices Guide): "We recommend a minimum of one small node group with at least one worker node", and "Do not run Karpenter on a node that is managed by Karpenter."

EKS Auto Mode runs that autoscaling for you, "Relying on Karpenter auto scaling", on nodes that "have a maximum lifetime of 21 days (which you can reduce)". Its instances "are owned by EKS and are more restricted", and those created since April 22, 2026, with their volumes and network interfaces, are hidden by default from EC2 console views and describe API list operations, but "Hidden resources remain fully operational and billable." Each one adds a fee of its own to its EC2 price.

AWS Fargate runs each Pod alone: "Each Pod that runs on Fargate has its own compute boundary", and it is no longer AWS's first choice: "Amazon EKS with AWS Fargate remains an option for customers who want to run EKS, but Amazon EKS Auto Mode is the recommended approach moving forward". Amazon EKS Hybrid Nodes, the fifth option, use "your on-premises and edge infrastructure as nodes in Amazon EKS clusters", priced in Other billed features.

The scheduler places Pods by their requests, not by their use

The rule that sets the node count is in the Best Practices Guide's page on compute costs:

Requests should align with the actual utilization. If a container's requests are too high there will be unused capacity which is a large factor in total cluster costs.

"Pods are scheduled by Kubernetes to ensure that at least the requested resources for each Pod are available on the compute resource". The Best Practices Guide draws the line between two sets of rules: "The rules of the Kubernetes Scheduler, which uses the request value to schedule pods on a node, and then what happens after the pod is scheduled, which is the realm of Linux, not Kubernetes." Node autoscalers count the same way (Karpenter): "Consolidation and scheduling in general work by comparing the pods resource requests vs the amount of allocatable resources on a node. The resource limits are not considered."

So the requests, not the use, decide how many nodes run, and the nodes are most of the bill: "In most EKS clusters, the bulk of cost come from the EC2 instances that are used to run your containerized workloads". Requests that are too low cost something else: for memory, AWS recommends "Configure requests=limits for all non-CPU resources when using consolidation", since "If several pods on the same node burst at the same time, this can cause some of the pods to be terminated due to an out of memory (OOM) condition." (Karpenter). A node also runs "the Kubelet, logging agents, and any DaemonSets you would typically deploy to a node" (Compute and Autoscaling), so the Pods share what is left, its allocatable resources: kubectl top gives what a node uses and "the percentages of the node's allocatable capacity those numbers represent" (Expenditure awareness). No AWS page read gives the EKS node images' reservations in numbers, so pattern 1 states an illustrative one.

Pod networking: one VPC address per Pod, and how many fit on a node

The Amazon VPC CNI add-on, on each node, "creates elastic network interfaces and attaches them to your Amazon EC2 nodes" and "assigns a private IPv4 or IPv6 address from your VPC to each Pod." A Pod is an address in your VPC like an instance, and its traffic between zones is billed like an instance's. The interfaces also cap how many Pods a node holds (Amazon VPC CNI, Best Practices): "Note each instance type has a maximum number of ENIs that may be attached. This is one constraint on Pod density (number of Pods per node), in addition to compute resources." The EKS User Guide gives the rules:

The interface counts are the EC2 instance specifications'. A node can run out of addresses before it runs out of CPU: "you might have nodes that have available compute and memory resources, but can't accommodate additional Pods because the node has run out of IP addresses to assign to Pods". Prefix mode gives each node /28 prefixes of 16 addresses instead of single addresses (Prefix Mode for Linux), and AWS names the cost of going without (prefixes): it "adds cost and management overhead because you need to provision additional clusters and VPCs to meet scaling requirements."

Traffic that crosses zones

A cluster spread over three zones sends traffic between them by default (Cost Optimization - Networking): "On Amazon EKS, kube-proxy primarily uses iptables NAT rules (or nftables, IPVS as alternatives) for traffic distribution across all pods in the cluster, regardless of their node or AZ placement. This default distribution can lead to cross-AZ traffic routing, potentially causing increased latency for sensitive applications and inter-AZ data transfer charges in large deployments." A load balancer in instance mode adds a hop of its own, from the NodePort to a Pod in another zone; in IP mode it sends requests straight to the Pods (Send load balancer traffic straight to the Pods). Pattern 4 prices both paths.

Kubernetes versions: 14 months of standard support, then 12 of extended support

"A minor version is under standard support in Amazon EKS for the first 14 months after it's released. Once a version is past the end of standard support date, it enters extended support for the next 12 months. Extended support allows you to stay at a specific Kubernetes version for longer at an additional cost per cluster hour. If you haven't updated your cluster before the extended support period ends, your cluster is auto-upgraded to the oldest currently supported extended version." The community releases a minor version "on average once every four months", and the charge starts "at the beginning of the day that the version reaches end of standard support, in the UTC+0 timezone". The dates AWS listed on October 15, 2026:

Each cluster's upgrade policy decides what happens at the end of standard support, and it cannot be changed late: "Once your cluster has entered extended support, you cannot disable it. To change the version support policy setting, your cluster must be running on a Kubernetes version in standard support."

A · STANDARD

At the end of standard support

The control plane upgrades by itself to the next version in standard support

Extended support charges

None

Nodes, after an automatic upgrade

Managed node groups stay on their version: you upgrade them; EKS Auto Mode nodes may update by themselves

B · EXTENDED

At the end of standard support

The cluster enters extended support, for up to 12 months; at its end, the control plane upgrades by itself

Extended support charges

Every hour, on top of the cluster fee

Nodes, after an automatic upgrade

Managed node groups and self-managed nodes stay on their version: you upgrade them; EKS Auto Mode nodes may update by themselves

What differs: who sets the upgrade date, AWS at the end of standard support or you within the next 12 months, and the charge that comes with the second.

The default depends on how the cluster was created (enabling extended support): "If you create a cluster in the AWS console, it will have the upgrade policy set to disable extended support. If you create a cluster in another way, it will have the upgrade policy set to enable extended support." The upgrade itself goes one step at a time: "Because Amazon EKS runs a highly available control plane, you can update only one minor version at a time". The nodes do not follow the control plane, EKS Auto Mode's apart (version lifecycle): managed node group instances "aren't automatically upgraded when you or Amazon EKS update your control plane", "If you update the control plane, you must still update the Fargate nodes yourself", and when extended support ends, "The auto-upgrade includes only the Kubernetes control plane. If you have EKS Auto Mode nodes, they may automatically update." With Auto Mode, after a control plane upgrade, "existing instances are gradually updated" (Amazon EKS FAQs). The version lifecycle page adds that a cluster upgraded in place "can be rolled back to the previous minor version within 7 days of the upgrade completing", but "If you roll back from a version under standard support to a version under extended support, extended support charges resume for that cluster". To see where a cluster stands, the console's support period is the place: "If your cluster support period is Extended support, you are being charged for EKS extended support", and "The Support Period cannot be retrieved with the AWS API or CLI." The price is in The cluster fee, standard and extended support.

What EKS is used for

AWS's common use cases each move a different line of the bill:

For batch and big data, the same page names the purchase option: "Utilize Spot Instances to run your batch processing and big data workloads such as Apache Hadoop and Spark, at a fraction of the cost."

EKS or Amazon ECS?

On a bill, the orchestrator is the difference. "There is no additional charge for Amazon ECS orchestration", and "You pay for AWS resources (such as Amazon EC2 instances, Amazon EBS volumes, or public IPv4 addresses) you create to run your application." An EKS cluster adds its fee, $73.00 a month in Paris on a version in standard support, computed, on top of nodes priced the same. Fargate's Paris rates are the same for both, but Amazon ECS gets more of it: "Windows Operating System and ARM CPU Architecture are currently only available for Amazon ECS", and Fargate Spot too, since "Amazon EKS doesn't support Fargate Spot".

EKS or Kubernetes on EC2 yourself?

A control plane you run on EC2 has no AWS price to compare with the fee: its instances, volumes, etcd backups and the work of running it are yours. This article states what the fee buys, the control plane above, rather than a premium for EKS, and the EC2 article prices the instances and volumes either way.

How EKS pricing works

What an EKS bill is made of

The pricing page lists the EKS lines: "Amazon EKS has per cluster pricing based on Kubernetes cluster version support, pricing for Amazon EKS Auto Mode, pricing for Amazon EKS Capabilities, and per vCPU pricing for Amazon EKS Hybrid Nodes, and pricing for Amazon EKS Provisioned Control Plane." Then the rest: "You also pay for the resources you use to run your applications on Kubernetes worker nodes such as Amazon EC2 instances, Amazon EBS volumes, and public IPv4 addresses, as well as any cross AZ traffic from nodes to the Kubernetes control plane." Line by line:

Commitments discount some of these lines only: "Both Compute and EC2 Instance plan types apply to EC2 instances that are a part of Amazon EMR, Amazon EKS, and Amazon ECS clusters. Amazon EKS charges will not be covered by Savings Plans, but the underlying EC2 instances will be"; Compute Savings Plans "also apply to your Fargate and Lambda usage". Put together, a small cluster's month looks like this:

The cluster fee, standard and extended support

The control plane is priced per cluster and per hour, and its options add their own hourly rates on top:

The price list has two rows for a cluster in extended support, "Amazon EKS cluster usage in EU (Paris)" and "Amazon EKS extended support usage in EU (Paris)", and the pricing page writes their sum as one rate. So a cluster in extended support costs $438.00 a month, 6.00 times a standard cluster's $73.00, computed:

The pricing page gives the fee "per cluster per hour" and no rule for partial hours; per-second billing is stated for EKS Auto Mode and Fargate only, so this article does not claim it for the fee. A cluster on the XL tier of the Provisioned Control Plane costs $1,277.50 a month with its fee, computed, and "You can change between Provisioned Control Plane scaling tiers or return to standard control plane at any time." The fee is the same whether the cluster runs one Pod or a thousand: the cluster count, not the cluster size, sets this line, which pattern 2 prices for a fleet.

The nodes: EC2 prices, Graviton and the root volume

Nodes are EC2 instances, billed by Amazon EC2 at its own rates. The node types of this article's patterns, in Paris:

At the same size, m7g.xlarge costs 19.0% less than m7i.xlarge and c7g.xlarge 19.0% less than c7i.xlarge, computed; AWS's own figure is that Graviton processors "are up to 20% cheaper and 60% more energy efficient than x86" (Compute and Autoscaling). Newer is not cheaper: m8g.xlarge costs 10.0% more than m7g.xlarge. The EC2 article reads these names letter by letter.

Each node also has a root volume. In the API's words, "The root device disk size (in GiB) for your node group instances. The default disk size is 20 GiB for Linux and Bottlerocket": $1.86 a month per node on gp3, computed, at $0.0928 per GB-month. A node in a public subnet also gets a public IPv4 address, $3.65 a month each (Amazon VPC pricing), and AWS's advice is the other way: "We recommend deploying your nodes to private subnets, if possible". Spot nodes are "spare Amazon EC2 capacity that offers steep discounts off of On-Demand prices", which "can be interrupted with a two-minute interruption notice when EC2 needs the capacity back"; their prices are not in the AWS Price List, so this article gives them no number. The EC2 article explains how Spot is billed.

EKS Auto Mode: a fee on every instance it launches

The pricing page bills Auto Mode by the instance: "You pay for EKS Auto Mode based on the duration and type of Amazon EC2 instances launched and managed by EKS Auto Mode. The EKS Auto Mode prices below are in addition to the Amazon EC2 instance price, which covers the EC2 instances themselves. Like EC2 instance charges, EKS Auto Mode charges are billed per-second, with a one-minute minimum." And the fee does not move with a discount: "the EKS Auto Mode charges are independent of the EC2 instance purchase option." The Paris price list has one fee row per instance type:

For each of these 7 types, the fee is 12.0% of the On-Demand rate, computed; the research behind this article found the same share for most of the 655 types of the Paris offer, and a smaller one for some GPU types. Since no commitment lowers the fee, its share of the bill grows with one:

A · EC2 On-Demand

m7g.xlarge On-Demand, with the Auto Mode fee Illustrative

Line	A month
Compute	$155.67
m7g.xlarge, On-Demand730 h × $0.1904 /h	$138.99
EKS Auto Mode fee730 h × $0.02285 /h	$16.68
A month, computed	$155.67

B · Compute Savings Plan

m7g.xlarge on a one-year Compute Savings Plan, with the same fee Illustrative

Line	A month
Compute	$122.09
m7g.xlarge, Compute Savings Plan, 1 year, No Upfront730 h × $0.1444 /h	$105.41
EKS Auto Mode fee730 h × $0.02285 /h	$16.68
A month, computed	$122.09

Compute Savings Plan costs $33.58 a month less than EC2 On-Demand (21.6% less), computed.

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 28, 2026, October 12, 2026 and October 13, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

On the committed instance, the fee is 15.8% of the instance's rate, computed. What it buys, in AWS's words (Cost optimization in EKS Auto Mode): "EKS Auto Mode continuously optimizes your cluster's compute costs through consolidation, bin-packing, and right-sizing", with the autoscaling, network interface and EBS controllers run by AWS outside the cluster, off your nodes. Its built-in node pools are guarded: "Instance families restricted to C, M, and R", "Generation 5 or newer", and "On-demand capacity only — No Spot instances, which avoids interruption-driven churn but also means no Spot savings." Commitments still apply to the instances: "Compute Savings Plans and Reserved Instances are automatically applied when eligible EC2 instances are launched". And a pricing note, not a limit (Amazon EKS pricing): "If you intend to use EKS Auto Mode for more than 150 nodes across your organization, please contact your account team for additional pricing information."

AWS Fargate on EKS: billed by the Pod's configuration

"If you are using AWS Fargate, pricing is calculated based on the vCPU and memory resources used from the time you start to download your container image until the Amazon EKS pod terminates, rounded up to the nearest second. A minimum charge of one minute applies". In Paris, from the Amazon EKS offer:

What a Pod is billed is its configuration, not its requests (Fargate Pod configuration): "Fargate adds 256 MB to each Pod's memory reservation for the required Kubernetes components (kubelet, kube-proxy, and containerd)", then "Fargate rounds up to the following compute configuration that most closely matches the sum of vCPU and memory requests". AWS's example: "a request for 1 vCPU and 8 GB memory will have 256 MB added to its memory request, and will provision a Fargate task with 2 vCPUs and 9 GB memory, since no task with 1 vCPU and 9 GB memory is available." The CapacityProvisioned annotation "represents the enforced Pod capacity and it determines the cost of your Pod running on Fargate." Against nodes, the answer depends on how full the nodes are:

How to read it: a Pod's share of a node is the larger of its vCPU and memory shares of a 4 vCPU, 16 GiB node, and the last two columns are the share of a node's capacity its Pods must request, on average, for the node to cost less per Pod than Fargate. Below about 78.3% to 95.1% of requested capacity, m7i.xlarge nodes cost more per Pod than Fargate; m7g.xlarge nodes from 63.4% to 77.0%. The table treats Fargate's GB and an instance's GiB alike, and ignores what a node keeps for the system and its DaemonSets, which raises the real break-even, since Pods can request only the node's allocatable capacity; Fargate cannot run DaemonSets, so their agents become sidecars in each Pod, which lowers it; Spot and Savings Plans on nodes move it again. AWS's view of the trade (Compute and Autoscaling): "Fargate cannot benefit from bin packing or CPU over provisioning because the boundary for the workload is a node which is not burstable or shareable between workloads. Fargate will save you EC2 instance management time which itself has a cost, but CPU and memory costs may be more expensive than other EC2 capacity types."

Fargate on EKS also gives up options that cost less elsewhere (AWS Fargate): "Daemonsets aren't supported on Fargate", Pods "are only supported on private subnets (with NAT gateway access to AWS services, but not a direct route to an Internet Gateway)", "Amazon EKS doesn't support Fargate Spot", and "You can't mount Amazon EBS volumes to Fargate Pods"; its comparison table answers "No" to running "workloads that require Arm processors". Finished Jobs keep billing: "with Fargate you will incur costs if you don't clean up the Job afterwards." Compute Savings Plans cover Fargate: one year No Upfront costs 15.0% less per vCPU-hour in Paris, and three years 40.0% less, computed, where AWS says "Savings Plans offer savings of up to 50% on your AWS Fargate usage".

Commitments: the nodes and Fargate, not the EKS fees

A Savings Plan discounts the instance hours of the nodes, whoever launches them, and Fargate (Compute Savings Plans only), but none of the EKS fees. For m7g.xlarge in Paris:

AWS's maxima are wider, Compute Savings Plans "up to 66% off of On-Demand rates" and EC2 Instance Savings Plans "up to 72% off On-Demand, in exchange for a commitment to a specific instance family in a chosen AWS Region" (Savings Plans types). That family is the catch on EKS: Karpenter and Auto Mode choose instance types from what a NodePool allows, so an EC2 Instance Savings Plan covers them only while they stay in its family. Neither plan covers the cluster fee, extended support, the Provisioned Control Plane, the Auto Mode fee, Capabilities or Hybrid Nodes; the Paris Savings Plans offer has rates for the Fargate usage types and for no other Amazon EKS line.

Data transfer and the network around the cluster

The network lines of a cluster come from several services, each with its rule:

Between zones, the EC2 pricing page bills data transferred "across Availability Zones in the same AWS Region" in each direction, $0.01 per GB in Paris. The bill shows it twice: "For a given resource, you're charged for both inbound and outbound traffic in a data transfer within an AWS Region". So 1 TB a month between two Pods in different zones costs $20.48, computed. For images, the S3 gateway endpoint does most of the work on its own, because "Amazon ECR uses Amazon S3 to store your image layers": "There are no hourly or data transfer costs associated with Gateway VPC Endpoints" (Cost Optimization - Networking), where 1 TB of layers through a NAT gateway costs $51.20 of processing, computed. The ecr.api and ecr.dkr interface endpoints carry the API calls and the image manifests, and a private cluster without a NAT gateway needs them: two endpoints in three zones cost $48.18 a month before their traffic, computed. For Application Load Balancers, "cross-zone load balancing is always enabled at the load balancer level"; Network Load Balancers have it "disabled by default", and once it is on, "EC2 data transfer charges apply". In IP mode the load balancer sends each request straight to a Pod, and for that path the Best Practices Guide states "there are no data transfer charges involved in this approach".

Other billed features

The other EKS lines and the CloudWatch Logs rows that price control plane logs, in Paris:

"You are charged for each capability resource for each hour it is active on your Amazon EKS cluster", and an Argo CD Application deployed to several clusters counts once per target cluster. Hybrid Nodes are "charged per vCPU per hour based on the resources of the nodes as reported to Kubernetes", and "You are charged the hybrid nodes fee if you use Amazon EC2 instances for your hybrid nodes infrastructure" (Amazon EKS pricing). Control plane logs are off by default (Send control plane logs to CloudWatch Logs): "By default, cluster control plane logs aren't sent to CloudWatch Logs. You must enable each log type individually", and "You are charged the standard CloudWatch Logs data ingestion and storage costs for any logs sent to CloudWatch Logs from your clusters." Container Insights is billed by Amazon CloudWatch and is not priced here: with enhanced observability for EKS it "uses a tiered pricing model based on observations", and otherwise "CloudWatch Container Insights ingests performance events as CloudWatch Logs that automatically create CloudWatch metrics" (Amazon CloudWatch pricing). Two things cost nothing: managed node groups, and connecting an outside cluster to the console, since "There is no charge for clusters you connect to the Amazon EKS console with the Amazon EKS Connector".

Reading the EKS lines of a bill, and splitting them by namespace

The usage types carry the Region's code, EUW3- in Paris. From the Paris price list:

Tags do not follow the cluster to its nodes (Expenditure awareness): "Tags added to an EKS cluster are specific to the AWS EKS cluster resource, they do not propagate to other AWS resources used by the cluster such as EC2 instances or load balancers." So the nodes need their own: "With Cluster Autoscaler, tag your worker nodes inside a managed node group using launch template. For self managed node groups, tag your instances using EC2 auto scaling group. For instances provisioned by Karpenter, tag them using spec.tags in the node template" (Compute and Autoscaling).

Below the node, split cost allocation data "generates container-level costs by looking at each container's EC2 instance resource consumption, and generates cost based on the amortized cost of the instance and the percentage of CPU and memory resources consumed by the containers that ran on the instance", with cost allocation tags such as aws:eks:namespace, aws:eks:workload-name and aws:eks:node. It has three measurement bases (Enabling split cost allocation data): resource requests, which "will encourage application teams to only provision what they need"; Amazon Managed Service for Prometheus, "the higher of Kubernetes pod CPU and memory resource requests and actual utilization"; and Amazon CloudWatch Container Insights, whose basis adds two metrics of its own to Container Insights (with Container Insights). Where it shows (Enabling split cost allocation data): "Split cost allocation data is not available in Cost Explorer. It is available in legacy Cost and Usage Reports (CUR) and Cost and Usage Report 2.0 (CUR 2.0) with Data Exports." It weighs CPU and memory "based on a 9:1 ratio. This is derived from per vCPU per hour and per GB per hour prices in AWS Fargate" (its example); in Paris, those two prices are 9.17 to 1, computed. Teams that are labels rather than namespaces can be tags too: "Split cost allocation data supports Kubernetes labels as cost allocation tags for Amazon EKS clusters. While these labels are automatically imported as user-defined cost allocation tags, they require activation at the management account level" (Kubernetes labels).

In short: The cluster fee is one line of an EKS bill and seldom the largest: the nodes, billed as EC2, follow the Pods' requests, the network follows where the Pods talk, and only extended support or a Provisioned Control Plane tier makes the control plane itself a large line: a cluster in extended support costs 6.00 times a standard cluster, one on the XL tier 17.50 times, computed.

Architecture patterns around EKS and what they cost

Four illustrative configurations in Paris, each priced before and after the levers of the next section, line by line from the AWS Price List: a cluster whose requests set its node count, clusters multiplied and left on old versions, capacity sized for a peak that lasts a few hours, and traffic that crosses zones for no reason. None is a client case; every amount is computed, and each card lists its assumptions and what it leaves out. The EC2 patterns price the compute side of a single application the same way.

Pattern 1 of 4 · Illustrative configuration

A production cluster: requests set high, nodes On-Demand

One production cluster in Paris runs 48 replicas of an API whose Pods request 1 vCPU each and use about 0.4, on a managed node group of Intel nodes paid On-Demand; then the same replicas with requests set from measured use, on Graviton nodes covered by a Compute Savings Plan.

Scroll the diagram sideways →

The requests carried the bill: 48 vCPU requested for 19.2 used before (40.0%), 24 for the same 19.2 after (80.0%), computed. With an EC2 Instance Savings Plan for the m7g family instead of the Compute Savings Plan, the same seven nodes cost $727.81 a month in all, but the plan stays with that family if Karpenter or Auto Mode later chooses another. Under EKS Auto Mode, the fee adds $116.76 a month to the seven nodes, $940.63 in all, computed: no plan discounts it.

Before · Requests from launch day, Intel nodes On-Demand$2,849.84

With the levers · Requests from measured use, Graviton nodes, Compute Savings Plan$823.87

• Compute$2,820.14 → $810.88, too small to draw
• Storage$29.70 → $12.99, too small to draw

Before · Requests from launch day, Intel nodes On-Demand: compute $2,820.14, storage $29.70, total $2,849.84 a month.

With the levers · Requests from measured use, Graviton nodes, Compute Savings Plan: compute $810.88, storage $12.99, total $823.87 a month.

With the levers: $2,025.97 a month less (71.1% less), computed.

A production cluster: requests set high, nodes On-Demand, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
Requests from launch day, m7i.xlarge On-DemandBefore the levers		$2,849.84	—
Requests from measured useLever: Set requests from measured use		$1,287.86	−$1,561.98
Graviton nodes (m7g.xlarge)Lever: Choose the node shape, and move to Graviton		$1,058.93	−$228.93
One-year Compute Savings PlanLever: Commit to the cluster's floor		$823.87	−$235.06

USD, before tax. AWS Price List, eu-west-3, offer files published September 28, 2026, October 12, 2026 and October 13, 2026, fetched October 16, 2026.

Levers

• Set requests from measured use
• Choose the node shape, and move to Graviton
• Commit to the cluster's floor

The bills line by line, the assumptions and the sources

A production cluster: requests set high, nodes On-Demand, before: Requests from launch day, Intel nodes On-Demand Illustrative

16 m7i.xlarge nodes On-Demand, three Pods each, requests of 1 vCPU and 2 GiB per Pod.

Line	A month
Compute	$2,820.14
Cluster fee, on a Kubernetes version in standard support1 cluster × 730 h × $0.10 /h	$73.00
16 × m7i.xlarge nodes, On-Demand16 nodes × 730 h × $0.2352 /h	$2,747.14
Storage
EBS gp3 root volumes, 20 GiB per node320 GiB × $0.0928 /GB-mo	$29.70
A month, computed	$2,849.84

A production cluster: requests set high, nodes On-Demand, with the levers: Requests from measured use, Graviton nodes, Compute Savings Plan Illustrative

7 m7g.xlarge nodes on a one-year No Upfront Compute Savings Plan, up to seven Pods each, requests of 0.5 vCPU and 1.5 GiB per Pod.

Line	A month
Compute	$810.88
Cluster fee, on a Kubernetes version in standard support1 cluster × 730 h × $0.10 /h	$73.00
7 × m7g.xlarge nodes, one-year Compute Savings Plan, No Upfront7 nodes × 730 h × $0.1444 /h	$737.88
Storage
EBS gp3 root volumes, 20 GiB per node140 GiB × $0.0928 /GB-mo	$12.99
A month, computed	$823.87

EC2 Instance Savings Plan instead: $727.81 a month, 74.5% less than before, computed.

The same nodes under EKS Auto Mode: $940.63 a month, 67.0% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 48 replicas of one API, in both variants. Each Pod requests 1 vCPU and 2 GiB, set at launch; its measured use (p95 over two weeks, illustrative) is about 0.4 vCPU and 1.2 GiB, stable.
• Each node keeps 0.5 vCPU and 2 GiB for the system and the DaemonSets (illustrative: the real figure is the node's allocatable capacity, and kubectl describe node shows the share of it each request takes), so an m7i.xlarge or an m7g.xlarge (4 vCPU, 16 GiB) has 3.5 vCPU and 14 GiB for the API's Pods.
• Before: 3 Pods per node by CPU (7 would fit by memory), so 16 nodes. After: requests of 0.5 vCPU and 1.5 GiB (the measured use plus headroom), 7 Pods per node by CPU (9 by memory), so 7 nodes, spread over three Availability Zones; a node autoscaler or a resized node group keeps the count there. Both stay below the 58 Pods the Amazon VPC CNI allows on these types.
• The API's images are built for arm64 and run at the same use per Pod on Graviton: to verify with a load test.
• The Savings Plan covers the 7 nodes every hour of the year: a plan bills every hour of its term, used or not.
• Each node has a 20 GiB gp3 root volume, the managed node group's default disk size for Linux. The nodes sit in private subnets, with no public IPv4 address.

Not counted

• Load balancers, NAT gateways, data transfer and monitoring, the same in both variants.
• The DaemonSets' Pods beyond the stated reservation, and the change itself (a load test, a rolling update of the node group).

Sources

• Compute and Autoscaling
• Karpenter
• Node and Workload Efficiency
• Expenditure awareness
• Choose an optimal Amazon EC2 node instance type
• Savings Plans types
• Amazon EKS pricing

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 28, 2026, October 12, 2026 and October 13, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

Pattern 2 of 4 · Illustrative configuration

Six team clusters, two of them in extended support

Three product teams in Paris each run a production and a staging cluster: six clusters, each with its own VPC and system nodes, two of them left on a Kubernetes version in extended support; then a production and a non-production cluster shared by the teams, both in standard support.

Scroll the diagram sideways →

The upgrade alone removes the extended support line; the move to shared clusters removes four cluster fees and the system nodes and NAT gateways that came with each cluster. What it gives up is isolation, in AWS's words: "The safest way to isolate an application is always to run it in a separate cluster". Share clusters where isolation allows it lists what namespaces do and do not separate.

Before · A cluster per team and environment$2,658.95

With the levers · Two shared clusters on standard support$642.98

• Compute$1,271.95 → $423.98, too small to draw
• Network$657.00 → $219.00, too small to draw
• Other$730.00 → —, too small to draw

Before · A cluster per team and environment: compute $1,271.95, network $657.00, other $730.00, total $2,658.95 a month.

With the levers · Two shared clusters on standard support: compute $423.98, network $219.00, total $642.98 a month.

With the levers: $2,015.97 a month less (75.8% less), computed.

Six team clusters, two of them in extended support, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
Six clusters, two in extended supportBefore the levers		$2,658.95	—
The two staging clusters upgradedLever: Upgrade before extended support		$1,928.95	−$730.00
Two shared clustersLever: Share clusters where isolation allows it		$642.98	−$1,285.97

USD, before tax. AWS Price List, eu-west-3, offer files published September 28, 2026 and October 12, 2026, fetched October 16, 2026.

Levers

• Upgrade before extended support
• Share clusters where isolation allows it

The bills line by line, the assumptions and the sources

Six team clusters, two of them in extended support, before: A cluster per team and environment Illustrative

6 EKS clusters, two of them in extended support, each in its own VPC with 3 NAT gateways and 2 system nodes.

Line	A month
Compute	$1,271.95
Cluster fees6 clusters × 730 h × $0.10 /h	$438.00
System nodes, 2 × m7g.large per cluster, On-Demand12 nodes × 730 h × $0.0952 /h	$833.95
Network
NAT gateways, one per zone in each cluster's VPC18 NAT gateways × 730 h × $0.05 /h	$657.00
Other
Extended support, on top of the fee2 clusters × 730 h × $0.50 /h	$730.00
A month, computed	$2,658.95

Six team clusters, two of them in extended support, with the levers: Two shared clusters on standard support Illustrative

A production and a non-production cluster, a namespace per team, both on a version in standard support, each in its own VPC with 3 NAT gateways and 2 system nodes.

Line	A month
Compute	$423.98
Cluster fees2 clusters × 730 h × $0.10 /h	$146.00
System nodes, 2 × m7g.large per cluster, On-Demand4 nodes × 730 h × $0.0952 /h	$277.98
Network
NAT gateways, one per zone in each cluster's VPC6 NAT gateways × 730 h × $0.05 /h	$219.00
A month, computed	$642.98

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• Six clusters before, two after. Two staging clusters run Kubernetes 1.33, in extended support since July 29, 2026; every other cluster runs a version in standard support.
• Each cluster has its own VPC over 3 Availability Zones, with a NAT gateway in each zone, and a system managed node group of 2 m7g.large (CoreDNS, the node autoscaler, agents), enough for its system Pods in both variants. If the clusters shared VPCs, the NAT gateway line would not change with their number.
• The application nodes are the same in both variants and are left out: the teams' Pods need the same capacity in a shared cluster.
• The teams accept soft multi-tenancy in the shared clusters: a namespace per team, with RBAC, network policies and resource quotas. Separate clusters isolate them more strongly.
• The upgrade from 1.33 goes one minor version at a time, and the node groups and add-ons are upgraded with the control plane.

Not counted

• Application nodes, load balancers (one per team and environment in both variants), NAT data processing and the system nodes' 20 GiB root volumes.
• The engineering time of the upgrades and of the move to shared clusters.

Sources

• Amazon EKS pricing
• Understand the Kubernetes version lifecycle on EKS
• View current cluster upgrade policy
• Update existing cluster to new Kubernetes version
• Tenant Isolation
• Pricing for NAT gateways

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 28, 2026 and October 12, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

Pattern 3 of 4 · Illustrative configuration

Batch and CI nodes sized for the peak

A cluster in Paris runs CI runners and batch jobs during working hours, whose requests need ten m7i.2xlarge nodes at the peak and almost nothing outside: a node group sized for the peak and always on, then Karpenter nodes that follow the jobs.

Scroll the diagram sideways →

The 1,733⅓ job instance-hours a month could also run on Spot, for the jobs that tolerate an interruption; Spot prices are not in the AWS Price List, so they are counted here, not priced (Run interruptible Pods on Spot). Under EKS Auto Mode instead of Karpenter, the fee adds $114.52 a month on the same instances, $1,141.87 in all, computed.

Before · A node group sized for the peak, always on$3,506.92

With the levers · Karpenter nodes that follow the jobs$1,027.35

• Compute$3,506.92 → $1,027.35, too small to draw

Before · A node group sized for the peak, always on: compute $3,506.92, total $3,506.92 a month.

With the levers · Karpenter nodes that follow the jobs: compute $1,027.35, total $1,027.35 a month.

With the levers: $2,479.57 a month less (70.7% less), computed.

Levers

• Let a node autoscaler remove what is empty

The bills line by line, the assumptions and the sources

Batch and CI nodes sized for the peak, before: A node group sized for the peak, always on Illustrative

A managed node group of 10 m7i.2xlarge On-Demand, running all month, 730 hours.

Line	A month
Compute	$3,506.92
Cluster fee, on a Kubernetes version in standard support1 cluster × 730 h × $0.10 /h	$73.00
Job nodes, 10 × m7i.2xlarge On-Demand, all month10 nodes × 730 h × $0.4704 /h	$3,433.92
A month, computed	$3,506.92

Batch and CI nodes sized for the peak, with the levers: Karpenter nodes that follow the jobs Illustrative

10 m7i.2xlarge On-Demand launched by Karpenter for the 173⅓ working hours, and 2 m7g.large always on for the controller.

Line	A month
Compute	$1,027.35
Cluster fee, on a Kubernetes version in standard support1 cluster × 730 h × $0.10 /h	$73.00
Job nodes, 10 × m7i.2xlarge On-Demand, during working hours10 nodes × 173⅓ h × $0.4704 /h	$815.36
Node group for the Karpenter controller, 2 × m7g.large On-Demand2 nodes × 730 h × $0.0952 /h	$138.99
A month, computed	$1,027.35

EKS Auto Mode instead of Karpenter: $1,141.87 a month, 67.4% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• The jobs' requests fit 10 m7i.2xlarge (8 vCPU, 32 GiB) exactly at the peak, during working hours: 8 hours a day, 5 days a week, 52 weeks a year, 8 × 5 × 52 / 12 = 173⅓ hours a month, and almost nothing outside.
• Before: a managed node group of ten nodes, On-Demand, with no node autoscaler; the system Pods run on the job nodes.
• After: a Karpenter NodePool with consolidation, which launches the same type when jobs are pending (it may pick others the NodePool allows) and removes the nodes once they are empty. The Karpenter controller runs on a managed node group of 2 m7g.large, always on, not on the nodes it manages.
• EKS Auto Mode instead of Karpenter: the same instances, its fee on each one for the hours it runs, the 2 small nodes kept for the Pods that run all month.

Not counted

• EBS root volumes (in both variants), image pulls, the Amazon SQS queue of Karpenter's interruption handling, and the seconds billed while a node starts and stops.
• Spot: the job instance-hours that tolerate interruption could run on Spot, whose prices are not in the AWS Price List, so they are not priced.

Sources

• Scale cluster compute with Karpenter and Cluster Autoscaler
• Karpenter
• Compute and Autoscaling
• Simplify node lifecycle with managed node groups
• Amazon EKS pricing
• Cost Optimization Pillar: Design principles

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 28, 2026 and October 12, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

Pattern 4 of 4 · Illustrative configuration

Chatty services across three zones

A production cluster in Paris of nine m7g.xlarge nodes over three Availability Zones, whose services call each other 60 TB a month, behind an Application Load Balancer that carries 10 TB: calls and load balancer hops spread over every zone, then kept in the caller's zone.

Scroll the diagram sideways →

The network lines alone go from $955.73 to $122.88 a month, 87.1% less, computed: before the levers they were 41.9% of the cluster's bill, on nodes that did not change.

Before · Load balancer in instance mode, calls spread over all zones$2,279.66

With the levers · Load balancer in IP mode, calls kept in their zone$1,446.81

• Compute$1,323.93 → $1,323.93, too small to draw
• Network$955.73 → $122.88, too small to draw

Before · Load balancer in instance mode, calls spread over all zones: compute $1,323.93, network $955.73, total $2,279.66 a month.

With the levers · Load balancer in IP mode, calls kept in their zone: compute $1,323.93, network $122.88, total $1,446.81 a month.

With the levers: $832.85 a month less (36.5% less), computed.

Levers

• Keep Pod traffic in its zone
• Send load balancer traffic straight to the Pods

The bills line by line, the assumptions and the sources

Chatty services across three zones, before: Load balancer in instance mode, calls spread over all zones Illustrative

9 m7g.xlarge nodes; two calls in three and two load balancer hops in three cross a zone.

Line	A month
Compute	$1,323.93
Cluster fee, on a Kubernetes version in standard support1 cluster × 730 h × $0.10 /h	$73.00
9 × m7g.xlarge nodes, On-Demand, shared by the services9 nodes × 730 h × $0.1904 /h	$1,250.93
Network	$955.73
Pod-to-Pod calls across zones: 40,960 GB, billed out of one zone and into the other81,920 GB × $0.01 /GB	$819.20
Load balancer hops from a NodePort to a Pod in another zone: 6,826.67 GB, billed out and in13,653.33 GB × $0.01 /GB	$136.53
A month, computed	$2,279.66

Chatty services across three zones, with the levers: Load balancer in IP mode, calls kept in their zone Illustrative

The same 9 nodes; 10.0% of the calls still cross a zone, and the load balancer sends requests straight to the Pods.

Line	A month
Compute	$1,323.93
Cluster fee, on a Kubernetes version in standard support1 cluster × 730 h × $0.10 /h	$73.00
9 × m7g.xlarge nodes, On-Demand, shared by the services9 nodes × 730 h × $0.1904 /h	$1,250.93
Network
Pod-to-Pod calls across zones: 6,144 GB, billed out of one zone and into the other12,288 GB × $0.01 /GB	$122.88
A month, computed	$1,446.81

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 61,440 GB a month (60 TB) of calls between the services' Pods, and 10,240 GB (10 TB) of requests and responses through the Application Load Balancer, both illustrative; Pods and calls spread evenly over the three zones.
• Before: kube-proxy spreads each Service's calls over all its endpoints, so with Pods even in three zones two calls in three leave the caller's zone (computed under that assumption); the load balancer targets NodePorts (instance mode), and two of its hops in three go on to a Pod in another zone.
• After: trafficDistribution: PreferClose on the called Services, and 10.0% of the calls still cross a zone (illustrative: rolling updates, scaling, a zone without ready endpoints); the load balancer in IP mode sends each request straight to a Pod.
• Each GB between two zones is billed out of one and into the other. The zones stay balanced enough that same-zone routing does not overload one of them (otherwise, a Deployment per zone).

Not counted

• The load balancer's hours and capacity units (the same in both variants), the traffic between the nodes and the control plane, NAT and internet traffic.

Sources

• Cost Optimization - Networking
• Amazon EC2 On-Demand Pricing
• Understanding data transfer charges
• How Elastic Load Balancing works

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 16, 2026, September 28, 2026 and October 12, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

How to reduce EKS costs

Each lever below comes from AWS documentation; their order is this article's. For compute, AWS gives its own (Compute and Autoscaling): "Right-size workloads", "Reduce unused capacity", then "Optimize compute capacity types (e.g. Spot) and accelerators (e.g. GPUs)". A Savings Plan bills every hour of its term, so a commitment comes last, once the capacity it covers is as small as it will get: see the bill first, remove what is billed but serves nothing, reshape the requests, the nodes and the clusters, keep traffic where it is free, and commit to what remains. The levers, in that order:

1. Lever 01,SeeSee the EKS bill by line and by namespaceAlways, and first
2. Lever 02,TrimUpgrade before extended supportClusters on a version past standard support
3. Lever 03,TrimLet a node autoscaler remove what is emptyLoad that varies over the day
4. Lever 04,TrimPay for control plane extras only while they are usedProvisioned tiers, logs, Capabilities
5. Lever 05,ReshapeSet requests from measured useRequests set at launch, never revisited
6. Lever 06,ReshapeChoose the node shape, and move to GravitonNodes full on one resource, idle on the other
7. Lever 07,ReshapeRun interruptible Pods on SpotStateless, fault-tolerant Pods
8. Lever 08,ReshapeShare clusters where isolation allows itA cluster per team or environment
9. Lever 09,ReshapePut Pods on Fargate where its price per Pod winsFew small services, poorly packed nodes
10. Lever 10,ReshapeWeigh the Auto Mode fee against the work it removesSmall platform teams
11. Lever 11,RouteKeep Pod traffic in its zoneChatty services over three zones
12. Lever 12,RouteSend load balancer traffic straight to the PodsLoad balancers in instance mode
13. Lever 13,RouteKeep image pulls off the NAT gatewayFrequent pulls, large images
14. Lever 14,CommitCommit to the cluster's floorCapacity present every hour, once the rest is done
15. Lever 15,ReviewReview on a cadenceEvery cluster

In short: Commit last: see the bill by line and namespace, upgrade and remove what is empty, set requests, node shapes and cluster counts from what the Pods use, keep traffic in its zone, and only then commit to the floor that is left.

FAQ

How much does an EKS cluster cost per month?

In Paris, the cluster fee is $0.10 per hour on a Kubernetes version in standard support, $73.00 a month at 730 hours, computed, with or without nodes. The nodes, their volumes and their addresses are billed on top by Amazon EC2, Amazon EBS and Amazon VPC, and they are usually the larger part (What an EKS bill is made of).

What does EKS extended support cost?

$0.50 per hour per cluster in Paris, on top of the cluster fee, for the 12 months after a version's 14 months of standard support: $438.00 a month in all, 6.00 times a standard cluster, computed. Whether a cluster enters it depends on its upgrade policy, and the policy cannot be changed once it has (Kubernetes versions).

Does EKS Auto Mode cost more?

It adds a fee per instance it launches, billed per second, 12.0% of the On-Demand rate for the types this article prices in Paris, computed, and no Savings Plan or Spot lowers it; in exchange AWS runs the nodes and the controllers that would otherwise run on them (EKS Auto Mode).

Is Fargate cheaper than EC2 nodes on EKS?

It depends on how full the nodes are: Fargate bills each Pod's requests plus 256 MB, rounded up to a configuration, and costs less per Pod than nodes requested below about 78.3% to 95.1% of their capacity for m7i.xlarge in Paris, computed. On EKS it has no Spot, no Arm and no DaemonSets (AWS Fargate on EKS).

How do I see EKS costs per namespace or team?

With split cost allocation data, turned on from the payer account: it splits each node's cost between its Pods by their requests or their use and tags them by cluster, namespace and workload, in CUR and CUR 2.0, not in Cost Explorer. Kubernetes labels can become cost allocation tags once activated (Reading the EKS lines of a bill).