Kubernetes-Load-Balancer-Kosten entstehen außerhalb des Clusters: Jeder Service vom Typ LoadBalancer lässt den Cloud-Controller einen Load Balancer des Anbieters anlegen, der je Stunde und nach verarbeitetem Verkehr berechnet wird, und jede öffentliche Adresse daran kostet ihre eigene Stunde. Dazu kommt der Verkehr, den der Cluster erzeugt: zwischen Zonen innerhalb des Clusters, durch NAT-Gateways ins Internet, und als Egress zu Nutzern und anderen Regionen. Diese Seite beschreibt, warum die Zahl der Load Balancer der Zahl der Services folgt, wie ein Ingress-Controller oder die Gateway API sie bündeln, was zonenübergreifender Verkehr im Cluster kostet und wie Topology Aware Routing ihn senkt, und wo NAT-Egress auf der Rechnung steht. Die Preise der drei Anbieter für Load Balancer, NAT und Adressen stehen unter Load Balancer, NAT und öffentliche IPs, die für Verkehr unter Datentransfer und Egress.

So funktioniert es

Ein Service vom Typ LoadBalancer ist eine Anweisung an den Cloud-Controller, einen Load Balancer des Anbieters zu erstellen und auf die Nodes oder Pods des Service zu zeigen. Der Load Balancer ist eine Ressource des Anbieters mit Stundenpreis, verarbeiteten Bytes oder Kapazitätseinheiten und einer öffentlichen Adresse; er bleibt bestehen, bis der Service gelöscht wird, und steht in den Abrechnungsdaten unter dem Netzwerkdienst des Anbieters, nicht unter dem Cluster. Zwanzig Services dieses Typs sind zwanzig Load Balancer. Ein Ingress-Controller oder eine Gateway-API-Implementierung bündelt sie: Ein Load Balancer nimmt den gesamten HTTP-Verkehr an und verteilt ihn nach Host und Pfad auf die Services, die dann vom Typ ClusterIP sein können. Mit der Gateway API teilen sich mehrere Teams ein Gateway, an das sie ihre HTTPRoute-Objekte hängen; der Load Balancer ist einer, die Routen sind viele.

Verkehr innerhalb des Clusters ist nicht frei, sobald er eine Zone verlässt. Ein Cluster über drei Zonen schickt einen Teil jeder Anfrage von einem Pod zu einem Pod in einer anderen Zone, und bei AWS kostet jede Richtung dieses Verkehrs je Gigabyte; derselbe Verkehr zwischen Zonen wird bei Google Cloud berechnet. Kubernetes bietet dagegen Topology Aware Routing: Mit der Annotation service.kubernetes.io/topology-mode: Auto verteilt der EndpointSlice-Controller Hinweise, nach denen kube-proxy Anfragen an Endpunkte in derselben Zone leitet, solange jede Zone genug Endpunkte hat. internalTrafficPolicy: Local hält Verkehr auf demselben Node, externalTrafficPolicy: Local erspart den zweiten Hop vom Load Balancer über einen fremden Node. Jede dieser Einstellungen tauscht Verteilung gegen Verkehrskosten.

Egress ins Internet verlässt den Cluster über ein NAT-Gateway oder den Load Balancer des Anbieters, je nach Netzwerkmodell, und kostet dort je Stunde und je verarbeitetem Gigabyte, dazu den Datentransfer nach draußen. Ein Cluster, der Container-Images aus einer öffentlichen Registry zieht, Metriken an einen externen Dienst sendet und Objekte aus einem Speicherdienst derselben Region liest, erzeugt NAT-Verkehr, den kein Pod als Kosten sieht.

je ein Service vomTyp LoadBalancerüber einen Ingress-Controller oder GatewayPod zu Pod übereine Zoneaus dem Cluster hinausWie werden Servicesnach außen gegeben?Ein Provider-Load-Balancer jeService: Stunden, verarbeitete Bytesoder Kapazitätseinheiten, eineöffentliche Adresse, bis er gelöscht wirdEin Load Balancer für allen HTTP-Verkehr, verteilt nach Host undPfad; die Services ClusterIPWohin gehtder Verkehr?Je Gigabyte, bei AWS in jedeRichtung; Topology Aware Routinghält ihn in der ZoneDas NAT-Gateway: Stunden,verarbeitete Gigabyte undder Transfer hinaus
Jeder Service vom Typ LoadBalancer ist ein Provider-Load-Balancer, ein Ingress macht daraus einen, und Verkehr zahlt erneut, wenn er eine Zone kreuzt oder über NAT hinausgeht

AWS

Mit dem AWS Load Balancer Controller erzeugt ein Service vom Typ LoadBalancer einen Network Load Balancer, ein Ingress-Objekt einen Application Load Balancer; mehrere Ingress-Objekte teilen sich einen ALB über die Annotation alb.ingress.kubernetes.io/group.name. EKS Auto Mode bringt diese Integration mit. Je Load Balancer fallen Stunden und Kapazitätseinheiten an, je öffentlicher IPv4-Adresse 0,005 USD je Stunde, je NAT-Gateway Stunden und verarbeitete Gigabyte, und Verkehr zwischen Availability Zones 0,01 USD je Gigabyte in jeder Richtung; die Positionen und Usage Types erklären Load Balancing und öffentliche IPv4-Adressen und Datentransfer.

Azure

AKS betreibt einen Standard Load Balancer je Cluster, der zugleich den ausgehenden Verkehr der Nodes übersetzt; jeder Service vom Typ LoadBalancer bekommt eine eigene Frontend-IP auf demselben Load Balancer, und jede dieser öffentlichen Adressen wird einzeln berechnet. Alternativ läuft der Egress über ein NAT-Gateway oder eine eigene Route.

Google Cloud

Ein Service vom Typ LoadBalancer erzeugt einen Passthrough Network Load Balancer, ein Ingress-Objekt einen Application Load Balancer, die Gateway API einen je Gateway; Egress aus privaten Nodes läuft über Cloud NAT, das je Gateway-Stunde und je Gigabyte berechnet wird.

Was es für Ihre Kosten bedeutet

Drei Entscheidungen setzen den Netzwerkanteil eines Clusters. Erstens die Zahl der Load Balancer: ein Ingress oder Gateway je Cluster und Umgebung statt eines Load Balancers je Service; die Services selbst werden ClusterIP. Zweitens die Topologie: Wer Pods über drei Zonen verteilt, zahlt zonenübergreifenden Verkehr, und Topology Aware Routing senkt ihn nur, wenn jede Zone genug Replikas hat; ein Cluster in einer Zone spart diesen Verkehr und verliert die Zonenausfallsicherheit. Drittens der Egress: private Endpunkte zu den Speicher- und Registry-Diensten derselben Region nehmen Verkehr vom NAT-Gateway, und eine Registry in derselben Region spart den Image-Pull über das Internet (Datentransfer-Optimierung).

janeinDie Zahl der Load Balancer: ein Ingressoder Gateway je Cluster und Umgebung,Services als ClusterIPPods über dreiZonen verteilt?Zonenübergreifender Verkehr bezahlt;Topology Aware Routing senkt ihn nurmit genug Repliken in jeder ZoneEine Zone: der Verkehr gespart,die Zonenresilienz verlorenEgress: private Endpunkte zu denSpeicher- und Registry-Diensten derRegion nehmen Verkehr vom NAT-Gateway
Ein Ingress statt eines Balancers je Service, die Zonenverteilung gegen den zonenübergreifenden Verkehr abgewogen, und private Endpunkte, die den Egress vom NAT-Gateway nehmen

In den Abrechnungsdaten gehören diese Positionen dem Netzwerkdienst des Anbieters und erreichen den Cluster nur über Tags, die der Controller setzt, und den Namespace nur über eine eigene Regel: Ein Load Balancer je Service lässt sich dem Team zuordnen, der Ingress und das NAT-Gateway sind gemeinsame Clusterkosten mit einem Schlüssel nach Anfragen oder Bytes. Welche Zonen und Nodes ein Pod bekommt, entscheidet der Node-Pool und seine Verteilung über Zonen.

Wo es schiefgeht

  • Ein Load Balancer je Service. Symptom: Der Netzwerkdienst des Anbieters zeigt Dutzende Load Balancer für einen Cluster. Ursache: Services vom Typ LoadBalancer statt eines Ingress; jeder zahlt seine Stunden und seine Adresse.
  • Load Balancer bleibt nach dem Service. Symptom: Ein Load Balancer ohne Ziele läuft weiter. Ursache: Der Service wurde gelöscht, während der Controller nicht lief, oder ein Finalizer blieb; der Anbieter räumt nicht auf.
  • Zonenübergreifender Verkehr unerwartet hoch. Symptom: Die Datentransfer-Position einer Region wächst mit dem Cluster. Ursache: Pods und ihre Abhängigkeiten verteilen sich über Zonen, ohne Topology Aware Routing; jede Anfrage kreuzt mit zwei Dritteln Wahrscheinlichkeit eine Zonengrenze.
  • Topology Aware Routing ohne Wirkung. Symptom: Die Annotation ist gesetzt, der Verkehr unverändert. Ursache: Eine Zone hat zu wenige Endpunkte, und der Controller verteilt keine Hinweise; die Verteilung fällt auf den Standard zurück.
  • NAT-Gateway als größter Posten. Symptom: Das NAT-Gateway kostet mehr als die Load Balancer. Ursache: Image-Pulls, Speicherzugriffe und Telemetrie laufen durch das Gateway statt über private Endpunkte.
  • Public IP je Fargate-Pod oder je Service. Symptom: Die Position für öffentliche Adressen wächst mit der Zahl der Dienste. Ursache: Jede Frontend-IP und jede öffentliche Adresse wird je Stunde berechnet, auch ohne Verkehr.

Beispiel

Listenpreise, gelesen am 2026-10-21 aus den AWS-Preislisten für Frankfurt (eu-central-1): Network Load Balancer 0,027 USD je Stunde plus 0,006 USD je Kapazitätseinheit und Stunde, Application Load Balancer 0,027 USD je Stunde plus 0,008 USD je Kapazitätseinheit und Stunde, NAT-Gateway 0,052 USD je Stunde plus 0,052 USD je verarbeitetem Gigabyte, Datentransfer zwischen Availability Zones 0,01 USD je Gigabyte in jeder Richtung.

Zwölf Services vom Typ LoadBalancer kosten allein an Stunden 12 × 0,027 × 730 = 236,52 USD im Monat, dazu die Kapazitätseinheiten jedes einzelnen; ein ALB als Ingress für dieselben zwölf Dienste kostet 0,027 × 730 = 19,71 USD plus seine Kapazitätseinheiten. Ein NAT-Gateway mit 1.000 Gigabyte im Monat kostet 0,052 × 730 + 1.000 × 0,052 = 37,96 + 52,00 = 89,96 USD. Schicken die Pods eines Clusters 500 Gigabyte je Richtung über Zonengrenzen, kostet das 1.000 × 0,01 = 10,00 USD im Monat; mit Topology Aware Routing und drei Replikas je Zone bleibt der Großteil in der Zone.

Quellen

Gelesen am 2026-10-21. Kubernetes Service, Topology Aware Routing und Gateway API, AWS Load Balancer Controller, AWS Price List Bulk API, Angebote AWSELB, AmazonEC2 und AWSDataTransfer, eu-central-1, Microsoft Public Standard Load Balancer in AKS, Google Cloud LoadBalancer-Services in GKE und Cloud NAT.