Cloud Networking 101: VPC/VNet, Subnetze, Route Tables (praxisnah erklärt)

Cloud Networking 101 wirkt auf den ersten Blick wie „nur ein paar IP-Bereiche“, ist in der Praxis aber die Grundlage für Verfügbarkeit, Sicherheit und Performance fast jeder Cloud-Architektur. Ob AWS, Azure oder Google Cloud: Ohne ein solides Verständnis von VPC/VNet, Subnetzen und Route Tables entstehen typische Produktionsprobleme wie unerklärliche Timeouts, fehlende Erreichbarkeit von Abhängigkeiten, unerwartete Egress-Kosten oder Sicherheitslücken durch falsch gesetzte Routen. Der entscheidende Unterschied zur klassischen Netzwerkumgebung ist nicht, dass Netzwerke in der Cloud „einfacher“ sind – sondern dass sie stark virtualisiert, automatisierbar und eng mit Identität, Security Controls und Plattformdiensten verzahnt sind. Wer Cloud Networking 101 sauber beherrscht, kann Services gezielt segmentieren, Blast Radius reduzieren und Connectivity reproduzierbar bauen. Dieser praxisnahe Einstieg erklärt VPC/VNet, Subnetze und Route Tables so, dass Sie typische Designs sofort einordnen und häufige Fehlkonfigurationen vermeiden können.

VPC und VNet: Was ist das eigentlich?

Eine VPC (Virtual Private Cloud) in AWS oder ein VNet (Virtual Network) in Microsoft Azure ist Ihr logisch isoliertes Netzwerk in der Cloud. Sie definieren darin vor allem:

• Adressraum: den IP-Bereich (meist private IPv4) für Ihre Workloads
• Segmentierung: Subnetze, Security Policies, Zonengrenzen
• Routing: wie Traffic innerhalb des Netzes und nach außen fließt
• Konnektivität: Peering, VPN, private Verbindungen zu On-Prem oder anderen Clouds

Wichtig: Eine VPC/VNet ist kein physisches Netzwerk. Es ist ein virtualisiertes Konstrukt, das von der Cloud-Plattform bereitgestellt wird. Trotzdem gelten klassische Prinzipien weiterhin: IP-Planung, Routing-Logik und das Prinzip „Least Privilege“ – nur eben als Konfiguration statt als Kabel und Switches.

Primärquellen zum Nachlesen sind die offiziellen Dokumentationen: AWS VPC Überblick, Azure Virtual Network Überblick und Google Cloud VPC Dokumentation.

IP-Adressräume und CIDR: Der wichtigste Design-Entscheid

Am Anfang jeder VPC/VNet steht der IP-Adressraum, typischerweise in CIDR-Notation (z. B. 10.0.0.0/16). Diese Entscheidung wirkt langfristig, weil nachträgliche Änderungen oft aufwendig sind (Workload-Migration, Umnummerierung, Anpassung von Routen und Firewall-Regeln). In der Cloud wird fast immer privates IPv4 genutzt, also Adressbereiche aus RFC 1918.

• 10.0.0.0/8 (großer privater Bereich)
• 172.16.0.0/12 (mittelgroßer Bereich)
• 192.168.0.0/16 (häufig in kleineren Netzen)

Die Referenz dafür ist RFC 1918. Für die CIDR-Notation ist außerdem RFC 4632 hilfreich.

Praxisregel für IP-Planung

Planen Sie den Adressraum so, dass er Wachstum und zusätzliche Subnetze abdeckt, ohne unnötig groß zu sein. Zu klein führt zu IP-Engpässen; zu groß ist selten ein technisches Problem, kann aber Governance erschweren (und macht Fehler potenziell „breiter“).

Wie viele IPs hat ein Subnetz? (CIDR kurz erklärt)

Ein CIDR-Präfix /p bedeutet: p Bits sind Netzwerkanteil, der Rest ist Hostanteil. Die Anzahl möglicher Adressen in einem IPv4-Netz ist:

$\mathrm{IPs}=2^{32–p}$

Beispiel: Bei p = 24 ergibt das 2⁸ = 256 Adressen. Je nach Cloud-Anbieter sind einige davon reserviert (z. B. Netzwerk-/Broadcast-Äquivalente oder Plattformadressen), weshalb die nutzbaren IPs geringer sein können. Prüfen Sie dazu die Anbieter-Dokumentation, etwa in den Kapiteln zu Subnetzen und IP-Reservierungen.

Subnetze: Segmentierung, Zonen und Sicherheitsgrenzen

Subnetze teilen den VPC/VNet-Adressraum in kleinere Bereiche auf. Das ist nicht nur „Ordnung“, sondern ein zentrales Mittel für:

• Isolation: Trennung von öffentlich erreichbaren Komponenten und internen Services
• Blast Radius: Fehler und Fehlkonfigurationen betreffen weniger Bereiche
• Routing: unterschiedliche Routen für unterschiedliche Subnetze (z. B. Internet vs. private Egress)
• Organisation: Zuordnung zu Umgebungen (Prod/Stage), Teams oder Workload-Typen

Public vs. Private Subnet (praxisnah)

In der Praxis ist ein Subnetz „public“, wenn Workloads darin direkt über eine Route ins Internet erreichbar sind (typisch über ein Internet Gateway) und öffentliche IPs nutzen können. Ein „private“ Subnetz hat keine direkte Route ins Internet. Private Workloads gehen – falls nötig – über kontrollierten Egress (z. B. NAT) nach außen. Das Muster ist weit verbreitet, weil es Sicherheit und Kontrolle verbessert.

• Public Subnets: Load Balancer, Bastion (falls noch nötig), Edge-Komponenten
• Private Subnets: Applikationsserver, Datenbanken, interne APIs, Worker
• Isolierte Subnets: besonders sensible Systeme ohne Internet-Egress

Subnetze und Availability Zones

Viele Cloud-Designs nutzen Subnetze pro Availability Zone (AZ). Der Grund: Sie wollen Ausfälle einer Zone abfangen, Workloads verteilen und Routing/Policies sauber pro Zone steuern. Typisch ist ein Muster wie: pro AZ ein öffentliches Subnetz und ein privates Subnetz. Das erleichtert auch das Troubleshooting, weil Sie zonale Engpässe (z. B. NAT-Kapazität, Routing-Fehler) schneller eingrenzen.

Route Tables: Die Verkehrsregeln Ihres Cloud-Netzes

Route Tables definieren, wohin ein Paket geht, wenn es ein bestimmtes Zielnetz erreichen soll. Eine Route besteht vereinfacht aus:

• Destination: Ziel-CIDR oder Präfix (z. B. 0.0.0.0/0 für „alles“)
• Target/Next Hop: wohin der Traffic geleitet wird (z. B. Internet Gateway, NAT, Peering, VPN)

Die wichtigste Regel in Routing-Tabellen ist: Longest Prefix Match. Das heißt: Wenn mehrere Routen passen, gewinnt die spezifischste (mit dem längsten Präfix, also der größten /Zahl). Das ist zentral, um zu verstehen, warum Traffic manchmal „anders“ läuft als erwartet.

Longest Prefix Match (kurz und praktisch)

Angenommen, Sie haben diese zwei Routen:

• 10.0.0.0/16 → intern
• 10.0.10.0/24 → spezielles Target

Traffic nach 10.0.10.5 nutzt die /24-Route, weil sie spezifischer ist. Dieses Prinzip erklärt viele Routing-Effekte bei Peering, Service Endpoints und Übergängen zu On-Prem.

Typische Targets in Route Tables (und wofür sie stehen)

Welche Targets verfügbar sind, hängt vom Anbieter ab, das Grundprinzip ist jedoch ähnlich. In der Praxis begegnen Ihnen besonders häufig:

• Internet Gateway: ermöglicht direkten Internetzugang für public Subnets
• NAT Gateway / NAT Service: erlaubt Outbound-Internet für private Subnets ohne Inbound-Erreichbarkeit
• VPC/VNet Peering: verbindet zwei Netze direkt (privat), ohne Internet
• VPN / ExpressRoute / Direct Connect: private Verbindung zu On-Premises
• Transit/Hub-Konzepte: zentrale Routing-Drehscheibe für viele Netze

Lesenswert dazu sind die Anbieterübersichten, etwa AWS Route Tables oder Azure User Defined Routes.

Security: Route Tables sind nicht gleich Firewall

Ein häufiger Denkfehler in Cloud Networking 101 ist, Routing mit Security gleichzusetzen. Route Tables sagen nur, wohin Traffic gehen soll – nicht, ob er erlaubt ist. Ob Traffic tatsächlich fließen darf, entscheiden separate Security Controls, zum Beispiel:

• Security Groups / NSGs: zustandsbehaftete Regeln auf Instanz-/Interface-Ebene
• Network ACLs: häufig zustandslos, auf Subnetz-Ebene
• WAF/Gateway Policies: auf Layer 7, für HTTP/API

In der Praxis bedeutet das: Ein korrektes Routing kann trotzdem „keine Verbindung“ ergeben, wenn Security-Regeln blockieren. Umgekehrt kann eine offene Security Group dennoch keine Erreichbarkeit schaffen, wenn die Route fehlt. Gute Troubleshooter prüfen immer beides: Routing und Policies.

Praxisbeispiel: Drei-Tier-Architektur in der Cloud

Ein klassisches, leicht verständliches Setup besteht aus drei Ebenen: Edge, App, Data. Sie können das als mentalen Bauplan verwenden, um Subnetze und Route Tables zu strukturieren.

• Edge (public): Load Balancer, Ingress, ggf. WAF/CDN-Integration
• App (private): Web/API-Services, Worker, interne Komponenten
• Data (isoliert oder private): Datenbanken, Caches, Messaging, Secrets

Routing-Logik (typisch):

• Public Subnet: 0.0.0.0/0 → Internet Gateway
• Private App Subnet: 0.0.0.0/0 → NAT (Outbound), interne CIDRs → lokal/Peering
• Data Subnet: kein Default-Route ins Internet (oder nur über stark kontrollierten Egress)

Dieses Muster ist nicht „immer richtig“, aber es ist ein stabiler Ausgangspunkt, weil es Inbound minimal hält und Outbound kontrollierbar macht.

Peering und Hub-and-Spoke: Wie Netze miteinander sprechen

Sobald Sie mehr als eine VPC/VNet haben (z. B. getrennte Umgebungen, Teams oder Regionen), stellt sich die Frage nach Konnektivität. Zwei häufige Muster sind:

• Peering: direkte Verbindung zwischen zwei Netzen; gut für einfache, überschaubare Topologien
• Hub-and-Spoke: zentraler Hub routet zwischen vielen Spokes; besser für Skalierung und Governance

Peering ist leicht zu starten, kann aber bei vielen Netzen unübersichtlich werden (viele Verbindungen, viele Routen). Hub-and-Spoke vereinfacht oft Governance, weil zentrale Security- und Routing-Controls im Hub liegen. Welche Variante passt, hängt von Größe, Compliance und Betriebsmodell ab.

Fehlerbilder in der Praxis: So debuggen Sie „keine Verbindung“ systematisch

Ein großer Teil der täglichen Cloud-Netzwerkarbeit ist Troubleshooting. Der wichtigste Tipp: Gehen Sie strukturiert vor und prüfen Sie zuerst die häufigsten Ursachen.

• 1) DNS/Name: Auflösung korrekt? Ziel-IP stimmt? (gerade bei privaten Zonen wichtig)
• 2) Routing: Gibt es eine Route zum Zielnetz und zurück? Longest Prefix Match beachten
• 3) Security Controls: Security Group/NSG/NACL erlauben Port/Protokoll in beide Richtungen?
• 4) Zonen/Peering: Richtige Peering-/Hub-Routen propagiert? Keine CIDR-Überlappungen?
• 5) Egress/Internet: NAT/Firewall korrekt? Gibt es einen Default-Route nur wo er sein soll?

Gerade CIDR-Überlappungen sind ein häufiger Showstopper bei Peering und Hybrid-Anbindungen: Wenn zwei Netze denselben oder überlappenden IP-Bereich nutzen, sind Routing-Entscheidungen nicht mehr eindeutig. Deshalb ist IP-Planung am Anfang so wichtig.

Subnetz-Größe und Wachstum: Warum „zu knapp“ teuer wird

Ein unterschätzter Aspekt ist, dass nicht nur VMs/Pods IPs brauchen, sondern auch Cloud-Interfaces, Load Balancer, Managed Services, Datenbankendpunkte oder zusätzliche Netzwerkkarten. Wenn Subnetze zu klein sind, treten „komische“ Fehler auf: Nodes können nicht skalieren, Pods bekommen keine IP, neue Interfaces lassen sich nicht anlegen, oder Deployments scheitern plötzlich. Planen Sie daher IP-Headroom und berücksichtigen Sie, dass Plattformen intern Adressen reservieren.

• Headroom: Reserve für Scale-out, Blue/Green, Canary, Failover
• Service-Wachstum: neue Komponenten, zusätzliche AZs, neue Environments
• Managed Services: können mehr IPs beanspruchen als erwartet

Observability fürs Netzwerk: Was Sie mindestens messen sollten

Cloud Networking 101 endet in der Praxis nicht bei der Konfiguration. Ohne Netzwerk-Observability bleiben Probleme schwer greifbar. Ein Minimum an Telemetrie hilft, ob ein Problem wirklich „Netzwerk“ ist oder eher App/Downstream.

• Flow Logs: wer spricht mit wem, auf welchem Port, erlaubt oder abgelehnt
• Ingress/Egress: Throughput, Drops, NAT-Auslastung, Verbindungsanzahl
• Latenz-Signale: TCP Connect Time, TLS Handshake (wo verfügbar), Retransmits
• Segmentierung: nach Subnetz, AZ, Security Domain, Service

Outbound-Links für vertiefende Grundlagen

• AWS: Was ist eine VPC?
• AWS: Route Tables in der VPC
• Azure: Virtual Network (VNet) Überblick
• Azure: User Defined Routes (Route Tables)
• Google Cloud: VPC Networking
• RFC 1918: Private IPv4-Adressbereiche
• RFC 4632: Classless Inter-Domain Routing (CIDR)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.