AWS PrivateLink sur Vercel : ce que les équipes Pro et Enterprise y gagnent
AWS PrivateLink relie Vercel aux services AWS sans passer par l’Internet public. Découvrez ses tarifs, ses prérequis et ses limites avant de vous lancer.
Le 1er septembre 2026, Vercel a rendu AWS PrivateLink accessible aux équipes Pro et Enterprise via Advanced Networking. Leurs Vercel Functions et leurs builds disposent ainsi d’un accès privé aux services AWS compatibles, sans faire transiter le trafic par l’Internet public.
AWS PrivateLink sur Vercel : de quoi s’agit-il ?
PrivateLink modifie le chemin réseau entre un projet Vercel et son backend. Il ne déplace pas ce backend, ne remplace pas son système d’authentification et ne réserve pas non plus un cloud Vercel à votre seul usage.
Imaginez un corridor privé entre le réseau de Vercel et un service publié sur AWS. Un endpoint VPC en constitue la porte d’entrée. VPC signifie « virtual private cloud » : c’est la frontière réseau isolée d’AWS. Avec 2 zones de disponibilité, Vercel déploie l’endpoint dans 2 zones prises en charge par le service.
Lors de la création d’une connexion, Vercel provisionne un endpoint dédié à votre équipe dans 2 zones de disponibilité compatibles avec le service cible. Vercel attribue également à l’équipe un rôle IAM AWS, c’est-à-dire l’identité que le propriétaire du service peut autoriser, ainsi qu’un nom d’hôte stable :
<service>.team_<team-id>.endpoints.vercel.com
Vos Functions déployées et vos tâches de build utilisent ce nom d’hôte. Le trafic destiné au service passe par l’endpoint privé, tandis que Vercel comptabilise le volume transféré sur cette connexion.
Voilà tout le mécanisme : l’application continue de joindre un nom d’hôte, mais le réseau achemine les paquets correspondants par la voie privée.
Ce qui change vraiment : l’exposition du réseau
La nouveauté porte sur l’exposition réseau. Une équipe Pro peut désormais soustraire le trafic vers les backends compatibles à l’Internet public sans devoir passer à un VPC dédié.
Cette option est utile avec RDS, Aurora, Neon, Redshift, Snowflake, MongoDB Atlas, Confluent, un service interne placé derrière un AWS Network Load Balancer, ou encore S3 et DynamoDB via des gateway endpoints. La cible doit néanmoins publier un service d’endpoint AWS PrivateLink. Sans cela, la fonctionnalité n’a aucun point auquel se connecter.
La tarification devient simple une fois la question d’Advanced Networking réglée. La première connexion PrivateLink est incluse avec Advanced Networking. Chaque connexion supplémentaire coûte $30 par mois, auxquels Vercel ajoute $0.04 par GB transféré via PrivateLink.
Prenons un cas concret : 2 connexions régionales transfèrent 500 GB au total. Le transfert revient à $20. La connexion supplémentaire ajoute $30, soit une ligne PrivateLink de $50 par mois pour la connexion et le transfert.
Les utilisateurs Hobby ne sont pas concernés par cette nouveauté. Rien ne change non plus dans l’immédiat pour les équipes dont le backend se trouve hors d’AWS, ne publie aucun endpoint PrivateLink ou peut accepter du trafic public sans risque.
Choisir l’option réseau adaptée au niveau d’isolation
Ces solutions réseau de Vercel répondent à des besoins différents.
PrivateLink occupe une position intermédiaire. Il crée une voie privée vers un service, tout en conservant un VPC sous-jacent partagé. Si le cahier des charges impose un « réseau à locataire unique », choisissez Secure Compute. S’il demande seulement une « adresse IP connue » et autorise le routage public, l’option Static IPs peut suffire.
Qui peut en profiter dès maintenant ?
Un fondateur SaaS dont la base de données est sur AWS
Un fondateur qui héberge son application sur Vercel Pro et sa base de données sur RDS ou Aurora peut relier le projet au service d’endpoint de la base, autoriser le rôle IAM de Vercel, puis remplacer l’hôte de base de données de l’application par le nom d’hôte géré par Vercel.
Le gain est ciblé, mais concret : le trafic de la base emprunte une voie privée sans remettre en cause le processus de déploiement Vercel existant. Il ne s’agit pas d’une isolation réseau complète, mais cette configuration peut supprimer un accès public qui bloquait une revue de sécurité.
Un ingénieur plateforme qui expose une API interne
Un ingénieur plateforme peut placer un service interne derrière un AWS Network Load Balancer, publier le service d’endpoint et ajouter le rôle IAM fourni par Vercel à la liste des identités autorisées. Les Functions peuvent alors appeler ce service via le nom d’hôte stable, plutôt qu’au moyen d’une adresse d’API publique.
Le travail de sécurisation du périmètre s’allège. Le propriétaire du service approuve un seul principal AWS et conserve le service hors de l’Internet public.
Une équipe data qui utilise un service managé
Une équipe data qui construit son produit avec Snowflake, MongoDB Atlas ou Confluent peut utiliser l’endpoint PrivateLink du fournisseur, à condition que celui-ci en propose un dans la région AWS correspondante. L’application et ses tâches de build partagent alors la même connexion privée.
La liaison entre un déploiement Vercel et le service de données devient ainsi plus simple. La faisabilité de l’architecture reste toutefois dictée par la disponibilité des endpoints chez le fournisseur.
Une équipe backend multi-région
Une équipe backend déployée au plus près des utilisateurs dans plusieurs régions a besoin de 1 connexion PrivateLink par région AWS. Le service doit être présent dans chaque région correspondante ou prendre en charge PrivateLink entre régions.
Le trafic est moins exposé sans forcer tous les appels à transiter par une seule région. La contrepartie est tout aussi claire : chaque connexion régionale supplémentaire ajoute $30 par mois avant même le transfert.
Configurer AWS PrivateLink dans le bon ordre
Vérifier que la cible est compatible
Demandez au propriétaire ou au fournisseur du service le nom du service d’endpoint AWS et sa région. Le service doit accepter tous les principaux AWS ou autoriser le rôle IAM que Vercel attribue à votre équipe.
Activer la fonctionnalité réseau de Vercel
Ouvrez le projet, puis accédez à Settings, Networking, Advanced Networking et AWS PrivateLink. Activez Advanced Networking si cette option ne l’est pas encore pour l’équipe.
Créer la connexion
Sélectionnez New Connection, saisissez le nom du service d’endpoint, choisissez la région correspondante, puis décidez d’activer ou non Private DNS.
Utiliser le nom d’hôte de Vercel
Faites pointer l’hôte du service utilisé par l’application vers le nom stable sous
endpoints.vercel.comcréé par Vercel. Ne partez pas du principe que le nom de la zone hébergée privée du fournisseur sera résolu depuis le réseau partagé de Vercel.Redéployer et contrôler
Redéployez le projet, puis vérifiez que les requêtes vers le backend aboutissent via la connexion, aussi bien à l’exécution que pendant les builds.
L’erreur la plus courante concerne le DNS. Sur le réseau partagé de Vercel, les endpoints d’interface ne peuvent pas utiliser la zone hébergée privée du fournisseur. Utilisez le nom d’hôte géré par Vercel, et non le nom d’endpoint généré par AWS ni le nom d’hôte public du fournisseur.
Les limites à connaître
Chaque connexion n’existe que dans 1 région AWS. L’affectation à un projet s’étend à tous les environnements de ce projet : impossible donc d’activer PrivateLink en production tout en le désactivant pour les previews au sein du même projet.
Routing Middleware ne se trouve pas non plus sur ce chemin, car il s’exécute à l’edge. Seuls les endpoints d’interface et les endpoints de passerelle sont pris en charge. Les endpoints Gateway Load Balancer et les endpoints de ressources ne le sont pas.
PrivateLink règle le routage réseau, pas l’autorisation applicative. Le mot de passe de la base de données, la politique IAM, le token de service et les droits des utilisateurs restent indispensables. Pour les applications agentiques qui ont besoin d’identifiants fournisseur managés, Vercel Connect constitue une couche d’authentification distincte.
Que faire maintenant ?
Passez à l’action cette semaine si vous utilisez Pro ou Enterprise, si la cible publie déjà un endpoint AWS PrivateLink et si la suppression du passage par le réseau public comble une véritable lacune de sécurité ou de conformité. Commencez par un service dans sa région AWS, puis contrôlez le trafic d’exécution et de build avant d’ajouter d’autres régions.
Attendez si le fournisseur ne peut pas communiquer de nom de service d’endpoint, si les previews et la production doivent suivre des règles réseau différentes au sein d’un même projet, ou si l’équipe n’a pas encore confirmé le tarif d’Advanced Networking.
Préférez Static IPs si le backend exige uniquement une liste d’adresses IP autorisées et si le routage public convient. Choisissez Secure Compute lorsque le besoin porte sur un VPC dédié ou du VPC peering. Les équipes Hobby et celles qui appellent des services situés hors d’AWS ne sont pas concernées par cette nouveauté.
Recevez une explication claire du prochain changement de plateforme.
2 sept. 2026
Préférez ce site dans Google
Marquez omidsaffari.com comme source préférée et Google le met en avant pour vous dans Top Stories, AI Overviews et AI Mode.
