Eine VPC mit Anwendungssubnetzen erstellen

Einführung

Eine Paketzustellungsanwendung benötigt getrennte Adressbereiche für ihren öffentlichen Dienst und interne Worker. Du erstellst eine VPC, platzierst zwei nicht überlappende Subnetze in verschiedenen Availability Zones und prüfst den Adressplan in AWS View.

Du solltest bereits AWS-CLI-Befehle ausführen und Ressourcen-IDs lesen können. Die CLI ist für diese neue Umgebung eingerichtet. Abschließend entfernst du nur die selbst erstellten Ressourcen.

Bezug zu Zertifizierungen

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

• Cloud Practitioner (CLF-C02) · Aufgaben 3.2 und 3.5: VPC- und Subnetzkomponenten sowie die Beziehung zwischen einer Region und Availability Zones.
• Solutions Architect – Associate (SAA-C03) · Aufgabe 3.4: Grundlegende Platzierung von Subnetzschichten und Planung nicht überlappender IP-Adressbereiche.
• CloudOps Engineer – Associate (SOA-C03) · Aufgabe 5.1: Grundlegende VPC- und Subnetzkonfiguration.

Die Liefer-VPC erstellen

In diesem Schritt wählst du den übergeordneten Adressbereich der Anwendung und erstellst ihre VPC.

Eine Virtual Private Cloud (VPC) ist ein isoliertes Netzwerk für Ressourcen in einer AWS-Region. Ihr CIDR-Block legt die für Subnetze verfügbaren Adressen fest. Die IPv4-CIDR-Schreibweise kombiniert Startadresse und Präfixlänge: 10.20.0.0/16 umfasst 10.20.0.0 bis 10.20.255.255. Eine kleinere Präfixzahl lässt mehr Adressbits übrig; /16 ist daher größer als /24.

Führe Befehle im vorbereiteten Terminal aus und klicke daneben auf AWS View. Die Ansicht liest denselben Ressourcenstatus wie die CLI und zeigt deine erstellten Netzwerkressourcen. Halte beide Oberflächen bereit.

Beginne im Arbeitsverzeichnis:

cd /home/labex/project

Lies vor Änderungen den vorhandenen VPC-Bestand. --query wählt ID und CIDR aus; --output table erleichtert den Vergleich:

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

Das Referenznetz verwendet 10.99.0.0/16. Weitere vorhandene VPCs können erscheinen. Lass sie unverändert; du erstellst und löschst später dein eigenes Netz 10.20.0.0/16.

Die EC2-Befehlsgruppe enthält VPC-Netzwerkoperationen. --cidr-block legt den Bereich fest, --tag-specifications setzt bei der Erstellung die Tags Name und Project. Anführungszeichen halten Klammern und Kommas in einem Argument zusammen.

Der Shell-Ausdruck $(...) führt einen Befehl aus und übernimmt dessen Ausgabe. Die Zuweisung an VPC_ID speichert die generierte ID für spätere Befehle. --query 'Vpc.VpcId' --output text liefert nur diese ID:

VPC_ID=$(aws ec2 create-vpc \
  --cidr-block 10.20.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=delivery-network},{Key=Project,Value=parcel}]' \
  --query 'Vpc.VpcId' \
  --output text)

Bei einer übernommenen Ausgabe wird das Ergebnis nicht angezeigt. Lies die Ressource mit der gespeicherten ID zurück. "$VPC_ID" setzt den Wert als ein Argument ein:

aws ec2 describe-vpcs \
  --vpc-ids "$VPC_ID" \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock,State:State}' \
  --output table

Der CIDR lautet 10.20.0.0/16, der Status available. AWS View zeigt nun delivery-network mit demselben CIDR und ohne Anwendungssubnetze. Lass dieses Terminal offen, damit die gespeicherten IDs erhalten bleiben.

Das Subnetz für den öffentlichen Dienst hinzufügen

In diesem Schritt reservierst du einen kleineren Bereich innerhalb der VPC und platzierst ihn in einer Availability Zone.

Ein Subnetz ist ein Teil des VPC-Adressbereichs. Jedes Subnetz gehört zu genau einer Availability Zone (AZ) dieser Region; die VPC erstreckt sich über die Region. Ein Name wie us-east-1a bezeichnet den Standort der Subnetzressourcen.

Reserviere 10.20.1.0/24 für den späteren öffentlichen Dienst. Der Bereich umfasst 10.20.1.0 bis 10.20.1.255 und liegt in 10.20.0.0/16. AWS reserviert die ersten vier und die letzte Adresse eines gewöhnlichen IPv4-Subnetzes. Somit bleiben in diesem /24 251 zuweisbare Adressen. Weise reservierte Adressen keinen Workloads zu.

Prüfe die verfügbaren Zonennamen. Die Region wurde beim Umgebungsstart konfiguriert:

aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[].{Zone:ZoneName,State:State}' \
  --output table

Verwende hier us-east-1a und für das nächste Subnetz us-east-1b. --vpc-id wählt das übergeordnete Netz, --availability-zone den Standort. Speichere die neue ID für die Bereinigung:

PUBLIC_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-public},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

Lies übergeordnetes Netz, Bereich und Zone zurück:

aws ec2 describe-subnets \
  --subnet-ids "$PUBLIC_SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

Die VPC-ID entspricht der gespeicherten ID, der Bereich ist 10.20.1.0/24, die Zone us-east-1a. AWS View ordnet das Subnetz delivery-network zu.

Der Name delivery-public beschreibt den geplanten Zweck. Ein Name allein macht ein Subnetz nicht öffentlich: Es benötigt noch eine Route zu einem Internet-Gateway, die du im nächsten Lab einrichtest.

Ein getrenntes Worker-Subnetz hinzufügen

In diesem Schritt erhalten die internen Worker ein eigenes, nicht überlappendes Subnetz. Anschließend vergleichst du den vollständigen Plan.

Zwei Subnetze derselben VPC dürfen sich nicht überlappen. 10.20.2.0/24 hält den Worker-Bereich von 10.20.1.0/24 getrennt. Beide liegen innerhalb des /16 der VPC.

Platziere das Subnetz in us-east-1b, um Subnetze verschiedener Zonen innerhalb einer VPC zu beobachten. Das zeigt nur die Platzierung; eine redundante Anwendung über mehrere Zonen hast du noch nicht bereitgestellt.

PRIVATE_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.2.0/24 \
  --availability-zone us-east-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-private},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

Ein serverseitiger Filter wählt nur die Subnetze deiner VPC. In Name=vpc-id,Values=... bezeichnet Name den Filter und Values enthält die passende VPC-ID:

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'Subnets[].{ID:SubnetId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

Die beiden Zeilen zeigen folgenden Plan. Generierte IDs und Reihenfolge können variieren:

Versuche 10.20.1.128/25 hinzuzufügen, um die Überlappungsgrenze zu beobachten. Dieser kleinere Bereich liegt bereits in delivery-public und kann kein weiteres Subnetz dieser VPC sein:

aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.128/25 \
  --availability-zone us-east-1a

Die erwartete Fehlermeldung enthält InvalidSubnet.Conflict. Ein drittes Subnetz wird nicht erstellt. Behalte die beiden gültigen /24-Bereiche.

Vergleiche diese Bereiche und Zonen in AWS View. Beide Subnetze haben noch keine Internetroute. Ihre getrennten Bereiche ermöglichen separate Routing- und Zugriffsregeln in den folgenden Labs.

Beispiel: Beide Subnetz-CIDRs liegen im VPC-Bereich; jedes Subnetz zeigt seine Zone. Die Ressourcen-IDs deiner Umgebung unterscheiden sich.

Das Übungsnetz entfernen

In diesem Schritt entfernst du deine zwei Subnetze und die VPC, während das vorhandene Referenznetz erhalten bleibt.

Ressourcen haben Abhängigkeiten: Eine VPC mit deinen Subnetzen kann nicht entfernt werden. Lösche nur die gespeicherten Subnetz-IDs. Erfolgreiche Löschbefehle erzeugen keine Ausgabe:

aws ec2 delete-subnet --subnet-id "$PUBLIC_SUBNET_ID"

aws ec2 delete-subnet --subnet-id "$PRIVATE_SUBNET_ID"

Entferne nun die leere VPC:

aws ec2 delete-vpc --vpc-id "$VPC_ID"

Lies erneut den vollständigen VPC-Bestand. Verlasse dich für den Löschungsnachweis nicht auf ein veränderbares Tag:

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

Es gibt keine VPC 10.20.0.0/16 mehr. Die Referenz 10.99.0.0/16 und andere bestehende Netze bleiben erhalten. Eine fehlgeschlagene Bestandsabfrage beweist keine Bereinigung. AWS View zeigt nun keine Anwendungs-VPC.

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

Das nächste Lab startet in einer neuen Umgebung mit einer eigenen vorbereiteten Anwendung. Dort lernst du, wie Internet-Gateway, Route und öffentliche Adresse eine externe Anfrage zur Anwendung ermöglichen.

Zusammenfassung

Du hast einen VPC-Adressbereich erstellt, in zwei nicht überlappende Anwendungssubnetze aufgeteilt und jedes in einer Availability Zone platziert. Mit CLI und AWS View hast du die Beziehungen geprüft und danach nur dein Übungsnetz gelöscht.

Fahre mit Ein öffentliches Subnetz mit dem Internet verbinden fort, um aus dem Adressplan einen funktionierenden Anwendungspfad zu machen.