Zwei VPCs verbinden: VPC Peering und Routen-Konfiguration in derselben Region

Zwei VPCs im selben AWS-Account und derselben Region sollen über private IPs miteinander kommunizieren — klingt einfach, aber in der Praxis scheitern viele an genau drei Stellen: fehlende Routen, falsch konfigurierte Security Groups oder ein übersehenes DNS-Flag. Dieser Beitrag zeigt den vollständigen Weg von der Peering-Anfrage bis zum ersten erfolgreichen Ping.

TL;DR: VPC Peering einrichten

Schritt	Aktion	Häufiger Fehler
1	Peering-Verbindung erstellen und akzeptieren	Anfrage bleibt im Status 'pending-acceptance'
2	Routen in beiden VPCs eintragen	Nur eine Seite wird konfiguriert
3	Security Groups anpassen	CIDR statt SG-Referenz verwendet
4	DNS-Auflösung aktivieren (optional)	Flag bleibt deaktiviert, private Hostnamen lösen nicht auf

Wie VPC Peering funktioniert

VPC Peering erstellt eine direkte Netzwerkverbindung zwischen zwei VPCs. Der Traffic läuft über die AWS-interne Infrastruktur — kein Internet-Gateway, kein VPN, kein NAT. Die Verbindung ist nicht transitiv: Wenn VPC A mit VPC B und VPC B mit VPC C gepeert ist, kann VPC A nicht automatisch VPC C erreichen. Jede Verbindung muss explizit aufgebaut werden.

Damit Pakete fließen können, müssen drei Schichten korrekt konfiguriert sein: die Peering-Verbindung selbst, die Routen-Tabellen in beiden VPCs und die Security Groups der beteiligten Ressourcen. Fehlt eine dieser Schichten, ist die Verbindung still blockiert — keine Fehlermeldung, nur Timeout.

graph LR A["VPC A 10.0.0.0/16"] -- "pcx-xxx" --> B["VPC B 10.1.0.0/16"] A --> RTA["Route Table A 10.1.0.0/16 -> pcx-xxx"] B --> RTB["Route Table B 10.0.0.0/16 -> pcx-xxx"] RTA --> SGA["Security Group A Outbound: erlaubt"] RTB --> SGB["Security Group B Inbound: erlaubt"]

VPC A (10.0.0.0/16) und VPC B (10.1.0.0/16) sind die beiden Netzwerke, die verbunden werden sollen.
Peering Connection (pcx-xxx) ist die logische Verbindung zwischen den VPCs — sie ist bidirektional, aber Routen müssen auf beiden Seiten manuell eingetragen werden.
Route Tables: Jede VPC benötigt einen Eintrag, der den CIDR-Block der Gegenseite über die Peering-Verbindung leitet.
Security Groups kontrollieren, welche Ports und Protokolle tatsächlich erlaubt sind — die Peering-Verbindung allein öffnet keinen Traffic.

Voraussetzungen prüfen

Bevor die Peering-Verbindung erstellt wird, müssen die CIDR-Blöcke beider VPCs bekannt sein und dürfen sich nicht überlappen. Überlappende CIDRs sind der häufigste Grund, warum Peering-Verbindungen zwar akzeptiert werden, aber nie funktionieren.

# CIDR-Blöcke beider VPCs abfragen
aws ec2 describe-vpcs \
  --filters 'Name=tag:Name,Values=vpc-a,vpc-b' \
  --query 'Vpcs[*].{ID:VpcId,CIDR:CidrBlock,Name:Tags[?Key==`Name`].Value|[0]}' \
  --output table \
  --region us-east-1

Notieren Sie die VPC-IDs und CIDR-Blöcke — sie werden in allen folgenden Schritten benötigt.

Schritt 1: Peering-Verbindung erstellen

Da beide VPCs im selben Account und derselben Region liegen, kann die Anfrage sofort akzeptiert werden. Bei Cross-Account-Peering müsste der Ziel-Account die Anfrage separat bestätigen.

# Peering-Anfrage erstellen (von VPC A zu VPC B)
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-0abc1234def567890 \
  --peer-vpc-id vpc-0def5678abc901234 \
  --region us-east-1

Der Output enthält die VpcPeeringConnectionId (Format: pcx-xxxxxxxxxxxxxxxxx). Diese ID wird für alle weiteren Schritte benötigt.

# Peering-Anfrage akzeptieren
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-0abc1234def567890 \
  --region us-east-1

Status nach dem Akzeptieren sollte active sein. Überprüfen:

aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0abc1234def567890 \
  --query 'VpcPeeringConnections[0].Status.Code' \
  --output text \
  --region us-east-1

Schritt 2: Routen in beiden VPCs eintragen

Eine aktive Peering-Verbindung leitet noch keinen Traffic — die Routen-Tabellen wissen nichts davon. Dieser Schritt wird auf beiden Seiten vergessen oder nur einseitig durchgeführt, was zu asymmetrischem Routing führt: Pakete kommen an, Antworten finden keinen Weg zurück.

Zuerst die relevanten Routen-Tabellen-IDs ermitteln:

# Routen-Tabellen für VPC A
aws ec2 describe-route-tables \
  --filters 'Name=vpc-id,Values=vpc-0abc1234def567890' \
  --query 'RouteTables[*].{ID:RouteTableId,Subnets:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1

# Routen-Tabellen für VPC B
aws ec2 describe-route-tables \
  --filters 'Name=vpc-id,Values=vpc-0def5678abc901234' \
  --query 'RouteTables[*].{ID:RouteTableId,Subnets:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1

# Route in VPC A: Traffic zu VPC B (10.1.0.0/16) über Peering leiten
aws ec2 create-route \
  --route-table-id rtb-0abc1234def567890 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-0abc1234def567890 \
  --region us-east-1

# Route in VPC B: Traffic zu VPC A (10.0.0.0/16) über Peering leiten
aws ec2 create-route \
  --route-table-id rtb-0def5678abc901234 \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id pcx-0abc1234def567890 \
  --region us-east-1

Falls mehrere Subnetz-Routen-Tabellen existieren, muss der Eintrag in jede Tabelle eingetragen werden, deren Subnetze kommunizieren sollen.

Schritt 3: Security Groups anpassen — und warum SG-Referenzen besser sind als CIDRs

Hier liegt die häufigste Fehldiagnose: Die Peering-Verbindung ist aktiv, die Routen stimmen, aber der Traffic kommt trotzdem nicht an. Die Security Group der Ziel-Instanz lässt den Quell-CIDR nicht durch.

Eine Security Group ist kein Netzwerk-Filter auf Routing-Ebene — sie sitzt direkt an der Netzwerkschnittstelle der Instanz. Selbst wenn das Paket die richtige Route nimmt, wird es an der Instanz verworfen, wenn keine passende Inbound-Regel existiert.

Intra-Region-Peering: SG-Referenz ist möglich und bevorzugt. Innerhalb derselben Region kann in einer Security Group-Regel direkt die Security Group ID der Peer-VPC als Quelle referenziert werden. Das ist wartungsfreundlicher als CIDR-Blöcke, weil neue Instanzen in der referenzierten SG automatisch abgedeckt sind.

Inter-Region-Peering: CIDR-Blöcke sind zwingend erforderlich. Über Regionsgrenzen hinweg ist die Referenzierung von Security Group IDs aus der Peer-VPC nicht möglich — dort müssen CIDR-Blöcke verwendet werden.

# Security Group ID der Quell-Instanzen in VPC A ermitteln
aws ec2 describe-instances \
  --filters 'Name=vpc-id,Values=vpc-0abc1234def567890' \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,SG:SecurityGroups[*].GroupId}' \
  --output table \
  --region us-east-1

# Inbound-Regel in VPC B: Zugriff von SG in VPC A erlauben (Intra-Region)
# Erlaubt z.B. Port 443 von der Security Group sg-0abc1234 aus VPC A
aws ec2 authorize-security-group-ingress \
  --group-id sg-0def5678abc901234 \
  --protocol tcp \
  --port 443 \
  --source-group sg-0abc1234def567890 \
  --region us-east-1

# Alternative: Inbound-Regel per CIDR (erforderlich bei Inter-Region-Peering)
aws ec2 authorize-security-group-ingress \
  --group-id sg-0def5678abc901234 \
  --protocol tcp \
  --port 443 \
  --cidr 10.0.0.0/16 \
  --region us-east-1

Denken Sie daran: Wenn die Kommunikation bidirektional sein soll, müssen Inbound-Regeln auf beiden Seiten konfiguriert werden.

Schritt 4: DNS-Auflösung über Peering aktivieren (optional)

Standardmäßig lösen private DNS-Hostnamen (z.B. ip-10-0-1-5.ec2.internal) nicht über Peering-Verbindungen auf. Wenn Anwendungen private Hostnamen statt IP-Adressen verwenden, muss DNS-Support explizit aktiviert werden.

# DNS-Auflösung für Peering-Verbindung aktivieren
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0abc1234def567890 \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region us-east-1

Zusätzlich muss DNS-Support in beiden VPCs selbst aktiviert sein:

# DNS-Support in VPC A prüfen und aktivieren
aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0abc1234def567890 \
  --attribute enableDnsSupport \
  --region us-east-1

aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0abc1234def567890 \
  --enable-dns-support \
  --region us-east-1

# Dasselbe für VPC B
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0def5678abc901234 \
  --enable-dns-support \
  --region us-east-1

IAM-Berechtigungen für VPC Peering

Wer die Peering-Verbindung nicht als Root oder Admin-User einrichtet, benötigt explizite IAM-Berechtigungen. Die folgende Policy deckt alle notwendigen Aktionen ab:

🔽 IAM Policy für VPC Peering einrichten (klicken zum Ausklappen)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VpcPeeringManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcPeeringConnection",
        "ec2:AcceptVpcPeeringConnection",
        "ec2:ModifyVpcPeeringConnectionOptions",
        "ec2:DescribeVpcPeeringConnections",
        "ec2:DescribeVpcs",
        "ec2:DescribeRouteTables",
        "ec2:CreateRoute",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeVpcAttribute",
        "ec2:ModifyVpcAttribute"
      ],
      "Resource": "*"
    }
  ]
}

Die meisten Describe- und List-Aktionen für EC2 erfordern "Resource": "*", da ressourcenbasierte Einschränkungen für diese Aktionen nicht unterstützt werden. Prüfen Sie die AWS Service Authorization Reference für aktuelle Einschränkungen.

Diagnose: Symptom, Fehldiagnose, tatsächliche Ursache

Symptom: Ping von Instanz A (10.0.1.5) zu Instanz B (10.1.1.5) läuft in Timeout. Die Peering-Verbindung zeigt Status active in der Konsole.

Fehldiagnose: Die Peering-Verbindung ist aktiv, also muss das Problem bei der Anwendung liegen. Viele prüfen an dieser Stelle Anwendungslogs oder starten Instanzen neu.

Tatsächliche Ursache: Die Routen-Tabelle des Subnetzes, in dem Instanz A läuft, hat keinen Eintrag für 10.1.0.0/16. Das Paket verlässt die Instanz, findet im Subnet-Router keine passende Route und wird verworfen — kein Log-Eintrag, kein ICMP-Fehler zurück.

Fix: aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-0abc1234 zeigt, welche Routen-Tabelle dem Subnetz zugeordnet ist. Fehlt der Eintrag für den Peer-CIDR, ist das die Ursache. Nach dem Eintragen der Route funktioniert der Ping sofort — ohne Neustart, ohne Wartezeit.

graph TD START["Peering active
aber kein Traffic"] --> R1{"Route fuer
Peer-CIDR vorhanden?"} R1 -- "Nein" --> FIX1["create-route eintragen fuer beide VPCs"] R1 -- "Ja" --> R2{"SG Inbound-Regel
erlaubt Quelle?"} FIX1 --> DONE["Verbindung funktioniert"] R2 -- "Nein" --> FIX2["authorize-security-group-ingress SG-Referenz oder CIDR"] R2 -- "Ja" --> R3{"NACL erlaubt
Inbound + Outbound?"} FIX2 --> DONE R3 -- "Nein" --> FIX3["NACL-Regeln pruefen zustandslos: beide Richtungen"] R3 -- "Ja" --> DONE FIX3 --> DONE

Peering active, aber kein Traffic: Der häufigste Ausgangspunkt — Status grün, aber Verbindung schlägt fehl.
Route fehlt: Prüfen mit describe-route-tables. Wenn der Peer-CIDR nicht in der Tabelle steht, ist das die Ursache.
SG blockiert: Wenn die Route vorhanden ist, aber Traffic nicht ankommt, prüfen Sie die Inbound-Regeln der Ziel-Security-Group.
NACL blockiert: Network ACLs sind zustandslos — sowohl Inbound als auch Outbound müssen explizit erlaubt sein. Dieser Layer wird oft vergessen.
Verbindung funktioniert: Alle drei Schichten korrekt konfiguriert.

VPC Peering einrichten: Zusammenfassung und nächste Schritte

VPC Peering in derselben Region und demselben Account ist konzeptionell einfach, aber die Konfiguration verteilt sich auf drei unabhängige Schichten. Wer nur die Peering-Verbindung erstellt und den Rest vergisst, sitzt vor einem stillen Timeout ohne hilfreiche Fehlermeldung.

Für komplexere Topologien mit vielen VPCs ist AWS Transit Gateway die skalierbarere Alternative — Peering wird bei mehr als vier bis fünf VPCs schnell unübersichtlich, weil jede Verbindung einzeln verwaltet werden muss.

Weiterführende Ressourcen:

Glossar

Begriff	Bedeutung
VPC Peering	Direkte Netzwerkverbindung zwischen zwei VPCs über die AWS-interne Infrastruktur, ohne Internet oder VPN.
Routen-Tabelle	Regelt, wohin Pakete aus einem Subnetz weitergeleitet werden. Muss auf beiden Seiten einer Peering-Verbindung aktualisiert werden.
CIDR-Block	IP-Adressbereich einer VPC, z.B. 10.0.0.0/16. Darf sich bei Peering-Verbindungen nicht mit dem Peer überlappen.
Security Group	Zustandsbehafteter Firewall-Filter auf Instanzebene. Kontrolliert eingehenden und ausgehenden Traffic unabhängig vom Routing.
Transitive Verbindung	Routing über eine dritte VPC als Zwischenstation — wird von VPC Peering nicht unterstützt.

Dieses Blog durchsuchen

SW BBANG D