Was ist Amazon VPC?
Amazon VPC (Virtual Private Cloud) ist der fundamentale Netzwerkdienst von AWS, der einen logisch isolierten virtuellen Netzwerkbereich in der AWS Cloud bereitstellt. VPC bildet die Grundlage für praktisch alle AWS-Workloads: EC2-Instanzen, RDS-Datenbanken, Lambda-Funktionen in VPC, ECS-Container, und EKS-Kubernetes-Cluster laufen alle innerhalb eines VPC. Sie definieren Ihren eigenen IP-Adressbereich, erstellen Subnetze, konfigurieren Routing-Tabellen und kontrollieren Netzwerk-Gateways vollständig.
Die Architektur von VPC ermöglicht Netzwerk-Isolation ähnlich einem traditionellen Rechenzentrum, kombiniert mit den Skalierungsvorteilen und der Flexibilität der Cloud. Sie können Ressourcen in Public Subnets (mit Internet-Zugriff) oder Private Subnets (ohne direkte Internet-Verbindung) platzieren, Multi-Tier-Architekturen mit unterschiedlichen Sicherheitszonen aufbauen und Hybrid-Cloud-Verbindungen zu On-Premise-Rechenzentren herstellen.
Für europäische Unternehmen ist VPC in allen EU-Regionen verfügbar und ermöglicht vollständige Kontrolle über Datenresidenz. Durch gezielte Konfiguration von Subnets, Route Tables und VPC Endpoints können Sie sicherstellen, dass Daten die EU nicht verlassen. VPC ist kostenlos; Sie zahlen nur für genutzte Komponenten wie NAT Gateways, VPN Connections und VPC Endpoints.
VPC-Komponenten im Detail
Subnets
Subnetze unterteilen einen VPC in logische Netzwerksegmente, die jeweils einer Availability Zone zugeordnet sind. Public Subnets haben eine Route zum Internet Gateway und ermöglichen Internet-Zugriff für Ressourcen mit öffentlichen IPs. Private Subnets haben keine direkte Internet-Route; Ressourcen können über NAT Gateway ausgehende Verbindungen initiieren, sind aber nicht von außen erreichbar. Isolated Private Subnets haben keine Route zu NAT oder Internet Gateway für vollständige Isolation (typisch für Datenbanken).
Route Tables
Route Tables steuern den Netzwerk-Traffic zwischen Subnets, Gateways und externen Netzwerken. Jedes Subnet ist einer Route Table zugeordnet. Lokale Routes innerhalb des VPC CIDR sind automatisch vorhanden. Sie fügen Routes für Internet Gateway (0.0.0.0/0 → IGW), NAT Gateway, Virtual Private Gateway (VPN), Transit Gateway oder VPC Peering Connections hinzu. Jede Route Table kann mit mehreren Subnets assoziiert werden.
Internet Gateway
Internet Gateway ermöglicht bidirektionale Internet-Kommunikation für Ressourcen in Public Subnets. Ein IGW ist horizontal skaliert, redundant und hochverfügbar ohne Bandbreitenlimits. Pro VPC kann nur ein IGW existieren. Ressourcen benötigen zusätzlich eine öffentliche IP oder Elastic IP, um über das IGW erreichbar zu sein.
NAT Gateway
NAT Gateway ermöglicht Ressourcen in Private Subnets ausgehenden Internet-Zugriff (z.B. für Software-Updates) ohne eingehende Verbindungen zu erlauben. NAT Gateway ist ein Managed Service (keine EC2-Instanz wie NAT Instance), hochverfügbar innerhalb einer AZ, skaliert automatisch bis 100 Gbps. Kosten: $0.045/Stunde + $0.045/GB verarbeitete Daten. Für High Availability: ein NAT Gateway pro AZ.
Security Groups
Security Groups sind stateful Firewalls auf Instanz-/ENI-Ebene. Regeln definieren erlaubten eingehenden und ausgehenden Traffic basierend auf Protokoll, Port und Quelle/Ziel (IP-Range oder andere Security Group). Stateful bedeutet: erlaubte eingehende Verbindungen dürfen automatisch zurück antworten. Security Groups evaluieren alle Regeln; wenn irgendeine Regel matcht, wird Traffic erlaubt. Nur Allow-Regeln möglich, alles andere wird implizit verweigert.
Network ACLs
Network ACLs sind stateless Firewalls auf Subnet-Ebene. Im Gegensatz zu Security Groups sind NACLs stateless: Return-Traffic muss explizit erlaubt werden. Regeln werden in Reihenfolge (Rule Number) evaluiert; erste Match gewinnt. Allow- und Deny-Regeln möglich. Default NACL erlaubt allen Traffic; Custom NACLs verweigern standardmäßig alles. NACLs dienen als zusätzliche Sicherheitsebene zu Security Groups.
VPC Peering
VPC Peering verbindet zwei VPCs für private Kommunikation über AWS-Netzwerk. Peering funktioniert innerhalb einer Region, cross-region und cross-account. Wichtig: Kein Transitive Routing (A peered mit B, B peered mit C → A kann NICHT mit C kommunizieren). CIDR-Blöcke dürfen sich nicht überlappen. Kostenlos innerhalb einer AZ, Data Transfer cross-AZ/cross-region wird berechnet.
VPC Endpoints
VPC Endpoints ermöglichen privaten Zugriff auf AWS-Services ohne Internet Gateway oder NAT. Gateway Endpoints (kostenlos) für S3 und DynamoDB nutzen Route Table Entries. Interface Endpoints (powered by PrivateLink) für 100+ Services erstellen ENIs in Subnets mit privaten IPs. Interface Endpoints kosten $0.01/Stunde + $0.01/GB Data Processing.
Transit Gateway
Transit Gateway ist ein zentraler Netzwerk-Hub für Verbindungen zwischen VPCs, VPN-Connections, Direct Connect Gateways und Peering zu anderen Transit Gateways. Vereinfacht komplexe Netzwerk-Topologien durch Hub-and-Spoke-Modell statt VPC-Peering-Mesh. Kosten: $0.05/Stunde + $0.02/GB. Unterstützt bis zu 5.000 VPC-Attachments pro Transit Gateway.
Typische Anwendungsfälle für Amazon VPC
Multi-Tier Web-Anwendungen
Klassische 3-Tier-Architektur: Public Subnets für Application Load Balancer (Internet-facing), Private Subnets für Application Server (EC2, ECS, EKS), Isolated Private Subnets für Datenbanken (RDS, Aurora). Jede Tier in mindestens 2 Availability Zones für High Availability. Security Groups isolieren Traffic: ALB akzeptiert nur HTTP/S von Internet, App-Server nur von ALB, Datenbank nur von App-Server.
Hybrid-Cloud-Verbindungen
Verbinden Sie AWS VPC mit On-Premise-Rechenzentren via Site-to-Site VPN (verschlüsselt über Internet, bis 1.25 Gbps pro Tunnel) oder AWS Direct Connect (dedizierte Netzwerkverbindung, bis 100 Gbps). Transit Gateway als zentraler Hub für mehrere VPCs und VPN-Connections. AWS Client VPN für Remote-User-Zugriff auf VPC-Ressourcen. Nutzen Sie Route 53 Resolver Endpoints für DNS-Auflösung zwischen On-Premise und AWS.
Sichere Isolation von Umgebungen
Trennen Sie Development, Staging und Production in separate VPCs mit unterschiedlichen AWS Accounts (AWS Organizations). VPC Peering für kontrollierte Kommunikation zwischen Umgebungen. Shared Services VPC für zentrale Services (DNS, Monitoring, Logging), verbunden via Transit Gateway. Nutzen Sie AWS Resource Access Manager für Subnet-Sharing zwischen Accounts.
Compliance und Datenresidenz
Für regulierte Branchen (Finance, Healthcare, Public Sector): Fully Private VPCs ohne Internet Gateway, VPC Endpoints für AWS-Service-Zugriff, Private NAT Gateway für Updates aus AWS-Repositories. AWS Organizations Service Control Policies erzwingen Datenresidenz (verbieten Ressourcen außerhalb EU-Regionen). VPC Flow Logs in S3 mit Glacier Archival für Compliance-Audits.
Microservices-Architekturen mit Service Mesh
EKS oder ECS Fargate in Private Subnets, Application Load Balancer oder API Gateway in Public Subnets. Service-zu-Service-Kommunikation über PrivateLink oder direkt via Security Groups. AWS App Mesh oder Istio für Service Mesh. VPC Endpoints für AWS-Services (S3, DynamoDB, Secrets Manager, ECR) reduzieren NAT Gateway Traffic und Kosten.
Disaster Recovery und Business Continuity
Primary VPC in einer Region, Standby VPC in zweiter Region. Route 53 Health Checks und Failover Routing für automatisches Failover. Cross-Region VPC Peering oder Transit Gateway Peering für Data Replication. S3 Cross-Region Replication für Backups, RDS Cross-Region Read Replicas, DynamoDB Global Tables. Disaster Recovery Tests regelmäßig durchführen.
Best Practices für Amazon VPC
1. IP-Adressbereich sorgfältig planen
Wählen Sie ausreichend große CIDR-Blöcke (z.B. /16 pro VPC) für zukünftiges Wachstum. Vermeiden Sie Überschneidungen mit On-Premise-Netzwerken oder anderen VPCs. Nutzen Sie RFC 1918 Private IP Ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Für Multi-VPC-Szenarien: konsistente CIDR-Strategie (z.B. 10.1.0.0/16 für Dev, 10.2.0.0/16 für Prod). VPC unterstützt sekundäre CIDR-Blöcke für Erweiterung.
2. Multi-AZ-Design für High Availability
Verteilen Sie Subnets über mindestens 2 (besser 3) Availability Zones. Pro AZ ein Public und ein Private Subnet. NAT Gateway pro AZ (nicht shared) für AZ-Independence. Load Balancer automatisch über AZs verteilt. RDS Multi-AZ Deployments für Datenbank-Failover. Auto Scaling Groups über mehrere AZs für Compute-Redundanz.
3. Least-Privilege Security Groups
Security Groups sollten minimal notwendige Ports und Protocols erlauben. Nutzen Sie Security Group References statt CIDR-Blöcken (z.B. App-Server erlaubt Port 8080 von ALB-Security-Group statt 0.0.0.0/0). Separate Security Groups pro Tier und Funktion. Keine inbound 0.0.0.0/0 Regeln außer für Load Balancer HTTP/S. Regelmäßige Audits mit AWS Config Managed Rules.
4. Private Subnets as Default
Platzieren Sie alle Ressourcen standardmäßig in Private Subnets. Nur Internet-facing Load Balancer, NAT Gateways und Bastion Hosts (besser: AWS Systems Manager Session Manager) in Public Subnets. Datenbanken und Caches in Isolated Private Subnets ohne NAT Route. Reduziert Attack Surface erheblich.
5. VPC Flow Logs für Visibility aktivieren
Aktivieren Sie Flow Logs auf VPC-Level (oder Subnet-/ENI-Level für Granularität). Speichern Sie in S3 (kosteneffizient, langfristige Speicherung) oder CloudWatch Logs (für Alarme). Nutzen Sie Athena für SQL-basierte Log-Analyse. GuardDuty analysiert Flow Logs automatisch für Threat Detection. Flow Logs helfen bei Troubleshooting (warum Connection rejected) und Security-Audits.
6. VPC Endpoints für AWS-Services nutzen
Nutzen Sie Gateway Endpoints (kostenlos) für S3 und DynamoDB statt NAT Gateway Traffic. Interface Endpoints für häufig genutzte Services (ECR, Secrets Manager, Systems Manager, CloudWatch) reduzieren NAT Gateway Kosten und verbessern Security. PrivateLink-Endpoints für SaaS-Anbieter (z.B. Snowflake, Databricks) für privaten Zugriff ohne Internet-Transit.
7. Defense-in-Depth mit NACLs
Nutzen Sie Network ACLs als zusätzliche Sicherheitsebene zu Security Groups. Blockieren Sie bekannte Bad IPs auf NACL-Ebene (alle Ressourcen im Subnet geschützt). Deny-Rules für nicht-autorisierte Ports. Ephemeral Ports (1024-65535) für ausgehenden Traffic berücksichtigen. NACLs evaluieren Regeln in Reihenfolge; niedrige Rule Numbers für Deny-Rules.
8. Tagging-Strategie für Kostenallokation
Taggen Sie alle VPC-Ressourcen konsistent: Environment (dev/prod), Team, CostCenter, Project. Aktivieren Sie Cost Allocation Tags in Billing Console. VPC, Subnets, Security Groups, NAT Gateways sollten getaggt sein. Nutzen Sie AWS Resource Groups für ressourcen-übergreifende Operationen. Tag Policies in AWS Organizations erzwingen Tagging-Standards.
9. Monitoring und Alarme konfigurieren
CloudWatch Alarme für NAT Gateway Errors, VPN Connection Status, Transit Gateway Packet Loss. VPC Flow Logs zu CloudWatch mit Metric Filters für ungewöhnliche Patterns. AWS Network Manager für zentrale Übersicht bei Transit Gateway. Reachability Analyzer für Troubleshooting von Connectivity-Problemen. GuardDuty für automatische Threat Detection.
10. Automation mit Infrastructure as Code
Verwalten Sie VPC-Infrastruktur mit Terraform, AWS CDK oder CloudFormation. Versionieren Sie IaC-Code in Git. Nutzen Sie AWS Service Catalog für genehmigte VPC-Templates. VPC-Module wiederverwendbar über Umgebungen. Drift Detection mit CloudFormation oder AWS Config für Abweichungen von definierten Zuständen.
Amazon VPC vs. Alternativen
Beim Vergleich von Amazon VPC mit Netzwerk-Lösungen anderer Cloud-Provider zeigen sich unterschiedliche Stärken:
Amazon VPC vs. Google Cloud VPC: Google Cloud nutzt globales VPC-Modell (ein VPC kann über mehrere Regionen spannen), AWS VPC ist regional (VPC Peering für Multi-Region). Google bietet automatische Subnet-CIDR-Expansion, AWS erfordert sekundäre CIDR-Blöcke. AWS hat mehr Regionen weltweit (33 vs. 40+), ausgefeiltere Hybrid-Cloud-Optionen (Direct Connect, Transit Gateway), und bessere Isolation durch Account-basierte Trennung.
Amazon VPC vs. Azure Virtual Network: Azure ist stärker bei Hybrid-Cloud-Integration (ExpressRoute ähnlich Direct Connect, aber tiefere Integration mit On-Premise-Active-Directory). AWS überzeugt durch mehr Service-Integrationen (100+ Services mit VPC Endpoints), Transit Gateway für komplexe Topologien, und ausgereiftere Security-Features (GuardDuty VPC Integration, Network Firewall). AWS PrivateLink ist ausgereifter als Azure Private Link.
Wann VPC Peering vs. Transit Gateway? VPC Peering für einfache Point-to-Point-Verbindungen zwischen wenigen VPCs (kostenlos innerhalb AZ). Transit Gateway für Hub-and-Spoke bei >5 VPCs, zentrale Routing-Policies, oder Hybrid-Cloud-Szenarien mit mehreren VPN-Connections. Transit Gateway kostet mehr ($0.05/h + $0.02/GB), vereinfacht aber Management erheblich.
Als Multi-Cloud-Experten beraten wir Sie herstellerneutral zur optimalen Netzwerk-Architektur für Ihre Anforderungen.
Amazon VPC Integration mit innFactory
Als AWS Partner unterstützt innFactory Sie bei:
Netzwerk-Architektur-Design: Wir konzipieren skalierbare, sichere VPC-Architekturen für Ihre AWS-Workloads: Multi-Tier-Designs für Web-Anwendungen, Hybrid-Cloud-Verbindungen mit Direct Connect oder VPN, Multi-Account-Strategien mit AWS Organizations und Transit Gateway, Disaster-Recovery-Architekturen mit Cross-Region-Failover.
Migration und Hybrid-Cloud: Überführung bestehender On-Premise-Workloads zu AWS: Netzwerk-Assessment und Planung, Direct Connect Setup für dedizierte Verbindungen, Site-to-Site VPN für verschlüsselte Connectivity, DNS-Integration mit Route 53 Resolver Endpoints, IP-Address-Management mit AWS IPAM.
Security-Hardening: Implementierung von Defense-in-Depth-Strategien: Security Group und NACL Design nach Least-Privilege, VPC Flow Logs mit GuardDuty Integration, AWS Network Firewall für IDS/IPS, PrivateLink für SaaS-Integration ohne Internet-Transit, Compliance-konforme Netzwerke (PCI DSS, HIPAA, TISAX).
Kostenoptimierung: Analyse und Optimierung Ihrer VPC-Kosten: NAT Gateway Consolidation oder Migration zu NAT Instances für niedrigen Traffic, Gateway Endpoints statt NAT für S3/DynamoDB, VPC Endpoints für häufig genutzte Services, Data Transfer Optimierung durch AZ-Konsolidierung, AWS PrivateLink statt Internet-basierte Verbindungen.
Monitoring und Troubleshooting: Implementierung umfassender Netzwerk-Visibility: VPC Flow Logs zu S3 mit Athena-Queries, CloudWatch Dashboards für Netzwerk-Metriken, Network Manager für Transit Gateway Monitoring, Reachability Analyzer für Connectivity-Troubleshooting, automatische Alarme für Anomalien.
Training und Best Practices: Schulungen zu AWS Networking: VPC-Grundlagen für Einsteiger, Advanced Networking (Transit Gateway, PrivateLink, Direct Connect), Security Best Practices, Hybrid-Cloud-Architekturen. Hands-on Workshops mit Ihren Anforderungen. Aufbau interner Netzwerk-Kompetenzen.
Kontaktieren Sie uns für eine unverbindliche Beratung zu Amazon VPC und AWS Networking.
Verfügbare Varianten & Optionen
Default VPC
- Pre-configured
- Internet connectivity included
- Quick start
- Less security control
- Public subnets by default
Custom VPC
- Full network control
- Custom IP ranges
- Security group customization
- Manual configuration required
Typische Anwendungsfälle
Technische Spezifikationen
Häufig gestellte Fragen
Was ist Amazon VPC?
Amazon VPC (Virtual Private Cloud) ist ein logisch isolierter Netzwerkbereich in der AWS Cloud, in dem Sie AWS-Ressourcen in einem von Ihnen definierten virtuellen Netzwerk starten können. Sie haben vollständige Kontrolle über IP-Adressbereiche, Subnetze, Routing-Tabellen und Netzwerk-Gateways. VPC bildet die Grundlage für nahezu alle AWS-Workloads und ermöglicht sichere Netzwerk-Isolation ähnlich einem traditionellen Rechenzentrum, kombiniert mit den Skalierungsvorteilen der Cloud.
Wann sollte ich Custom VPC statt Default VPC nutzen?
Nutzen Sie Custom VPC für Produktions-Workloads mit spezifischen Sicherheitsanforderungen. Custom VPC bietet volle Kontrolle über IP-Bereiche (CIDR-Blöcke), Subnet-Design (Public/Private), Security Groups, Network ACLs und Routing. Default VPC ist für Schnelltests geeignet, hat aber Sicherheitseinschränkungen: alle Subnets sind standardmäßig public, weniger Isolationsmöglichkeiten. Für Compliance, Multi-Tier-Architekturen oder Hybrid-Cloud ist Custom VPC Pflicht.
Was ist der Unterschied zwischen Security Groups und Network ACLs?
Security Groups sind stateful Firewalls auf Instanz-Ebene: Return-Traffic wird automatisch erlaubt, nur Allow-Regeln möglich, evaluiert alle Regeln. Network ACLs sind stateless Firewalls auf Subnet-Ebene: Return-Traffic muss explizit erlaubt werden, Allow- und Deny-Regeln möglich, evaluiert Regeln in Reihenfolge. Best Practice: Security Groups für granulare Kontrolle pro Ressource, NACLs als zusätzliche Subnet-Level-Schutzschicht.
Wie funktioniert VPC Peering?
VPC Peering verbindet zwei VPCs über privates AWS-Netzwerk, sodass Ressourcen über private IPs kommunizieren können. Funktioniert innerhalb einer Region, cross-region und cross-account. Keine Transitive Routing: VPC A peered mit B, B peered mit C → A kann NICHT mit C kommunizieren. Für Hub-and-Spoke-Topologien nutzen Sie Transit Gateway. VPC Peering ist kostenlos innerhalb einer AZ, Data Transfer wird berechnet.
Was kostet Amazon VPC?
Die VPC selbst ist kostenlos. Sie zahlen für genutzte Komponenten: NAT Gateway ($0.045/Stunde + $0.045/GB verarbeitete Daten), VPN Connection ($0.05/Stunde), Transit Gateway ($0.05/Stunde + $0.02/GB), VPC Endpoints ($0.01/Stunde + $0.01/GB für Interface Endpoints, Gateway Endpoints sind kostenlos), PrivateLink, und Data Transfer zwischen AZs ($0.01/GB). IP Address Manager (IPAM) kostet $0.00027/IP/Monat.
Ist Amazon VPC DSGVO-konform?
Ja, VPC ist in allen EU-Regionen (Frankfurt, Irland, Paris, Stockholm, Mailand) verfügbar. VPC-Konfiguration beeinflusst Datenresidenz: Private Subnets ohne NAT Gateway oder Internet Gateway verhindern Internet-Zugriff vollständig. VPC Endpoints ermöglichen Zugriff auf AWS-Services ohne Internet. Flow Logs können in CloudWatch oder S3 in EU-Regionen gespeichert werden. Kombinieren Sie mit AWS Organizations SCP für erzwungene Datenresidenz.
Was sind VPC Endpoints und wann sollte ich sie nutzen?
VPC Endpoints ermöglichen privaten Zugriff auf AWS-Services ohne Internet Gateway, NAT oder VPN. Zwei Typen: Gateway Endpoints (kostenlos, für S3 und DynamoDB) und Interface Endpoints (powered by PrivateLink, für 100+ Services, kostenpflichtig). Nutzen Sie Endpoints für: bessere Sicherheit (Traffic bleibt in AWS-Netzwerk), Compliance (kein Internet-Transit), Performance (niedrigere Latenz), Kostenersparnis (kein NAT Gateway für S3/DynamoDB-Traffic).
Wie konfiguriere ich eine Multi-Tier-Architektur mit VPC?
Klassisches 3-Tier-Design: Public Subnets für Load Balancer (Internet-facing), Private Subnets für Application Layer (EC2, ECS), Isolated Private Subnets für Datenbanken (RDS, ElastiCache) ohne Route zu NAT Gateway. Jede Tier in mindestens 2 AZs für High Availability. Security Groups: ALB erlaubt HTTP/S von 0.0.0.0/0, App-Layer erlaubt nur von ALB-Security-Group, DB-Layer erlaubt nur von App-Security-Group. Network ACLs als zusätzliche Subnet-Level-Absicherung.
Was ist AWS Transit Gateway und wann brauche ich es?
Transit Gateway ist ein zentraler Hub für Netzwerk-Konnektivität zwischen VPCs, On-Premise-Netzwerken (via VPN/Direct Connect) und Remote-Netzwerken. Ersetzt komplexe VPC-Peering-Mesh-Topologien durch Hub-and-Spoke-Modell. Nutzen Sie Transit Gateway wenn: mehr als 3-5 VPCs verbunden werden müssen, zentrale Routing-Policies benötigt werden, Hybrid-Cloud mit mehreren VPN-Connections, Multi-Region-Peering. Kosten: $0.05/Stunde + $0.02/GB.
Wie sichere ich eine VPC optimal ab?
Best Practices: Least-Privilege Security Groups (nur benötigte Ports/Protocols), Network ACLs als Defense-in-Depth, Private Subnets für alle Nicht-Internet-facing Ressourcen, VPC Flow Logs für Traffic-Analyse aktivieren, AWS Network Firewall für IDS/IPS, GuardDuty VPC Flow Logs Integration für Threat Detection, keine default Security Group nutzen, Session Manager statt SSH Bastion Hosts, PrivateLink für AWS-Service-Zugriff, regelmäßige Security Group Audits mit AWS Config.
Was sind VPC Flow Logs?
VPC Flow Logs erfassen Metadaten über IP-Traffic in VPC: Source/Destination IP, Ports, Protocol, Bytes, Packets, Accept/Reject-Status. Nutzbar für: Security-Analyse (ungewöhnliche Verbindungen), Troubleshooting (warum Connection fehlschlägt), Compliance-Audits, Kostenoptimierung (hoher Data Transfer). Flow Logs können auf VPC-, Subnet- oder ENI-Level aktiviert werden, gespeichert in CloudWatch Logs oder S3, analysiert mit Athena oder QuickSight.