Ausgehender Zugriff für ein privates AWS-Subnetz mit NAT

Einführung

Eine Lieferanwendung läuft in einem privaten Subnetz und muss einen externen Dienst erreichen, ohne eine öffentliche Adresse zu erhalten. Du erstellst ein öffentliches NAT-Gateway, ergänzt die ausgehende Route und beobachtest mit echten HTTP-Anfragen die Quelladressübersetzung und die Grenze gegenüber unaufgeforderten eingehenden Verbindungen.

Schließe zunächst Control Application Access with Security Groups ab. Diese neue Umgebung stellt eine eigene Anwendung, öffentliche und private Subnetze, eine öffentliche Internetroute und Sicherheitsregeln bereit. Die CLI ist bereits eingerichtet. Bewahre diese Ressourcen und das unbeteiligte Referenznetz; erstelle und lösche später nur dein NAT-Gateway, seine Elastic-IP-Adresse und die private Standardroute.

Bezug zu Zertifizierungen

Dieses Lab bietet praktische Übungen zu folgenden Prüfungsthemen.

Cloud Practitioner (CLF-C02) · Aufgabe 3.5: Rollen von Subnetzen und Gateways in einer VPC.
Solutions Architect – Associate (SAA-C03) · Aufgabe 1.2: Grundlegende Trennung öffentlicher und privater Subnetze mit Routingtabellen und NAT.
CloudOps Engineer – Associate (SOA-C03) · Aufgaben 5.1 und 5.3: NAT konfigurieren und eine fehlende Route im privaten Subnetz diagnostizieren.
Advanced Networking – Specialty (ANS-C01) · Aufgabe 3.1: Grundlagenübung zum Pflegen einer statischen VPC-Route und Prüfen ihrer Auswirkungen auf die Verbindung.

Private Anwendung untersuchen und NAT-Adresse reservieren

Du untersuchst das bereitgestellte Netz, beobachtest den fehlenden ausgehenden Pfad und reservierst eine Adresse für dein künftiges NAT-Gateway.

Verwende Terminal für die CLI-Befehle und öffne daneben AWS View. Die Ansicht liest denselben Ressourcenstand. Die Anwendung hat die private IPv4-Adresse 10.20.2.10 in private-subnet, nicht in public-subnet.

cd /home/labex/project

Wähle die Anwendungs-VPC über ihr Name-Tag. --filters beschränkt die Ergebnisse, --query wählt die ID und $(...) speichert sie in einer Shellvariable:

VPC_ID=$(aws ec2 describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[0].VpcId' \
  --output text)

Wähle das öffentliche Subnetz dieser VPC. Dort erhält das NAT-Gateway einen Internetpfad:

PUBLIC_SUBNET_ID=$(aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=public-subnet \
  --query 'Subnets[0].SubnetId' \
  --output text)

Wähle die vorhandene Routingtabelle des privaten Subnetzes. Du änderst ihre Standardroute und behältst die bestehende Subnetzzuordnung bei:

PRIVATE_RT_ID=$(aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=private-routes \
  --query 'RouteTables[0].RouteTableId' \
  --output text)

Untersuche beide bereitgestellten Routingtabellen. Die Projektion nach []. wählt lesbare Felder für jede Tabelle:

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'RouteTables[].{Name:Tags[?Key==`Name`].Value|[0],Routes:Routes,Associations:Associations}' \
  --output json

Beide benannten Tabellen enthalten die local-Route der VPC. Eine unbenannte Haupttabelle kann ebenfalls erscheinen; ändere sie nicht. Die benannten Tabellen sind ausdrücklich den Subnetzen zugeordnet, daher verwendest du die ausgewählte Tabelle private-routes. Die öffentliche Tabelle leitet außerdem 0.0.0.0/0 an ein Internet-Gateway; die private Tabelle besitzt keine Standardroute. Ein privates Subnetz hat keine direkte Route zum Internet-Gateway. Ein öffentliches NAT-Gateway lässt private Anwendungen IPv4-Verbindungen mit seiner öffentlichen Adresse beginnen. Es gehört in das öffentliche Subnetz, dessen eigene Internetroute bereits bereitsteht.

Klicke in AWS View auf Request outbound service. Die HTTP-Anfrage der privaten Anwendung liefert Connection failed: Es fehlt eine Route zum externen Dienst 198.51.100.20:9000. Klicke auf Request private application from outside; diese unaufgeforderte HTTP-Anfrage an 10.20.2.10:80 scheitert ebenfalls. Die Anwendung behält ihre private Adresse.

Eine Elastic-IP-Adresse ist eine reservierte öffentliche IPv4-Adresse. Reserviere eine in der VPC-Domäne und versehe sie mit Tags, um die Übungsressource zu erkennen. Der in Anführungszeichen stehende Wert von --tag-specifications ist ein einzelnes Argument für Ressourcentyp und Tags:

ALLOCATION_ID=$(aws ec2 allocate-address \
  --domain vpc \
  --tag-specifications 'ResourceType=elastic-ip,Tags=[{Key=Name,Value=parcel-nat-address},{Key=Project,Value=parcel}]' \
  --query 'AllocationId' \
  --output text)

Lies die reservierte Adresse aus:

aws ec2 describe-addresses \
  --allocation-ids "$ALLOCATION_ID" \
  --query 'Addresses[].{Allocation:AllocationId,PublicIP:PublicIp,Domain:Domain}' \
  --output table

Das Ergebnis enthält eine Reservierungs-ID, eine öffentliche IPv4-Adresse und die Domäne vpc. Notiere die öffentliche Adresse für den späteren Verkehrsvergleich. Sie gehört zum künftigen NAT-Gateway; ordne sie nicht der Anwendung zu. Lass dieses Terminal geöffnet, damit die gespeicherten IDs erhalten bleiben.

Öffentliches NAT-Gateway erstellen

Du platzierst NAT im öffentlichen Subnetz und prüfst, dass das Erstellen allein keine Route für die private Anwendung einrichtet.

NAT benötigt zwei vorhandene Ressourcen: das öffentliche Subnetz und die reservierte Elastic IP. --subnet-id wählt den Standort, --allocation-id die öffentliche Adresse und --connectivity-type public ein Gateway für Internetverkehr. Der Ressourcentyp natgateway setzt die Eigentums-Tags. Speichere die erzeugte ID:

NAT_ID=$(aws ec2 create-nat-gateway \
  --subnet-id "$PUBLIC_SUBNET_ID" \
  --allocation-id "$ALLOCATION_ID" \
  --connectivity-type public \
  --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=parcel-nat},{Key=Project,Value=parcel}]' \
  --query 'NatGateway.NatGatewayId' \
  --output text)

Die Erstellung kann zurückkehren, bevor das Gateway bereit ist. Ein CLI-Waiter liest den Status wiederholt, bis die benannte Bedingung erfüllt ist. Warte vor dem Hinzufügen einer Route auf available:

aws ec2 wait nat-gateway-available --nat-gateway-ids "$NAT_ID"

Ein erfolgreicher Waiter endet ohne Ausgabe. Lies Status, Subnetz und Adresszuordnung:

aws ec2 describe-nat-gateways \
  --nat-gateway-ids "$NAT_ID" \
  --query 'NatGateways[].{ID:NatGatewayId,State:State,Subnet:SubnetId,Addresses:NatGatewayAddresses}' \
  --output json

State ist available, Subnet entspricht deinem öffentlichen Subnetz und NatGatewayAddresses enthält Reservierungs-ID und öffentliche Adresse. PrivateIp liegt im öffentlichen Subnetzbereich 10.20.1.0/24; dies ist die private Adresse der NAT-Schnittstelle, getrennt von Elastic IP und Anwendungsadresse. NAT ist eine eigene Ressource; die private Anwendung hat diese Adresse nicht erhalten.

AWS View zeigt nun NAT. Klicke erneut auf Request outbound service. Die Anfrage scheitert weiterhin, weil der privaten Routingtabelle eine Standardroute fehlt. Das Gateway bietet einen möglichen nächsten Hop, wählt ihn aber nicht automatisch für das private Subnetz. Die vorhandene öffentliche Internet-Gateway-Route bleibt unverändert.

Privaten ausgehenden Verkehr über NAT routen

Du ergänzt die private Standardroute und vergleichst die private Anwendungsadresse mit der vom externen Dienst beobachteten Quelladresse.

Eine Route wählt den nächsten Hop für einen Zielbereich. 0.0.0.0/0 gilt für IPv4-Ziele, die keiner spezifischeren Route entsprechen. --nat-gateway-id wählt dein NAT anstelle des Internet-Gateways. Füge diese Route ausschließlich der gespeicherten privaten Tabelle hinzu:

aws ec2 create-route \
  --route-table-id "$PRIVATE_RT_ID" \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id "$NAT_ID"

Die Antwort bestätigt die Erstellung. Lies die Routen der privaten Tabelle:

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

Die lokale Route bleibt bestehen. Die neue Standardroute hat deine NatGatewayId und den Status active. Pakete nehmen nun diesen Weg: private Anwendung → NAT im öffentlichen Subnetz → Internet-Gateway → externer Dienst.

Sobald AWS View die private Standardroute zeigt, klicke auf Request outbound service. Die Antwort lautet Success. Ihr Inhalt ist die tatsächlich vom externen HTTP-Dienst beobachtete IPv4-Quelladresse. Vergleiche sie mit deiner reservierten öffentlichen Adresse:

aws ec2 describe-addresses \
  --allocation-ids "$ALLOCATION_ID" \
  --query 'Addresses[0].PublicIp' \
  --output text

Beide Adressen stimmen überein. Network Address Translation (NAT) ersetzt die private Quelladresse der Anwendung durch die öffentliche Gateway-Adresse und verfolgt die Verbindung, damit die Antwort den Initiator erreicht. Die eigene Anwendungsadresse bleibt 10.20.2.10.

Die private Anwendung erreicht den externen Dienst über ihre NAT-Route

Beispiel in AWS View: Die Anwendung bleibt unter 10.20.2.10, die private Standardroute wählt das verfügbare NAT-Gateway und die HTTP-Antwort nennt die reservierte öffentliche Adresse. Erzeugte Ressourcen-IDs und Adressen können abweichen.

Klicke auf Request private application from outside. Die Antwort bleibt Connection failed. Ausgehende Verbindungen und ihre Antworten erzeugen keinen öffentlichen eingehenden Pfad zur privaten Anwendung. NAT nimmt keine unaufgeforderte Internetverbindung für diese Anwendung an.

Fehlende private Route diagnostizieren und wiederherstellen

Du entfernst eine Route, beobachtest den Fehler und stellst die Verbindung ohne erneutes Erstellen von NAT wieder her.

Ein Gateway kann verfügbar sein, obwohl sein Client keine nutzbare Route hat. Lösche nur die private Standardroute; bewahre NAT und die öffentliche Internetroute:

aws ec2 delete-route --route-table-id "$PRIVATE_RT_ID" --destination-cidr-block 0.0.0.0/0

Erfolgreiches Löschen erzeugt keine Ausgabe. Untersuche die private Tabelle:

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

Nur die lokale VPC-Route bleibt. AWS View zeigt weiterhin das verfügbare NAT-Gateway, aber keine private Standardroute. Klicke auf Request outbound service; die neue Anfrage scheitert. Ein früherer Erfolg ist ein historisches Ergebnis, nicht das Ergebnis dieser neuen Anfrage.

Stelle dieselbe Route zum selben Gateway wieder her:

aws ec2 create-route \
  --route-table-id "$PRIVATE_RT_ID" \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id "$NAT_ID"

Lies die Routen erneut:

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

Die aktive Standardroute erscheint wieder. Sende in AWS View eine neue Request outbound service; sie gelingt und zeigt dieselbe öffentliche NAT-Adresse. Request private application from outside scheitert weiterhin. So unterscheidest du ein verfügbares Gateway von einem vollständigen Routingpfad des Clients.

NAT-Übungspfad löschen und seine Adresse freigeben

Du entfernst deine Route und NAT, gibst die öffentliche Adresse frei und belegst, dass das bereitgestellte private Netz intakt bleibt.

Lösche die private Standardroute vor ihrem nächsten Hop. Sonst kann die Tabelle eine Route zu einem gelöschten Gateway behalten:

aws ec2 delete-route --route-table-id "$PRIVATE_RT_ID" --destination-cidr-block 0.0.0.0/0

Erfolgreiches Löschen erzeugt keine Ausgabe. Lösche nur dein NAT-Gateway:

aws ec2 delete-nat-gateway --nat-gateway-id "$NAT_ID"

Die Antwort identifiziert das angeforderte Gateway. Verwende vor der Adressfreigabe den Lösch-Waiter:

aws ec2 wait nat-gateway-deleted --nat-gateway-ids "$NAT_ID"

Der erfolgreiche Waiter endet ohne Ausgabe. Das Löschen von NAT entfernt seine Netzwerkschnittstelle und hebt die Elastic-IP-Zuordnung auf, gibt aber die Reservierung nicht frei. Lies die Adresse vor der Freigabe:

aws ec2 describe-addresses \
  --allocation-ids "$ALLOCATION_ID" \
  --query 'Addresses[].{Allocation:AllocationId,PublicIP:PublicIp,Association:AssociationId}' \
  --output json

Reservierung und öffentliche Adresse bleiben bestehen, während Association den Wert null hat: Die Adresse ist reserviert, aber nicht mehr zugeordnet. Gib nun diese getrennte Ressource frei:

aws ec2 release-address --allocation-id "$ALLOCATION_ID"

Erfolgreiches Freigeben erzeugt keine Ausgabe. Lies den vollständigen Gateway-Bestand statt nur entfernbarer Tags:

aws ec2 describe-nat-gateways \
  --query 'NatGateways[].{ID:NatGatewayId,State:State,Subnet:SubnetId}' \
  --output table

Dein Gateway kann mit Status deleted weiterhin aufgeführt sein; kein Übungs-Gateway darf aktiv sein. Ein gespeicherter Löschdatensatz bedeutet nicht, dass das Gateway noch Verkehr weiterleiten kann. Prüfe den gesamten Adressbestand:

aws ec2 describe-addresses \
  --query 'Addresses[].{Allocation:AllocationId,PublicIP:PublicIp}' \
  --output table

Die Übungsreservierung fehlt. Lies jetzt die privaten Routen:

aws ec2 describe-route-tables \
  --route-table-ids "$PRIVATE_RT_ID" \
  --query 'RouteTables[].Routes' \
  --output json

Die lokale VPC-Route bleibt, die Standardroute fehlt. Die bereitgestellte Anwendung, Subnetze, Sicherheitsregeln, das öffentliche Internet-Gateway und das Referenznetz bleiben erhalten. Eine fehlgeschlagene Bestandsabfrage beweist kein Löschen.

Klicke in AWS View auf Request outbound service; sie scheitert wieder, weil du den NAT-Pfad bewusst entfernt hast. Request private application from outside bleibt blockiert. Diese Ergebnisse entsprechen dem ursprünglichen privaten Netzwerkzustand.

Führen Sie die Abschlussprüfung dieses Schritts aus.

Zusammenfassung

Du hast eine öffentliche Adresse reserviert, NAT im öffentlichen Subnetz platziert und die ausgehenden Anfragen einer privaten Anwendung darüber geroutet. Der externe Dienst sah die übersetzte NAT-Adresse; unaufgeforderte eingehende Anfragen blieben blockiert. Das Entfernen und Wiederherstellen der privaten Standardroute zeigte, warum allein die Gateway-Verfügbarkeit keine Verbindung herstellt.

Danach hast du Route und NAT entfernt, die Adresse freigegeben und den bewahrten privaten Netzwerkzustand geprüft.

Einem privaten Subnetz ausgehenden Zugriff geben