---
title: "HPA Scale-to-Zero in EKS: Wie Kubernetes 1.37 GPU-Kosten senkt – und was Sie beachten müssen"
description: Kubernetes 1.37 macht HPA Scale-to-Zero zum Beta-Standard, jetzt auch auf EKS. Was das für GPU-Workloads bedeutet und wo der Cold-Start-Kompromiss liegt.
---

[DMoove Blog](https://dmoove.com/blog)

# [HPA Scale-to-Zero in EKS: Wie Kubernetes 1.37 GPU-Kosten senkt – und was Sie beachten müssen](https://dmoove.com/blog/hpa-scale-to-zero-eks-gpu-kosten)

 Geschrieben von [Yannick Tresch](https://dmoove.com/blog/author/yannick-tresch) | Oct 8, 2026, 8:52:41 PM

## HPA Scale-to-Zero ist Beta – und standardmäßig aktiv

Wer GPU-Workloads auf Amazon EKS betreibt, kennt das Problem: Inferenz-Pods laufen nachts weiter, das Modell wartet auf Anfragen, und die GPU-Rechnung läuft trotzdem. Kubernetes 1.37 „Garhwal“, erschienen am 26. August 2026, ändert die Ausgangslage. Der **HorizontalPodAutoscaler (HPA) kann nativ auf null Replikas skalieren** – ohne zusätzliche Komponenten und ohne Feature-Gate-Konfiguration. Die Funktion ist Beta und standardmäßig aktiv. Seit Anfang Oktober 2026 unterstützt auch Amazon EKS die Version 1.37.

Bisher war `minReplicas: 0` im HPA nur hinter einem Alpha-Feature-Gate möglich, das sich auf EKS nicht aktivieren lässt. Wer auf EKS auf null skalieren wollte, brauchte KEDA oder ein ähnliches Add-on. Mit Kubernetes 1.37 entfällt diese Hürde. Für Teams, die KI-Inferenz oder GPU-gestützte Batch-Verarbeitung betreiben, ist das eine der praktisch relevantesten Änderungen des Releases – vorausgesetzt, man versteht, was die Funktion kann und was nicht.

Dieser Artikel erklärt den Mechanismus, zeigt, wann Scale-to-Zero auf EKS tatsächlich Kosten spart, und benennt den Kompromiss, den jedes Team bewusst eingehen muss.

## Wie HPA Scale-to-Zero in Kubernetes 1.37 funktioniert

Ein HPA mit `minReplicas: 0` skaliert eine Workload auf null Pods, sobald die konfigurierte Metrik unter den Schwellenwert fällt, und wieder auf mindestens einen Pod, wenn sie steigt. Drei Punkte sind dabei entscheidend.

**CPU- und Memory-Metriken reichen nicht.** Ohne laufende Pods gibt es keine Ressourcenmetriken, der HPA hätte kein Signal zum Hochskalieren. Die Kubernetes-API lehnt deshalb einen HPA mit `minReplicas: 0` ab, der nur CPU- oder Memory-Metriken verwendet. Nötig ist mindestens eine *Object Metric* oder *External Metric*, die unabhängig von den Pods existiert – typischerweise eine Queue-Tiefe, ein Request-Zähler oder eine Metrik aus Prometheus. Ist die Metrik nicht abrufbar, kann der HPA nicht aus null hochskalieren.

**Der HPA unterscheidet „automatisch auf null skaliert“ von „manuell pausiert“.** Dafür setzt der Controller die Statusbedingung `ScaledToZero=True`, wenn er selbst eine Workload auf null skaliert; die Bedingung gibt es seit Kubernetes 1.36. Nur dann wertet er weiter die Metriken aus und skaliert bei Bedarf wieder hoch. Eine Workload, die jemand manuell auf null gesetzt hat, weckt der HPA nicht. Deployments sollten deshalb mit mindestens einem Replika starten.

**Das Feature-Gate ist in 1.37 aktiv.** `HPAScaleToZero` ist auf `kube-apiserver` und `kube-controller-manager` standardmäßig eingeschaltet. Wer das Feature deaktivieren oder auf eine ältere Version zurückgehen will, setzt betroffene HPAs vorher auf `minReplicas: 1` und skaliert laufende Workloads hoch – sonst bleiben sie bei null stehen.

Ein minimales Beispiel für einen HPA mit Scale-to-Zero, der auf eine externe Queue-Metrik reagiert:

```
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: llm-inference
  minReplicas: 0
  maxReplicas: 4
  metrics:
  - type: External
    external:
      metric:
        name: sqs_queue_depth
      target:
        type: AverageValue
        averageValue: "5"
```

## Warum GPU-Workloads besonders profitieren

Für CPU-Workloads ist Scale-to-Zero nützlich, für GPU-Workloads fällt der Effekt ungleich größer aus. Eine p5.48xlarge mit acht H100-GPUs kostet On-Demand rund 55 USD pro Stunde (us-east-1), also etwa 6,90 USD pro GPU-Stunde. Aktuelle Preise je Region finden Sie in der [AWS EC2-Preisübersicht](https://aws.amazon.com/ec2/pricing/on-demand/). Ein GPU-Pod, der nachts oder am Wochenende ohne Anfragen läuft, kostet real Geld.

Dazu kommt das Signalproblem: CPU-Metriken sagen bei GPU-Pods wenig darüber aus, ob die GPU gebraucht wird. Die Pflicht zu Object- oder External-Metriken zwingt zu einem besseren Signal. Wer auf Queue-Tiefe oder Inference-Request-Rate skaliert, misst den tatsächlichen Bedarf.

Auch die Gebührenseite hat sich bewegt: AWS hat zum 1. Juli 2026 die Management-Gebühren für GPU-Instanzen in EKS Auto Mode gesenkt, bei **G-Series-Instanzen um 35 %, bei P-Series und AWS Trainium um 60 %**. Die Senkung gilt automatisch für alle Auto-Mode-Cluster. Beachten Sie die Einordnung: Die Auto-Mode-Gebühr ist ein Aufschlag auf den EC2-Preis. Gesenkt wurde nur dieser Aufschlag, nicht der Instanzpreis. Der Effekt ist damit real, aber deutlich kleiner, als die Prozentzahlen vermuten lassen. Den größeren Hebel bietet Scale-to-Zero, weil dann für Leerlaufzeiten weder Instanz noch Aufschlag anfallen.

Für Staging-Umgebungen, interne Tools und Batch-Inferenz-Endpunkte mit sporadischem Traffic ist Scale-to-Zero damit wirtschaftlich klar attraktiv. Für produktive, nutzergerichtete Inferenz-APIs gilt das nur mit Einschränkungen – dazu gleich mehr.

## Der Cold-Start-Kompromiss: Was wirklich passiert

Scale-to-Zero spart Geld, solange keine Pods laufen. Kommt eine Anfrage, muss der Cluster aber von null auf einen bereiten Pod kommen – und das dauert. Wie lange, hängt davon ab, ob der GPU-Node noch läuft oder ebenfalls abgebaut wurde.

Ist der Node noch vorhanden, fallen Scheduling, Image-Pull und Modell-Laden an. Wurde er bereits konsolidiert, kommen Node-Provisionierung, GPU-Treiber-Initialisierung und ein frischer Image-Pull hinzu. Laut cast.ai dauert die Gesamtzeit bei großen Modellen auf frischen Nodes typischerweise **8 bis 15 Minuten**. Das ist ein Orientierungswert aus einem Vendor-Blog. Die tatsächliche Dauer hängt von Modellgröße, AMI-Typ und Netzwerkbandbreite ab.

Hinzu kommt: Kubernetes Services puffern keine Anfragen, solange kein Pod bereit ist. Das hält auch der [Kubernetes-Blog zum Release](https://kubernetes.io/blog/2026/09/02/kubernetes-v1-37-hpa-scale-to-zero-beta/) ausdrücklich fest. Wer Scale-to-Zero für HTTP-Endpunkte einsetzt, braucht eine vorgelagerte Pufferschicht, etwa eine SQS-Queue, einen Message-Broker oder ein Gateway, das Anfragen hält, bis der Pod bereit ist.

Daraus ergibt sich eine Faustregel:

- **Geeignet für Scale-to-Zero:** Queue-basierte Batch-Inferenz, interne Tools mit toleranter Latenz, Staging- und Entwicklungsumgebungen sowie Workloads mit vorhersehbaren Ruhephasen, etwa nachts.
- **Nicht geeignet:** Nutzergerichtete Inferenz-APIs mit Latenzanforderungen im Sekundenbereich, Echtzeit-Anwendungen und Workloads mit nahezu konstanter Last.

## HPA vs. KEDA: Was sich ändert und was bleibt

KEDA (Kubernetes Event-Driven Autoscaling) unterstützt Scale-to-Zero seit Jahren, über `minReplicaCount: 0` in einem `ScaledObject`. Viele EKS-Teams haben KEDA genau deshalb eingeführt, weil der native HPA nicht unter ein Replika skalieren konnte. Dieser Grund entfällt mit Kubernetes 1.37.

Was bleibt: KEDA bietet eine deutlich breitere Bibliothek an Event-Quellen. Wer auf SQS-Queue-Tiefe, Kafka-Lag oder Dutzende weitere Signale skalieren will, ohne einen Prometheus Adapter zu betreiben, ist mit KEDA weiterhin besser bedient. Für einfache Fälle – eine Prometheus-Metrik, ein externer Zähler – reicht der native HPA jetzt aus.

Die beiden Ansätze schließen sich nicht aus. KEDA übernimmt den Wechsel zwischen null und einem Pod selbst und delegiert die Skalierung darüber hinaus an einen HPA, den es verwaltet. Teams, die KEDA bereits betreiben, müssen nichts ändern. Teams, die Scale-to-Zero neu einführen und keine komplexen Event-Quellen brauchen, können mit dem nativen HPA starten.

## Pod-Ebene allein spart keine Node-Kosten

Solange der GPU-Node weiterläuft, bringt Scale-to-Zero auf Pod-Ebene keine Instanzersparnis. Der zweite Layer ist Karpenter (oder EKS Auto Mode) mit einer Konsolidierungsrichtlinie, die leere Nodes abbaut. Erst wenn beide Ebenen zusammenspielen – der HPA skaliert Pods auf null, Karpenter entfernt den leeren Node –, entfällt die GPU-Instanzgebühr vollständig.

Bei selbst verwaltetem Karpenter empfiehlt sich `consolidationPolicy: WhenEmpty` mit einem kurzen `consolidateAfter`-Fenster. EKS Auto Mode bringt die Konsolidierung mit. Beachten Sie aber eine Änderung in Kubernetes 1.37: Neue Auto-Mode-NodePools, die keine `consolidationPolicy` angeben, verwenden laut EKS-Release-Notes jetzt `Balanced` statt `WhenEmptyOrUnderutilized`. Für GPU-Pools lohnt es sich, die Richtlinie explizit zu setzen.

## Was EKS-Teams jetzt konkret tun sollten

EKS unterstützt Kubernetes 1.37 seit Anfang Oktober 2026. Die Funktion ist Beta, ein Test auf Staging-Clustern ist deshalb der sinnvolle erste Schritt:

- **Kandidaten identifizieren:** Welche Workloads haben heute `minReplicas: 1` und laufen regelmäßig im Leerlauf? GPU-Pods in Staging, Batch-Inferenz-Deployments und interne Modell-Endpunkte kommen zuerst infrage.
- **Externe Metriken aufbauen:** Scale-to-Zero funktioniert nur mit Object- oder External-Metriken. Wer noch keinen Prometheus Adapter oder KEDA betreibt, muss das nachholen. Eine SQS-Queue als Trigger ist für Batch-Workloads oft die einfachste Lösung.
- **Karpenter-Konsolidierung konfigurieren:** Ohne Node-Konsolidierung spart Scale-to-Zero keine Instanzkosten. `consolidationPolicy: WhenEmpty` mit einem `consolidateAfter`-Wert von 5 bis 10 Minuten ist ein praktikabler Ausgangspunkt für GPU-Node-Pools.
- **Cold-Start-Latenz messen:** Vor dem Produktiveinsatz sollte die tatsächliche Cold-Start-Zeit im eigenen Cluster feststehen. AMI-Typ, Modellgröße und ECR-Bandbreite entscheiden, ob die Latenz akzeptabel ist.
- **EKS Auto Mode in die TCO-Rechnung aufnehmen:** Die gesenkten GPU-Management-Gebühren sind ein Posten in der Rechnung, aber kein alleiniger Migrationsgrund. Im Zusammenspiel mit Scale-to-Zero verbessern sie die Bilanz.

Wer heute schon KEDA betreibt, muss nichts überstürzen. Die Richtung ist aber klar: Scale-to-Zero wird Teil des Standard-Werkzeugkastens für GPU-Workloads auf Kubernetes. Teams, die jetzt Metriken und Karpenter-Konfiguration in Ordnung bringen, können umstellen, sobald die Funktion aus der Beta herauskommt – ohne Zeitdruck.

Weiterführend: [EKS Capabilities: Managed Argo CD, ACK und kro im Überblick](https://dmoove.com/blog/eks-capabilities-platform-engineering) und [Amazon CloudWatch Omni: Was die neue AWS-Observability-Plattform für EKS-Teams bedeutet](https://dmoove.com/blog/amazon-cloudwatch-omni-was-die-neue-aws-observability-plattform-f-r-eks-teams-bedeutet).

[Vollständigen Beitrag anzeigen](https://dmoove.com/blog/hpa-scale-to-zero-eks-gpu-kosten)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Yannick Tresch"
  },
  "dateModified" : "2026-10-08T20:52:41.231Z",
  "datePublished" : "2026-10-08T20:52:41Z",
  "headline" : "HPA Scale-to-Zero in EKS: Wie Kubernetes 1.37 GPU-Kosten senkt – und was Sie beachten müssen",
  "image" : {
    "@type" : "ImageObject",
    "height" : 1024,
    "url" : "https://26586893.fs1.hubspotusercontent-eu1.net/hubfs/26586893/AI-Generated%20Media/Images/Technicians%20Analyzing%20Kubernetes%20Metrics%20In%20Modern%20Data%20Center.png",
    "width" : 1535
  },
  "mainEntityOfPage" : "https://dmoove.com/blog/hpa-scale-to-zero-eks-gpu-kosten",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "DMoove Blog"
  }
}
```