Peering VPC vs PrivateLink — joignabilité complète ou service-seulement, et ce que votre partenaire veut vraiment

Une intégration partenaire commence par une demande informelle : « pouvez-vous nous donner une connectivité privée à votre API ? ». La réponse par défaut est de monter un peering VPC, d’échanger les CIDR, de mettre à jour les tables de routage des deux côtés, et d’expédier. Trois mois plus tard l’équipe d’audit du partenaire signale le peering comme trop large — ils ont une joignabilité réseau complète dans votre VPC, et le contrôle de sécurité sur ce qu’ils peuvent toucher est « on espère qu’ils n’appellent que le load balancer ». Le peering était la mauvaise primitive. La bonne est PrivateLink — il expose un seul service à travers la frontière et rien d’autre. Voici la ligne entre les deux, et comment choisir correctement du premier coup.

Ce qui se passe

Le peering VPC est une connexion au niveau réseau entre deux VPC. Une fois appairés, les instances dans le VPC A peuvent atteindre les IP de la plage CIDR du VPC B (sous réserve des tables de routage et des groupes de sécurité), et vice versa. Le peering est symétrique — les deux côtés voient le CIDR de l’autre. Le peering est non-transitif — A appairé à B et B appairé à C ne donne pas à A l’accès à C. Le peering est conscient de la région — le peering inter-région existe et est facturé aux tarifs de transfert inter-région. Le coût est horaire par peering plus le transfert de données.

Les capacités que le peering vous donne :

Joignabilité IP complète vers le CIDR du VPC partenaire.
La possibilité pour n’importe quelle instance dans l’un ou l’autre VPC d’initier une connexion vers n’importe quelle IP de l’autre.
Résolution DNS du DNS privé du VPC partenaire, si vous l’activez explicitement.

Les capacités que le peering ne vous donne pas :

Contrôle d’accès au niveau service. Une fois appairé, une instance dans le VPC partenaire peut faire nmap sur tout votre CIDR. La seule application est les groupes de sécurité par instance, ce qui veut dire que vous devez maintenir les règles SG à travers la frontière.
Tolérance au chevauchement CIDR. Deux VPC avec des CIDR qui se chevauchent ne peuvent pas être appairés.
Simplicité multi-comptes. Le peering inter-comptes fonctionne, mais la surface de contrôle de sécurité est « ils ont une route vers votre VPC » ce qui est rarement ce que votre équipe de sécurité veut.

AWS PrivateLink est une connexion au niveau service. Le fournisseur de service (vous) place un Network Load Balancer devant le service à exposer, puis crée un service d’endpoint VPC qui pointe sur ce NLB. Le consommateur du service (votre client ou partenaire) crée un endpoint d’interface dans son VPC pointant sur votre service d’endpoint. Son instance résout maintenant un nom d’hôte régional (vpce-xxx.us-east-1.vpce.amazonaws.com ou un nom DNS privé comme api.votredomaine.com si vous activez le DNS privé) vers l’ENI de l’endpoint dans son VPC. Le trafic circule de son VPC à travers PrivateLink vers votre NLB vers votre service. Les deux VPC ne sont pas appairés. Son VPC ne voit que le seul service que vous avez exposé. Votre VPC ne voit que les requêtes entrant via le NLB.

Les capacités que PrivateLink vous donne :

Exposition service-seulement. Le consommateur atteint un port TCP sur un NLB, rien d’autre.
Tolérance au chevauchement CIDR. Les deux VPC peuvent avoir des CIDR 10.0.0.0/16 identiques et ça marche — l’ENI de l’endpoint vit dans l’espace IP du consommateur, et le NLB possède la destination de votre côté. Aucune négociation CIDR.
Autorisation par consommateur. Chaque compte client reçoit une acceptation explicite pour utiliser votre service d’endpoint. L’ID de compte du consommateur est le principal IAM que vous accordez.
DNS qui marche tout seul. Le SDK du consommateur appelle api.votredomaine.com ; le DNS privé le résout vers l’ENI de l’endpoint ; l’appel arrive sur votre service. Pas de bricolage /etc/hosts, pas de drapeau de résolution DNS du peer.

Les capacités que PrivateLink ne vous donne pas :

Joignabilité complète. Si vous avez cinq services, il vous faut cinq services d’endpoint (ou un NLB avec cinq target groups, ce qui marche pour les mises en place HTTPS-seulement mais contraint le protocole). PrivateLink est la mauvaise primitive quand le modèle de connectivité est « joignabilité réseau usage général ».
Flux symétrique. Le consommateur appelle le fournisseur. Le fournisseur ne peut pas initier vers le consommateur. Pour une API requête/réponse c’est bien ; pour un webhook de retour le fournisseur doit trouver un chemin public (ce qui annule l’intérêt).

Comment vérifier

Le cadre de décision est « quelle est la vraie exigence de connectivité ? »

Exigence	Peering	PrivateLink
Même organisation, deux VPC qui doivent se parler entièrement	oui	excessif
Exposition d’API inter-comptes à un client	trop large	oui
Fournisseur SaaS exposant une API à de nombreux clients	mauvais	oui
Client consommant une API SaaS en privé	dépend du fournisseur ; s’il l’offre, préférer PrivateLink	oui si le fournisseur le supporte
VPC de services partagés joignable depuis plusieurs environnements	TGW, pas peering ni PrivateLink	pas le bon outil
VPC avec CIDR qui se chevauchent	impossible	marche
Accès base de données inter-comptes	trop large ; considérer comme un mauvais choix	oui
Trafic général bidirectionnel	oui	impossible

Le pivot le plus commun qu’on voit : un SaaS B2B qui a commencé par mettre en place un peering VPC avec chaque client (parce que « connectivité privée » était la demande et le peering était la première réponse qu’il connaissait). Au sixième client, les CIDR de peering entrent en collision ; la négociation CIDR devient un blocant commercial ; l’équipe de sécurité signale que le VPC appairé du client A peut techniquement atteindre le trafic du client B via un bastion partagé. La correction est d’exposer l’API via un service d’endpoint PrivateLink. Chaque client crée un endpoint unidirectionnel vers le VPC du SaaS. Le chevauchement CIDR est sans importance. Le client A ne voit pas le client B. La liste d’autorisation du service d’endpoint est le contrôle d’accès style IAM.

L’autre pivot : le côté client. Consommer un SaaS via PrivateLink plutôt que par Internet public vaut la peine quand :

Le SaaS le supporte.
La sensibilité des données justifie le coût opérationnel d’un endpoint de plus par AZ.
Le client est assez gros pour que les économies de coûts sortants sur le trafic inter-région justifient le coût horaire de l’endpoint.

Pour la plupart des petites intégrations SaaS-client, HTTPS public avec clés API est plus simple. PrivateLink est la bonne réponse à l’extrémité entreprise de la base clients où « aucun chemin Internet public » est une vraie exigence.

La correction

La procédure de décision pour une nouvelle exigence de connectivité privée :

Demandez « à quoi sert la connectivité ? » Si la réponse est « on veut que leurs serveurs applicatifs appellent notre API », c’est service-seulement. PrivateLink. Si la réponse est « on veut une joignabilité complète entre nos deux VPC pour une intégration qui va grandir », c’est niveau réseau. Peering ou TGW.
Demandez « combien de parties ? » Deux VPC, même organisation, qui ne grandiront pas : le peering convient. Trois ou plus, même organisation : TGW. Un service exposé à de nombreuses parties : PrivateLink. La décision peering vs PrivateLink porte fondamentalement sur si la connectivité est plusieurs-à-un (PrivateLink) ou deux-à-deux (peering).

Pour la mise en place côté fournisseur PrivateLink :

# 1. NLB devant le service
aws elbv2 create-load-balancer \
  --name api-private-nlb \
  --type network \
  --scheme internal \
  --subnets subnet-prod-1a subnet-prod-1b subnet-prod-1c

# 2. Service d'endpoint pointant sur le NLB
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/net/api-private-nlb/abc123 \
  --acceptance-required \
  --private-dns-name api.example.com

# 3. Autoriser des comptes clients spécifiques
aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id vpce-svc-abc123 \
  --add-allowed-principals arn:aws:iam::555566667777:root

Pour la mise en place côté consommateur PrivateLink (dans le compte du client) :
```
aws ec2 create-vpc-endpoint \
  --vpc-endpoint-type Interface \
  --vpc-id vpc-customer123 \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-abc123 \
  --subnet-ids subnet-customer-1a subnet-customer-1b subnet-customer-1c \
  --security-group-ids sg-allow-app-to-endpoint \
  --private-dns-enabled
```
Le drapeau --private-dns-enabled fait que api.example.com résout vers l’ENI de l’endpoint depuis le VPC du client. Cela exige que le fournisseur ait vérifié le domaine (enregistrement DNS TXT) et que le client ait enableDnsHostnames et enableDnsSupport sur son VPC.

Pour le peering, quand c’est vraiment le bon outil :

# Demander le peering depuis le compte du VPC A
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-a-123 \
  --peer-vpc-id vpc-b-456 \
  --peer-owner-id 555566667777 \
  --peer-region us-east-1

# Accepter depuis le compte du VPC B
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-abc123

# Ajouter des routes des deux côtés
aws ec2 create-route \
  --route-table-id rtb-a-private \
  --destination-cidr-block 10.30.0.0/16 \
  --vpc-peering-connection-id pcx-abc123

Mettez à jour les groupes de sécurité des deux côtés pour autoriser le trafic spécifique qui compte. Le défaut est de n’autoriser rien — le peering ouvre la route, les SG ouvrent la conversation.

La migration du peering vers PrivateLink est directe une fois le NLB en place : montez le service d’endpoint, faites créer l’endpoint au client, basculez son DNS vers le nom d’endpoint privé, surveillez une semaine, démontez le peering. La partie la plus dure est de convaincre l’équipe du client que le changement vaut la peine — habituellement il faut une revue de sécurité qui signale d’abord le peering comme trop large.

L’autre règle qu’on tient : PrivateLink est la bonne primitive pour les intégrations SaaS-client, point. Même si le premier client aurait été correct avec un peering, le deuxième aura une collision CIDR et le troisième aura une constatation d’audit. Commencer avec le service d’endpoint est le chemin à plus bas coût.

Pour la suite multi-VPC quand les deux côtés sont à l’intérieur de la même organisation, voir Transit Gateway en étoile. Pour le côté coût-de-sortie de la décision d’endpoint, voir Endpoints VPC — passerelle et interface.

Stack Harbor conçoit et audite les topologies VPC en production dans le cadre de Gestion AWS et des Environnements infogérés en continu. Si vos intégrations clients tournent sur des peerings trop larges, commencez par une consultation d’infrastructure.