VPC Peering : relier deux VPC

À la fin de ce tutoriel, vous aurez deux VPC en ca-central-1 avec des CIDR disjoints, une connexion VPC Peering active (requester/accepter), des routes de chaque côté, et un test de connectivité privée — sans Transit Gateway.

Niveau : Intermédiaire · Temps estimé : 50–60 min · Versions testées : VPC Peering 2026, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

Slug : aws-vpc-peering · Série : AWS Solutions Architect · Mot-clé SEO : VPC peering

← Précédent : SG vs NACL · → Suivant : Transit Gateway · Hub : Démarrer avec AWS

Le VPC Peering établit un lien réseau privé (non transitif) entre deux VPC pour que les instances communiquent via leurs adresses privées, sans Internet ni VPN. C’est le choix le plus simple pour 2–3 VPC ; au-delà, préférez Transit Gateway.

Prérequis

• Profil lab
• Comprendre subnets + route tables (VPC)
• CIDR qui ne se chevauchent pas (sinon peering impossible)

Coût estimé : peering intra-AZ data transfer faible ; créez des VPC vides (sans NAT). Supprimez tout en fin de lab. Hors lab, facturez surtout le trafic inter-AZ / inter-Region ; la connexion pcx-* n’est pas facturée comme une TGW.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

VPC-A  10.10.0.0/16                    VPC-B  10.20.0.0/16
├── subnet 10.10.1.0/24                ├── subnet 10.20.1.0/24
├── RT : 10.20.0.0/16 → pcx-…         ├── RT : 10.10.0.0/16 → pcx-…
└─────────────── VPC Peering pcx-… ───────────────┘

(Schéma — alt : « Deux VPC peerés avec routes réciproques ».)

Les CIDR /16 et subnets /24 sont volontairement séparés : un overlap (même partiel) fait échouer create-vpc-peering-connection. Planifiez les plages avant le lab (IPAM ou table partagée).

Étape 1 — Limites du peering (examen)

Point	Détail
Transitivité	Non — A↔B et B↔C ≠ A↔C
CIDR	Pas de overlap
Edge	Pas d’accès IGW/NAT du pair via le peering (sauf cas edge/TGW)
DNS	Optionnel : resolve DNS privé cross-VPC
Scale	N² connexions → préférer Transit Gateway au-delà de quelques VPC

Retenez : le peering ne partage pas l’IGW ni le NAT du pair. Un trafic 0.0.0.0/0 dans VPC-A ne sort pas via l’IGW de VPC-B. Pour un hub de sortie, TGW — pas le peering seul.

Étape 2 — Créer VPC-A et VPC-B

VPC_A=$(aws ec2 create-vpc --cidr-block 10.10.0.0/16 
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=lab-vpc-a}]' 
  --query Vpc.VpcId --output text)
VPC_B=$(aws ec2 create-vpc --cidr-block 10.20.0.0/16 
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=lab-vpc-b}]' 
  --query Vpc.VpcId --output text)

AZ=$(aws ec2 describe-availability-zones --query 'AvailabilityZones[0].ZoneName' --output text)

SUB_A=$(aws ec2 create-subnet --vpc-id "$VPC_A" --cidr-block 10.10.1.0/24 
  --availability-zone "$AZ" 
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=lab-a-1}]' 
  --query Subnet.SubnetId --output text)
SUB_B=$(aws ec2 create-subnet --vpc-id "$VPC_B" --cidr-block 10.20.1.0/24 
  --availability-zone "$AZ" 
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=lab-b-1}]' 
  --query Subnet.SubnetId --output text)

echo "A=$VPC_A B=$VPC_B"

Même AZ pour simplifier le lab. En prod, placez les workloads selon la résilience ; le peering fonctionne cross-AZ dans la Region.

Étape 3 — Créer et accepter le peering

PCX=$(aws ec2 create-vpc-peering-connection 
  --vpc-id "$VPC_A" 
  --peer-vpc-id "$VPC_B" 
  --tag-specifications 'ResourceType=vpc-peering-connection,Tags=[{Key=Name,Value=lab-pcx-ab}]' 
  --query VpcPeeringConnection.VpcPeeringConnectionId --output text)

aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id "$PCX"

aws ec2 describe-vpc-peering-connections --vpc-peering-connection-ids "$PCX" 
  --query 'VpcPeeringConnections[0].Status.Code'
# → active

Same-account = vous acceptez vous-même. Cross-account : le compte pair accepte.

Tant que le statut n’est pas active (ex. pending-acceptance), les routes vers le pcx ne seront pas utilisables. En cross-compte, vérifiez le compte et la Region du peer-vpc-id avant de créer.

Étape 4 — Routes des deux côtés (obligatoire)

Sans routes, le peering est « actif » mais muet.

RT_A=$(aws ec2 describe-route-tables --filters Name=vpc-id,Values="$VPC_A" 
  --query 'RouteTables[0].RouteTableId' --output text)
RT_B=$(aws ec2 describe-route-tables --filters Name=vpc-id,Values="$VPC_B" 
  --query 'RouteTables[0].RouteTableId' --output text)

# Prefer custom RT associées aux subnets si vous en créez ; main RT OK pour lab minimal

aws ec2 create-route --route-table-id "$RT_A" 
  --destination-cidr-block 10.20.0.0/16 
  --vpc-peering-connection-id "$PCX"

aws ec2 create-route --route-table-id "$RT_B" 
  --destination-cidr-block 10.10.0.0/16 
  --vpc-peering-connection-id "$PCX"

Si plusieurs RT (public/privé), ajoutez la route sur chaque RT qui doit joindre le pair.

Astuce lab : filtrez la RT associée à SUB_A / SUB_B plutôt que d’assumer l’index [0]. Une route oubliée sur une seule RT privée est la cause n°1 des ping qui échouent alors que le pcx est active.

Étape 5 — DNS resolution (option)

aws ec2 modify-vpc-peering-connection-options 
  --vpc-peering-connection-id "$PCX" 
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true 
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

Utile pour résoudre les noms privés EC2 de l’autre VPC. Activez aussi enableDnsHostnames / enableDnsSupport sur chaque VPC si besoin — sinon les noms privés EC2 ne seront pas publiés correctement.

Étape 6 — Security Groups cross-VPC

Les SG peuvent référencer un SG du VPC pair dans la même Region (pas besoin d’ouvrir tout le CIDR) :

SG dans VPC-B : allow TCP 22 depuis SG de VPC-A (peered)

Sinon allow depuis 10.10.0.0/16 (moins précis).

En CLI, la règle source utilise l’ID du SG distant (--source-group) une fois le peering actif. Les NACL restent basées sur CIDR : si vous durcissez des NACL custom, autorisez les plages du pair dans les deux sens.

Peering inter-Region et inter-comptes

• Inter-Region : supporté ; attention latence et coûts data transfer. Les SG référencent moins facilement le pair distant — souvent CIDR.
• Inter-comptes : requester crée, accepter dans l’autre compte (même organisation ou externe). Taggez Name + propriétaire pour l’audit.

Ne confondez pas avec PrivateLink (endpoint service NLB) : PrivateLink n’expose pas tout le CIDR du VPC provider, seulement un service.

Inter-Region : spécifiez --peer-region à la création. Documentez la Region du pair (latence 30–80 ms pour apps chatty).

Étape 7 — Test connectivité (option EC2)

Deux EC2 (une par subnet), SG ICMP/TCP ouverts depuis le CIDR pair, sans IP publique obligatoire si vous passez par SSM + endpoints — ou bastion.
ping / nc vers l’IP privée du pair doit réussir.

Sans EC2, validez au moins : status active + routes présentes des deux côtés.

Si vous lancez des instances, notez leurs IP privées puis testez A→B. Un échec ICMP avec routes OK pointe vers SG ou NACL. Preférez un port TCP (nc -vz) pour coller à un scénario réel.

Scénario examen classique

« Trois VPC A, B et C : A peeré avec B, B peeré avec C. Pourquoi A ne joint pas C ? »
Réponse : pas de transitivité. Il faut un peering A–C, ou un Transit Gateway (hub) avec RT qui propage les CIDR. Autre piège : peering active mais ping KO → routes manquantes ou SG/NACL. Enfin : « sortir sur Internet via le NAT du VPC pair » → impossible via peering seul.

En SAA-C03, associez aussi « expose only an API » → PrivateLink, et « 40+ VPC dans l’orga » → TGW (+ RAM), pas une toile de pcx-*.

Lab bonus (5–8 min) — routes oubliées

1. Créez le peering et acceptez-le jusqu’à active.
2. N’ajoutez la route que dans RT_A (pas dans RT_B) : le test A→B échoue ou est asymétrique.
3. Ajoutez la route B→A : la connectivité privée revient.

Ce mini-lab fixe le réflexe : pcx active ≠ trafic ; les routes bilatérales sont obligatoires sur chaque RT concernée.

Étape 8 — Vérification

aws ec2 describe-vpc-peering-connections --vpc-peering-connection-ids "$PCX"
aws ec2 describe-route-tables --route-table-ids "$RT_A" "$RT_B" 
  --query 'RouteTables[].Routes'

Checklist : CIDR disjoints · pcx active · routes A→B et B→A · (DNS options si besoin).

Vérifiez aussi que la cible de chaque route est bien l’ID pcx-… et que l’état n’est pas blackhole après suppression accidentelle du peering.

Quand choisir peering vs autres options

Besoin	Option
2–3 VPC mêmes comptes, simple	VPC Peering
Beaucoup de VPC / spokes	Transit Gateway
Exposer seulement une API/NLB	PrivateLink
Datacenter on-prem	Direct Connect / VPN (+ TGW souvent)

En Solutions Architect Associate, on vous piège souvent sur la non-transitivité et l’oubli des routes. Autre piège : croire que le peering donne accès à Internet via le pair — ce n’est pas le cas.

Nettoyage

aws ec2 delete-route --route-table-id "$RT_A" --destination-cidr-block 10.20.0.0/16
aws ec2 delete-route --route-table-id "$RT_B" --destination-cidr-block 10.10.0.0/16
aws ec2 delete-vpc-peering-connection --vpc-peering-connection-id "$PCX"
aws ec2 delete-subnet --subnet-id "$SUB_A"
aws ec2 delete-subnet --subnet-id "$SUB_B"
aws ec2 delete-vpc --vpc-id "$VPC_A"
aws ec2 delete-vpc --vpc-id "$VPC_B"

Ordre : routes → peering → subnets → VPC. Si des ENI ou instances restent, delete-vpc échouera.

Checklist avant prod

1. CIDR documentés (IPAM / spreadsheet) — zéro overlap futur.
2. Routes sur toutes les RT concernées (pas seulement la main).
3. SG least privilege (SG-to-SG si same Region).
4. Flow Logs sur les deux VPC pour debug.
5. Tags Name, Owner, Environment sur pcx-*.
6. Documenter requester/accepter (surtout cross-compte) et la Region du pair.
7. Vérifier qu’aucune route blackhole ne reste après un delete/recreate de peering.

Erreurs fréquentes

Symptôme	Cause	Correction
InvalidVpcPeering / create fail	CIDR overlap	Changer un CIDR
Peering active mais ping fail	Routes manquantes / SG	Routes bilatérales + SG
Espoir A↔C via B	Pas de transitivité	TGW ou peering A–C
Cross-region	Possible mais latence+	Documenter Region pair
Route blackhole	Peering supprimé / pas encore active	Recréer pcx ou attendre active
DNS privé KO cross-VPC	Options peering / DNS VPC off	AllowDnsResolutionFromRemoteVpc + DNS hostnames

Autres cas : accepter oublié (pending-acceptance) ; route sur la mauvaise RT ; NACL deny ; DNS privé sans options peering. Rejouez la checklist de l’étape 8 avant de refaire les ressources. En ca-central-1, gardez les deux VPC dans la même Region pour le lab ; documentez --peer-region seulement si vous testez l’inter-Region volontairement.

Quiz (5 questions)

1. Le VPC peering est-il transitif ? – A. Oui toujours
– B. Non
– C. Seulement en ca-central-1

2. Après acceptation du peering, il manque souvent : – A. Un certificat ACM
– B. Les routes vers le CIDR pair
– C. Un ALB obligatoire

3. Beaucoup de VPC à mailler → plutôt : – A. Une toile de peerings N²
– B. Transit Gateway (hub)
– C. Un seul Security Group mondial

4. Un peering permet-il d’utiliser l’IGW / NAT du VPC pair ? – A. Oui, automatiquement
– B. Non — pas d’accès edge du pair via peering
– C. Seulement si DNS est activé

5. Pour exposer seulement une API (NLB) sans partager tout le CIDR : – A. VPC Peering mesh
– B. PrivateLink (endpoint service)
– C. Ouvrir 0.0.0.0/0 sur la NACL

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

• VPC peering
• Peering limitations
• Prochain : Transit Gateway

Maillage série AWS (P1)

← Précédent	SG vs NACL
→ Suivant	Transit Gateway
Aussi	VPC fondations

---

Retour parcours AWS — hub de la série et leçons sœurs.