Site icon bintorosoft.com

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

Red Snapper

Conceptual image of miniature engineer and worker plug-in lan cable to computer

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:

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.

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:

IPs = 2 32 – p

Beispiel: Bei p = 24 ergibt das 28 = 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:

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.

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:

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:

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:

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:

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.

Routing-Logik (typisch):

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 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.

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.

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.

Outbound-Links für vertiefende Grundlagen

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:

Lieferumfang:

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.

 

Exit mobile version