NAT-Gateway und private Subnetze

Ressourcen in privaten Subnetzen verfügen nur über private IP-Adressen und haben keine Route zu einem Internet Gateway. Daher können sie keine ausgehenden Verbindungen zum Internet initiieren. Häufig müssen sie jedoch das Internet erreichen: um Betriebssystem-Patches herunterzuladen, Docker-Images abzurufen, Drittanbieter-APIs aufzurufen oder Software zu aktualisieren. Die Lösung besteht darin, den Datenverkehr privater Subnetze über ein Gerät zu leiten, das Internetzugriff hat und NAT (Network Address Translation) durchführt, wobei die privaten IP-Adressen hinter einer öffentlichen IP-Adresse verborgen werden. AWS bietet zwei Optionen: das verwaltete NAT Gateway und eine selbst verwaltete NAT Instance (veraltet).

Ein NAT Gateway ist ein vollständig verwalteter, hochverfügbarer Service, der es Instances in privaten Subnetzen ermöglicht, ausgehende Verbindungen zum Internet zu initiieren, während unaufgeforderter eingehender Datenverkehr blockiert wird. Es befindet sich in einem öffentlichen Subnetz, verfügt über eine Elastic IP und skaliert automatisch auf eine Bandbreite von bis zu 100 Gbit/s. Sie müssen die zugrunde liegende Infrastruktur weder patchen noch skalieren oder verwalten. Das NAT Gateway übersetzt die private Quell-IP-Adresse ausgehender Pakete in seine eigene EIP und leitet die Antworten anschließend an die ursprüngliche private IP-Adresse zurück.

Nachdem Sie ein NAT Gateway erstellt haben, fügen Sie der Routing-Tabelle des privaten Subnetzes eine Route hinzu: Ziel 0.0.0.0/0 → NAT Gateway-ID. Dadurch wird festgelegt, dass sämtlicher für das Internet bestimmter Traffic von Instances im privaten Subnetz an das NAT Gateway gesendet wird, das ihn anschließend über das Internet Gateway ins Internet weiterleitet. Die Routing-Tabelle enthält weiterhin die lokale VPC-Route (z. B. 10.0.0.0/16 → local) für internen Traffic. Ohne diesen Routeneintrag haben Instances im privaten Subnetz auch bei einem bereitgestellten NAT Gateway keinen Internetzugriff.

Ein NAT Gateway ist AZ-spezifisch – es verarbeitet nur Traffic von Subnetzen in derselben AZ. Für hohe Verfügbarkeit stellen Sie pro AZ ein NAT Gateway bereit und erstellen Sie AZ-spezifische Routing-Tabellen für private Subnetze: Die Routing-Tabelle des privaten Subnetzes in AZ-a leitet 0.0.0.0/0 an das NAT-Gateway in AZ-a weiter; die Routing-Tabelle des privaten Subnetzes in AZ-b leitet an das NAT-Gateway in AZ-b weiter. Dadurch vermeiden Sie Gebühren für den Datentransfer zwischen AZs und stellen sicher, dass die Instances in AZ-b mit ihrem eigenen NAT weiterhin Internetzugriff haben, falls AZ-a ausfällt.

Eine NAT Instance ist eine selbst verwaltete EC2-Instance, auf der ein NAT-AMI ausgeführt wird – der herkömmliche Ansatz aus der Zeit vor der Einführung von NAT Gateways. Bei NAT Instances müssen Sie: die Quell-/Zielprüfung der EC2-Instance deaktivieren, Bandbreite und Skalierung verwalten, das Betriebssystem patchen und Ausfälle behandeln. Sie sind für Anwendungsfälle mit sehr geringer Bandbreite günstiger und können als Bastion Hosts verwendet werden. NAT Gateways sind die empfohlene Wahl für Produktionsumgebungen: vollständig verwaltet, automatisch skaliert, mit einer Verfügbarkeits-SLA von 99,99 % innerhalb einer AZ und ohne erforderliches Patchen. Diese Gegenüberstellung wurde in der Prüfung in der Vergangenheit häufig abgefragt.

Die Preise für NAT Gateways bestehen aus zwei Komponenten: einer Stundengebühr pro NAT Gateway (etwa 0,045 USD/Stunde in us-east-1, ungefähr 32 USD/Monat) und einer Gebühr für die Datenverarbeitung pro GB (etwa 0,045 USD/GB in us-east-1). Bei Workloads, die große Datenmengen über NAT übertragen (z. B. beim Abrufen großer Container-Images oder bei umfangreichen Downloads), können die Kosten für die Datenverarbeitung den größten Anteil ausmachen. Optimieren Sie die NAT-Kosten, indem Sie den Traffic zu S3 und DynamoDB über VPC Gateway Endpoints leiten (umgeht NAT vollständig und ist kostenlos) und AWS-API-Aufrufe über VPC Interface Endpoints statt über NAT leiten.

Datenbank-Instances in privaten Subnetzen sollten nicht über das NAT Gateway routen – es gibt keinen Grund, warum sie Verbindungen ins Internet initiieren sollten. Datenbanken müssen nur Verbindungen von der Anwendungsschicht (innerhalb der VPC) empfangen und gegebenenfalls AWS-Services wie S3 (für Exporte/Importe) über einen VPC Endpoint erreichen. Für Patches und Updates der Datenbank ist RDS ein verwalteter Service, sodass Sie Betriebssystem-Patches nicht direkt anwenden. Verwenden Sie für selbst verwaltete Datenbanken auf EC2 den Systems Manager Patch Manager. Dieser kann über SSM patchen, ohne dass Internetzugriff erforderlich ist, sofern der SSM-VPC-Endpoint konfiguriert ist.

Ein NAT Gateway stellt ein zustandsbehaftetes NAT nur für ausgehenden Traffic bereit: Es lässt initiierte ausgehende Verbindungen und deren Antworten zu, blockiert jedoch alle nicht angeforderten eingehenden Verbindungen. Es ist keine Firewall und untersucht oder filtert keine Inhalte des Traffics. Für die Filterung ausgehenden Traffics (z. B. um aus privaten Subnetzen nur bestimmte Ziel-Domains oder -IPs zuzulassen) benötigen Sie zusätzliche Kontrollen: eine im VPC bereitgestellte AWS Network Firewall oder eine Firewall-Appliance eines Drittanbieters hinter einem Gateway Load Balancer. Security Groups und NACLs gelten unabhängig vom NAT weiterhin für Instances in privaten Subnetzen.

Neben öffentlichen NAT Gateways (mit EIPs für den Internetzugriff) unterstützt AWS private NAT Gateways ohne EIP. Private NAT Gateways werden verwendet, um private IP-Adressen für Traffic zwischen VPCs oder zwischen einer VPC und lokalen Netzwerken zu übersetzen, wenn sich CIDR-Bereiche überschneiden. Wenn beispielsweise VPC-A (10.0.0.0/16) mit einem lokalen Netzwerk kommunizieren muss, das ebenfalls 10.0.0.0/16 verwendet, übersetzt ein privates NAT Gateway in VPC-A die Quell-IPs in einen sich nicht überschneidenden Bereich, bevor der Traffic über ein Transit Gateway zum lokalen Netzwerk geroutet wird.

Überwachen Sie Zustand und Leistung des NAT Gateways mithilfe von CloudWatch-Metriken. Wichtige Metriken sind: ActiveConnectionCount (aktuell aktive TCP-Verbindungen über das NAT), BytesInFromDestination / BytesInFromSource (Datenübertragung in beide Richtungen), PacketDropCount (verworfene Pakete – weist auf Bandbreitenlimits oder Fehler hin) und ErrorPortAllocation (das NAT hat die Portzuweisungen ausgeschöpft – kann auf eine Erschöpfung der Ports durch zu viele Verbindungen hinweisen). Jedes NAT Gateway unterstützt bis zu 55.000 gleichzeitige Verbindungen pro eindeutigem Ziel. Darüber hinaus können Verbindungen verworfen werden.

Nicht alle Workloads in privaten Subnetzen benötigen ein NAT Gateway. Berücksichtigen Sie das Zugriffsmuster: Wenn Instances nur mit anderen VPC-Ressourcen und AWS-Services kommunizieren müssen, die über VPC Endpoints erreichbar sind (S3, DynamoDB, SSM, ECR, Secrets Manager), können Sie vollständig auf das NAT Gateway verzichten und dadurch etwa 32 USD/Monat pro AZ sowie Gebühren für die Datenverarbeitung einsparen. Dies ist das ideale Muster für vollständig private Microservices, die für den Zugriff auf alle AWS-Services VPC Interface Endpoints verwenden. Prüfen Sie jeden Service, den Ihre Instances aufrufen, und stellen Sie fest, ob ein kostenloser Gateway Endpoint oder ein kostenpflichtiger Interface Endpoint NAT ersetzen kann.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: NAT Gateways ermöglichen Instances in privaten Subnetzen den ausgehenden Internetzugriff, indem sie deren private IPs in eine Elastic IP übersetzen, Sie müssen in der Routing-Tabelle des privaten Subnetzes eine Route für 0.0.0.0/0 hinzufügen, die auf das NAT Gateway verweist, und Sie sollten pro AZ ein NAT Gateway bereitstellen, um hohe Verfügbarkeit zu erreichen und Gebühren für den Datentransfer zwischen AZs zu vermeiden. Als Nächstes vergleichen wir Network ACLs und Security Groups als mehrschichtige VPC-Verteidigung.