AWS Cloud Practitioner 06: Netzwerk und globale Auslieferung
Jede EC2-Instanz, jede RDS-Datenbank und jeder Load Balancer steht in einem Netz, das wir selbst zuschneiden. Dieses Netz heißt Virtual Private Cloud (VPC), dazu kommen Dienste, die Netze verbinden, filtern, benennen und Inhalte schnell zu den Nutzern bringen. Im Exam Guide gehört das zur größten Domäne, Cloud Technology and Services mit 34 Prozent. Die Prüfung verlangt keine Netzwerkplanung, aber sie fragt gern, welcher Baustein welches Problem löst und welche zwei Bausteine sich ähnlich sehen.
Die VPC als eigenes Netz in der Region
Eine VPC ist ein logisch abgetrenntes Netz innerhalb einer Region. Sie bekommt einen Adressbereich in CIDR-Schreibweise, etwa 172.31.0.0/16, und wird in Subnets aufgeteilt. Ein Subnet liegt immer in genau einer Availability Zone. Wer ausfallsicher bauen will, legt deshalb Subnets in mehreren AZs an und verteilt die Instanzen darauf, so wie in Teil 01 beschrieben.
Jeder Account bringt pro Region eine fertige Default-VPC mit. In eu-central-1 hat sie den Bereich 172.31.0.0/16 und ein Subnet in jeder der drei AZs. Für erste Versuche reicht das. Für produktive Workloads legt man üblicherweise eine eigene VPC mit bewusst gewählten Subnets an.
Die Route Table macht ein Subnet öffentlich
Ein Subnet ist nicht deshalb öffentlich, weil es so heißt. Es ist public, wenn seine Route Table eine Route zum Internet Gateway (IGW) enthält. Das Internet Gateway hängt an der VPC und ist die Tür nach draußen. Fehlt diese Route, ist das Subnet private, und Instanzen darin sind aus dem Internet nicht erreichbar.
Private Instanzen brauchen trotzdem oft einen Weg nach draußen, etwa für Software-Updates. Dafür gibt es das NAT Gateway. Es steht in einem Public Subnet, und die Route Table des Private Subnets schickt Internetverkehr dorthin. Der Verkehr geht damit nur ausgehend, Verbindungen von außen kommen nicht herein. Das NAT Gateway ist ein von AWS verwalteter Dienst. Die Alternative ist eine NAT Instance, also eine EC2-Instanz, deren Verfügbarkeit und Skalierung wir selbst betreuen (VPC-Doku). Genau diese Unterscheidung fragt die Prüfung ab: Internet Gateway für beide Richtungen, NAT Gateway nur für ausgehenden Verkehr aus privaten Subnets.
Öffentliche Adressen kosten Geld. Seit dem 1. Februar 2024 berechnet AWS für jede öffentliche IPv4-Adresse 0,005 USD pro Stunde, auch wenn sie an einer laufenden Instanz hängt. Ausgenommen sind nur eigene Adressen, die per BYOIP eingebracht werden (AWS News Blog, Preis Stand 2026-10-25, Momentaufnahme). Rechnerisch sind das bei 730 Stunden rund 3,65 USD pro Adresse und Monat. Die Free-Tier-Gutschrift von 750 Stunden öffentlicher IPv4 gilt nur noch im Legacy Free Tier für Accounts, die vor dem 15. Juli 2025 angelegt wurden (AWS re:Post). Die automatisch vergebene öffentliche IPv4-Adresse einer Instanz wechselt, wenn wir die Instanz stoppen und wieder starten, die private Adresse bleibt erhalten (AWS re:Post, EC2-Doku). Eine Elastic IP ist dagegen eine feste öffentliche IPv4-Adresse, die auch Stop und Start übersteht, und fällt unter dieselbe Gebühr.
NACL und Security Group filtern auf zwei Ebenen
Die Security Group kennen wir aus Teil 03 als Firewall direkt an der Instanz. Eine Ebene höher sitzt die Network ACL (NACL), die den Verkehr am Subnet filtert. Beide prüfen Verkehr anhand von Regeln, sie funktionieren aber grundverschieden.
| NACL | Security Group | |
|---|---|---|
| Ebene | Subnet | Instanz bzw. Netzwerkschnittstelle (ENI) |
| Regeln | ALLOW und DENY | nur ALLOW |
| Zustand | stateless, der Rückweg braucht eine eigene Regel | stateful, die Antwort ist automatisch erlaubt |
| Bezug | nur IP-Adressen | IP-Adressen und andere Security Groups |
Der wichtigste Unterschied steckt in der Zeile Zustand. Eine Security Group merkt sich, dass eine Verbindung von innen aufgebaut wurde, und lässt die Antwort ohne weitere Regel zurück. Eine NACL merkt sich nichts. Wer eingehend Port 443 erlaubt, muss bei der NACL auch die ausgehende Antwort eigens erlauben.
Daraus folgt die typische Arbeitsteilung. Eine bestimmte IP-Adresse aktiv sperren kann nur die NACL, weil nur sie DENY-Regeln kennt. Die Security Group beschreibt dagegen, wer überhaupt herein darf, und kann dabei auf andere Security Groups verweisen. So lässt sich etwa festlegen, dass die Datenbank nur Verkehr von den Instanzen der Web-Schicht annimmt, ohne eine einzige IP-Adresse zu nennen.
Für die Prüfung nennt der Exam Guide in Task 3.5 neben NACL und Security Group auch Amazon Inspector als Baustein für VPC-Sicherheit. Inspector behandelt Teil 08 ausführlich.
VPC Flow Logs ergänzen die Filter um Sichtbarkeit. Sie zeichnen den IP-Verkehr einer VPC, eines Subnets oder einer einzelnen ENI auf und schreiben ihn nach S3, in CloudWatch Logs oder nach Firehose. Wer wissen will, warum eine Verbindung abgewiesen wird, schaut dort nach.
VPCs untereinander und mit dem Rechenzentrum verbinden
Sobald es mehr als eine VPC gibt oder ein eigenes Rechenzentrum dazukommt, müssen die Netze verbunden werden. AWS bietet dafür mehrere Bausteine, die sich in Reichweite und Aufwand unterscheiden.
| Baustein | Zweck | Merkmal |
|---|---|---|
| VPC Peering | zwei VPCs privat verbinden | CIDR-Bereiche dürfen sich nicht überlappen, nicht transitiv |
| Transit Gateway | Hub-and-Spoke für tausende VPCs einer Region und on-prem | transitiv |
| VPC Endpoint, Gateway | privater Zugriff auf S3 und DynamoDB | nur diese beiden Services |
| VPC Endpoint, Interface | privater Zugriff auf AWS-Services | die meisten Services, auch S3 und DynamoDB |
| PrivateLink | eigenen Service an tausende VPCs freigeben | Network Load Balancer auf der Anbieterseite, ENI beim Nutzer |
| Site-to-Site VPN | Rechenzentrum mit der VPC verbinden | verschlüsselt über das Internet, schnell eingerichtet |
| Direct Connect | Rechenzentrum mit AWS verbinden | physische private Leitung, nicht über das Internet |
| Client VPN | einzelner Rechner in die VPC | OpenVPN-basiert |
Nicht transitiv ist das Schlüsselwort beim Peering. Sind VPC A und B gepeert und B und C ebenfalls, können A und C trotzdem nicht miteinander sprechen. Bei drei VPCs ist das noch überschaubar, bei fünfzig wird das Netz aus Einzelverbindungen unübersichtlich. Das Transit Gateway löst das, indem alle VPCs und die on-prem-Anbindung an einem zentralen Knoten hängen und darüber transitiv kommunizieren.
Gateway Endpoint und Interface Endpoint erlauben beide einer Instanz im Private Subnet, einen AWS-Service zu erreichen, ohne über Internet Gateway oder NAT Gateway zu gehen. Den Gateway-Typ gibt es nur für S3 und DynamoDB, er kostet nichts extra, ist aber aus dem eigenen Rechenzentrum, über Transit Gateway oder aus gepeerten VPCs anderer Regionen nicht nutzbar (VPC-Doku). Den kostenpflichtigen Interface-Typ bieten die meisten Services an, S3 und DynamoDB eingeschlossen. Bei S3 und DynamoDB haben wir also die Wahl zwischen beiden Typen, alle übrigen Services erreichen wir nur über einen Interface Endpoint (DynamoDB-Doku). PrivateLink dreht die Perspektive um. Hier geht es nicht um den Zugriff auf AWS-Services, sondern darum, einen eigenen Service anderen VPCs privat anzubieten.
Für die Anbindung des eigenen Rechenzentrums stehen VPN und Direct Connect zur Wahl. Das Site-to-Site VPN ist schnell aufgesetzt und läuft verschlüsselt über das öffentliche Internet. Die Verbindung hat zwei Enden. Auf der AWS-Seite endet sie an einem Virtual Private Gateway, das an die VPC angehängt wird, oder an einem Transit Gateway. Auf der Seite des Rechenzentrums steht das Customer Gateway, mit dem AWS das VPN-Gerät vor Ort beschreibt (Site-to-Site VPN Doku). Direct Connect ist eine physische Leitung, die erst bestellt und geschaltet werden muss. Wer in der Frage „sofort“ oder „schnell“ liest, landet beim VPN, wer „privat, nicht über das Internet“ liest, bei Direct Connect. In der In-Scope-Liste stehen AWS VPN als Oberbegriff sowie Site-to-Site VPN und Client VPN einzeln.
Route 53 übersetzt Namen und verteilt Verkehr
Amazon Route 53 ist der DNS-Dienst von AWS und, wie in Teil 01 erwähnt, ein globaler Service. Er löst Namen in Adressen auf und entscheidet dabei, welche Adresse ein Nutzer bekommt. Die Prüfung fragt nach den Record-Typen und den Routing Policies.
| Record | zeigt auf |
|---|---|
| A | eine IPv4-Adresse |
| AAAA | eine IPv6-Adresse |
| CNAME | einen anderen Hostnamen |
| Alias | eine AWS-Ressource, etwa einen Load Balancer oder eine CloudFront-Distribution |
Die Routing Policy bestimmt, nach welcher Regel Route 53 antwortet. Simple liefert einfach den hinterlegten Wert, ohne Health Check. Weighted verteilt den Verkehr nach Gewichten, etwa 90 zu 10 für einen vorsichtigen Rollout. Latency schickt Nutzer in die Region mit der geringsten Latenz. Failover leitet auf ein Ersatzziel um, sobald das primäre Ziel nicht mehr gesund ist. Daneben gibt es Geolocation, Geoproximity, IP-based und Multivalue Answer (Route 53 Doku).
CloudFront und Global Accelerator an der Edge
CloudFront und Global Accelerator arbeiten beide an den Edge Locations aus Teil 01 und werden deshalb gern verwechselt. Beide sind durch AWS Shield gegen DDoS-Angriffe geschützt. Ihr Zweck unterscheidet sich trotzdem deutlich.
Amazon CloudFront ist ein Content Delivery Network. Es speichert Inhalte für eine festgelegte Zeit (TTL) in den Edge Locations und liefert sie von dort aus. Das passt für alles, was sich cachen lässt, also Bilder, Videos und statische Webseiten. AWS Global Accelerator cacht nichts. Er gibt einer Anwendung statische IP-Adressen und leitet den Verkehr über die nächste Edge Location zum passenden Endpunkt. Er passt, wenn feste IPs gebraucht werden, wenn das Protokoll nicht HTTP ist oder wenn ein Failover zwischen Regionen deterministisch ablaufen soll.
| Anforderung | Dienst |
|---|---|
| Bilder, Video, statische Website weltweit schnell ausliefern | CloudFront |
| statische IP-Adressen für eine globale Anwendung | Global Accelerator |
| Nicht-HTTP-Verkehr beschleunigen | Global Accelerator |
| deterministisches Failover zwischen Regionen | Global Accelerator |
| große Uploads nach S3 aus der Ferne beschleunigen | S3 Transfer Acceleration |
Der dritte Edge-Dienst ist S3 Transfer Acceleration. Er beschleunigt Uploads in einen S3-Bucket, indem der Upload bei der nächsten Edge Location ankommt statt direkt in der entfernten Region.
Eine weitere Verwechslung betrifft CloudFront und die S3 Cross-Region Replication (CRR) aus Teil 04. CloudFront cacht global, aber nur für die Dauer der TTL. CRR kopiert neue Objekte automatisch und asynchron in einen oder mehrere Buckets in anderen Regionen, dort liegen sie dauerhaft als eigene Kopie (S3 User Guide). Wer weltweit niedrige Latenz für Leser will, nimmt CloudFront. Wer eine zweite Kopie in einer anderen Region braucht, nimmt CRR.
Einige Netzwerkdienste stehen laut Exam Guide ausdrücklich auf der Out-of-Scope-Liste und sind damit nicht prüfungsrelevant, darunter VPC Lattice, Cloud Map, Network Access Analyzer und Ground Station.
Hands-on
Schauen wir uns die Default-VPC in eu-central-1 an und legen danach eine Security Group an. Beides kostet nichts. Kosten entstehen, sobald eine Instanz mit öffentlicher IPv4-Adresse oder eine Elastic IP dazukommt. Die Ausgaben sind gekürzt, IDs abgeschnitten.
Zuerst die VPC selbst und ihre Subnets.
VPC_ID=$(aws ec2 describe-vpcs --region eu-central-1 \
--filters Name=is-default,Values=true \
--query 'Vpcs[0].VpcId' --output text)
aws ec2 describe-vpcs --region eu-central-1 --vpc-ids "$VPC_ID" \
--query 'Vpcs[].CidrBlock' --output text
172.31.0.0/16
In der Konsole: VPC → Your VPCs → VPC-ID anklicken; die Details nennen IPv4 CIDR, Default VPC, Main route table und Main network ACL, der Tab Resource map zeigt die Zusammenhänge als Bild.
aws ec2 describe-subnets --region eu-central-1 \
--filters Name=vpc-id,Values="$VPC_ID" \
--query 'Subnets[].[AvailabilityZone,CidrBlock,MapPublicIpOnLaunch]' \
--output text
eu-central-1a 172.31.16.0/20 True
eu-central-1b 172.31.32.0/20 True
eu-central-1c 172.31.0.0/20 True
In der Konsole: VPC → Subnets.
Ein Subnet pro AZ, und alle vergeben beim Start automatisch eine öffentliche Adresse. Warum sie public sind, zeigt die Route Table.
aws ec2 describe-route-tables --region eu-central-1 \
--filters Name=vpc-id,Values="$VPC_ID" \
--query 'RouteTables[].Routes[].[DestinationCidrBlock,GatewayId]' \
--output text
172.31.0.0/16 local
0.0.0.0/0 igw-…
In der Konsole: VPC → Route tables.
Die erste Route hält den Verkehr innerhalb der VPC, die zweite schickt alles andere zum Internet Gateway. Genau diese zweite Zeile macht die Default-Subnets öffentlich.
Die Default-NACL lässt alles durch.
aws ec2 describe-network-acls --region eu-central-1 \
--filters Name=vpc-id,Values="$VPC_ID" Name=default,Values=true \
--query 'NetworkAcls[].Entries[].[Egress,RuleNumber,RuleAction]' \
--output text
False 100 allow
False 32767 deny
True 100 allow
True 32767 deny
In der Konsole: VPC → Network ACLs.
Regel 100 erlaubt allen Verkehr, eingehend (Egress False) wie ausgehend (Egress True). Regel 32767 ist die Sternchen-Regel am Ende, die alles verbietet, was vorher nicht erlaubt wurde. Bei der Default-NACL greift sie praktisch nie. Die Default-Security-Group derselben VPC erlaubt eingehend nur Verkehr von Mitgliedern derselben Security Group und ausgehend alles nach 0.0.0.0/0. Abfragen lässt sie sich so:
aws ec2 describe-security-groups --region eu-central-1 \
--filters Name=vpc-id,Values="$VPC_ID" Name=group-name,Values=default
In der Konsole: VPC → Security groups.
Die eingehende Regel ist der Verweis auf eine andere Security Group aus der Tabelle oben, hier eben auf sich selbst.
Legen wir eine eigene Security Group für einen Webserver an. HTTPS darf von überall kommen, SSH nur aus einem bestimmten Netz. Für das Beispiel nehmen wir 203.0.113.0/24, einen Adressbereich, der für Dokumentation reserviert ist.
SG_ID=$(aws ec2 create-security-group --region eu-central-1 \
--group-name ccp-demo-web --description "CCP Demo Webserver" \
--vpc-id "$VPC_ID" --query GroupId --output text)
aws ec2 authorize-security-group-ingress --region eu-central-1 \
--group-id "$SG_ID" --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --region eu-central-1 \
--group-id "$SG_ID" --protocol tcp --port 22 --cidr 203.0.113.0/24
aws ec2 describe-security-groups --region eu-central-1 --group-ids "$SG_ID" \
--query 'SecurityGroups[].IpPermissionsEgress[].[IpProtocol,IpRanges[0].CidrIp]' \
--output text
-1 0.0.0.0/0
Eine Egress-Regel haben wir nicht angelegt. AWS hat sie beim Erstellen automatisch gesetzt, Protokoll -1 steht für allen Verkehr. Für die Antworten auf eingehende HTTPS-Anfragen wäre sie gar nicht nötig, weil die Security Group stateful ist.
In der Konsole: VPC → Security groups → Create security group (alternativ EC2 → Network & Security → Security Groups); die Detailseite trennt die Regeln in die Tabs Inbound rules und Outbound rules.
Zum Schluss prüfen wir, ob im Account Elastic IPs herumliegen, die Gebühren verursachen würden.
aws ec2 describe-addresses --region eu-central-1 \
--query 'length(Addresses)'
0
In der Konsole: VPC → Elastic IPs.
Aufräumen ist hier ein einziger Befehl. Die Default-VPC lassen wir stehen.
aws ec2 delete-security-group --region eu-central-1 --group-id "$SG_ID"
Für die Prüfung
| Stichwort in der Frage | Antwort |
|---|---|
| Subnet aus dem Internet erreichbar | Route zum Internet Gateway in der Route Table |
| private Instanz braucht Updates aus dem Internet | NAT Gateway |
| einzelne IP-Adresse aktiv sperren | NACL (DENY-Regel) |
| Firewall auf Instanzebene, stateful | Security Group |
| zwei VPCs privat verbinden | VPC Peering |
| viele VPCs und on-prem zentral, transitiv | Transit Gateway |
| S3 oder DynamoDB ohne Internet erreichen | Gateway Endpoint |
| eigenen Service anderen VPCs privat anbieten | PrivateLink |
| schnell und verschlüsselt ins Rechenzentrum | Site-to-Site VPN |
| VPN-Endpunkt auf der AWS-Seite | Virtual Private Gateway (oder Transit Gateway) |
| VPN-Endpunkt im eigenen Rechenzentrum | Customer Gateway |
| private Leitung, nicht über das Internet | Direct Connect |
| Mitarbeiter-Laptop in die VPC | Client VPN |
| IP-Verkehr mitschneiden für die Analyse | VPC Flow Logs |
| Nutzer in die Region mit der geringsten Latenz | Route 53 Latency Routing |
| statische Inhalte weltweit cachen | CloudFront |
| statische IPs, Nicht-HTTP-Protokoll, Failover zwischen Regionen | Global Accelerator |
| Uploads nach S3 aus der Ferne beschleunigen | S3 Transfer Acceleration |
Typische Fallen:
- Stateless und stateful vertauscht. Die NACL ist stateless und braucht eine Regel für den Rückweg, die Security Group ist stateful.
- Peering für viele VPCs. Peering ist nicht transitiv. Sobald die Frage von vielen VPCs oder einem zentralen Knoten spricht, ist Transit Gateway gemeint.
- Gateway Endpoint für jeden Service. Den Gateway-Typ gibt es nur für S3 und DynamoDB, alles andere braucht einen Interface Endpoint.
- NAT Gateway für eingehenden Verkehr. Das NAT Gateway lässt private Instanzen nur hinaus, nicht herein.
- Global Accelerator als Cache. Global Accelerator beschleunigt die Verbindung, cacht aber keine Inhalte. Caching ist CloudFront.
Quellen
- AWS Certified Cloud Practitioner (CLF-C02), Exam Guide: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02.html
- Exam Guide, Domain 3 (Cloud Technology and Services, Task 3.5): https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02-domain3.html
- In-Scope-Services: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/clf-02-in-scope-services.html
- Out-of-Scope-Services: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/clf-02-out-of-scope-services.html
- AWS News Blog, Gebühr für öffentliche IPv4-Adressen: https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/
- AWS re:Post, IPv4-Nutzung optimieren und Free Tier: https://repost.aws/knowledge-center/vpc-optimize-ipv4-usage
- AWS re:Post, öffentliche IP nach Stop und Start: https://repost.aws/knowledge-center/ec2-recover-ip-address
- EC2, Zustandswechsel einer Instanz: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html
- NAT Gateway und NAT Instance im Vergleich: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
- Gateway Endpoints, Einschränkungen: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-ddb.html
- Interface Endpoints für DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/privatelink-interface-endpoints.html
- Site-to-Site VPN, Funktionsweise: https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html
- VPC Flow Logs an Firehose: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-firehose.html
- Transit Gateway im Whitepaper „Building a Scalable and Secure Multi-VPC Network Infrastructure“: https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html
- Client VPN mit OpenVPN-Clients: https://docs.aws.amazon.com/vpn/latest/clientvpn-user/connect.html
- Route 53 Routing Policies: https://docs.aws.amazon.com/help-panel/Route53/latest/console/record-routing-policy.html
- Global Accelerator, statische Anycast-IPs: https://docs.aws.amazon.com/cli/latest/reference/globalaccelerator/index.html
- S3 Replication: https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
In Teil 07 geht es um die Dienste, die Anwendungen über Nachrichten entkoppeln, Infrastruktur als Code ausrollen und den Betrieb überwachen, von SQS und SNS über CloudFormation bis CloudWatch und CloudTrail.
