NAT Gateway Kosten senken (2026)

Aktualisiert: 9. September 2026

Ein AWS NAT Gateway kostet in einem produktiven 3-AZ-Setup rund 97 US-Dollar Grundgebühr pro Monat plus 0,045 US-Dollar pro verarbeitetem Gigabyte – die meisten Teams zahlen aber tatsächlich das Drei- bis Vierfache, weil S3-, ECR- und Cross-AZ-Traffic unnötig durch das Gateway laufen. In diesem Leitfaden zeige ich acht Strategien, mit denen ich bei mittelständischen AWS-Kunden (200 k–2 Mio. US-Dollar Monatsspend) zwischen 60 % und 90 % der NAT-Gateway-Gebühren wegoperationalisiert habe – inklusive Code-Beispielen, Terraform-Snippets und einer klaren Entscheidungsmatrix für 2026.

Ein NAT Gateway kostet 0,045 US-Dollar pro Stunde plus 0,045 US-Dollar pro GB – in einem 3-AZ-Setup sind das mindestens 97 US-Dollar Fixkosten monatlich, bevor Traffic anfällt.
Ein VPC Gateway Endpoint für S3 und DynamoDB ist kostenlos und spart in typischen Konten sofort 30–50 % der NAT-Gebühren.
Interface Endpoints für ECR, CloudWatch, SSM und Secrets Manager reduzieren Datenverarbeitungsgebühren um 78 % (0,01 vs. 0,045 US-Dollar/GB).
fck-nat auf einer t4g.nano-Instanz ersetzt das NAT Gateway für weniger als 4 US-Dollar pro Monat – ideal für Dev- und Test-VPCs.
Cross-AZ-Fehlrouten verursachen zusätzliche 0,01 US-Dollar/GB pro Richtung – das ist der versteckte Killer bei EKS-Clustern.
Eine sauber umgesetzte Endpoint-Strategie zahlt sich in der Regel innerhalb von 4 bis 6 Wochen aus und senkt die AWS-Netzwerkkosten um 60–90 %.

Wie viel kostet ein NAT Gateway wirklich?

Ein AWS NAT Gateway hat in Wahrheit nicht einen, sondern drei Kostenblöcke – und genau das übersehen die meisten Teams, wenn sie ihren Preis-Kalkulator öffnen. Erstens fallen 0,045 US-Dollar pro Stunde pro Gateway an, das sind bei 730 Stunden im Monat 32,85 US-Dollar Fixkosten. Zweitens kommen 0,045 US-Dollar pro verarbeitetem Gigabyte hinzu, egal ob der Traffic ins Internet oder wieder ins eigene VPC geht. Drittens berechnet AWS für jeden Byte, der über eine Availability Zone hinweg fließt, zusätzliche 0,01 US-Dollar/GB in beide Richtungen.

Wer aus Redundanzgründen ein NAT Gateway pro AZ betreibt – und das ist die AWS-empfohlene Standardarchitektur – zahlt allein 97 US-Dollar Grundgebühr pro Monat, bevor auch nur ein Kilobyte fließt. Bei einem typischen SaaS-Produktionsworkload mit 5 TB Egress im Monat sind das schnell 525 US-Dollar, bei datenintensiven Video- oder ML-Pipelines auch mal 4.000 US-Dollar im Monat – für ein Stück Infrastruktur, das man nicht sieht.

Wenn Sie zusätzlich noch die Egress-Gebühr von 0,09 US-Dollar/GB für Traffic ins Internet dazurechnen, kostet jedes GB, das ein privater EC2 in die Welt sendet, 0,135 US-Dollar. Das sind das Dreifache der beworbenen NAT-Rate – und der Grund, warum "EC2-Other" auf so vielen AWS-Rechnungen der zweitgrößte Posten nach EC2 selbst ist.

Warum sind meine NAT Gateway Kosten so hoch?

In den meisten Konten, die ich in den letzten zwei Jahren geprüft habe, kam der Löwenanteil der NAT-Kosten nicht vom eigentlichen Internet-Traffic, sondern von AWS-Service-Verkehr, der überhaupt kein NAT Gateway bräuchte. Konkret sehe ich bei fast jedem Kunden vier wiederkehrende Muster: S3-Downloads aus privaten Subnets, die über den öffentlichen S3-Endpunkt laufen, ECR-Image-Pulls aus EKS-Nodes, CloudWatch-Logs- und Metrik-Uploads von hunderten Instanzen sowie Secrets-Manager-Zugriffe bei jedem Container-Start.

Der Weg zur Analyse führt über VPC Flow Logs auf der Elastic Network Interface (ENI) des NAT Gateways. Der folgende Athena-Query zeigt Ihnen die Top-Ziele nach Bytes und identifiziert AWS-Service-IPs, die vermeidbar wären:

-- Top-10-Ziele nach Traffic durch das NAT Gateway (letzte 24 h)
SELECT
  dstaddr AS destination_ip,
  SUM(bytes) / 1024 / 1024 / 1024 AS gib_processed,
  COUNT(*) AS flow_count
FROM vpc_flow_logs
WHERE eni_id = 'eni-0abc123def456'      -- ENI Ihres NAT Gateways
  AND from_iso8601_timestamp(start) > current_timestamp - interval '1' day
  AND action = 'ACCEPT'
GROUP BY dstaddr
ORDER BY gib_processed DESC
LIMIT 10;

Die IP-Adressen, die Sie zurückbekommen, gleichen Sie mit den offiziellen AWS IP-Range-JSON-Dateien ab. Ranges mit der Service-Kennung S3, DYNAMODB, EC2 (für Regional-API-Calls) oder AMAZON sind Kandidaten für einen VPC Endpoint. Bei einem meiner Fintech-Kunden waren 71 % des NAT-Traffics reine ECR-Pulls für einen EKS-Cluster mit 240 Nodes – nach dem Rollout eines ECR-Interface-Endpoints sank der Posten auf 12 %.

Strategie 1: Gateway Endpoints für S3 und DynamoDB

Der schnellste NAT-Gateway-Kostenkiller sind VPC Gateway Endpoints für S3 und DynamoDB. Sie sind komplett kostenlos, brauchen keine Elastic Network Interfaces und routen den Traffic über das AWS-Backbone am NAT Gateway vorbei. Ich habe in der Praxis noch kein Konto gesehen, in dem sich diese Endpoints nicht innerhalb der ersten Wochen amortisiert haben – wenn Ihr Setup sie noch nicht hat, ist das Ihr erster Move.

Die Terraform-Konfiguration ist minimal. Wichtig: Der Endpoint muss allen Route Tables der privaten Subnets zugeordnet werden, sonst greift er nicht. Genau das übersehen Teams, die manuell in der Konsole klicken – und wundern sich dann, warum die NAT-Kosten nicht sinken.

# Terraform: S3- und DynamoDB-Gateway-Endpoints anlegen
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id

  tags = {
    Name    = "s3-gateway-endpoint"
    Purpose = "nat-cost-reduction"
  }
}

resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

Ein Zusatzeffekt: Cross-Region-S3-Traffic wird durch den Gateway Endpoint nicht abgedeckt. Wer regelmäßig aus Buckets in us-east-1 in einer eu-central-1-Region liest, sollte statt eines Endpoints eine S3-Replikationsregel in Kombination mit einem regional-lokalen Bucket einsetzen. Das kostet zwar einmalig Replikationsgebühren, spart aber den 0,02 US-Dollar/GB-Aufschlag für regionsübergreifenden Traffic dauerhaft.

Strategie 2: Interface Endpoints für AWS-Services

Für alle Services, die keinen kostenlosen Gateway Endpoint anbieten – also praktisch alles außer S3 und DynamoDB – gibt es Interface Endpoints (auch AWS PrivateLink genannt). Sie kosten 0,01 US-Dollar pro Endpoint pro AZ pro Stunde plus 0,01 US-Dollar/GB Verarbeitung. Klingt teuer, ist es aber nicht: Gegenüber den 0,045 US-Dollar/GB des NAT Gateways sparen Sie 78 % pro Gigabyte.

Der Break-Even ist erstaunlich niedrig. Ein Endpoint in drei AZs kostet rund 22 US-Dollar Grundgebühr im Monat. Ab etwa 700 GB Traffic durch diesen Service rechnet sich der Endpoint bereits. Für ECR, das bei einem EKS-Cluster mit 100+ Pods pro Node schnell Terabytes generiert, ist das ein No-Brainer. Ebenso für CloudWatch Logs, SSM (für Session Manager und Parameter Store), Secrets Manager, STS und SQS.

Die typische Prioritätenliste, die ich in Kundenprojekten immer wieder anwende, sieht so aus:

com.amazonaws.<region>.ecr.api und com.amazonaws.<region>.ecr.dkr – für Container-Image-Pulls
com.amazonaws.<region>.logs – für CloudWatch Logs
com.amazonaws.<region>.monitoring – für CloudWatch Metrics
com.amazonaws.<region>.ssm, ssmmessages, ec2messages – für Systems Manager
com.amazonaws.<region>.secretsmanager – für Secrets Manager
com.amazonaws.<region>.sqs und sns – für Messaging

Wichtig: Setzen Sie private_dns_enabled = true, damit AWS-SDKs automatisch den privaten DNS-Namen auflösen. Sonst muss jede Anwendung explizit die neue Endpoint-URL kennen – ein häufiger Grund, warum Rollouts nicht das erwartete Einsparungspotenzial heben.

resource "aws_vpc_endpoint" "ecr_dkr" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.ecr.dkr"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true
}

Strategie 3: Cross-AZ-Routing eliminieren

Der versteckte Killer, den ich bei mindestens jedem zweiten EKS-Kunden gefunden habe, ist falsches Cross-AZ-Routing. In einem Setup mit drei NAT Gateways – eines pro AZ – muss jede private Subnet-Route-Tabelle exakt auf das NAT Gateway in ihrer eigenen AZ zeigen. Sonst zahlt AWS die 0,01 US-Dollar/GB in beide Richtungen: Pod in AZ A schickt Traffic an NAT Gateway in AZ B (Cross-AZ hin), NAT antwortet aus AZ B nach AZ A (Cross-AZ zurück). Bei 10 TB Traffic sind das plötzlich 200 US-Dollar zusätzlich im Monat – für einen reinen Konfigurationsfehler.

Der Klassiker: Ein Team hat aus Kostengründen nur ein einziges NAT Gateway gebaut und dessen Route in alle privaten Route Tables eingetragen. Auf dem Papier spart das die zwei zusätzlichen Grundgebühren (65 US-Dollar), verursacht in der Praxis aber ein Vielfaches an Cross-AZ-Traffic – und obendrein einen Single Point of Failure. Nur bei sehr kleinen Umgebungen mit unter 500 GB Traffic ist das noch wirtschaftlich.

Der Fix in Terraform ist eine einfache count-Zuweisung, die pro AZ ein NAT Gateway und eine zugehörige Route Table erzeugt:

resource "aws_nat_gateway" "per_az" {
  count         = length(var.availability_zones)
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
}

resource "aws_route_table" "private" {
  count  = length(var.availability_zones)
  vpc_id = aws_vpc.main.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.per_az[count.index].id   # NAT der eigenen AZ
  }
}

resource "aws_route_table_association" "private" {
  count          = length(var.availability_zones)
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private[count.index].id
}

Bei Kubernetes-Clustern lohnt zusätzlich topologySpreadConstraints, damit Pods eines StatefulSets nicht ungewollt AZ-übergreifend miteinander sprechen. Wer tiefer in kubernetesspezifische Netzwerkoptimierung einsteigen will, findet in meinem Guide zu Kubernetes-Kosten mit Karpenter und Kubecost weitere Hebel.

Strategie 4: fck-nat statt Managed NAT Gateway

Für Dev-, Test- und viele Preview-Umgebungen ist das Managed NAT Gateway schlicht überdimensioniert. Die Open-Source-Alternative fck-nat von Andrew Guenther läuft auf einer t4g.nano-Instanz (Graviton, 2 vCPU, 0,5 GB RAM) für 3,75 US-Dollar pro Monat und kennt keine Datenverarbeitungsgebühr. Bei 1 TB Traffic spart das gegenüber einem Managed Gateway rund 75 US-Dollar im Monat pro AZ.

Die Instanz unterstützt bis zu 5 Gbit/s Burst-Durchsatz und läuft in einer Auto Scaling Group mit einer Größe von 1, sodass sie sich bei Ausfall selbst ersetzt. Für produktive Workloads mit strengen SLAs würde ich weiter das Managed Gateway empfehlen – die verwaltete Redundanz von AWS ist den Aufpreis dort wert. Aber für alles darunter ist fck-nat eine der ehrlichsten FinOps-Wetten, die man 2026 eingehen kann.

Der einfachste Rollout erfolgt über das offizielle fck-nat-GitHub-Repository, das ein fertiges AMI und ein CDK-Konstrukt bereitstellt. Der Netzwerk-Setup ist identisch mit einer klassischen NAT-Instance: Source/Destination-Check auf der ENI deaktivieren, IP-Forwarding aktivieren, Route Table auf die ENI zeigen lassen.

Strategie 5: IPv6 und Egress-Only Internet Gateway

Der langfristig effektivste Weg, NAT-Gateway-Gebühren strukturell loszuwerden, ist ein Umstieg auf IPv6. IPv6-Adressen sind kostenlos, und AWS bietet mit dem Egress-Only Internet Gateway (EIGW) ein Gegenstück zum NAT Gateway, das weder Stunden- noch Verarbeitungsgebühren berechnet. Sie zahlen nur die Standard-Egress-Rate von 0,09 US-Dollar/GB für Internet-Traffic – und die fällt beim Managed NAT Gateway ohnehin obendrauf an.

Der Haken: Ihre gesamte Kommunikationskette muss IPv6 sprechen, vom EC2-OS über die Sicherheitsgruppen bis zu jedem einzelnen Endpunkt, den Sie kontaktieren. 2026 ist das für die meisten AWS-eigenen Services und für populäre SaaS-APIs (Stripe, Datadog, GitHub, Snowflake) unproblematisch, aber Legacy-B2B-Integrationen sind oft noch IPv4-only. Bewährt hat sich ein Dual-Stack-Ansatz: EIGW für IPv6-fähigen Traffic (typischerweise 60–80 % des Volumens), NAT Gateway für den Rest.

Ein realistischer Rollout-Plan über zwei bis drei Quartale sieht so aus:

IPv6-CIDR-Block auf VPC-Ebene aktivieren (kostenlos, sofort verfügbar).
Alle Subnets mit /64-Prefix-Ranges versehen.
EIGW erstellen und in privaten Route Tables auf ::/0 routen.
Sicherheitsgruppen um IPv6-Regeln erweitern.
Application-Load-Balancer und Zielsysteme auf Dual-Stack umstellen.
Traffic-Anteil pro Woche in CloudWatch tracken und NAT-Bandbreite entsprechend zurücknehmen.

Strategie 6: NAT Gateways in Dev- und Test-Umgebungen konsolidieren

In den seltensten Fällen brauchen Ihre drei Sandbox-Konten jeweils ein eigenes Multi-AZ-NAT-Setup. Eine typische Fehlkonfiguration, die ich bei Terraform-basierten Landing Zones sehe, sind neun NAT Gateways (drei Konten × drei AZs) für Umgebungen, die Freitagabend heruntergefahren werden. Das sind 292 US-Dollar Grundgebühr im Monat für Infrastruktur, die 60 % der Zeit ungenutzt läuft.

Zwei Ansätze funktionieren gut. Der erste ist ein zentrales Egress-VPC im Netzwerk-Konto, das per Transit Gateway mit allen Dev-VPCs verbunden ist. Ein einziges Multi-AZ-NAT-Setup teilt sich dann den Traffic aller nicht-produktiven Konten. Der zweite, günstigere Weg für sehr kleine Teams: Schedules über EventBridge, die NAT Gateways abends per Lambda löschen und morgens neu anlegen. Da ein NAT Gateway sekundengenau abgerechnet wird, spart das Wochenendfenster (Freitag 20:00 bis Montag 07:00) rund 15 US-Dollar pro Gateway pro Monat.

Wenn Sie in Ihrer Governance außerdem Reserved-Instance- und Savings-Plan-Portfolios sauber trennen wollen, hilft der Blick in meinen Vergleich Savings Plans vs. Reserved Instances 2026 – die dort beschriebenen Allokationsmuster lassen sich 1:1 auf Netzwerk-Ressourcen übertragen.

NAT Gateway vs. VPC Endpoint: Wann lohnt sich was?

Die häufigste Frage, die ich in Workshops höre, ist "Welche Kombination ist die günstigste?" – die Antwort hängt am Traffic-Muster. Die folgende Tabelle fasst zusammen, was ich in echten Kundenumgebungen 2025 und 2026 gemessen habe. Rechenbasis: eu-central-1, 3-AZ-Setup, 1 TB Traffic pro Monat.

Kriterium	Managed NAT Gateway	VPC Gateway Endpoint (S3/DDB)	VPC Interface Endpoint	fck-nat	Egress-Only IGW (IPv6)
Grundgebühr / Monat	~32 US-Dollar/AZ	0 US-Dollar	~7,3 US-Dollar/AZ	~3,75 US-Dollar/AZ	0 US-Dollar
Datenverarbeitung/GB	0,045 US-Dollar	0 US-Dollar	0,01 US-Dollar	0 US-Dollar	0 US-Dollar
Egress ins Internet	0,09 US-Dollar/GB	—	—	0,09 US-Dollar/GB	0,09 US-Dollar/GB
Ausfallsicherheit	Multi-AZ managed	Multi-AZ managed	Multi-AZ managed	Selbst gepflegt	Multi-AZ managed
Ideal für	Prod Internet-Egress	S3, DynamoDB	ECR, Logs, SSM	Dev/Test-VPCs	IPv6-fähige Workloads
Ersparnis vs. NAT	Referenz	~100 %	~78 %	~90 %	~100 %

Die pragmatische Strategie 2026 ist fast immer ein Mix: Gateway Endpoints für S3 und DynamoDB in jedem VPC (Pflicht), Interface Endpoints für die Top-3-AWS-Services nach Traffic (üblich: ECR, Logs, SSM), Managed NAT Gateway für den Rest in Produktion, fck-nat oder EIGW für Dev-, Test- und Sandbox-Konten. Dieses Muster hat bei einem Video-Processing-Kunden von mir 310.000 US-Dollar pro Monat gespart – hauptsächlich, indem wir Lambda-lastige Workloads nach Fargate Spot verschoben und gleichzeitig die zugehörigen Endpoint-Landschaften konsequent aufgeräumt haben.

Monitoring und dauerhafte Kontrolle

Damit die Ersparnisse nicht in sechs Monaten wieder verwässern, sollten Sie drei CloudWatch-Metriken auf permanenten Dashboards halten: BytesOutToDestination pro NAT Gateway, BytesInFromDestination pro NAT Gateway und die kombinierte Egress-Metrik pro VPC. Ein einfacher Alert bei über 20 % Wachstum pro Woche fängt die typische "Ein Team hat eine neue Data-Pipeline deployt"-Situation ab, bevor sie zu einem 5.000-US-Dollar-Monatsschock wird.

Zusätzlich empfehle ich, mindestens einmal pro Quartal die AWS-Cost-Anomaly-Detection-Reports für die Servicegruppe "EC2 - Other" durchzugehen und die Top-Flow-Log-Destinations zu prüfen. Die offizielle AWS-Dokumentation zu NAT Gateways listet mittlerweile auch die relevanten Kennzahlen und Best Practices, die inzwischen fast alle Cloud-Provider in ähnlicher Form übernommen haben.

Häufig gestellte Fragen

Wie viel kann ich mit VPC Endpoints im Vergleich zum NAT Gateway sparen?

In typischen Konten sinkt die NAT-Gateway-Rechnung nach dem Einsatz von Gateway Endpoints für S3/DynamoDB und Interface Endpoints für ECR, Logs und SSM um 60 bis 90 Prozent. Ausgangspunkt sind meist 500 bis 1.000 US-Dollar Monatskosten – nach der Optimierung landen die meisten Teams bei 50 bis 200 US-Dollar.

Ist fck-nat für produktive Workloads geeignet?

Für Dev-, Test- und Preview-Umgebungen: ja, uneingeschränkt. Für kritische Produktion mit strengen SLAs würde ich weiterhin das Managed NAT Gateway empfehlen, weil AWS die Redundanz, Skalierung und Wartung übernimmt. Kombinationen aus fck-nat für Dev und Managed für Prod sind der übliche Kompromiss.

Was ist der Unterschied zwischen einem Gateway Endpoint und einem Interface Endpoint?

Gateway Endpoints unterstützen nur S3 und DynamoDB, sind komplett kostenlos und funktionieren über Route-Table-Einträge. Interface Endpoints (PrivateLink) unterstützen fast alle AWS-Services, kosten rund 7,3 US-Dollar pro AZ und Monat plus 0,01 US-Dollar/GB und nutzen private ENIs mit eigenen DNS-Namen.

Warum tauchen NAT-Gateway-Kosten in der AWS-Rechnung unter „EC2-Other“ auf?

AWS gruppiert alle netzwerkbezogenen Zusatzkosten – NAT Gateway, EBS-Snapshots, Data Transfer – unter „EC2-Other“. Zur genauen Aufschlüsselung filtern Sie im Cost Explorer nach „Usage Type Group“ und wählen die Kategorien mit „NatGateway“. Cost Allocation Tags sind Pflicht, wenn Sie die Kosten auf Teams verteilen wollen.

Reicht ein einzelnes NAT Gateway für alle Availability Zones aus?

Nur für sehr kleine Umgebungen mit unter 500 GB Traffic pro Monat. Sobald mehr Volumen anfällt, übersteigen die Cross-AZ-Gebühren von 0,01 US-Dollar/GB pro Richtung schnell die 65 US-Dollar, die Sie durch zwei zusätzliche Grundgebühren gespart hätten – und Sie handeln sich einen Single Point of Failure ein.