NAT Gateway vs. NAT Instance auf AWS: Was passt für deine private Infrastruktur?

Private EC2-Instanzen brauchen gelegentlich ausgehenden Internetzugang — für Paket-Updates, externe API-Aufrufe oder das Herunterladen von Abhängigkeiten. Die Frage, die dabei fast immer auftaucht: Soll ich den verwalteten NAT Gateway von AWS nutzen, oder betreibe ich lieber eine eigene NAT-Instanz auf EC2? Beide Wege funktionieren, aber sie unterscheiden sich fundamental in Betrieb, Kosten und Fehlerverhalten.

TL;DR: NAT Gateway vs. NAT Instance

Kriterium NAT Gateway NAT Instance
Verwaltung Vollständig von AWS verwaltet Selbst verantwortlich (Patching, HA, Monitoring)
Hochverfügbarkeit Innerhalb einer AZ redundant; für Multi-AZ: je eine pro AZ Manuell konfigurieren (Auto Scaling, Failover-Skripte)
Durchsatz Skaliert automatisch bis zu dokumentierten Limits Begrenzt durch Instanztyp und Netzwerkbandbreite
Security Groups Nicht anwendbar Konfigurierbar — bietet feinere Kontrolle
Port Forwarding / Bastion Nicht unterstützt Möglich (iptables, SSH-Forwarding)
Kosten Stundengebühr + Datenverarbeitungsgebühr EC2-Instanzkosten (ggf. günstiger bei geringem Traffic)
Empfehlung ✅ Produktionsumgebungen, Standardfall Nur bei sehr spezifischen Anforderungen oder Kostendruck

Wie NAT auf AWS funktioniert — das Fundament

Instanzen in einem privaten Subnetz haben keine öffentliche IP-Adresse und keine direkte Route ins Internet. Damit ausgehende Verbindungen trotzdem funktionieren, braucht es eine Komponente im öffentlichen Subnetz, die das Source-NAT (SNAT) übernimmt: Sie ersetzt die private Quell-IP durch eine öffentliche IP, leitet das Paket ins Internet weiter und mappt die Antwort zurück an die ursprüngliche Instanz.

Sowohl NAT Gateway als auch NAT Instance erfüllen diese Aufgabe — aber auf sehr unterschiedliche Weise. Der NAT Gateway ist ein verwalteter AWS-Service, der im öffentlichen Subnetz sitzt und eine Elastic IP nutzt. Die NAT Instance ist eine reguläre EC2-Instanz, auf der IP-Masquerading aktiviert ist und bei der Source/Destination Check deaktiviert sein muss.

graph LR PrivInst["Private EC2-Instanz
10.0.1.5"] PrivRT["Private Route-Table
0.0.0.0/0 → NAT"] NAT["NAT Gateway / NAT Instance
Öffentliches Subnetz + EIP"] IGW["Internet Gateway"] Internet["Internet
z.B. apt-Repository"] PrivInst -->|"Paket: src=10.0.1.5"| PrivRT PrivRT --> NAT NAT -->|"SNAT: src=EIP"| IGW IGW --> Internet Internet -->|"Antwort an EIP"| IGW IGW --> NAT NAT -->|"Zurück an 10.0.1.5"| PrivInst
  1. Private Instanz sendet ein Paket an eine externe Adresse (z.B. apt-Repository).
  2. Die Route-Table des privaten Subnetzes leitet 0.0.0.0/0 an das NAT-Gerät (Gateway oder Instanz) im öffentlichen Subnetz.
  3. Das NAT-Gerät ersetzt die Quell-IP durch seine eigene Elastic IP und sendet das Paket über das Internet Gateway ins Internet.
  4. Die Antwort kommt zurück, das NAT-Gerät mappt sie auf die ursprüngliche private IP und leitet sie weiter.

NAT Gateway: Der verwaltete Standardweg

Der NAT Gateway ist die von AWS empfohlene Lösung für die meisten Produktionsumgebungen. Er wird im öffentlichen Subnetz erstellt, bekommt eine Elastic IP zugewiesen und ist danach einsatzbereit — kein OS-Patching, keine Failover-Konfiguration, kein Monitoring des Prozesses selbst.

NAT Gateway erstellen (CLI)

# Elastic IP allozieren
aws ec2 allocate-address \
  --domain vpc \
  --region us-east-1

# NAT Gateway im öffentlichen Subnetz erstellen
aws ec2 create-nat-gateway \
  --subnet-id subnet-0abc123456789def0 \
  --allocation-id eipalloc-0abc123456789def0 \
  --region us-east-1

# Route in der privaten Route-Table setzen
aws ec2 create-route \
  --route-table-id rtb-0abc123456789def0 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0abc123456789def0 \
  --region us-east-1

Was du wissen musst — jenseits der Dokumentation

Ein NAT Gateway ist AZ-spezifisch. Das steht in der Dokumentation, wird aber in der Praxis regelmäßig falsch konfiguriert: Ein einzelner NAT Gateway in us-east-1a leitet Traffic aus us-east-1b über AZ-Grenzen — das erzeugt Datenübertragungskosten zwischen AZs und einen Single Point of Failure für Instanzen in anderen AZs.

Stell dir vor, du hast eine Autobahn (NAT Gateway) in einer Stadt (AZ), aber alle Autos aus der Nachbarstadt müssen erst rüberfahren, bevor sie auf die Autobahn dürfen. Das kostet Zeit und Maut — und wenn die Brücke gesperrt ist, kommt niemand mehr durch.

Die korrekte Architektur für Multi-AZ-Umgebungen: Ein NAT Gateway pro AZ, jedes mit eigener Elastic IP, und jede private Route-Table zeigt auf den NAT Gateway in der eigenen AZ.

graph TD subgraph AZ_A["Availability Zone A"] PubA["Öffentliches Subnetz A"] NATGW_A["NAT Gateway A
EIP-A"] PrivA["Privates Subnetz A
Route: 0.0.0.0/0 → NATGW-A"] end subgraph AZ_B["Availability Zone B"] PubB["Öffentliches Subnetz B"] NATGW_B["NAT Gateway B
EIP-B"] PrivB["Privates Subnetz B
Route: 0.0.0.0/0 → NATGW-B"] end IGW["Internet Gateway"] PrivA --> NATGW_A NATGW_A --> IGW PrivB --> NATGW_B NATGW_B --> IGW IGW --> Internet["Internet"]
  1. Jede AZ hat ein öffentliches und ein privates Subnetz.
  2. Der NAT Gateway sitzt im öffentlichen Subnetz der jeweiligen AZ.
  3. Die Route-Table des privaten Subnetzes zeigt ausschließlich auf den lokalen NAT Gateway — kein AZ-übergreifender Traffic.
  4. Fällt eine AZ aus, sind nur die Instanzen dieser AZ betroffen. Die anderen AZs funktionieren unabhängig weiter.

Kosten im Blick behalten

NAT Gateway berechnet eine Stundengebühr für die Existenz des Gateways sowie eine Gebühr pro verarbeitetem Gigabyte. Bei hohem ausgehendem Traffic kann das schnell teuer werden. Preise und aktuelle Limits: AWS VPC Pricing.

Eine oft übersehene Optimierung: Wenn deine Instanzen häufig auf S3 oder DynamoDB zugreifen, leite diesen Traffic über einen VPC Gateway Endpoint — der ist kostenlos und umgeht den NAT Gateway vollständig.

# VPC Endpoint für S3 erstellen (kein NAT-Traffic für S3)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123456789def0 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0abc123456789def0 \
  --region us-east-1

NAT Instance: Mehr Kontrolle, mehr Aufwand

Eine NAT Instance ist eine EC2-Instanz, die als NAT-Router konfiguriert ist. AWS stellt dafür Community-AMIs bereit, aber du kannst auch jede Amazon Linux 2-Instanz manuell konfigurieren. Der entscheidende Unterschied: Du bist für alles verantwortlich — Verfügbarkeit, Patches, Monitoring, Skalierung.

Wann eine NAT Instance sinnvoll ist

Es gibt legitime Gründe, eine NAT Instance zu wählen:

  • Port Forwarding: Du brauchst eingehende Verbindungen auf spezifische interne Hosts (z.B. Bastion-Funktionalität kombiniert mit NAT).
  • Security Groups auf NAT-Ebene: Du willst ausgehenden Traffic auf Instanzebene mit Security Groups filtern — NAT Gateway unterstützt das nicht.
  • Sehr geringer Traffic, Kostendruck: Eine kleine t3.nano-Instanz kann günstiger sein als die Stundengebühr eines NAT Gateways bei minimalem Durchsatz.

NAT Instance konfigurieren

Die kritische Einstellung, die gerne vergessen wird: Source/Destination Check muss deaktiviert sein. Standardmäßig verwirft eine EC2-Instanz Pakete, bei denen sie weder Quelle noch Ziel ist. Für NAT-Funktionalität muss genau das erlaubt werden.

# Source/Destination Check deaktivieren
aws ec2 modify-instance-attribute \
  --instance-id i-0abc123456789def0 \
  --no-source-dest-check \
  --region us-east-1

# IP-Forwarding und Masquerading auf der Instanz aktivieren (als root)
echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
sysctl -p

# iptables MASQUERADE-Regel für ausgehenden Traffic
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Regel persistent speichern (Amazon Linux 2)
service iptables save

Das Hochverfügbarkeitsproblem

Hier liegt der eigentliche Betriebsaufwand. Fällt die NAT Instance aus, verlieren alle privaten Instanzen ihren Internetzugang — ohne automatisches Failover. Du musst selbst eine Lösung bauen: Auto Scaling Group mit einem Skript, das beim Launch die Route-Table aktualisiert, oder eine aktiv-passiv-Konfiguration mit Health Checks.

graph TD PrivInst["Private Instanzen"] PrimNAT["Primäre NAT Instance
Route-Table zeigt hierher"] HC["Health Check
CloudWatch Alarm"] ASG["Auto Scaling Group"] NewNAT["Neue NAT Instance
User Data: Route-Table Update"] PrivInst -->|"Ausgehender Traffic"| PrimNAT PrimNAT -->|"Instanz fällt aus"| HC HC -->|"Alarm ausgelöst"| ASG ASG -->|"Neue Instanz startet"| NewNAT NewNAT -->|"Route-Table aktualisiert"| PrivInst
  1. Die primäre NAT Instance läuft im öffentlichen Subnetz und bedient den ausgehenden Traffic.
  2. Ein Health Check (z.B. CloudWatch Alarm + Lambda) überwacht die Instanz.
  3. Fällt die primäre Instanz aus, startet die Auto Scaling Group eine neue Instanz.
  4. Ein Skript im User Data oder ein Lambda-Trigger aktualisiert die Route-Table, um auf die neue Instanz zu zeigen.
  5. Während dieser Zeit — typischerweise mehrere Minuten — ist kein ausgehender Traffic möglich.

Das ist lösbar, aber es ist echte Arbeit. Und es ist Arbeit, die du bei einem NAT Gateway nicht hast.

Entscheidungsbaum: Was passt zu deinem Use Case?

graph TD Start(["Brauchst du ausgehenden
Internetzugang für private Instanzen?"]) Q1{"Benötigst du Port Forwarding
oder Bastion-Funktionalität?"} Q2{"Benötigst du Security Groups
auf NAT-Ebene?"} Q3{"Sehr geringer Traffic und
extremer Kostendruck?"} NATGW["✅ NAT Gateway
Empfohlen"] NATINST["⚙️ NAT Instance
Mit eigenem Betriebsaufwand"] Start --> Q1 Q1 -->|"Ja"| NATINST Q1 -->|"Nein"| Q2 Q2 -->|"Ja"| NATINST Q2 -->|"Nein"| Q3 Q3 -->|"Ja"| NATINST Q3 -->|"Nein"| NATGW

IAM-Berechtigungen für NAT Gateway Management

Wer NAT Gateways per CLI oder IaC verwaltet, braucht die entsprechenden EC2-Berechtigungen. Hier ein Beispiel für eine Least-Privilege-Policy:

🔽 IAM Policy für NAT Gateway Management (klicken zum Öffnen) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NATGatewayManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNatGateway",
        "ec2:DeleteNatGateway",
        "ec2:DescribeNatGateways",
        "ec2:AllocateAddress",
        "ec2:ReleaseAddress",
        "ec2:DescribeAddresses",
        "ec2:CreateRoute",
        "ec2:ReplaceRoute",
        "ec2:DescribeRouteTables"
      ],
      "Resource": "*"
    }
  ]
}

Hinweis: DescribeNatGateways, DescribeAddresses und DescribeRouteTables unterstützen keine ressourcenbasierte Einschränkung — "Resource": "*" ist hier erforderlich. Überprüfe die aktuellen Einschränkungen im AWS Service Authorization Reference.

Erfahrung aus der Praxis: Der stille Kostenblock

Symptom: Die AWS-Rechnung steigt unerwartet. CloudWatch zeigt keinen auffälligen Traffic-Anstieg. Der NAT Gateway läuft seit Monaten stabil.

Fehldiagnose: Irgendeine Instanz muss plötzlich mehr Traffic erzeugen. Also werden Instanz-Metriken durchforstet — ohne Ergebnis.

Tatsächliche Ursache: S3-Traffic läuft über den NAT Gateway, obwohl ein VPC Endpoint vorhanden ist. Warum? Weil der Endpoint nur in einer Route-Table eingetragen war — nicht in allen privaten Route-Tables. Instanzen in anderen Subnetzen nutzten weiterhin den NAT Gateway für S3-Zugriffe.

Fix: Alle privaten Route-Tables prüfen und den S3-Endpoint-Eintrag in jeder Tabelle ergänzen.

# Alle Route-Tables in der VPC auflisten
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0abc123456789def0 \
  --query 'RouteTables[*].{ID:RouteTableId,Routes:Routes}' \
  --region us-east-1

# VPC Endpoint-Routen für fehlende Route-Tables ergänzen
aws ec2 modify-vpc-endpoint \
  --vpc-endpoint-id vpce-0abc123456789def0 \
  --add-route-table-ids rtb-0abc123456789def0 \
  --region us-east-1

Der Endpoint war vorhanden — er war nur nicht überall aktiv. Das ist der Unterschied zwischen 'konfiguriert' und 'wirksam'.

NAT Gateway vs. NAT Instance: Abschluss und nächste Schritte

Für die meisten Produktionsumgebungen ist der NAT Gateway die richtige Wahl: kein Betriebsaufwand, automatische Skalierung, keine Failover-Logik. Die NAT Instance bleibt relevant, wenn du Port Forwarding, Security-Group-Filterung auf NAT-Ebene oder extreme Kostenkontrolle bei minimalem Traffic brauchst.

Was du als nächstes tun solltest:

  • Prüfe, ob du VPC Gateway Endpoints für S3 und DynamoDB nutzt — das spart sofort NAT-Gateway-Kosten.
  • Stelle sicher, dass du in Multi-AZ-Setups einen NAT Gateway pro AZ hast.
  • Wenn du eine NAT Instance betreibst: Dokumentiere dein Failover-Verfahren und teste es.

Weiterführende Dokumentation: AWS NAT Gateway Dokumentation | NAT Instance Dokumentation

Glossar

Begriff Bedeutung
SNAT (Source NAT) Netzwerktechnik, bei der die Quell-IP-Adresse eines Pakets durch eine andere ersetzt wird — hier: private IP → öffentliche Elastic IP.
Elastic IP (EIP) Statische, öffentliche IPv4-Adresse in AWS, die einem NAT Gateway oder einer EC2-Instanz zugewiesen werden kann.
Source/Destination Check AWS-Sicherheitsmechanismus auf EC2-Ebene: Pakete werden verworfen, wenn die Instanz weder Quelle noch Ziel ist. Muss für NAT Instances deaktiviert werden.
VPC Gateway Endpoint Privater Verbindungspunkt für S3 und DynamoDB innerhalb der VPC — ohne Nutzung von NAT Gateway oder Internet Gateway.
Route Table Regelsatz in AWS VPC, der bestimmt, wohin Netzwerkpakete aus einem Subnetz weitergeleitet werden.

Related Posts

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

EC2 ohne Internetzugang im eigenen VPC – Internet Gateway und Route Table korrekt einrichten

Du hast ein eigenes VPC erstellt, eine EC2-Instanz in einem öffentlichen Subnetz gestartet – und ping google.com läuft ins Leere. Kein Timeout-Fehler, keine Fehlermeldung, einfach nichts. Dieses Problem tritt fast immer auf, wenn ein Custom VPC ohne Internet Gateway oder mit einer unvollständigen Route-Table-Konfiguration aufgesetzt wird, weil AWS bei eigenen VPCs bewusst keine Standard-Internetverbindung mitliefert. TL;DR – EC2 Internetzugang im Custom VPC Schritt Aktion Warum notwendig 1 Internet Gateway erstellen und an VPC anhängen Ohne IGW gibt es keinen Pfad ins öffentliche Internet 2 Route Table aktualisieren (0.0.0.0/0 → IGW) Der Traffic muss explizit über das IGW geroutet werden 3 Subnetz mit Route Table verknüpfen Eine Route Table ohne Subnetz-Assoziation hat keine Wirkung 4 Öffentliche IP oder Elastic IP prüfen Ohne öffentliche IP kann das IGW keinen eingehenden Rückpfad aufbauen 5 Securi...
Mehr anzeigen

LSI vs. GSI in DynamoDB: Den richtigen Sekundärindex wählen

Man hat eine DynamoDB-Tabelle aufgebaut, die Abfragen über den Primärschlüssel laufen schnell — und dann kommt die Anforderung, dieselben Daten nach einem anderen Attribut zu filtern. Genau hier beginnt die Entscheidung zwischen einem Local Secondary Index (LSI) und einem Global Secondary Index (GSI) , und wer sie falsch trifft, zahlt entweder mit Flexibilitätsverlust oder mit unerwartetem Durchsatz-Overhead. TL;DR: LSI vs. GSI auf einen Blick Merkmal LSI GSI Erstellungszeitpunkt Nur bei Tabellenerstellung Jederzeit Partition Key Identisch mit Basistabelle Beliebiges Attribut Sort Key Anderes Attribut als Basistabelle Beliebiges Attribut (optional) Konsistenzmodell Strongly consistent möglich Nur eventually consistent Kapazität Teilt RCU/WCU mit Basistabelle Eigene RCU/WCU (Provisioned) oder On-Demand Datenmenge pro Partition Key Max. 10 GB Unbegrenzt Max. Anzahl pro Tabelle 5 20 (Standard...
Mehr anzeigen

ElastiCache Redis einsetzen: Wann ein Caching-Layer deine RDS-Datenbank entlastet

Du hast die Abfragen optimiert, Indizes gesetzt, Read Replicas hinzugefügt — und der RDS-Endpunkt ist immer noch der Engpass. Das passiert fast immer dann, wenn dieselben Zeilen hunderte Male pro Sekunde gelesen werden und jede Anfrage trotzdem den vollen Datenbankpfad durchläuft. Ein ElastiCache Redis-Layer löst genau dieses Problem, indem er häufig gelesene Ergebnisse im Arbeitsspeicher hält und RDS damit aus der kritischen Anfragekette herausnimmt. TL;DR: ElastiCache Redis als Caching-Layer vor RDS Aspekt Ohne Cache Mit ElastiCache Redis Lesepfad App → RDS (Disk/Buffer Pool) App → Redis (RAM) → RDS nur bei Cache Miss Latenz (typisch) Einige Millisekunden bis Dutzende ms Unter 1 ms bei Cache Hit RDS-Last bei hohem Traffic Linear steigend Deutlich reduziert bei hoher Hit-Rate Datenkonsistenz Immer aktuell Abhängig von TTL und Invalidierungsstrategie Operativer Aufwand Gering Mittel (Cache-Strategie,...
Mehr anzeigen