Kubernetes Hosting Kosten Vergleich 2026: Anbieter-Preise und 6 Spar-Hebel

TL;DR

Die sechs Hebel, die eine Kubernetes-Cloud-Rechnung am stärksten senken — sortiert nach typischem Einsparpotenzial auf den Compute-Anteil:

Die Prozentwerte sind Schätzungen auf Basis der offiziellen Anbieter-Rabattstaffeln und typischer Auslastungswerte aus unserer Projektpraxis — keine Garantie, aber realistische Größenordnungen. Wer alle sechs Hebel zieht, halbiert die Rechnung häufig. Die Anbieter-Preistabelle für 2026 finden Sie weiter unten.

Das Problem: Die K8s-Rechnung wächst schneller als der Umsatz

Das Muster ist bei fast jedem SaaS-Unternehmen zwischen 10 und 100 Mitarbeitern gleich: Der Cluster wurde vor zwei, drei Jahren aufgesetzt, damals mit großzügigen Defaults. Seitdem kamen Umgebungen dazu (Staging, Preview-Deployments, ein zweites Produkt), aber niemand hat je Requests reduziert oder Nodes konsolidiert. Ergebnis: Die Cloud-Rechnung steigt 20-40 % pro Jahr, während die tatsächliche Auslastung der Nodes oft bei 20-35 % CPU liegt.

Der erste Schritt ist immer Messung statt Bauchgefühl:

kubectl top nodes
kubectl describe node <node-name> | grep -A 8 "Allocated resources"

Wenn Allocated resources bei 85 % CPU-Requests liegt, kubectl top nodes aber 25 % tatsächliche Nutzung zeigt, bezahlen Sie für Luft. Genau diese Differenz — reservierte minus genutzte Ressourcen — ist das Budget, das die sechs Hebel in diesem Artikel freisetzen. Für Transparenz auf Namespace- und Team-Ebene lohnt sich OpenCost (CNCF, kostenlos) oder Kubecost; ohne Kostenzuordnung pro Workload bleibt jede Optimierung Stochern im Nebel.

Grundlagen: Die echten Kostentreiber

Eine Managed-Kubernetes-Rechnung besteht aus vier Blöcken, deren Gewichtung fast immer unterschätzt wird:

1. Worker-Nodes (60-80 % der Rechnung). Der mit Abstand größte Block. Alles, was Node-Stunden reduziert (Rightsizing, Bin-Packing, Autoscaling, Spot), wirkt hier direkt.
2. Egress und internes Netzwerk (5-20 %). Ausgehender Traffic kostet bei den Hyperscalern 0,08-0,11 €/GB. Dazu kommen Cross-AZ-Traffic (ca. 0,01-0,02 USD/GB je Richtung bei AWS) und NAT-Gateways, die pro Stunde und pro verarbeitetem GB abrechnen.
3. Load Balancer und IPs (2-5 %). Jeder Service vom Typ LoadBalancer provisioniert einen eigenen Cloud-LB für 15-25 €/Monat. Zehn Microservices mit je einem eigenen LB statt einem Ingress-Controller kosten 150-250 €/Monat für nichts.
4. Control-Plane, Storage, Logging (5-15 %). Die Control-Plane ist mit 0-70 €/Monat fast vernachlässigbar. Log-Ingestion in CloudWatch/Azure Monitor dagegen skaliert unbemerkt — ein geschwätziger Debug-Logger in Produktion kann mehrere hundert Euro pro Monat kosten.

Wie sich diese Blöcke gegen die Kosten eines selbst betriebenen Clusters rechnen (inklusive Personalkosten, die bei On-Premise der dominante Faktor sind), haben wir separat im Vergleich interner vs. externer Kubernetes-Kosten aufgeschlüsselt.

Praxis: Die 6 Spar-Hebel im Detail

Hebel 1: Spot-Instances (60-90 % auf betroffene Nodes)

Spot- (AWS/Azure) bzw. Spot-VMs (GCP) sind überschüssige Kapazität mit Rabatten von 60-90 % gegenüber On-Demand — bei dem Risiko, dass die Cloud die VM mit 30-120 Sekunden Vorwarnung zurückzieht. Für stateless Workloads mit mehr als einem Replica ist das in der Praxis gut beherrschbar, wenn drei Bedingungen erfüllt sind: mehrere Instance-Typen erlaubt, PodDisruptionBudgets gesetzt, Graceful Shutdown implementiert.

Das Fundament ist ein PDB pro kritischem Deployment:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

Und ein terminationGracePeriodSeconds plus sauberes SIGTERM-Handling in der Anwendung. Wer beides hat, kann 50-80 % der Worker-Kapazität auf Spot fahren. Datenbanken, Message-Broker und alles mit lokalem State bleiben auf On-Demand.

Hebel 2: Reserved Instances, Savings Plans, CUDs (30-57 % auf Basislast)

Für die Grundlast — die Kapazität, die nachts um drei genauso läuft wie mittags — sind Commitments der risikoärmste Hebel:

• AWS: Compute Savings Plans bis ca. 66 % (3 Jahre, All Upfront), flexibel über Instance-Familien
• Azure: Reserved VM Instances bis ca. 57-65 % (3 Jahre), plus Azure Savings Plan als flexiblere Variante
• GCP: Committed Use Discounts bis ca. 57 % (3 Jahre), Flexible CUDs ohne Bindung an Maschinentypen

Die Regel für den Mittelstand: Committen Sie nur die gemessene Basislast der letzten 6 Monate, nicht die Peak-Kapazität, und starten Sie mit 1-Jahres-Laufzeit (typisch 30-40 % Rabatt). Ein 3-Jahres-Commitment auf eine Architektur, die Sie nächstes Jahr auf ARM umziehen wollen, ist ein klassischer Fehlgriff — außer Sie nehmen die typ-flexiblen Varianten (Compute Savings Plans, Flexible CUDs).

Hebel 3: Rightsizing der Requests (20-50 % weniger Node-Bedarf)

Der Scheduler plant nach requests, nicht nach tatsächlicher Nutzung. Zu hohe Requests bedeuten: Nodes gelten als voll, obwohl sie leer laufen, und der Cluster-Autoscaler bestellt neue. Erst die Bestandsaufnahme — Pods ganz ohne Requests finden, die das Bin-Packing unberechenbar machen:

kubectl get pods -A -o json | jq -r '.items[] | select([.spec.containers[].resources.requests] | any(. == null)) | "\(.metadata.namespace)/\(.metadata.name)"' | sort -u

Dann liefert der Vertical Pod Autoscaler im Empfehlungsmodus (ohne automatische Eingriffe) belastbare Zielwerte:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updatePolicy:
    updateMode: 'Off'

kubectl describe vpa api-vpa | grep -A 10 "Recommendation"

Wer VPA-Empfehlungen für den ganzen Cluster auf einem Dashboard sehen will, nimmt Goldilocks — es legt automatisch VPAs im Empfehlungsmodus über alle Namespaces. In Clustern, die nie ein Rightsizing gesehen haben, sind CPU-Requests erfahrungsgemäß um Faktor 2-4 überdimensioniert; 20-50 % weniger Node-Bedarf sind realistisch. Für die Gegenrechnung, wie viele Nodes Ihre Workloads nach dem Rightsizing tatsächlich brauchen, gibt es unseren Kubernetes Resource-Rechner.

Bonus für Nicht-Produktionsumgebungen: kube-downscaler fährt Dev und Staging außerhalb der Arbeitszeiten auf null:

metadata:
  annotations:
    downscaler/uptime: 'Mon-Fri 07:00-20:00 Europe/Berlin'

65 von 168 Wochenstunden Laufzeit statt Dauerbetrieb — das sind gut 60 % weniger Node-Stunden für diese Umgebungen.

Hebel 4: Karpenter und Node-Konsolidierung (15-30 %)

Der klassische Cluster-Autoscaler skaliert starre Node-Groups. Karpenter (stabil auf EKS, als AKS Node Autoprovisioning auch auf Azure) wählt stattdessen pro Scheduling-Entscheidung den günstigsten passenden Instance-Typ und räumt unterausgelastete Nodes aktiv ab:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ['spot', 'on-demand']
        - key: kubernetes.io/arch
          operator: In
          values: ['amd64', 'arm64']
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values: ['4', '8', '16']
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s
  limits:
    cpu: '200'

Zwei Details in diesem Manifest tragen die Einsparung: consolidationPolicy: WhenEmptyOrUnderutilized ersetzt teure, halb leere Nodes laufend durch kleinere oder packt Pods zusammen, und die ARM-Freigabe (arm64) öffnet Graviton- bzw. Ampere-Instanzen, die pro vCPU rund 10-20 % günstiger sind — vorausgesetzt, Ihre Images sind Multi-Arch gebaut.

Hebel 5: Bin-Packing und Node-Größen (10-25 %)

Auch ohne Karpenter lässt sich die Packungsdichte erhöhen. Drei Stellschrauben:

• Weniger, größere Nodes: Kubelet, Monitoring-Agents und System-Pods kosten pro Node einen fixen Overhead (oft 0,2-0,5 vCPU). 6 große Nodes statt 18 kleine sparen diesen Overhead zwölffach — der Preis ist ein größerer Blast-Radius pro Node-Ausfall.
• Requests an Node-Geometrie anpassen: Ein Pod mit 2,5 vCPU Request lässt auf einem 8-vCPU-Node nach drei Pods 0,5 vCPU Verschnitt. Requests von 2,5 auf 2,0 senken heißt: vier Pods pro Node statt drei.
• Autoscaler-Profil schärfen: Beim Cluster-Autoscaler --scale-down-utilization-threshold von den defaulted 0.5 auf 0.65-0.7 anheben, damit halb volle Nodes tatsächlich abgeräumt werden.

Hebel 6: Egress und NAT (5-15 % der Gesamtrechnung)

Der unsichtbarste Posten. Drei typische Lecks:

• NAT-Gateway als Image-Autobahn: Jeder Container-Pull aus einem öffentlichen Registry läuft durchs NAT-Gateway (AWS: ca. 0,052 USD/h plus 0,052 USD pro verarbeitetem GB in Frankfurt). Abhilfe: VPC-Endpoints für ECR/S3 bzw. Private Link, dazu ein Pull-Through-Cache in der eigenen Registry.
• Cross-AZ-Chatter: Replikas, die über drei AZs verteilt sind und untereinander reden, erzeugen Cross-AZ-Traffic. Topology-Aware Routing (service.kubernetes.io/topology-mode: Auto) hält Traffic in der Zone.
• Unkomprimierte Antworten: Gzip/Brotli am Ingress plus ein CDN vor öffentlichen Endpoints reduziert das Egress-Volumen oft um die Hälfte.

Wo genau Ihr Traffic hinfließt, zeigt kubectl nicht — dafür braucht es VPC Flow Logs oder ein eBPF-Tool wie Hubble (Cilium).

Anbieter-Kostenvergleich 2026

Listenpreise für EU-Regionen (Frankfurt bzw. nächstgelegen), gerundet, ohne Rabatte, Stand Juli 2026 — eigene Zusammenstellung aus den öffentlichen Preisrechnern der Anbieter. Preise ändern sich laufend; verifizieren Sie vor einer Entscheidung mit dem jeweiligen Anbieter-Rechner oder direkt mit unserem Multi-Cloud-Kostenrechner, der die Rechnung für Ihre konkrete Node-Anzahl aufmacht.

Zwei ehrliche Einordnungen zu dieser Tabelle: Erstens sind Hetzner-Preise nicht direkt vergleichbar — der Betriebsaufwand (Upgrades, etcd-Backups, HA-Control-Plane, Security-Patching), den AKS/EKS/GKE abnehmen, kostet Sie intern schnell 0,2-0,5 FTE. Zweitens entscheidet bei den drei Hyperscalern selten der Listenpreis, sondern das Rabatt- und Tooling-Umfeld: GKE hat automatische Rabatte, EKS das reifste Karpenter-Setup, AKS die kostenlose Control-Plane und den einfachsten Weg für Microsoft-Shops. Eine breitere Analyse der Kostenlage im deutschen Markt steht im Artikel zur Kubernetes-Kostenoptimierung in Deutschland.

Umsetzungs-Checkliste, priorisiert nach Hebel

Fallstricke

• Spot ohne Vorbereitung. Wer Spot aktiviert, bevor PDBs, mehrere Replikas und Graceful Shutdown stehen, tauscht 70 % Kostenersparnis gegen nächtliche Incidents. Reihenfolge einhalten: erst Resilienz, dann Spot. Und nie nur einen Instance-Typ zulassen — Spot-Verfügbarkeit schwankt pro Typ und AZ.
• Zu aggressives Rightsizing. CPU-Requests unter die reale P95-Last zu drücken, führt zu Throttling; Memory-Requests unter Peak-Verbrauch zu OOMKills — und die tauchen in keinem Kosten-Dashboard auf, sondern im Pager. VPA-Empfehlungen basieren auf Historie: Ein Batch-Job, der nur monatlich läuft, ist darin unsichtbar.
• Egress-Blindflug bei der Anbieterwahl. Wer 10+ TB/Monat ausliefert, für den ist die Egress-Spalte der Tabelle wichtiger als der Node-Preis: 10 TB kosten bei den Hyperscalern 700-1.100 €/Monat, bei Hetzner sind sie inklusive. Erst das eigene Traffic-Profil messen, dann Anbieter vergleichen.
• Commitments auf gestern. Reserved Instances auf die aktuelle Peak-Kapazität statt auf die Basislast, oder instanzgebundene Commitments vor einem geplanten Architekturwechsel — beides verwandelt einen Rabatt in eine Fehlinvestition.
• Konsolidierung gegen die Verfügbarkeit. Karpenter mit consolidateAfter: 60s und ohne PDBs verschiebt Pods mitten im Traffic-Peak. Konsolidierung braucht dieselben Schutzmechanismen wie Spot.

FAQ

Was ist der schnellste Hebel mit dem geringsten Risiko? kube-downscaler für Nicht-Produktionsumgebungen: ein Tag Aufwand, rund 60 % Ersparnis auf Dev-/Staging-Nodes, null Risiko für Produktion. Direkt danach: Pods ohne Requests fixen.

Kann ich Spot-Instances in Produktion einsetzen? Ja, für stateless Workloads mit mindestens 2-3 Replikas, PodDisruptionBudgets und sauberem SIGTERM-Handling. 50-80 % Spot-Anteil sind in Produktion gängige Praxis. Stateful Workloads (Datenbanken, Broker) gehören auf On-Demand- oder reservierte Kapazität.

Wie riskant sind Reserved Instances und Savings Plans wirklich? Überschaubar, wenn Sie nur die gemessene Basislast committen und flexible Varianten wählen (Compute Savings Plans, Flexible CUDs), die Instanzfamilien-Wechsel erlauben. Riskant wird es bei 3-Jahres-Commitments auf konkrete Instance-Typen, wenn ein Replatforming ansteht.

Lohnt sich der Wechsel zu Hetzner oder IONOS gegenüber AKS/EKS/GKE? Beim reinen Node-Preis: ja, aber seit Hetzners Preiserhöhung im Juni 2026 nur noch Faktor 1,5-2 statt der früheren 3-4. Dazu kosten selbst verwaltete Cluster realistisch 0,2-0,5 FTE Betriebsaufwand — bei einem Engineering-Gehalt von 80-100k € frisst das die Ersparnis unterhalb von etwa 15-25 Nodes wieder auf. Rechnen statt glauben; die Gegenüberstellung interner und externer Kosten liefert das Rechenmodell.

Wie viel Einsparung ist insgesamt realistisch? Bei einem Cluster, der noch nie systematisch optimiert wurde: 30-60 % innerhalb von zwei bis drei Monaten, ohne Anbieterwechsel. Die Hebel multiplizieren sich nicht voll — Rightsizing verkleinert die Basis, auf die Spot und Commitments wirken — aber die Hälfte der Rechnung ist ein erreichbares Ziel.

Fazit

Kubernetes-Hosting-Kosten sind kein Anbieterproblem, sondern ein Auslastungsproblem: Der Unterschied zwischen AKS, EKS und GKE liegt bei vergleichbarer Konfiguration im einstelligen Prozentbereich — der Unterschied zwischen einem unoptimierten und einem durchoptimierten Cluster bei 30-60 %. Deshalb zuerst die sechs Hebel im eigenen Cluster ziehen, in der Reihenfolge der Checkliste, und erst danach über einen Anbieterwechsel nachdenken.

Wenn Sie wissen wollen, was Ihr konkretes Setup bei AKS, EKS und GKE kosten würde — mit Ihren Node-Klassen, Ihrer Node-Anzahl und Ihrem Traffic-Profil: Rechnen Sie es im kostenlosen K8s-Multi-Cloud-Rechner durch →

Preisangaben: Listenpreise Stand Juli 2026, EU-Regionen, gerundet, ohne individuelle Rabatte. Einsparungs-Prozentwerte sind Schätzungen auf Basis öffentlicher Rabattstaffeln und Projekterfahrung.