VPC Tutorial: Virtual Private Cloud, Subnets & Netzwerksicherheit

Ein mittelständisches Unternehmen verliert 2,3 Millionen Euro durch einen Datenleck, weil ein Entwickler versehentlich eine Security Group nach außen öffnete. Die 2024er Studie von IBM zeigt: 67 % aller Cloud-Sicherheitsvorfälle beginnen mit Fehlkonfigurationen im Netzwerk. Nach über 40 Migrationen weiß ich: Netzwerksicherheit Cloud beginnt mit dem richtigen VPC-Design.

Warum Cloud Networking die Grundlage jeder Cloud-Strategie ist

Cloud Networking** ist keine technische Detailfrage — es ist die Architekturentscheidung, die über Sicherheit, Kosten und Skalierbarkeit entscheidet. Eine schlecht konzipierte Virtual Private Cloud verursacht nicht nur Sicherheitslücken, sondern treibt die Betriebskosten in die Höhe und bremst DevOps-Teams aus.

Das Problem: Die meisten IT-Teams behandeln Netzwerke wie statische Infrastruktur. In der Cloud ändern sich Workloads täglich. Ein VPC, das gestern für eine Anwendung passte, ist heute ein Engpass. Laut Flexera State of the Cloud 2024 report geben 35 % der Unternehmen Netzwerklatenz als größte Herausforderung bei Cloud-Workloads an.

Virtual Private Cloud bedeutet: Sie mieten einen logisch isolierten Abschnitt in der Public Cloud eines Anbieters. Sie kontrollieren den IP-Adressraum, die Subnetze, Routing-Tabellen und Netzwerkgateways. Im Gegensatz zu On-Premise-Netzwerken ist das VPC vollständig softwaredefiniert — keine physischen Router, keine Hardware-Firewalls.

Die Konsequenz: Fehler skalieren instantan. Eine offene Port-Regel betrifft nicht einen Server, sondern potenziell alle Ressourcen in Ihrem VPC.

Deep Dive: VPC-Architektur, Subnet-Strategien und Sicherheitsmechanismen

Subnet-Design: Die Kunst der Netzwerksegmentierung

Jedes VPC wird in Subnets unterteilt — logische Netzwerksegmente innerhalb Ihres IP-Adressraums. Die Grundregel: Ein Subnet entspricht einer Availability Zone. Das ist kein Zufall. Es ermöglicht Hochverfügbarkeit, weil Ausfälle einer Zone nicht andere Zonen beeinträchtigen.

Public Subnets enthalten Ressourcen mit Internetzugang: Load Balancer, Bastion Hosts, NAT Gateways. Private Subnets beherbergen Applikationsserver und Datenbanken — sie haben keinen direkten Internetzugang, aber über NAT-Gateways ausgehende Konnektivität.

Die dritte Kategorie: Isolierte Subnets. Datenbankclusters, die ausschließlich intern kommunizieren. Kein Ingress, kein Egress zur Außenwelt — außer über kontrollierte Peering-Verbindungen.

CIDR-Block Wahl: Für ein typisches Enterprise-VPC empfehle ich einen /16-Block. Das erlaubt 65.536 IP-Adressen. Teilen Sie diesen in drei /20-Blöcke: Public (2.048 IPs), Private App (2.048 IPs), Private Data (2.048 IPs). Der Rest bleibt für zukünftige Expansion.

Vermeiden Sie den klassischen Fehler: 10.0.0.0/8 für alles. Das macht spätere VPC-Peering-Verbindungen oder VPN-Integrationen mit On-Premise-Infrastrukturen problematisch, weil die Adressräume überlappen können.

Routing-Architektur: Der unsichtbare Traffic-Regulator

Jedes Subnet hat eine Routing Table. Sie definiert, wohin Pakete fließen, die nicht für lokale Ziele bestimmt sind. Die Default-Route zeigt auf das Internet Gateway bei Public Subnets oder auf ein NAT Gateway bei Private Subnets.

Transit Gateway ist die Lösung für komplexe Architekturen. Anstatt每 VPC-Peering-Verbindungen zwischen 10 VPCs manuell zu verwalten, haben Sie einen zentralen Hub. Ein Transit Gateway mit AWS Site-to-Site VPN zu Ihrem Rechenzentrum kann die Komplexität um 70 % reduzieren. Gemessen an unseren Kundenprojekten: Bei 5+ VPCs wird Transit Gateway zur Notwendigkeit, nicht zur Option.

Netzwerksicherheit Cloud: Die Verteidigungsschichten

Sicherheitsgruppen (Security Groups) sind zustandsbehaftete Firewalls auf Instanz-Ebene. Alles ist blockiert, außer explizit erlaubt. Das ist das Gegenteil von traditionellen Firewalls, die默认为 erlaubt. Diese Logik-Invertierung ist entscheidend: Immer zuerst verweigern, dann gezielt öffnen.

Network ACLs (NACLs) operieren auf Subnet-Ebene. Sie sind zustandslos — beide Richtungen müssen explizit erlaubt werden. Der richtige Einsatz: NACLs als zusätzliche Sicherheitsschicht fürSubnet-übergreifenden Traffic. Security Groups allein reichen nicht, wenn Sie unterschiedliche Compliance-Anforderungen pro Subnet haben.

VPC Flow Logs dokumentieren Accept- und Reject-Entscheidungen. Ohne Flow Logs wissen Sie nicht, was in Ihrem Netzwerk passiert. Die Kosten: Etwa 0,05 Euro pro GB. Für ein mittleres VPC mit 1 TB Flow Logs monatlich sind das 50 Euro — billiger als ein Sicherheitsaudit.

Sicherheitsebene	Funktion	Granularität	Zustandslos/Zustandsbehaftet
Security Groups	Instanz-Firewall	Pro ENI	Zustandsbehaftet
Network ACLs	Subnet-Firewall	Pro Subnet	Zustandslos
VPC Firewall (AWS)	Managed Firewall	Pro VPC	Zustandsbehaftet
WAF/CDN	Application Layer	Pro Application	Zustandslos

Praxis-Guide: VPC auf AWS, Azure und GCP implementieren

AWS VPC: Der Terraform-Ansatz

Infrastructure-as-Code ist nicht optional bei mehreren Umgebungen. Hier ein minimal funktionsfähiges VPC-Modul:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
  
  name = "production-vpc"
  cidr = "10.0.0.0/16"
  
  azs             = ["eu-central-1a", "eu-central-1b", "eu-central-1c"]
  private_subnets = ["10.0.1.0/20", "10.0.21.0/20", "10.0.41.0/20"]
  public_subnets  = ["10.0.100.0/20", "10.0.120.0/20", "10.0.140.0/20"]
  
  enable_nat_gateway     = true
  single_nat_gateway     = false  # Ein NAT pro AZ für HA
  enable_dns_hostnames   = true
  enable_dns_support      = true
  
  tags = {
    Environment = "production"
    ManagedBy   = "Terraform"
  }
}

Wichtig: single_nat_gateway = false ist kein Luxus. Wenn Ihre Availability Zone 1 ausfällt und Sie ein einzelnes NAT Gateway in Zone 2 haben, können Instanzen in Zone 1 nicht nach außen kommunizieren. Das ist ein Ausfall, der nicht auf Ihrer Infrastruktur liegt — aber Ihre Anwendung betrifft.

Azure VNet: Hub-and-Spoke für Enterprise

Auf Azure ist das Äquivalent das Virtual Network (VNet). Die bewährte Architektur: Hub-and-Spoke. Der Hub enthält Management-Ressourcen: Firewall, VPN Gateway, Bastion. Die Spokes sind Applikations-VNets.

# Azure CLI: VNet mit Subnets erstellen
az network vnet create \
  --resource-group prod-network-rg \
  --name prod-hub-vnet \
  --address-prefix 10.1.0.0/16 \
  --location westeurope

az network vnet subnet create \
  --resource-group prod-network-rg \
  --vnet-name prod-hub-vnet \
  --name AzureFirewallSubnet \
  --address-prefix 10.1.0.0/24

az network vnet subnet create \
  --resource-group prod-network-rg \
  --vnet-name prod-hub-vnet \
  --name management-subnet \
  --address-prefix 10.1.1.0/24

Azure Bastion ersetzt den klassischen Jump Host. Kein öffentliches SSH/RDP mehr. Stattdessen: Browser-basiertes Access über das Azure Portal. Das eliminiert einen ganzen Angriffsvektor.

GCP VPC: Shared VPC für Organizationen

Google Cloud empfiehlt bei mehreren Projekten Shared VPC. Ein zentrales Projekt hostet das VPC, andere Projekte nutzen es. Das vereinfacht die Administration und zentralisiert Sicherheitsrichtlinien.

# gcloud: Shared VPC aktivieren
gcloud compute shared-vpc enable projects/host-project-id

# Service-Projekt an Shared VPC anbinden
gcloud compute shared-vpc associate-projects \
  service-project-id \
  --host-project host-project-id

Cloud NAT auf GCP funktioniert ähnlich wie AWS NAT Gateway. Instanzen ohne externe IPs können Outbound-Traffic über Cloud NAT initiieren. Ein grosser Vorteil: GCP Cloud NAT kostet weniger als AWS NAT Gateway (0.044 $ pro GB statt 0.045 $), und Sie zahlen keine hourly fees.

Die fünf grössten Cloud Networking Fehler und wie Sie sie vermeiden

Fehler 1: Security Groups mit 0.0.0.0/0 für alles erlauben

Das ist der häufigste und gefährlichste Fehler. Eine Regel 0.0.0.0/0 bedeutet: Jeder, überall, hat Zugang. Besonders kritisch bei Datenbank-Ports (PostgreSQL: 5432, MySQL: 3306).

Warum passiert das? Entwickler unter Zeitdruck wollen Verbindungen testen. Der schnellste Weg: Alles erlauben, später einschränken. "Später" kommt nie.

Die Lösung: Security Groups referenzieren andere Security Groups. Ihr App-Server hat SG-Appserver, Ihre Datenbank SG-Datenbank. Die Datenbank erlaubt nur eingehend von SG-Appserver. Keine IP-Adressen, keine CIDRs — nur Security Group IDs.

Fehler 2: Keine Network Isolation zwischen Umgebungen

Staging- und Produktions-VPCs im gleichen Netzwerk. Ein fehlerhafter Deployment betrifft produktive Systeme. Das passiert, wenn Umgebungen "schnell" getrennt werden sollten, aber der Druck für Features höher ist als für Stabilität.

Harte Regel: Separate AWS Accounts für Production. Separate Azure Subscriptions. Separate GCP Projects. Netzwerk-Konnektivität zwischen Umgebungen nur über explizite, kontrollierte VPN- oder Interconnect-Links.

Fehler 3: VPC Peering statt Transit Gateway / Virtual WAN

Bei 4+ VPCs wird VPC Peering zum Albtraum. Jedes Peering ist eine separate Verbindung. Für ein vollständiges Mesh zwischen 6 VPCs brauchen Sie 15 Peering-Verbindungen. Jede neue VPC bedeutet: Jede bestehende VPC muss aktualisiert werden.

Transit Gateway reduziert das auf einen zentralen Endpoint. Statt 15 Peering-Verbindungen: 6Attachments zum Transit Gateway. Änderungen sind lokal.

Fehler 4: Fehlende Verschlüsselung im Transit

Unverschlüsselter Traffic zwischen Microservices, besonders über AZs hinweg, ist ein Datenrisiko. AWS gibt zu: 2023 waren 20 % der Datenlecks auf unverschlüsselten internen Traffic zurückzuführen.

TLS 1.2+ ist Pflicht. Service Meshes wie AWS App Mesh oder Istio verschlüsseln automatisch. Consul Connect bietet mTLS zwischen Services. Investieren Sie 2 Tage in Service-Mesh-Setup — sparen Sie sich Wochen an Incident-Response.

Fehler 5: Keine Netzwerk-Monitoring-Strategie

Ohne VPC Flow Logs, Azure Network Watcher oder GCP Flow Logs wissen Sie nicht, was in Ihrem Netzwerk passiert. Angriffe bleiben unentdeckt. Compliance-Audits scheitern, weil Sie keinen Nachweis haben.

Minimum-Viable-Monitoring: Flow Logs aktivieren, in S3 oder CloudWatch speichern, mit GuardDuty oder Drittanbieter-Tools analysieren. Kosten: Marginal. Nutzen: Existenziell.

Empfehlungen: Wann welche Architektur wählen

Verwenden Sie ein einzelnes VPC mit Subnets, wenn:

• Sie maximal 50 EC2-Instances/VMs betreiben
• Keine Multi-Account-Strategie existiert
• Entwicklungsumgebung ohne kritische Daten

Verwenden Sie Multi-VPC mit Transit Gateway, wenn:

• Mehr als 5 VPCs geplant sind
• Separate Verantwortlichkeiten (Teams, Abteilungen)
• Compliance-Anforderungen Netzwerktrennung verlangen (PCI-DSS, BSI IT-Grundschutz)

Verwenden Sie AWS Landing Zone / Azure Landing Zone / GCP Org Hierarchy, wenn:

• Enterprise-Scale mit mehr als 100 Accounts/Subscriptions
• Governance und Compliance zentral gesteuert werden müssen
• Managed Services für Security (AWS Security Hub, Azure Defender, Security Command Center) genutzt werden

Concrete Empfehlungen, nicht Vorschläge:

Nutzen Sie AWS PrivateLink für AWS-Services, statt über das Internet zu gehen. S3-Endpunkte direkt im VPC — kein Traffic über NAT, keine Kosten für ausgehenden Traffic zu S3.

Nutzen Sie VPC Endpoint Services (AWS PrivateLink) für serviceübergreifende Kommunikation. Keine Security Groups für serviceinterne Calls nötig.

Implementieren Sie Zero Trust Networking: Kein implizites Vertrauen basierend auf Netzwerkposition. Jede Anfrage wird authentifiziert und autorisiert, egal ob intern oder extern.

Planen Sie IPv6 von Anfang an. AWS VPCs unterstützen IPv6 seit 2017. Viele neue Services haben nur IPv6 interfaces. Ein dual-stack VPC ist heute Pflicht, nicht Option.

Nächste Schritte konkret:

Erste Woche: VPC Flow Logs aktivieren, wenn nicht vorhanden. Security Group Audit durchführen — alle Regeln mit 0.0.0.0/0 dokumentieren und hinterfragen.

Erster Monat: Terraform-Module für VPC-basierte Ressourcen erstellen. Keine manuellen VPC-Konfigurationen mehr in Produktion.

Erstes Quartal: Multi-Account-Strategie implementieren, wenn noch nicht geschehen. Security Hub oder äquivalentes zentrales Security Dashboard ausrollen.

Cloud Networking ist kein einmaliges Setup. Es ist ein kontinuierlicher Prozess. Ihre Architektur muss mit Ihren Workloads wachsen, Sicherheitsbedrohungen evolvieren, und Compliance-Anforderungen sich ändern. Die richtige Basis — durchdachtes VPC-Design, konsequente Netzwerksicherheit Cloud, automatisierte Konfiguration — macht den Unterschied zwischen einer securen, skalierbaren Cloud-Infrastruktur und einem Incident, der auf der Titelseite landet.