Einführung
Eine Lieferanwendung ist in einer VPC vorbereitet, aber ihr öffentlicher Dienst kann noch keine externe Anfrage empfangen. Du erstellst den fehlenden Pfad: ein an die VPC angebundenes Internet-Gateway, eine Standardroute in der Routingtabelle des Anwendungssubnetzes und eine öffentliche Adresse, die der Netzwerkschnittstelle der Anwendung zugeordnet ist.
Schließe zuerst Eine VPC mit Anwendungssubnetzen erstellen ab. Diese neue Umgebung stellt eine eigene VPC, Subnetze, Anwendung und Zugriffsregeln bereit; sie verwendet deine vorherige VM nicht erneut. Die CLI ist bereits konfiguriert. Erhalte das unabhängige Referenznetzwerk und alle bereitgestellten Anwendungsressourcen.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Cloud Practitioner (CLF-C02) · Aufgabe 3.5: VPC-Gateway-Komponenten und ihr Zweck.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 3.4: Grundlegende Routing- und Adressierungsbedingungen öffentlicher Subnetze.
- CloudOps Engineer – Associate (SOA-C03) · Aufgaben 5.1 und 5.3: Grundlegende Konfiguration von Internet-Gateway und Routen sowie Diagnose einer fehlenden VPC-Route.
- Advanced Networking – Specialty (ANS-C01) · Aufgabe 2.2: Grundlagenübung zur Routingkonfiguration in einem Konnektivitätsentwurf mit einer einzelnen VPC.
Ein Internet-Gateway anbinden
In diesem Schritt prüfst du das bereitgestellte Anwendungsnetzwerk und bindest ein Internet-Gateway an seine VPC an.
Verwende Terminal für Befehle und klicke daneben auf AWS View. Die Ansicht liest denselben Ressourcenstatus wie die CLI. Die VPC application-network enthält public-subnet und private-subnet; die bereitgestellte Anwendung verwendet die private Adresse 10.20.1.10 in public-subnet.
cd /home/labex/project
Wähle die Anwendungs-VPC über ihr Tag Name aus. --filters begrenzt die Ergebnisse des Servers; --query wählt die ID aus. $(...) übernimmt diese ID in eine Shellvariable für die übrigen Schritte:
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Frage die Subnetze des ausgewählten Netzwerks ab:
aws ec2 describe-subnets \
--filters "Name=vpc-id,Values=$VPC_ID" \
--query 'Subnets[].{CIDR:CidrBlock,ID:SubnetId}' \
--output table
Die Bereiche sind 10.20.1.0/24 und 10.20.2.0/24. Das separate Referenznetzwerk 10.99.0.0/16 gehört nicht zur Aufgabe; erhalte es.
HTTP ist das Anfrage-Antwort-Protokoll dieses Anwendungsendpunkts. Ein Port bezeichnet den empfangenden Dienst; diese Anwendung lauscht auf TCP-Port 80. Klicke in AWS View auf Request application · client A. Dadurch wird eine externe Anfrage vom bereitgestellten Client 198.51.100.10 gesendet. Das Ergebnis lautet Connection failed mit No public address. Die Anwendung existiert, ihr öffentlicher Pfad ist jedoch unvollständig.
Ein Internet-Gateway (IGW) verbindet den öffentlichen Routingpfad einer VPC mit dem Internet. Das Erstellen und Anbinden sind separate Vorgänge. Kennzeichne das neue Gateway mit Tags, um deine Übungsressource zu erkennen; die Tagspezifikation in Anführungszeichen ist ein einzelnes Argument:
IGW_ID=$(aws ec2 create-internet-gateway \
--tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=parcel-internet},{Key=Project,Value=parcel}]' \
--query 'InternetGateway.InternetGatewayId' \
--output text)
Binde nur dieses Gateway an die ausgewählte Anwendungs-VPC an:
aws ec2 attach-internet-gateway --internet-gateway-id "$IGW_ID" --vpc-id "$VPC_ID"
Bei erfolgreicher Anbindung gibt der Befehl nichts aus. Frage stattdessen die Beziehung ab:
aws ec2 describe-internet-gateways \
--internet-gateway-ids "$IGW_ID" \
--query 'InternetGateways[].{ID:InternetGatewayId,Attachments:Attachments}' \
--output json
Die Anbindung nennt deine VPC und hat den Status available. AWS View zeigt dieses Internet-Gateway jetzt unter der VPC. Die Anbindung allein stellt keine Subnetzroute oder öffentliche Anwendungsadresse bereit. Lasse dieses Terminal geöffnet, damit die gespeicherten IDs erhalten bleiben.
Die Standardroute des öffentlichen Subnetzes hinzufügen
In diesem Schritt leitest du den Internetverkehr des öffentlichen Subnetzes an das angebundene Gateway weiter.
Eine Routingtabelle ordnet Zieladressbereiche den jeweiligen Zielen zu. Jedes Subnetz verwendet seine zugeordnete Tabelle oder die Haupttabelle der VPC, wenn keine explizite Zuordnung besteht. Hier wurden separat zugeordnete Tabellen bereitgestellt: public-routes und private-routes. Wähle public-routes innerhalb deiner Anwendungs-VPC:
PUBLIC_ROUTE_TABLE_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)
Frage sowohl die Routen als auch die Zuordnungen ab:
aws ec2 describe-route-tables \
--route-table-ids "$PUBLIC_ROUTE_TABLE_ID" \
--query 'RouteTables[].{ID:RouteTableId,Routes:Routes,Associations:Associations}' \
--output json
Die Zuordnung bezeichnet public-subnet; die vorhandene Route 10.20.0.0/16 hat das Ziel local, wodurch VPC-Verkehr innerhalb der VPC bleibt. Lösche diese lokale Route nicht und ändere private-routes nicht.
Eine Standardroute, 0.0.0.0/0, umfasst IPv4-Ziele, für die keine spezifischere Route gilt. --gateway-id legt das Internet-Gateway als Ziel fest:
aws ec2 create-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id "$IGW_ID"
Die Antwort enthält Return: true. Frage die Tabelle erneut ab:
aws ec2 describe-route-tables \
--route-table-ids "$PUBLIC_ROUTE_TABLE_ID" \
--query 'RouteTables[].Routes[].{Destination:DestinationCidrBlock,Target:GatewayId,State:State}' \
--output table
Die Standardroute verweist auf dein igw-... und hat den Status active; die lokale Route bleibt bestehen. AWS View zeigt 0.0.0.0/0 unter public-routes mit demselben Gateway als Ziel. Klicke erneut auf Request application · client A. Die Anfrage schlägt weiterhin mit No public address fehl. Das Subnetz hat jetzt eine öffentliche Route, aber die Anwendung benötigt eine eigene öffentliche IPv4-Adresse.
Eine öffentliche Adresse zuordnen und HTTP testen
In diesem Schritt ordnest du der bereitgestellten Anwendung eine Elastic IP zu und sendest eine erfolgreiche externe Anfrage.
Eine Elastic IP ist eine deinem Konto zugewiesene öffentliche IPv4-Adresse, die einer unterstützten Ressource zugeordnet werden kann. Ihre Zuweisungs-ID bezeichnet die reservierte Adresse; ihre Zuordnungs-ID bezeichnet die Verbindung zu einer Ressource. Beim Aufräumen entfernst du sowohl die Verbindung als auch die Zuweisung.
Eine Netzwerkschnittstelle (ENI) stellt die Netzwerkanbindung und private IP einer Anwendung bereit. Dieses Lab liefert die Anwendungsschnittstelle; du musst weder eine Instance erstellen noch ihr Betriebssystem konfigurieren. Wähle sie anhand von VPC und Name aus:
ENI_ID=$(aws ec2 describe-network-interfaces \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=application-interface \
--query 'NetworkInterfaces[0].NetworkInterfaceId' \
--output text)
Weise eine Adresse für die Verwendung in einer VPC zu und speichere ihre Zuweisungs-ID:
ALLOCATION_ID=$(aws ec2 allocate-address \
--domain vpc \
--query 'AllocationId' \
--output text)
Ordne sie der Anwendungsschnittstelle zu und speichere die Zuordnungs-ID:
ASSOCIATION_ID=$(aws ec2 associate-address \
--allocation-id "$ALLOCATION_ID" \
--network-interface-id "$ENI_ID" \
--query 'AssociationId' \
--output text)
Frage den daraus resultierenden Schnittstellenstatus ab:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,PrivateIP:PrivateIpAddress,PublicIP:Association.PublicIp}' \
--output table
Die private Adresse bleibt 10.20.1.10; das öffentliche Feld enthält jetzt eine Adresse. In AWS View zeigt die Anwendungskarte diese öffentliche Adresse zusammen mit der Gateway-Route. Klicke auf Request application · client A.
Das Ergebnis ist Success, mit Quelladresse 198.51.100.10, Zielport 80 und Antwortinhalt Application online. Dies ist eine HTTP-Antwort der bereitgestellten Anwendung. Eine Liste konfigurierter Ressourcen allein würde nicht belegen, dass die Anfrage funktioniert.
Beispielergebnis: Das öffentliche Subnetz zeigt die Gateway-Route und die Anwendungsadresse; die Anfrage liefert Application online. IDs und zugewiesene Adressen können variieren.
Die vorbereiteten Zugriffsregeln erlauben diesen Client und Port. Im nächsten Lab lernst du, diese Regeln zu steuern; lasse sie hier unverändert.
Eine fehlerhafte Route beobachten und wiederherstellen
In diesem Schritt entfernst du eine Route, beobachtest eine fehlgeschlagene Anfrage und stellst den funktionierenden Pfad wieder her.
Eine öffentliche Adresse ersetzt das Routing nicht. Entferne nur die von dir erstellte Standardroute; behalte die bereitgestellte lokale Route:
aws ec2 delete-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0
Bestätige, dass die öffentliche Adresse weiterhin zugeordnet ist:
aws ec2 describe-addresses \
--allocation-ids "$ALLOCATION_ID" \
--query 'Addresses[].{PublicIP:PublicIp,Interface:NetworkInterfaceId}' \
--output table
In AWS View enthält public-routes jetzt nur die lokale Route. Eine ältere Antwort kann als Previous request gekennzeichnet sein; sie beschreibt nicht die geänderte Konfiguration. Klicke auf Request application · client A, um eine neue Anfrage zu senden. Das Ergebnis wird Connection failed, obwohl die öffentliche Adresse bestehen bleibt.
Diagnosebeispiel: Die Anwendung besitzt weiterhin eine öffentliche Adresse, public-routes enthält nur die lokale Route und die neue Anfrage schlägt fehl.
Stelle die Route zum selben angebundenen Gateway wieder her:
aws ec2 create-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id "$IGW_ID"
Die Antwort enthält Return: true. Sobald die Route in AWS View wieder erscheint, klicke erneut auf Request application · client A. Success und Application online erscheinen wieder. Du hast das Routing als geänderte Bedingung isoliert, anstatt mehrere Einstellungen gleichzeitig zu ändern.
Deinen öffentlichen Pfad entfernen
In diesem Schritt entfernst du nur die von dir erstellte Adresse, Route und das Gateway. Die bereitgestellten Anwendungs- und Referenznetzwerke bleiben erhalten.
Ressourcen haben Abhängigkeiten. Löse zuerst die Zuordnung der Adresse zur Schnittstelle:
aws ec2 disassociate-address --association-id "$ASSOCIATION_ID"
Gib danach die Zuweisung frei; das Aufheben der Zuordnung allein lässt die Adresse als zugewiesene Ressource bestehen:
aws ec2 release-address --allocation-id "$ALLOCATION_ID"
Entferne deine Standardroute, bevor du das zugehörige Gateway trennst:
aws ec2 delete-route \
--route-table-id "$PUBLIC_ROUTE_TABLE_ID" \
--destination-cidr-block 0.0.0.0/0
aws ec2 detach-internet-gateway --internet-gateway-id "$IGW_ID" --vpc-id "$VPC_ID"
Lösche zuletzt das getrennte Gateway:
aws ec2 delete-internet-gateway --internet-gateway-id "$IGW_ID"
Diese Entfernungsbefehle erzeugen bei Erfolg keine Ausgabe. Frage vollständige Bestände ab, um die Abwesenheit der Ressourcen festzustellen, statt dich auf Tags zu verlassen:
aws ec2 describe-addresses --query 'Addresses' --output json
aws ec2 describe-internet-gateways --query 'InternetGateways' --output json
Beide liefern in dieser neuen Umgebung []. Prüfe die Routen des bereitgestellten Subnetzes erneut:
aws ec2 describe-route-tables \
--route-table-ids "$PUBLIC_ROUTE_TABLE_ID" \
--query 'RouteTables[].Routes[].{Destination:DestinationCidrBlock,Target:GatewayId}' \
--output table
Nur die lokale Route bleibt bestehen. Die bereitgestellte VPC, die Subnetze und die Anwendungsschnittstelle existieren weiterhin. AWS View zeigt dein Gateway und die öffentliche Adresse nicht mehr an. Klicke noch einmal auf Request application · client A; der entfernte öffentliche Pfad kann die Anfrage nicht bedienen. Eine fehlgeschlagene Bestandsabfrage belegt keine erfolgreiche Ressourcenbereinigung.
Führen Sie die Abschlussprüfung dieses Schritts aus.
Zusammenfassung
Du hast ein Internet-Gateway angebunden, eine Standardroute in der zugeordneten Routingtabelle des Anwendungssubnetzes hinzugefügt und eine Elastic IP zugeordnet. Du hast echten HTTP-Zugriff getestet, gezeigt, dass das Entfernen der Route trotz öffentlicher Adresse die Anfrage unterbricht, die Route wiederhergestellt und nur deine Übungsressourcen entfernt.
Fahre mit Den Anwendungszugriff mit Sicherheitsgruppen steuern fort, um einzuschränken, welche externen Anfragen die Anwendung erreichen können.
