Einführung
Eine private Lieferanwendung liest ein S3-Manifest über NAT. Sie benötigt einen dienstbezogenen Weg ohne allgemeinen Internetzugriff. Sie erstellen einen S3-Gateway-Endpunkt, vergleichen echte Anfragen, untersuchen eine falsche Tabellenzuordnung und stellen das bereitgestellte Netz wieder her.
Schließen Sie zuerst Give a Private Subnet Outbound Access ab. Diese neue Umgebung stellt ihre eigene Anwendung, ein S3-Objekt, öffentliche und private Subnetze, NAT und Sicherheitsregeln bereit. Die CLI ist eingerichtet. Erhalten Sie diese Ressourcen und das Referenznetz. Erstellen und löschen Sie nur Ihren Endpunkt; stellen Sie die vorübergehend entfernte private NAT-Standardroute wieder her.
Bezug zu Zertifizierungen
Dieses Lab vermittelt Grundlagen zu folgenden Prüfungsthemen:
- Cloud Practitioner (CLF-C02) · Aufgabe 3.5: Funktionen von VPC-Gateways und privater Konnektivität.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 1.2: Grundlegender Dienstzugriff privater Anwendungen über Endpunkte und Routentabellen.
- CloudOps Engineer – Associate (SOA-C03) · Aufgaben 5.1 und 5.3: Endpunkte konfigurieren und Tabellenzuordnungen untersuchen.
- Advanced Networking – Specialty (ANS-C01) · Aufgabe 3.1: Grundlagen zur Pflege von Dienstrouten und Prüfung privater Konnektivität.
Einen S3-Gateway-Endpunkt für die private Anwendung erstellen
Sie prüfen zunächst den NAT-Weg, identifizieren S3-Adressbereiche und erstellen den Endpunkt für die private Tabelle.
Verwenden Sie Terminal und öffnen Sie daneben AWS View. Die Anwendung behält 10.20.2.10. Der bereitgestellte Bucket parcel-delivery-storage enthält message.txt mit Parcel manifest ready.
cd /home/labex/project
Wählen Sie die VPC anhand des Tags Name. Filter wählen Ressourcen, die Abfrage extrahiert die ID und $(...) speichert sie:
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Speichern Sie die private und öffentliche Tabellen-ID. Die Subnetzzuordnungen sind bereits korrekt:
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)
PUBLIC_RT_ID=$(aws ec2 describe-route-tables \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=public-routes \
--query 'RouteTables[0].RouteTableId' \
--output text)
Lesen Sie Routen und Zuordnungen:
aws ec2 describe-route-tables \
--route-table-ids "$PRIVATE_RT_ID" "$PUBLIC_RT_ID" \
--query 'RouteTables[].{ID:RouteTableId,Routes:Routes,Associations:Associations}' \
--output json
Die private Route 0.0.0.0/0 führt zu NAT, die öffentliche zum Internet-Gateway. Beide behalten local. Speichern Sie die NAT-ID für die spätere Wiederherstellung:
NAT_ID=$(aws ec2 describe-nat-gateways \
--filter "Name=vpc-id,Values=$VPC_ID" Name=state,Values=available \
--query 'NatGateways[0].NatGatewayId' \
--output text)
Lesen Sie die Adressen zum Vergleich mit Anfragen:
aws ec2 describe-nat-gateways \
--nat-gateway-ids "$NAT_ID" \
--query 'NatGateways[].{State:State,Addresses:NatGatewayAddresses}' \
--output json
Klicken Sie in AWS View auf Read storage object: Success und das Manifest erscheinen. Source address ist die öffentliche NAT-Adresse. Request outbound service gelingt mit derselben Adresse. Dieses Ausgangsverhalten stellen Sie später wieder her.
Eine von AWS verwaltete Präfixliste fasst die Dienstnetze einer Region zusammen. Ein S3-Gateway-Endpunkt ergänzt die zugeordneten Tabellen um eine Route zu dieser Liste; er vergibt keine öffentliche Anwendungsadresse und keinen allgemeinen Internetzugang. Wählen Sie die S3-Liste und lesen Sie ihre IPv4-Bereiche:
PREFIX_ID=$(aws ec2 describe-prefix-lists \
--filters Name=prefix-list-name,Values=com.amazonaws.us-east-1.s3 \
--query 'PrefixLists[0].PrefixListId' \
--output text)
aws ec2 get-managed-prefix-list-entries \
--prefix-list-id "$PREFIX_ID" \
--query 'Entries[].Cidr' \
--output json
Erstellen Sie den S3-Endpunkt für us-east-1, nur mit der privaten Tabelle. --vpc-endpoint-type Gateway wählt den routenbasierten Typ, --service-name den regionalen Dienst und --route-table-ids die Anwendungstabelle. Tags kennzeichnen Ihre Übungsressource:
ENDPOINT_ID=$(aws ec2 create-vpc-endpoint \
--vpc-id "$VPC_ID" \
--vpc-endpoint-type Gateway \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids "$PRIVATE_RT_ID" \
--tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=parcel-s3-endpoint},{Key=Project,Value=parcel}]' \
--query 'VpcEndpoint.VpcEndpointId' \
--output text)
Lesen Sie Zustand und Zuordnung:
aws ec2 describe-vpc-endpoints \
--vpc-endpoint-ids "$ENDPOINT_ID" \
--query 'VpcEndpoints[].{ID:VpcEndpointId,State:State,Type:VpcEndpointType,Service:ServiceName,Tables:RouteTableIds}' \
--output json
Fahren Sie bei State: available fort. Andernfalls warten Sie einige Sekunden und wiederholen dieselbe Abfrage. Typ ist Gateway, Dienst S3 und einzige Tabelle die private. Lassen Sie Terminal für die Variablen geöffnet.
Klicken Sie erneut auf Read storage object. Das Manifest bleibt gleich, die Quelle wird 10.20.2.10. Die S3-Präfixroute ist spezifischer als die NAT-Standardroute: S3 nutzt den Endpunkt, sonstiger ausgehender Verkehr NAT.
S3 ohne NAT-Standardroute erreichen
Sie entfernen den allgemeinen Ausgangsweg und prüfen den speziellen Dienstweg.
Löschen Sie nur die private NAT-Standardroute. Erhalten Sie Gateway, Adresse, öffentliche Route und Endpunkt:
aws ec2 delete-route --route-table-id "$PRIVATE_RT_ID" --destination-cidr-block 0.0.0.0/0
Erfolgreiches Löschen erzeugt keine Ausgabe. Lesen Sie die Routen:
aws ec2 describe-route-tables \
--route-table-ids "$PRIVATE_RT_ID" \
--query 'RouteTables[].Routes' \
--output json
local und die S3-Route DestinationPrefixListId bleiben, die Standardroute fehlt. GatewayId ist die Endpunkt-ID, Zustand active. Endpunktzuordnungen verwalten diese Routen; bearbeiten oder löschen Sie sie nicht mit gewöhnlichen Routenbefehlen.
Read storage object liefert weiterhin Parcel manifest ready von 10.20.2.10. Request outbound service scheitert, weil 198.51.100.20:9000 außerhalb der S3-Präfixliste liegt und keine Standardroute hat. Request private application from outside scheitert ebenfalls. Der Endpunkt ermöglicht nur privaten S3-Zugriff, ohne öffentliche Adresse oder Routen zu fremden Internetzielen.
Beispiel: Die private Tabelle enthält local und das S3-Präfix, ohne 0.0.0.0/0. Die echte Antwort enthält das Manifest und Quelle 10.20.2.10. NAT ist verfügbar, liegt aber nicht auf diesem S3-Weg. Erzeugte IDs und Adressen können abweichen.
Die Zuordnung zur falschen Tabelle beobachten
Sie verschieben den Endpunkt aus der Anwendungstabelle und untersuchen, warum ein verfügbarer Endpunkt unerreichbar sein kann.
Endpunkt–Tabelle und Subnetz–Tabelle sind verschiedene Zuordnungen. Ändern Sie nur die erste:
aws ec2 modify-vpc-endpoint \
--vpc-endpoint-id "$ENDPOINT_ID" \
--add-route-table-ids "$PUBLIC_RT_ID" \
--remove-route-table-ids "$PRIVATE_RT_ID"
Die Antwort meldet Return: true. Lesen Sie den Endpunkt:
aws ec2 describe-vpc-endpoints \
--vpc-endpoint-ids "$ENDPOINT_ID" \
--query 'VpcEndpoints[].{State:State,Tables:RouteTableIds}' \
--output json
Er bleibt available, enthält aber nur die öffentliche Tabelle. Lesen Sie beide Tabellen:
aws ec2 describe-route-tables \
--route-table-ids "$PRIVATE_RT_ID" "$PUBLIC_RT_ID" \
--query 'RouteTables[].{ID:RouteTableId,Routes:Routes,Associations:Associations}' \
--output json
Die automatische S3-Route befindet sich jetzt in der öffentlichen Tabelle. Die private enthält nur local; ihre NAT-Standardroute wurde bereits entfernt. Beide Subnetzzuordnungen bleiben unverändert. Dieselbe VPC macht eine Endpunktroute nicht für jedes Subnetz verfügbar.
Sobald AWS View die Änderung zeigt, klicken Sie Read storage object. Die neue Anfrage meldet Connection failed und Storage unavailable: Der Anwendungstabelle fehlt der S3-Weg. Request outbound service scheitert ebenfalls. Ein früherer Erfolg ist nur historisch. Lassen Sie den Fehler für diese Prüfung bestehen; danach reparieren Sie ihn.
Die private Dienstroute wiederherstellen
Sie reparieren die Zuordnung ohne neuen Endpunkt, öffentliche Adresse oder NAT-Standardroute.
Ordnen Sie denselben Endpunkt wieder der privaten Tabelle zu und entfernen Sie die öffentliche:
aws ec2 modify-vpc-endpoint \
--vpc-endpoint-id "$ENDPOINT_ID" \
--add-route-table-ids "$PRIVATE_RT_ID" \
--remove-route-table-ids "$PUBLIC_RT_ID"
Lesen Sie die Zuordnung:
aws ec2 describe-vpc-endpoints \
--vpc-endpoint-ids "$ENDPOINT_ID" \
--query 'VpcEndpoints[].{State:State,Tables:RouteTableIds}' \
--output json
Nur die private Tabelle darf erscheinen. Prüfen Sie die Routen:
aws ec2 describe-route-tables \
--route-table-ids "$PRIVATE_RT_ID" "$PUBLIC_RT_ID" \
--query 'RouteTables[].{ID:RouteTableId,Routes:Routes}' \
--output json
Die private S3-Route kehrt automatisch zurück und verschwindet aus der öffentlichen Tabelle. Die öffentliche Internetroute bleibt erhalten; privat fehlt weiterhin die Standardroute.
Eine neue Read storage object-Anfrage liefert das ursprüngliche Manifest von 10.20.2.10. Request outbound service scheitert weiterhin, da S3-Endpunkte keinen allgemeinen Internetzugang schaffen. Request private application from outside bleibt gesperrt. Private Adresse und bereitgestellte Sicherheitsregeln bleiben erhalten.
Endpunkt entfernen und NAT-Ausgangszustand wiederherstellen
Sie löschen Ihren Endpunkt, prüfen seine automatischen Routen und stellen den privaten Standardweg zum bereitgestellten NAT wieder her.
Löschen Sie nur Ihren Endpunkt:
aws ec2 delete-vpc-endpoints --vpc-endpoint-ids "$ENDPOINT_ID"
Unsuccessful muss leer sein. Lesen Sie das vollständige Inventar ohne Filter nach löschbaren Tags:
aws ec2 describe-vpc-endpoints \
--query 'VpcEndpoints[].{ID:VpcEndpointId,State:State,Tables:RouteTableIds}' \
--output json
Ein Eintrag mit deleted kann bleiben; es darf keinen aktiven Übungsendpunkt geben. Ein Löschdatensatz routet keinen Verkehr. Bei deleting warten Sie einige Sekunden und wiederholen dieselbe Abfrage. Lesen Sie beide Tabellen:
aws ec2 describe-route-tables \
--route-table-ids "$PRIVATE_RT_ID" "$PUBLIC_RT_ID" \
--query 'RouteTables[].{ID:RouteTableId,Routes:Routes}' \
--output json
Keine darf das S3-Präfix enthalten. Read storage object scheitert, während privat nur local vorhanden ist. Damit prüfen Sie, dass kein versteckter Ersatzweg besteht.
Stellen Sie die Standardroute mit der gespeicherten NAT-ID wieder her. Löschen Sie weder NAT, Adresse, Anwendung noch S3-Daten:
aws ec2 create-route \
--route-table-id "$PRIVATE_RT_ID" \
--destination-cidr-block 0.0.0.0/0 \
--nat-gateway-id "$NAT_ID"
Lesen Sie die wiederhergestellten Routen:
aws ec2 describe-route-tables \
--route-table-ids "$PRIVATE_RT_ID" \
--query 'RouteTables[].Routes' \
--output json
local und die aktive NAT-Standardroute entsprechen dem Ausgangszustand. Eine fehlgeschlagene Inventarabfrage beweist keine Löschung: Die authentifizierte Abfrage muss erfolgreich Abwesenheit oder deleted und entfernte automatische Routen bestätigen.
Read storage object liefert das Manifest nun über NAT; Source address zeigt die öffentliche NAT-Adresse. Request outbound service gelingt mit derselben Adresse, während Request private application from outside gesperrt bleibt. Erhalten Sie VPC, Subnetze, NAT, Regeln, S3-Objekt und Referenznetz.
Führen Sie die Abschlussprüfung dieses Schritts aus.
Zusammenfassung
Sie erstellten einen S3-Endpunkt und prüften echte Lesezugriffe mit privater Quelle. Ohne NAT-Standardroute blieb S3 erreichbar, andere Ziele wurden blockiert. Eine öffentliche Tabellenzuordnung unterbrach den Zugriff; die private Zuordnung reparierte ihn ohne Änderung an Anwendung oder Regeln.
Sie entfernten den Endpunkt und seine automatischen Routen und stellten NAT wieder her.
