EKS Auto Mode adds a third charge to a cluster that already had two. AWS bills a management fee on top of the EC2 instances it launches for you, on top of the control plane, and the fee varies by instance type. So the cheapest node for a workload under Auto Mode is not necessarily the cheapest node.
What does EKS Auto Mode add to your bill?
A per-instance management fee. The Amazon EKS pricing page states it directly: "EKS Auto Mode charges a management fee that varies based on the EC2 instance type launched, in addition to your regular EC2 instance costs and control plane costs."
And the basis is duration and type: "You pay for EKS Auto Mode based on the duration and type of Amazon EC2 instances launched and managed by EKS Auto Mode."
| Layer | Charged on | Present without Auto Mode? |
|---|---|---|
| Control plane | Per cluster per hour, by version support status | Yes |
| EC2 instances | Normal EC2 rates for the nodes | Yes |
| Auto Mode management fee | Duration and type of instances Auto Mode launched | No |
The control plane layer is unchanged and is priced by Kubernetes version support status, which is its own trap: a cluster that falls out of standard support pays six times the control plane rate. Auto Mode does not affect that.
Why does the fee varying by instance type matter?
Because it changes the instance selection maths, and the direction is not obvious. The management fee is a function of the instance type launched, so it scales alongside the instance cost rather than being a flat per-node charge. Consolidating onto fewer, larger instances does not avoid it.
That is a meaningful difference from how people usually reason about Kubernetes node cost. The standard advice is to increase node size to improve packing density and reduce per-node overhead. Under Auto Mode, per-node overhead is not the dominant term: the fee follows the instance type, so a workload spread across larger instances carries a proportionally larger fee.
Read the current per-instance-type fees on the pricing page before choosing an instance family under Auto Mode. This is one of the few AWS charges where the cheapest raw compute may not be the cheapest total, and it cannot be reasoned about from the EC2 price list alone.
What are you buying for the fee?
Node lifecycle management you would otherwise run yourself. Auto Mode provisions, scales, patches and replaces nodes, which is the work that a self-managed Karpenter or Cluster Autoscaler deployment does, plus the operational burden of keeping those components healthy and current.
What Auto Mode actually manages is listed in the EKS Auto Mode documentation.
The comparison to make is therefore not "Auto Mode versus nothing" but "Auto Mode versus the engineering time and incident risk of managing node lifecycle." That is a real trade and it often favours Auto Mode on a small platform team. What it is not is a cost optimisation: it is a fee for removing work.
Worth being clear about what the fee does not remove. Your nodes still generate every underlying charge they did before, and none of them are covered:
- Cross-AZ traffic between pods and to the control plane, at $0.01 per GB in each direction. The pricing page lists "any cross AZ traffic from nodes to the Kubernetes control plane" as a separate charge.
- A public IPv4 address per node in a public subnet, at $0.005 per hour each.
- EBS volumes and snapshots for node and workload storage.
- Load balancers provisioned by Services and Ingresses, billed per hour plus capacity units.
All of which land under EC2 rather than under EKS, which is why cluster cost read from Cost Explorer's service view is always lower than cluster cost in reality. Breaking that apart is a group-by-usage-type.
How does this interact with per-pod cost allocation?
It does not, and that is the gap worth planning around. Split cost allocation data divides an instance's cost across the pods running on it, described in EKS split cost allocation data. The Auto Mode management fee is not instance cost. It is a separate charge on the instance, so it is not part of what SCAD splits.
The consequence is that per-pod chargeback under Auto Mode understates true cost by the fee, uniformly. If you allocate cluster cost to teams from SCAD alone, the management fee stays unallocated in a platform bucket, and it grows with the fleet. Adding it back means apportioning the fee by the same weighting SCAD used, which is a query you have to write; AWS does not provide it.
For anything that has to reach a pod, this is also a reminder that the CUR is the only source with the necessary columns. FOCUS has no table configurations, so it cannot produce per-pod cost at all: CUR 2.0 vs FOCUS.
What else has AWS added to EKS pricing?
Two further SKUs that are easy to enable and easy to miss, both named on the pricing page alongside Auto Mode. EKS Capabilities are billed per enabled capability plus per managed resource, with AWS listing per-Argo-CD-Application, per-ACK-resource and per-KRO-resource-graph-definition charges, "all ... calculated and billed per hour with no minimum commitment or upfront fees."
And EKS Provisioned Control Plane, which lets you "pre-provision the desired control plane capacity from a set of well-defined scaling tiers", replaces the standard per-cluster rate with a considerably larger tiered one. The pricing page names four scaling tiers: XL at $1.65, 2XL at $3.40, 4XL at $6.90 and 8XL at $13.90 per cluster per hour, adding that "If you intend to run your cluster on scaling tier larger than 8XL, contact your AWS account team for additional pricing information." At the 8XL tier that is over $10,000 a month for a control plane, against $73 for a standard one, so it is a deliberate purchase rather than something to enable experimentally.
The general point: EKS is no longer one line item with a flat rate. A cluster can now carry a control plane charge that varies by version support, a capacity tier, an Auto Mode fee per instance, and per-resource capability fees, none of which appear as separate services in Cost Explorer. Group by usage type and compare effective rates, not totals:
SELECT line_item_usage_type,
SUM(line_item_usage_amount) AS qty,
SUM(line_item_unblended_cost) AS cost
FROM cur
WHERE billing_period = '2026-07'
AND line_item_product_code = 'AmazonEKS'
GROUP BY 1
ORDER BY cost DESC;A cluster running Auto Mode will show more distinct usage types than one that is not. If a string appears that you cannot account for, something was enabled that nobody costed.