Connecter Deux VPCs avec le VPC Peering : Configuration et Tables de Routage

Vous avez deux VPCs dans le même compte et la même région AWS, et vos instances ne peuvent pas se parler en IP privée — c'est une situation classique quand on sépare les environnements (prod/staging) ou qu'on isole des workloads par domaine métier. Le VPC Peering est la solution native pour établir cette connectivité sans passer par Internet, mais la moitié des ingénieurs qui le configurent pour la première fois se retrouvent avec une connexion 'Active' qui ne route toujours rien, parce qu'ils ont oublié de mettre à jour les tables de routage des deux côtés.

TL;DR — Résumé de la Configuration VPC Peering

ÉtapeActionCôté concerné
1Créer la demande de peeringVPC requérant
2Accepter la connexion de peeringVPC acceptant
3Ajouter une route vers le CIDR distantLes deux VPCs
4Mettre à jour les Security GroupsLes deux VPCs
5Vérifier la résolution DNS (optionnel)Les deux VPCs

Comment Fonctionne le VPC Peering AWS

Un VPC Peering crée une connexion réseau privée entre deux VPCs. Le trafic transite par l'infrastructure AWS — il ne passe jamais par Internet public, ni par un VPN, ni par une passerelle. Du point de vue du routage, chaque VPC voit l'autre comme un réseau adjacent directement accessible via une route statique pointant vers l'identifiant de la connexion de peering (pcx-xxxxxxxx).

Contrainte fondamentale : les blocs CIDR des deux VPCs ne doivent pas se chevaucher. Si VPC-A utilise 10.0.0.0/16 et VPC-B utilise aussi 10.0.0.0/16, le peering sera refusé. Vérifiez cela avant de commencer.

Autre point critique : le VPC Peering n'est pas transitif. Si VPC-A est peeré avec VPC-B, et VPC-B est peeré avec VPC-C, VPC-A ne peut pas atteindre VPC-C via VPC-B. Chaque paire de VPCs nécessite sa propre connexion de peering.

graph LR subgraph VPCA ["VPC-A — 10.0.0.0/16"] InstA["Instance A 10.0.1.10"] RTA["Table de routage A 10.1.0.0/16 → pcx"] end subgraph VPCB ["VPC-B — 10.1.0.0/16"] InstB["Instance B 10.1.1.20"] RTB["Table de routage B 10.0.0.0/16 → pcx"] end PCX["Connexion Peering pcx-0abc123456789def0 État: Active"] InstA --> RTA RTA --> PCX PCX --> RTB RTB --> InstB
  1. VPC-A (CIDR 10.0.0.0/16) initie la demande de peering vers VPC-B.
  2. VPC-B (CIDR 10.1.0.0/16) accepte la connexion — la liaison pcx-xxxxxxxx passe en état 'Active'.
  3. Chaque VPC doit avoir une route dans sa table de routage pointant le CIDR de l'autre vers la connexion de peering.
  4. Les Security Groups de chaque côté doivent autoriser le trafic entrant depuis le CIDR distant (ou depuis un SG spécifique).

Prérequis — Vérifier les CIDRs Avant Tout

Avant de créer quoi que ce soit, récupérez les CIDRs de vos deux VPCs. Un chevauchement rend le peering impossible et AWS le rejettera immédiatement.

# Lister tous les VPCs du compte avec leurs CIDRs
aws ec2 describe-vpcs \
  --query 'Vpcs[*].{VpcId:VpcId,CIDR:CidrBlock,Name:Tags[?Key==`Name`].Value|[0]}' \
  --output table \
  --region us-east-1

Notez les identifiants VpcId et les blocs CIDR des deux VPCs. Vous en aurez besoin à chaque étape suivante.

Étape 1 : Créer la Demande de VPC Peering

Dans le même compte et la même région, vous êtes à la fois le requérant et l'acceptant — mais AWS exige quand même que vous passiez par les deux étapes. La demande crée la connexion en état 'pending-acceptance', et vous devez l'accepter explicitement même si les deux VPCs vous appartiennent.

# Créer la demande de peering depuis VPC-A vers VPC-B
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-0abc123456789def0 \
  --peer-vpc-id vpc-0def987654321abc0 \
  --region us-east-1

La commande retourne un objet JSON contenant le champ VpcPeeringConnectionId (format pcx-xxxxxxxxxxxxxxxx). Conservez cet identifiant — il est nécessaire pour toutes les étapes suivantes.

# Vérifier l'état de la connexion de peering
aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0abc123456789def0 \
  --query 'VpcPeeringConnections[0].{Status:Status.Code,Requester:RequesterVpcInfo.CidrBlock,Accepter:AccepterVpcInfo.CidrBlock}' \
  --output table \
  --region us-east-1

L'état doit afficher pending-acceptance à ce stade.

Étape 2 : Accepter la Connexion de VPC Peering

Même compte, même région — l'acceptation reste obligatoire. C'est une protection délibérée d'AWS contre les connexions de peering non souhaitées. Sans cette étape, la connexion expire automatiquement après 7 jours.

# Accepter la connexion de peering
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-0abc123456789def0 \
  --region us-east-1

Après acceptation, vérifiez que le statut passe bien à active :

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

Si vous voyez active, la connexion de peering est établie. Mais à ce stade, aucun trafic ne passe encore — les tables de routage n'ont pas été mises à jour.

Étape 3 : Mettre à Jour les Tables de Routage — Les Deux Côtés

C'est l'étape que la plupart des gens ratent. Une connexion de peering 'Active' ne signifie pas que le trafic est routé. Chaque VPC doit avoir une entrée dans sa table de routage indiquant : 'pour atteindre le CIDR de l'autre VPC, utilise cette connexion de peering'. Si vous oubliez un seul côté, le trafic sera asymétrique et les connexions TCP échoueront.

Commencez par identifier les tables de routage associées aux subnets concernés dans chaque VPC :

# Lister les tables de routage de VPC-A
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0abc123456789def0 \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Associations:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1
# Lister les tables de routage de VPC-B
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0def987654321abc0 \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Associations:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1

Ajoutez ensuite la route dans la table de routage de VPC-A pour atteindre le CIDR de VPC-B :

# Dans VPC-A : route vers le CIDR de VPC-B via la connexion de peering
aws ec2 create-route \
  --route-table-id rtb-0abc111222333444a \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-0abc123456789def0 \
  --region us-east-1

Puis la route symétrique dans la table de routage de VPC-B :

# Dans VPC-B : route vers le CIDR de VPC-A via la connexion de peering
aws ec2 create-route \
  --route-table-id rtb-0def555666777888b \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id pcx-0abc123456789def0 \
  --region us-east-1

Si vos VPCs ont plusieurs tables de routage (subnets publics et privés séparés), répétez l'opération pour chaque table de routage dont les subnets doivent communiquer.

graph TD A["Paquet depuis VPC-A 10.0.1.10 → 10.1.1.20"] --> B["Table de routage VPC-A 10.1.0.0/16 → pcx-xxx"] B --> C["Connexion Peering pcx-0abc123456789def0"] C --> D["Table de routage VPC-B 10.0.0.0/16 → pcx-xxx"] D --> E["Instance cible VPC-B 10.1.1.20"] E --> F["Réponse retour 10.1.1.20 → 10.0.1.10"] F --> D D -->|"Route de retour manquante? Trafic perdu"| G["⚠️ Timeout TCP"] D -->|"Route de retour présente"| C
  1. La table de routage de VPC-A contient une entrée : destination 10.1.0.0/16, cible pcx-0abc123456789def0.
  2. La table de routage de VPC-B contient une entrée symétrique : destination 10.0.0.0/16, cible pcx-0abc123456789def0.
  3. Sans les deux routes, le trafic TCP ne peut pas s'établir — les paquets de retour n'ont pas de chemin.

Étape 4 : Mettre à Jour les Security Groups

Les tables de routage définissent le chemin réseau. Les Security Groups définissent ce qui est autorisé à circuler sur ce chemin. Même avec un routage parfait, si le Security Group de votre instance dans VPC-B n'autorise pas le trafic entrant depuis le CIDR de VPC-A, les connexions seront silencieusement bloquées — sans message d'erreur explicite côté application.

Récupérez l'identifiant du Security Group de l'instance cible dans VPC-B :

# Lister les Security Groups de VPC-B
aws ec2 describe-security-groups \
  --filters Name=vpc-id,Values=vpc-0def987654321abc0 \
  --query 'SecurityGroups[*].{GroupId:GroupId,GroupName:GroupName}' \
  --output table \
  --region us-east-1

Autorisez le trafic entrant depuis le CIDR de VPC-A (exemple : port 443) :

# Autoriser le trafic HTTPS entrant depuis VPC-A vers une instance dans VPC-B
aws ec2 authorize-security-group-ingress \
  --group-id sg-0def123456789abc0 \
  --protocol tcp \
  --port 443 \
  --cidr 10.0.0.0/16 \
  --region us-east-1

Faites de même pour les Security Groups des instances dans VPC-A si elles doivent recevoir du trafic en retour initié depuis VPC-B. Les Security Groups AWS sont stateful — les réponses aux connexions initiées sont automatiquement autorisées, mais les nouvelles connexions initiées depuis VPC-B vers VPC-A nécessitent leurs propres règles d'entrée.

Étape 5 : Activer la Résolution DNS via le Peering (Optionnel)

Par défaut, si une instance dans VPC-A résout le nom DNS public d'une instance dans VPC-B, elle obtient l'IP publique — pas l'IP privée. Pour que la résolution DNS retourne les IPs privées à travers la connexion de peering, vous devez activer deux attributs DNS sur la connexion.

# Activer la résolution DNS côté requérant (VPC-A)
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0abc123456789def0 \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region us-east-1
# Activer la résolution DNS côté acceptant (VPC-B)
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0abc123456789def0 \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region us-east-1

Cette configuration n'est utile que si vos instances utilisent des noms DNS AWS générés automatiquement. Si vous utilisez Route 53 Private Hosted Zones partagées entre VPCs, le mécanisme est différent.

Diagnostic : La Connexion est 'Active' mais le Trafic ne Passe Pas

C'est le scénario classique. Vous avez la connexion de peering en état 'Active', vous êtes convaincu d'avoir tout configuré, et pourtant un simple curl entre deux instances timeout sans réponse.

Symptôme observé : curl http://10.1.0.45:8080 depuis une instance dans VPC-A retourne Connection timed out après 2 minutes. Pas de refus de connexion, pas d'erreur DNS — juste un timeout.

Première hypothèse (mauvaise) : le Security Group bloque. On ajoute une règle 0.0.0.0/0 en entrée sur le port 8080. Toujours timeout.

Cause réelle : la route dans la table de routage de VPC-B a été ajoutée sur la table de routage principale, mais le subnet de l'instance cible est associé à une table de routage personnalisée qui n'a pas la route de retour. Les paquets arrivent à l'instance, mais les réponses sont envoyées vers la passerelle par défaut au lieu de la connexion de peering.

Vérification :

# Identifier la table de routage effective du subnet de l'instance cible
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0target123456789ab \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Routes:Routes[*].{Dest:DestinationCidrBlock,Target:VpcPeeringConnectionId}}' \
  --output json \
  --region us-east-1

Si la route vers 10.0.0.0/16 n'apparaît pas dans le résultat, c'est confirmé — vous avez mis à jour la mauvaise table de routage. Ajoutez la route sur la table de routage correcte (celle associée au subnet de l'instance) et le trafic passera immédiatement.

Une connexion de peering ressemble à une autoroute construite entre deux villes. Les tables de routage sont les panneaux de signalisation qui indiquent aux voitures comment y accéder. Sans les panneaux des deux côtés, les voitures ne trouvent pas l'entrée — même si l'autoroute existe.

Vérification Finale de la Configuration VPC Peering

Avant de déclarer la configuration terminée, validez chaque couche indépendamment :

# Vérifier l'état de la connexion de peering
aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0abc123456789def0 \
  --query 'VpcPeeringConnections[0].{Status:Status.Code,RequesterCIDR:RequesterVpcInfo.CidrBlock,AccepterCIDR:AccepterVpcInfo.CidrBlock}' \
  --output table \
  --region us-east-1
# Vérifier les routes dans la table de routage de VPC-A
aws ec2 describe-route-tables \
  --route-table-ids rtb-0abc111222333444a \
  --query 'RouteTables[0].Routes[?VpcPeeringConnectionId!=null]' \
  --output table \
  --region us-east-1
# Vérifier les routes dans la table de routage de VPC-B
aws ec2 describe-route-tables \
  --route-table-ids rtb-0def555666777888b \
  --query 'RouteTables[0].Routes[?VpcPeeringConnectionId!=null]' \
  --output table \
  --region us-east-1

Si les trois commandes retournent les valeurs attendues et que le trafic ne passe toujours pas, l'étape suivante est de vérifier les Network ACLs au niveau subnet — elles sont stateless et peuvent bloquer le trafic de retour même si les Security Groups sont corrects.

# Vérifier les Network ACLs associées aux subnets concernés
aws ec2 describe-network-acls \
  --filters Name=association.subnet-id,Values=subnet-0target123456789ab \
  --query 'NetworkAcls[*].{AclId:NetworkAclId,Entries:Entries[*].{Rule:RuleNumber,Action:RuleAction,CIDR:CidrBlock,Protocol:Protocol}}' \
  --output table \
  --region us-east-1

Conclusion et Prochaines Étapes pour votre VPC Peering

Le VPC Peering entre deux VPCs du même compte et de la même région se configure en cinq étapes : créer la demande, accepter la connexion, mettre à jour les tables de routage des deux côtés, ajuster les Security Groups, et optionnellement activer la résolution DNS. L'erreur la plus fréquente est de mettre à jour la table de routage principale alors que le subnet cible est associé à une table personnalisée.

Pour aller plus loin :

  • Si vous devez connecter plus de deux VPCs, évaluez AWS Transit Gateway — le peering en maillage complet devient rapidement ingérable au-delà de quelques VPCs.
  • Pour la résolution DNS cross-VPC avec des zones privées Route 53, consultez la documentation sur l'association de zones privées à des VPCs.
  • Consultez la documentation officielle AWS VPC Peering pour les cas limites (inter-région, inter-compte).

Glossaire — Termes Clés du VPC Peering

TermeDéfinition
VPC PeeringConnexion réseau privée entre deux VPCs permettant le routage via l'infrastructure AWS sans passer par Internet.
CIDR BlockPlage d'adresses IP attribuée à un VPC ou subnet. Les CIDRs de deux VPCs peerés ne doivent pas se chevaucher.
Table de routageEnsemble de règles déterminant où le trafic réseau est dirigé dans un VPC. Chaque subnet est associé à une table de routage.
Security GroupPare-feu stateful au niveau instance contrôlant le trafic entrant et sortant. Distinct des Network ACLs qui opèrent au niveau subnet.
Network ACLFiltre stateless au niveau subnet. Contrairement aux Security Groups, les règles de retour doivent être explicitement autorisées.

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite