Cloud-Native Networking: VPC-Design
Optimieren Sie Ihr Netzwerk mit cloud-native networking: Wir zeigen VPC, Transit Gateway und Service Mesh für sichere, skalierbare Architekturen.
Das Wichtigste in Kürze
- VPC-Design mit segmentierten Subnetzen ist die Grundlage jeder sicheren Cloud-Architektur.
- Transit Gateway verbindet hunderte VPCs und On-Premise-Netzwerke über einen zentralen Hub.
- PrivateLink ermöglicht den Zugriff auf Services ohne Internet-Exposition.
- Network Policies in Kubernetes implementieren Microsegmentierung auf Pod-Ebene.
- Multi-Account-Strategien mit separaten VPCs pro Umgebung isolieren Blast Radius.
Netzwerk-Design in der Cloud ist fundamental anders als On-Premise. Statt physischer Switches und Router definiert man virtuelle Netzwerke per Code – flexibler, aber auch fehleranfälliger. Falsch konfigurierte Security Groups, zu breite CIDR-Blöcke und fehlende Segmentierung sind die häufigsten Ursachen für Cloud-Security-Incidents. Wer sein VPC-Design richtig plant, hat 80% der Sicherheitsarbeit erledigt.
VPC-Design: Die Grundlagen richtig legen
Ein VPC (Virtual Private Cloud) ist ein isoliertes Netzwerk in der Cloud. Die Design-Entscheidungen bei der Erstellung bestimmen Sicherheit und Flexibilität für Jahre. Drei Regeln: Erstens, CIDR-Blöcke großzügig planen – ein /16 (65.536 IPs) pro VPC, /24 pro Subnetz. Nachträgliches Erweitern ist limitiert. Zweitens, Public und Private Subnetze trennen. Nur Load Balancer und Bastion Hosts in Public Subnetzen. Drittens, mindestens 3 Availability Zones für Hochverfügbarkeit nutzen.
Multi-Account-Strategien mit AWS Organizations oder Azure Management Groups isolieren Umgebungen (Prod, Staging, Dev) in separaten Accounts mit eigenen VPCs. Ein Breach in der Dev-Umgebung kann nicht auf Production übergreifen.
Transit Gateway: Der zentrale Netzwerk-Hub
In Enterprise-Umgebungen mit 50-500+ VPCs wird Peer-to-Peer-Vernetzung unmanagbar. AWS Transit Gateway, Azure Virtual WAN und GCP Network Connectivity Center fungieren als zentrale Hubs: Alle VPCs und On-Premise-Netzwerke verbinden sich mit dem Hub statt miteinander.
Transit Gateway ermöglicht: Zentrales Routing zwischen VPCs, VPN-Terminierung für On-Premise-Anbindung, Inter-Region-Peering für Multi-Region-Setups und Route Tables für granulare Verkehrssteuerung. Die Kosten liegen bei 0,05 USD pro Stunde plus Datenverarbeitung – für große Setups günstiger und einfacher als hunderte VPC-Peerings.
PrivateLink und VPC Endpoints
Standardmäßig laufen API-Calls zu AWS-Services (S3, DynamoDB, SQS) über das öffentliche Internet. VPC Endpoints und PrivateLink halten den Traffic im AWS-Backbone: Gateway Endpoints (kostenlos für S3 und DynamoDB) und Interface Endpoints (für alle anderen Services) stellen private IP-Adressen im VPC bereit.
PrivateLink ermöglicht auch privaten Zugriff auf Third-Party-Services und eigene Services in anderen Accounts – ohne Internet, ohne NAT Gateway, ohne öffentliche IP. Für Compliance-kritische Workloads ist PrivateLink Pflicht.
DNS und Service Discovery in der Cloud
Route 53 Private Hosted Zones (AWS), Azure Private DNS und GCP Cloud DNS Private Zones ermöglichen interne DNS-Auflösung innerhalb von VPCs. Services werden über DNS-Namen statt IP-Adressen adressiert – essentiell für dynamische Cloud-Umgebungen, in denen IPs sich ändern.
In Kubernetes übernimmt CoreDNS die Service Discovery: Jeder Service bekommt automatisch einen DNS-Namen (service-name.namespace.svc.cluster.local). External DNS synchronisiert Kubernetes-Services automatisch mit Route 53 oder CloudDNS für externe Erreichbarkeit.
Network Security: Defense in Depth
Cloud-Netzwerk-Sicherheit ist ein Schichtmodell: Security Groups (Stateful Firewall auf Instanz-Ebene) → Network ACLs (Stateless Firewall auf Subnetz-Ebene) → WAF (Application-Layer am Load Balancer) → Network Policies (Pod-zu-Pod in Kubernetes) → Service Mesh (mTLS und Autorisierung zwischen Microservices).
Die wichtigste Regel: Deny by Default. Jede Security Group startet ohne Inbound-Regeln. Jede Network Policy blockiert allen Traffic, bis explizite Allow-Regeln definiert sind. Nur das freigeben, was tatsächlich benötigt wird.
Weiterlesen auf cloudmagazin.com
- Data Mesh in der Praxis: Dezentrale Datenarchitektur für Cloud-native Unternehmen
- Cloud-native Identity: OAuth 2.1, Passkeys und die Zukunft der Authentifizierung
- KI-Boom treibt den Cloud-Service-Markt an – Europa bleibt zurück
Mehr zum Thema: Weitere Artikel auf mybusinessfuture
Häufige Fragen
Wie viele VPCs sollte ein Unternehmen haben?
Mindestens drei: Produktion, Staging, Entwicklung – idealerweise in separaten AWS-Accounts. Große Unternehmen haben oft 50-500+ VPCs, organisiert nach Business-Units, Umgebungen und Compliance-Anforderungen. Mehr VPCs = bessere Isolation, aber mehr Management-Aufwand.
Was kostet ein NAT Gateway?
AWS NAT Gateway: 0,045 USD/Stunde (~33 USD/Monat) plus 0,045 USD/GB Datenverarbeitung. Bei hohem ausgehendem Traffic kann das teuer werden. Alternativen: NAT Instances (günstiger, aber selbst verwaltet), VPC Endpoints (eliminieren NAT für AWS-Service-Traffic) oder Dual-Stack IPv6 (kein NAT nötig).
Braucht man Transit Gateway für kleine Setups?
Nein. Für 2-5 VPCs reicht VPC Peering (kostenlos, direkte Verbindung). Transit Gateway lohnt sich ab 10+ VPCs oder wenn On-Premise-Anbindung und zentrales Routing benötigt werden.
Wie segmentiert man Netzwerk in Kubernetes?
Network Policies (Calico, Cilium) definieren, welche Pods mit welchen Pods kommunizieren dürfen. Namespace-basierte Isolation ist der Einstieg: Pods in verschiedenen Namespaces können nur kommunizieren, wenn eine Network Policy es explizit erlaubt.
Was ist der Unterschied zwischen Security Groups und Network ACLs?
Security Groups sind Stateful (Return-Traffic automatisch erlaubt), operieren auf Instanz-Ebene und unterstützen nur Allow-Regeln. Network ACLs sind Stateless (Return-Traffic muss explizit erlaubt werden), operieren auf Subnetz-Ebene und unterstützen Allow und Deny. In der Praxis reichen Security Groups für die meisten Szenarien.
Quelle des Titelbildes: Pexels / Brett Sayles
