EKS 1.36 Costs Rise Sharply When FinOps Discipline Is Missing
EKS 1.36 shifts the cost question to the platform. Allocation per pod, NodePool contract, multi-cloud mapping are now cluster tasks.
7 min read
EKS 1.36 shifts the cost question up a level: it’s no longer just about node efficiency, but allocation per workload. Those who don’t embed this into their platform now will pay with cloud bills that no one can explain clearly next quarter.
Key Takeaways
- Costs move to the platform. With EKS 1.36, allocation per pod and team becomes a platform responsibility. Pushing this to Finance won’t pass an audit.
- Karpenter is no longer just a savings plugin. Starting with this release wave, NodePool policy determines whether a team bears Spot risk or On-Demand premiums. This is a contractual issue, not a tooling one.
- Multi-cloud intensifies the problem. Running EKS alongside AKS or GKE means dealing with three allocation models that cannot be consolidated into a single FinOps view. The platform must translate this, otherwise every team calculates against every other.
Related:FinOps for AI Inference / Logistics company saves 31% on multi-cloud costs
What changes regarding costs with EKS 1.36
What is EKS 1.36? Amazon Elastic Kubernetes Service in the 1.36 release line is AWS’s managed Kubernetes service mirroring Kubernetes version 1.36. New here is not just the upstream feature set, but the tight integration of Karpenter, Split Cost Allocation Data, and Container Insights, which make pod-level costs directly auditable from within the cluster.
If you check the GSC console for what platform teams have been searching for in recent weeks, you’ll find “eks 1.36” multiple times in top queries. This isn’t interest in release notes. Typing that term indicates you already run a cluster and want to know how the cost visibility changes.
The short answer: AWS has pushed Cost Allocation Tags, Split Cost Allocation Data, and Container Insights with pod-level metrics into the EKS platform over several releases. EKS 1.36 is the point where these building blocks finally align. Previously, they were separate paths with separate data models. Now they land in a single view that platform teams must curate themselves.
This shifts responsibility. Previously, the platform team could say: We deliver the cluster; FinOps delivers the visibility. With 1.36, that flips. Whoever operates the cluster is also responsible for cost allocation because the tags, pod labels, and reporting pipeline are tied to the platform, not the finance tool.
Three Levers Platform Teams Need to Tighten Now
First: Tagging conventions. Without consistent tags across clusters, NodePools, namespaces, and pods, there is no allocation. Anyone still missing this in 2026 will have to rebuild visibility from scratch with every reporting run. One convention suffices, but it must be enforced–ideally via OPA policies or Kyverno.
Second: NodePool strategy. Karpenter has been stable since version 1.0 and is the default recommendation in EKS 1.36. A NodePool determines whether a workload runs on Spot or On-Demand, which instance family it receives, and whether Graviton is permitted. If this decision is left to application teams, there is no platform cost narrative. If made centrally, friction arises. Both approaches are fine, but they must be explicit.
Third: Pod-level allocation. AWS Split Cost Allocation Data distributes EC2 costs proportionally across pods. This only works if resource requests are set correctly. In most clusters, they aren’t. Pods run with default requests that are either too high or too low, rendering allocation useless. So before any cost story emerges, a requests audit comes first.
Karpenter Evolves From Cost Saver to Control Mechanism
In its early years, Karpenter’s goal was to replace Cluster Autoscaler and scale up faster. That job is done. What matters now is NodePool discipline. A NodePool represents an agreement between platform and team: Which instance types? Which availability zone? What spot ratio? How much disruption tolerance?
Bundling everything into a single NodePool means no control. Creating one per team introduces excessive complexity. Realistically, three to five NodePools per production cluster make sense: one for static long-running workloads, one for batch-capable spot workloads, one for GPU inference, and optionally one for compliance-isolated pods.
The NodePool definition thus becomes a FinOps decision embedded directly in the cluster manifest. It’s auditable, version-controlled, and lives in the same repo as the rest of the platform configuration. This is where cost governance becomes technical–not just another dashboard metric.
How Multi-Cloud Complicates EKS Billing
To finance teams, multi-cloud sounds like risk diversification. For platform engineers, it’s an allocation puzzle. EKS bills differently than AKS, AKS differently than GKE, and none of these three billing models can be mapped to one another without an adapter layer.
| Allocation Dimension | EKS 1.36 | AKS 1.32 | GKE 1.34 |
|---|---|---|---|
| Pod-Level Costs | Native Split Cost Allocation Data | Cost Analysis per Namespace | GKE Cost Allocation, label-based |
| Spot Orchestration | Karpenter NodePool | Spot Node Pools | Node Auto-Provisioning with Spot |
| Tag Inheritance | Kubernetes Labels mapped to AWS Tags | Azure Tags via Cluster Autoscaler | Labels native to GCP Billing |
| Reporting Latency | 24 hours | 12 to 24 hours | Up to 48 hours |
Source: Provider documentation as of May 2026, internal analysis.
Running three clouds side by side requires a translation layer. A tool like Kubecost or OpenCost can handle this, or you could build a custom pipeline that normalizes all three cost APIs into a single schema. What doesn’t work: letting each team define its own cloud conventions and then cobbling together an Excel spreadsheet at month’s end.
Allocation: Who Pays for Which Pod
The hardest question in any FinOps program isn’t the total bill, but how to split it. A cluster shared by four teams has one cluster operator and four consumers. The operator covers the control plane, networking, and shared services. The consumers pay for their respective pods.
It sounds straightforward. In practice, three things tend to break down: pods without clean labels go unassigned. Shared services like ingress controllers or service meshes get double-counted. Idle resources aren’t distributed. Any allocation model that doesn’t address these three points is politics, not accounting.
The pragmatic approach: pods without a team label land in a “platform bucket” and are reconciled monthly. Shared services are prorated based on CPU consumption. Idle capacity is allocated to the team responsible for the reserved instances or savings plans. It’s not perfect, but it’s defensible.
What Needs to Change in the Platform Agreement Now
A platform team that will be operating EKS 1.36 productively in 2026 has a different contract with the organization than it did two years ago. Back then, the question was: Can you give us a cluster that runs? Today, it’s: Can you tell us what it costs and who pays for it.
This requires three things in the service catalog. First, a tagging convention that serves as an onboarding prerequisite. Second, a node pool selection that the team must actively make, clearly described with cost implications. Third, a monthly cost report that sits on the finance team’s desk before the CFO asks for it.
Whoever gets this right has a platform. Whoever doesn’t ends up with a collection of clusters and an unknown bill. EKS 1.36 makes this difference technically visible. The decision to also implement it organizationally lies with the platform teams.
Frequently Asked Questions
Do I need Kubecost to allocate EKS costs cleanly?
No, but building your own solution becomes more complex. AWS Split Cost Allocation Data plus Cost Allocation Tags are sufficient for most single-cluster scenarios. Once more than three clusters or multi-cloud environments are involved, a tool like Kubecost, OpenCost, or a similar layer becomes worthwhile. The cost of these tools is usually significantly lower than the hours a team would spend building its own pipelines.
How does Karpenter interact with Reserved Instances and Savings Plans?
Karpenter automatically uses Reserved Instances and Savings Plans when they are available on the same instance family. However, it prefers cheaper spot instances, which, with an aggressive spot policy, can lead to underutilization of Savings Plans. If you purchase Savings Plans over multiple years, define NodePools with On-Demand-only capacity to absorb these plans and allow Spot instances only where workloads are disruption-tolerant.
What happens to cost allocation if a pod runs across multiple namespaces?
A pod always runs in only one namespace. What is meant here is: If a workload uses cross-namespace resources such as shared volumes, common services, or central databases, the allocation must reflect this interconnection. Practical approach: Place cross-namespace resources into a “Shared-Services” bucket, which distributes them to consumers based on a clearly defined key (CPU usage, number of requests). Those who don’t manage this lose 10 to 20 percent of their costs due to unclear allocation.
Is EKS 1.36 worth it for a small cluster with three teams?
Upgrading to 1.36 is worth it for every productive cluster, mainly due to security patches and AWS lifecycle policies. FinOps features are a bonus, not a driver. For three teams, often a single node pool with clearly defined spot tolerance, a consistent label schema, and a monthly cost export is sufficient. The full FinOps framework is needed for clusters with five or more teams or combined compute loads exceeding 200,000 euros per year.
Image: AI-generated (May 2026)
Image Source: AI-generated (May 2026), C2PA Certificate Embedded in Image
Translated from the German original using artificial intelligence. The German version is authoritative.
