Das NAT Gateway ist der teuerste Posten, den Sie nicht sehen

Veröffentlicht im TEN INVENT Blog · September 2026

Er steht nicht auf der Rechnung. Jedenfalls nicht als „NAT Gateway“. Er steht unter EC2-Other, als Nutzungstyp NatGateway-Hours neben einem weiteren namens NatGateway-Bytes, und in der Standardansicht des Cost Explorer ist er in die EC2-Zeile eingefaltet, weshalb ein Team, das keine einzige EC2-Instanz betreibt, auf eine EC2-Gebühr von $100 schauen und einen Fehler vermuten kann.

Es ist kein Fehler. Es sind $0,045 pro Stunde, jede Stunde, für jedes NAT Gateway, das Sie haben, bevor ein einziges Byte hindurchgeht, plus $0,045 für jedes Gigabyte, das es tut. Auf der Drei-Konten-Rechnung, die wir veröffentlicht haben, waren das 13 % des Gesamtbetrags, mehr als Lambda, DynamoDB und WAF zusammen, für eine Komponente, die nichts tut, außer privaten Dingen den Weg ins Internet zu erlauben. Dieser Artikel erklärt, warum Sie es haben, und wie wir von drei auf eines gekommen sind.

Warum Sie ein NAT Gateway haben

Weil etwas in einem privaten Subnetz liegt. Private Subnetze haben absichtlich keine Route zum Internet Gateway: nichts aus dem Internet kann sie erreichen. Der Preis ist, dass sie das Internet ebenfalls nicht erreichen können, und „das Internet“ schließt die AWS-API-Endpunkte ein, sodass eine Lambda in einem privaten Subnetz S3, Secrets Manager oder SQS ohne einen Ausweg nicht aufrufen kann. Der Ausweg ist ein NAT Gateway in einem öffentlichen Subnetz, mit einer Route von den privaten Subnetzen dorthin.

Unser Grund war Aurora. Die Datenbank liegt in einem privaten Subnetz, korrekt. Die Lambdas, die mit ihr sprechen, müssen im VPC sein, um sie zu erreichen. Sind sie einmal im VPC, brauchen sie das NAT für alles andere, was sie tun: ein Secret holen, eine Nachricht in eine Queue legen, eine Drittanbieter-API aufrufen. Eine Anforderung, Datenbankzugriff, zog ein Dutzend Funktionen ins VPC und ein NAT in jedes Konto.

Was es uns tatsächlich gekostet hat

Drei Konten, je ein NAT, je eine Availability Zone (eines pro AZ hatten wir bewusst nicht gemacht, das hätte es verdreifacht):

Beachten Sie die Form. Es ist fast vollständig die Stundengebühr. Die Bytes sind nichts, weil das meiste, was durch das NAT geht, kleine API-Aufrufe sind. Der übliche Rat, „reduzieren Sie Ihre NAT-Datenverarbeitung“, hätte uns drei Dollar gespart. Der Hebel ist die Anzahl.

Fünf Wege, weniger davon zu brauchen

1. Gateway-Endpunkte für S3 und DynamoDB. Kostenlos. Ein Gateway-Endpunkt ist ein Routing-Tabelleneintrag, der Traffic für S3 oder DynamoDB durch das AWS-Netz statt hinaus und zurück schickt. Er kostet nichts, ist zwei Zeilen CDK und gehört vom ersten Tag an in jedes VPC, unabhängig vom NAT. Er hat etwa die Hälfte unserer NAT-Bytes entfernt, was $1,50 wert war. Tun Sie es trotzdem; der Grund sind Latenz und kein Egress für S3-Traffic, nicht das NAT.

vpc.addGatewayEndpoint('S3', { service: ec2.GatewayVpcEndpointAwsService.S3 });
vpc.addGatewayEndpoint('DynamoDB', { service: ec2.GatewayVpcEndpointAwsService.DYNAMODB });

2. Interface-Endpunkte für die Dienste, die Sie tatsächlich aufrufen. $7,30 im Monat pro Stück. Ein Interface-Endpunkt ist eine Netzwerkschnittstelle in Ihrem Subnetz mit einer privaten IP für einen AWS-Dienst: Secrets Manager, SQS, ECR, CloudWatch Logs, STS. Jeder kostet etwa $7,30 im Monat plus $0,01 pro Gigabyte. Die Rechnung: ein Endpunkt zahlt sich nur aus, wenn er es erlaubt, ein NAT zu entfernen, oder wenn Sie mehr als etwa 700 GB im Monat hindurchschieben. Fünf Endpunkte, um alles abzudecken, was unsere Lambdas aufrufen, sind $37, mehr als das NAT, das sie ersetzen würden. Also nutzen wir sie an genau einer Stelle, siehe unten.

3. Aus dem VPC raus. Das ist der große. Eine Lambda muss nur dann im VPC sein, wenn sie mit etwas spricht, das nur dort erreichbar ist. Wir haben das Dutzend Funktionen geprüft: sieben sprachen mit Aurora, fünf nicht. Die fünf waren im VPC, weil das CDK-Construct in unserer Funktionsfabrik vpc: als Standard gesetzt hatte. Sie aus dem VPC zu nehmen war ein Flag und entfernte sie vollständig aus der Kundenliste des NAT. Eine Lambda außerhalb des VPC erreicht AWS-APIs direkt, kostenlos, und startet schneller.

Für die sieben, die Aurora brauchen, gibt es eine weitere Option, die wir prüfen: die RDS Data API, mit der eine Funktion außerhalb des VPC einen Aurora-Cluster über HTTPS abfragen kann. Sie ändert den Treiber, ist also kein Flag, würde das VPC aber vollständig von Lambdas leeren.

4. Keines in Dev. Das NAT der Dev-Umgebung existierte, damit Dev-Lambdas das Internet erreichen konnten. Nach Schritt 3 waren die einzigen Dinge in Devs privaten Subnetzen, die das Internet brauchten, die sieben Datenbankfunktionen, die Secrets holen und in Queues schreiben. Zwei Interface-Endpunkte, Secrets Manager und SQS, für $15 im Monat ersetzten ein NAT für $33, und Devs Drittanbieter-Aufrufe (es gibt keine in Dev; sie sind gestubbt) brauchten gar keinen Pfad mehr. Staging bekam dieselbe Behandlung.

5. Eine NAT-Instanz dort, wo Sie wirklich billigen Egress brauchen. Hätte Dev allgemeinen Internetzugang gebraucht, wäre die Antwort eine NAT-Instanz statt eines NAT Gateways: eine t4g.nano mit dem Open-Source-Image fck-nat kostet etwa $3 im Monat, schafft ein paar hundert Megabit und ist ein guter Tausch für eine Nicht-Produktionsumgebung, in der ein Single Point of Failure akzeptabel ist. Wir brauchten es nicht, aber es ist das richtige Werkzeug für „ich brauche ein NAT, aber kein $33-NAT“. Nie in Produktion.

Es gibt einen sechsten, der nur gilt, wenn Sie auf reines IPv6 gehen können: ein Egress-only Internet Gateway ist kostenlos und tut für IPv6, was ein NAT für IPv4 tut. Die meisten Drittanbieter-APIs sind noch nicht über IPv6 erreichbar, also war es für uns keine Option.

Wo wir gelandet sind

Produktion behält ihr NAT: sie ruft Drittanbieter-APIs auf, braucht einen echten Pfad, und $36 für eine verwaltete, Multi-AZ-fähige Komponente ohne Wartung sind fair. Die Ersparnis sind $36 im Monat, was klein klingt, bis man merkt, dass es 5 % der gesamten Rechnung sind, einen Nachmittag gekostet hat und derselbe Nachmittag fünf Lambdas schneller starten ließ.

Die Regel für neue Dinge

Bevor eine neue Funktion oder ein neuer Dienst in ein privates Subnetz kommt, muss im Pull Request eine Frage beantwortet werden: mit was im privaten Subnetz spricht er? Lautet die Antwort „mit nichts“, kommt er nicht hinein. Lautet sie „mit der Datenbank“, kommt er hinein und bekommt die Endpunkte aufgelistet, die er braucht. Lautet sie „er braucht das Internet“, dann ist es entweder Produktion oder ein Designgespräch.

Das NAT Gateway ist kein schlechtes Produkt. Es ist ein Produkt, von dem man leicht drei hat, ohne es entschieden zu haben. Zählen Sie Ihre.

Wenn Ihre EC2-Other-Zeile größer ist als Ihre EC2-Zeile, sagen wir Ihnen an einem Nachmittag, warum.