7 Min. Lesezeit

EKS 1.36 verschiebt die Kostenfrage ein Stockwerk höher: nicht mehr nur Node-Effizienz, sondern Allokation pro Workload. Wer das jetzt nicht in der Plattform verankert, bezahlt mit Cloud-Rechnungen, die im nächsten Quartal niemand mehr sauber erklären kann.

Verwandt:FinOps für KI-Inferenz  /  Logistiker spart 31 Prozent Multi-Cloud-Kosten

Was sich mit EKS 1.36 in der Kostenfrage verschiebt

Was ist EKS 1.36? Amazon Elastic Kubernetes Service in der Release-Linie 1.36 ist der gemanagte Kubernetes-Dienst auf AWS, der die Kubernetes-Version 1.36 abbildet. Neu ist nicht nur das Upstream-Featureset, sondern die enge Verzahnung von Karpenter, Split Cost Allocation Data und Container Insights, die Pod-Level-Kosten direkt aus dem Cluster heraus auditierbar machen.

Wer in der GSC-Konsole nachsieht, was Plattform-Teams in den letzten Wochen gesucht haben, findet „eks 1.36“ mehrfach in den Top-Anfragen. Das ist kein Release-Notes-Interesse. Wer den Begriff tippt, hat schon einen Cluster im Betrieb und will wissen, was sich an der Cost-Sicht ändert.

Die kurze Antwort: AWS hat über mehrere Releases Cost Allocation Tags, Split Cost Allocation Data und Container Insights mit Pod-Level-Metriken in die EKS-Plattform geschoben. EKS 1.36 ist der Zeitpunkt, an dem diese Bausteine zusammenpassen. Vorher waren es separate Pfade mit separaten Datenmodellen. Jetzt landen sie in einer Sicht, die Plattform-Teams selbst kuratieren müssen.

Das verändert die Verantwortung. Bisher konnte das Plattform-Team sagen: Wir liefern den Cluster, FinOps liefert die Sicht. Mit 1.36 kippt das. Wer den Cluster betreibt, ist auch für die Cost-Allokation verantwortlich, weil die Tags, die Pod-Labels und die Reporting-Pipeline an der Plattform hängen, nicht am Finance-Tool.

Drei Stellschrauben, die Plattform-Teams jetzt anziehen

Erstens: Tagging-Konvention. Ohne durchgezogene Tags auf Cluster, NodePool, Namespace und Pod gibt es keine Allokation. Wer das in 2026 noch nicht hat, baut die Sicht in jedem Reporting-Lauf neu auf. Eine Konvention reicht, aber sie muss erzwungen werden, idealerweise mit OPA-Policies oder Kyverno.

Zweitens: NodePool-Strategie. Karpenter ist seit Version 1.0 stabil und in EKS 1.36 standardmäßig empfohlen. Eine NodePool entscheidet, ob ein Workload auf Spot oder On-Demand läuft, welche Instance-Familie er bekommt und ob Graviton zugelassen ist. Wenn diese Entscheidung dem Anwendungs-Team überlassen wird, gibt es keine Plattform-Cost-Story. Wenn sie zentral getroffen wird, gibt es Reibung. Beides ist OK, aber es muss explizit sein.

Drittens: Pod-Level-Allokation. AWS Split Cost Allocation Data verteilt EC2-Kosten anteilig auf Pods. Das funktioniert nur, wenn Resource Requests sauber gesetzt sind. In den meisten Clustern sind sie es nicht. Pods laufen mit Default-Requests, die zu hoch oder zu niedrig sind, und die Allokation wird unbrauchbar. Vor der Cost-Story kommt also ein Requests-Audit.

Eine FinOps-Sicht auf EKS ist nur so genau wie die Resource Requests in den Manifests. Wer dort lügt, lügt sich die ganze Allokation kaputt.

Karpenter wird vom Sparvorteil zum Steuerinstrument

In den ersten Karpenter-Jahren ging es darum, Cluster-Autoscaler abzulösen und schneller hochzufahren. Das ist erledigt. Was jetzt zählt, ist die Disziplin der NodePools. Eine NodePool ist ein Vertrag zwischen Plattform und Team: Welche Instance-Typen, welche Verfügbarkeitszone, welcher Spot-Anteil, welche Disruption-Toleranz.

Wer das in einer einzigen NodePool für alles bündelt, hat keine Steuerung. Wer pro Team eine NodePool baut, hat zu viel Komplexität. Realistisch sind drei bis fünf NodePools pro produktivem Cluster: eine für statische Long-running-Workloads, eine für batch-fähige Spot-Workloads, eine für GPU-Inferenz, optional eine für Compliance-isolierte Pods.

Die NodePool-Definition ist damit eine FinOps-Entscheidung, die im Cluster-Manifest steht. Sie ist auditierbar, sie ist versioniert, und sie liegt im selben Repo wie der Rest der Plattform-Konfiguration. Das ist der Punkt, an dem Cost Governance technisch wird und nicht mehr in einem Dashboard.

Was Multi-Cloud mit der EKS-Rechnung anstellt

Multi-Cloud klingt für Finance nach Risikostreuung. Für die Plattform ist es ein Allokationsproblem. EKS rechnet anders als AKS, AKS rechnet anders als GKE, und keine der drei Sichten lässt sich ohne Adapter auf die andere mappen.

Quelle: Provider-Dokumentation Stand Mai 2026, eigene Auswertung.

Wer drei Clouds nebeneinander betreibt, braucht eine Übersetzungsschicht. Die kann ein Tool wie Kubecost oder OpenCost übernehmen, sie kann auch eine selbstgebaute Pipeline sein, die alle drei Cost-APIs auf ein gemeinsames Schema bringt. Was nicht funktioniert: für jedes Team eine eigene Cloud-Konvention zu erlauben und am Monatsende ein Excel zu bauen.

Allokation: wer zahlt für welchen Pod

Die schwierige Frage in jedem FinOps-Programm ist nicht die Summe, sondern die Aufteilung. Ein Cluster, der von vier Teams genutzt wird, hat einen Cluster-Operator und vier Konsumenten. Der Operator zahlt für Control-Plane, Networking, gemeinsame Services. Die Konsumenten zahlen für ihre Pods.

Das klingt einfach. In der Praxis kollabieren drei Dinge: Pods ohne saubere Labels werden nicht zugeordnet. Shared-Services wie Ingress-Controller oder Service Mesh werden doppelt gezählt. Idle-Ressourcen werden nicht verteilt. Eine Allokation, die diese drei Punkte nicht regelt, ist Politik, keine Rechnung.

Der pragmatische Pfad: Pods ohne Team-Label landen in einem „Plattform-Bucket“ und werden monatlich nachverhandelt. Shared-Services werden anteilig nach CPU-Verbrauch verteilt. Idle-Capacity wird auf das Team verteilt, das die Reserved Instances oder Savings Plans verursacht hat. Das ist nicht perfekt, aber es ist erklärbar.

Was sich am Plattform-Vertrag jetzt ändern muss

Ein Plattform-Team, das EKS 1.36 in 2026 produktiv betreibt, hat einen anderen Vertrag mit der Organisation als noch vor zwei Jahren. Damals war die Frage: Kannst du uns einen Cluster geben, der läuft. Heute lautet sie: Kannst du uns sagen, was er kostet und wer ihn zahlt.

Das verlangt drei Dinge im Service-Katalog. Erstens eine Tagging-Konvention, die als Onboarding-Voraussetzung gilt. Zweitens eine NodePool-Auswahl, die das Team aktiv treffen muss und die mit Cost-Implikationen klar beschrieben ist. Drittens ein monatlicher Cost-Report, der vor Finance auf dem Tisch liegt und nicht erst, wenn der CFO fragt.

Wer das hinbekommt, hat eine Plattform. Wer es nicht hinbekommt, hat eine Cluster-Sammlung mit unbekannter Rechnung. EKS 1.36 macht den Unterschied technisch sichtbar. Die Entscheidung, ihn auch organisatorisch zu ziehen, liegt bei den Plattform-Teams.

Häufige Fragen

Brauche ich Kubecost, um EKS-Kosten sauber zu allokieren?

Nein, aber die Aufgabe wird mit eigenem Bau aufwendiger. AWS Split Cost Allocation Data plus Cost Allocation Tags reichen für die meisten Single-Cluster-Szenarien. Sobald mehr als drei Cluster oder Multi-Cloud im Spiel sind, lohnt sich ein Tool wie Kubecost, OpenCost oder eine ähnliche Schicht. Die Kosten der Tools selbst sind meist deutlich niedriger als die Stunden, die ein Team in eigene Pipelines steckt.

Wie verhält sich Karpenter zu Reserved Instances und Savings Plans?

Karpenter nutzt Reserved Instances und Savings Plans automatisch, wenn sie auf der gleichen Instance-Familie verfügbar sind. Es bevorzugt aber günstige Spot-Instances, was bei aggressiver Spot-Policy dazu führt, dass Savings Plans nicht voll abgerufen werden. Wer Savings Plans über mehrere Jahre kauft, sollte NodePools mit On-Demand-only-Capacity definieren, die diese Plans absorbieren, und Spot nur dort zulassen, wo der Workload disruption-tolerant ist.

Was passiert mit Cost-Allokation, wenn ein Pod in mehrere Namespaces läuft?

Ein Pod läuft immer nur in einem Namespace. Was gemeint ist: Wenn ein Workload Cross-Namespace-Ressourcen wie Shared Volumes, gemeinsame Services oder zentrale Datenbanken nutzt, muss die Allokation diese Querverbindung abbilden. Pragmatischer Weg: Cross-Namespace-Ressourcen kommen in einen „Shared-Services“-Bucket, der nach klar definiertem Schlüssel (CPU-Verbrauch, Anzahl Requests) auf die Konsumenten verteilt wird. Wer das nicht regelt, verliert 10 bis 20 Prozent der Kosten in unklarer Zuordnung.

Lohnt sich EKS 1.36 für einen kleinen Cluster mit drei Teams?

Der Upgrade-Pfad auf 1.36 lohnt sich für jeden produktiven Cluster, allein wegen der Sicherheits-Patches und der Lifecycle-Politik von AWS. Die FinOps-Features sind ein Bonus, kein Treiber. Für drei Teams reicht oft eine einzige NodePool mit klar definierter Spot-Toleranz, ein konsistentes Label-Schema und ein monatlicher Cost-Export. Den vollen FinOps-Apparat brauchen Cluster ab fünf Teams oder kombinierter Compute-Last über 200.000 Euro im Jahr.

Titelbild: KI-generiert (Mai 2026)

Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt