7 min read<\/p>\n
EKS 1.36 shifts the cost question up a level: it\u2019s no longer just about node efficiency, but allocation per workload. Those who don\u2019t embed this into their platform now will pay with cloud bills that no one can explain clearly next quarter.<\/strong><\/p>\n Key Takeaways<\/p>\n Related:<\/span>FinOps for AI Inference<\/a> \/<\/span> Logistics company saves 31% on multi-cloud costs<\/a><\/p>\n What is EKS 1.36?<\/strong> Amazon Elastic Kubernetes Service in the 1.36 release line is AWS\u2019s 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.<\/p>\n If you check the GSC console for what platform teams have been searching for in recent weeks, you\u2019ll find “eks 1.36” multiple times in top queries. This isn\u2019t interest in release notes. Typing that term indicates you already run a cluster and want to know how the cost visibility changes.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2013ideally via OPA policies or Kyverno.<\/p>\n 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.<\/p>\n 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\u2019t. 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.<\/p>\n \n”<\/span><\/p>\n A FinOps view of EKS is only as accurate as the resource requests defined in your manifests. Get those wrong, and you break the entire allocation model.<\/p>\n<\/blockquote>\n<\/figure>\n In its early years, Karpenter\u2019s 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?<\/p>\n 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.<\/p>\n The NodePool definition thus becomes a FinOps decision embedded directly in the cluster manifest. It\u2019s auditable, version-controlled, and lives in the same repo as the rest of the platform configuration. This is where cost governance becomes technical\u2013not just another dashboard metric.<\/p>\n To finance teams, multi-cloud sounds like risk diversification. For platform engineers, it\u2019s 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.<\/p>\n Source: Provider documentation as of May 2026, internal analysis.<\/p>\n 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\u2019t work: letting each team define its own cloud conventions and then cobbling together an Excel spreadsheet at month\u2019s end.<\/p>\n The hardest question in any FinOps program isn\u2019t 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.<\/p>\n 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\u2019t distributed. Any allocation model that doesn\u2019t address these three points is politics, not accounting.<\/p>\n The pragmatic approach: pods without a team label land in a \u201cplatform bucket\u201d 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\u2019s not perfect, but it\u2019s defensible.<\/p>\n 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.<\/p>\n 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\u2019s desk before the CFO asks for it.<\/p>\n Whoever gets this right has a platform. Whoever doesn\u2019t 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.<\/p>\n 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.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n\n
What changes regarding costs with EKS 1.36<\/h2>\n
Three Levers Platform Teams Need to Tighten Now<\/h2>\n
Karpenter Evolves From Cost Saver to Control Mechanism<\/h2>\n
How Multi-Cloud Complicates EKS Billing<\/h2>\n
\n\n
\n \nAllocation Dimension<\/th>\n EKS 1.36<\/th>\n AKS 1.32<\/th>\n GKE 1.34<\/th>\n<\/tr>\n<\/thead>\n \n Pod-Level Costs<\/strong><\/td>\n Native Split Cost Allocation Data<\/td>\n Cost Analysis per Namespace<\/td>\n GKE Cost Allocation, label-based<\/td>\n<\/tr>\n \n Spot Orchestration<\/strong><\/td>\n Karpenter NodePool<\/td>\n Spot Node Pools<\/td>\n Node Auto-Provisioning with Spot<\/td>\n<\/tr>\n \n Tag Inheritance<\/strong><\/td>\n Kubernetes Labels mapped to AWS Tags<\/td>\n Azure Tags via Cluster Autoscaler<\/td>\n Labels native to GCP Billing<\/td>\n<\/tr>\n \n Reporting Latency<\/strong><\/td>\n 24 hours<\/td>\n 12 to 24 hours<\/td>\n Up to 48 hours<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Allocation: Who Pays for Which Pod<\/h2>\n
What Needs to Change in the Platform Agreement Now<\/h2>\n
Frequently Asked Questions<\/h2>\n
Do I need Kubecost to allocate EKS costs cleanly?<\/strong><\/summary>\n
How does Karpenter interact with Reserved Instances and Savings Plans?<\/strong><\/summary>\n
What happens to cost allocation if a pod runs across multiple namespaces?<\/strong><\/summary>\n
Is EKS 1.36 worth it for a small cluster with three teams?<\/strong><\/summary>\n
Editor’s Reading Tips<\/h3>\n