Vercel AWS PrivateLink: qué ofrece a los equipos Pro
Vercel añade AWS PrivateLink en Pro y Enterprise para conectar servicios AWS por red privada. Analizamos su configuración, precios y límites.
El 1 de septiembre de 2026, Vercel puso AWS PrivateLink a disposición de los equipos Pro y Enterprise mediante Advanced Networking. Esto proporciona a tus Vercel Functions y compilaciones (builds) una ruta privada hacia servicios de AWS compatibles, evitando que el tráfico tenga que cruzar la internet pública.
Qué es realmente Vercel AWS PrivateLink
PrivateLink cambia el camino entre tu proyecto de Vercel y tu backend. No traslada el backend, no reemplaza sus mecanismos de autenticación ni le da a Vercel una nube dedicada exclusiva para ti.
Imagínalo como un pasillo privado desde la red de Vercel hasta un servicio publicado en AWS. Un endpoint de VPC es la puerta de entrada a ese pasillo. VPC significa nube privada virtual (virtual private cloud), que define el límite de red aislado de AWS. Usar 2 Availability Zones significa que Vercel distribuye el endpoint a través de 2 zonas compatibles con dicho servicio.
Cuando creas una conexión, Vercel aprovisiona un endpoint dedicado para tu equipo en 2 Availability Zones admitidas por el servicio de destino. Vercel también asigna a tu equipo un rol de AWS IAM, que es la identidad que el propietario del servicio puede autorizar, y le otorga a la conexión un hostname estable:
<service>.team_<team-id>.endpoints.vercel.com
Tus Functions desplegadas y tus procesos de build utilizan ese hostname. El tráfico dirigido al servicio de destino viaja por el endpoint privado, mientras Vercel registra el consumo de transferencia de esa conexión.
Ese último detalle resume todo el mecanismo. Tu aplicación sigue comunicándose con un hostname. La red es la que decide que los paquetes para ese hostname viajen por la vía privada.
El impacto real: exposición de red
El único eje que ha cambiado es la exposición de red. Un equipo en el plan Pro ahora puede mantener el tráfico hacia un backend compatible fuera de la internet pública sin tener que contratar una VPC dedicada.
Esto resulta útil cuando el destino es RDS, Aurora, Neon, Redshift, Snowflake, MongoDB Atlas, Confluent, un servicio interno detrás de un AWS Network Load Balancer, o S3 y DynamoDB a través de gateway endpoints. El servicio de destino debe publicar necesariamente un endpoint service de AWS PrivateLink. Si no lo hace, esta funcionalidad no tiene a qué conectarse.
La estructura de precios es sencilla una vez resuelto el coste de Advanced Networking. La primera conexión de PrivateLink está incluida con Advanced Networking. Cada conexión adicional cuesta $30 por mes, y Vercel factura $0.04 por GB transferido a través de PrivateLink.
Como ejemplo concreto: supongamos que 2 conexiones regionales transfieren 500 GB en total. La transferencia suma $20. La conexión adicional añade $30, por lo que el coste publicado de conexión y transferencia de PrivateLink asciende a $50 por mes.
Los usuarios de planes Hobby no están incluidos en este lanzamiento. Los equipos cuyo backend esté fuera de AWS, no exponga un endpoint de PrivateLink o pueda recibir tráfico público de forma segura tampoco verán ningún cambio inmediato.
Cómo elegir la opción de red adecuada
Estas opciones de red de Vercel resuelven problemas distintos.
PrivateLink se sitúa en el punto intermedio. Ofrece un canal privado hacia un servicio concreto, pero la VPC subyacente sigue siendo compartida. Si tu requisito exige una “red de un solo inquilino”, utiliza Secure Compute. Si basta con tener una “dirección IP conocida” y el enrutamiento público es admisible, Static IPs puede ser suficiente.
Quién puede implementarlo de inmediato
Fundadores de SaaS con bases de datos en AWS
Un fundador cuya aplicación corre en Vercel Pro y cuya base de datos reside en RDS o Aurora puede conectar el proyecto al endpoint service de la base de datos, autorizar el rol de IAM de Vercel y cambiar el host de la base de datos en la aplicación por el hostname gestionado por Vercel.
La ventaja es puntual pero directa: el tráfico de la base de datos gana una ruta privada mientras el equipo conserva su flujo de despliegue habitual en Vercel. No es un aislamiento de red total, pero elimina una vía pública que solía frenar auditorías de seguridad.
Ingenieros de plataforma que exponen APIs internas
Un ingeniero de plataforma puede situar un servicio interno detrás de un AWS Network Load Balancer, publicar el endpoint service y autorizar en la lista de permitidos el rol de IAM suministrado por Vercel. A partir de ahí, las Functions pueden invocar ese servicio mediante el hostname estable en lugar de una dirección API pública.
El beneficio es reducir trabajo perimetral: el responsable del servicio aprueba una única entidad principal de AWS y mantiene el servicio fuera de la internet pública.
Equipos de datos con servicios gestionados
Un equipo de producto de datos que trabaje con Snowflake, MongoDB Atlas o Confluent puede recurrir al endpoint de PrivateLink de dicho proveedor si este lo ofrece en la misma AWS Region. La aplicación y sus procesos de build comparten esa misma conexión privada.
El resultado es un canal más limpio entre el despliegue en Vercel y el servicio de datos. La disponibilidad del endpoint en el proveedor determinará si la arquitectura es viable.
Equipos con backends multirregión
Un equipo de backend que opera cerca de sus usuarios en varias regiones necesitará 1 conexión de PrivateLink por cada AWS Region. El servicio debe existir en cada región correspondiente o admitir PrivateLink interregional.
La ventaja es una menor exposición de red sin canalizar todas las llamadas a través de una sola región. La contrapartida es proporcional: cada conexión regional adicional añade $30 mensuales antes de calcular la transferencia.
Pasos de configuración en el orden correcto
Confirmar que el destino es compatible
Solicita al proveedor o responsable del servicio el nombre del endpoint service de AWS y su Region. El servicio debe aceptar todas las entidades de AWS o incluir en la lista de permitidos el rol de IAM asignado por Vercel a tu equipo.
Activar la función de red en Vercel
Abre el proyecto, ve a Settings, luego a Networking, Advanced Networking y AWS PrivateLink. Activa Advanced Networking si aún no está habilitado para tu equipo.
Crear la conexión
Haz clic en New Connection, introduce el nombre del endpoint service, elige la Region correspondiente y decide si deseas activar Private DNS.
Configurar el hostname de Vercel
Apunta el host del servicio en tu aplicación al hostname estable
endpoints.vercel.comcreado por Vercel. No asumas que la zona privada alojada (private hosted zone) del proveedor se resolverá desde la red compartida de Vercel.Volver a desplegar y validar
Vuelve a desplegar el proyecto y confirma que tanto las peticiones en tiempo de ejecución como las que ocurren durante el build se comunican correctamente a través de la conexión.
El error más habitual reside en el DNS. Los interface endpoints en la red compartida de Vercel no pueden utilizar la zona privada alojada del proveedor. Emplea siempre el hostname gestionado por Vercel, no el nombre de endpoint generado por AWS ni el hostname público del proveedor.
Limitaciones reales que conviene conocer
Cada conexión existe en 1 AWS Region. La asignación a un proyecto abarca todos sus entornos, por lo que no es posible habilitar PrivateLink para producción y mantenerlo inactivo para entornos de preview dentro del mismo proyecto.
Routing Middleware tampoco entra en esta ruta porque se ejecuta en el edge. Solo se admiten interface endpoints y gateway endpoints; los endpoints de Gateway Load Balancer y los de recursos no son compatibles.
PrivateLink resuelve el enrutamiento de red, no la autorización a nivel de aplicación. La contraseña de la base de datos, las políticas de IAM, los tokens de servicio y los permisos de usuario siguen siendo indispensables. Si desarrollas aplicaciones basadas en agentes que necesitan credenciales gestionadas, Vercel Connect actúa como la capa de autenticación independiente.
Decisiones recomendadas
Conviene actuar esta semana si estás en Pro o Enterprise, tu backend de destino ya expone un endpoint de AWS PrivateLink y suprimir el salto por la red pública resuelve una brecha real de seguridad o cumplimiento. Empieza por un servicio en su AWS Region y verifica el tráfico de runtime y de build antes de sumar más regiones.
Conviene esperar si el proveedor no puede facilitarte un nombre de endpoint service, si necesitas políticas de red distintas entre preview y producción dentro del mismo proyecto o si el equipo no ha confirmado aún el coste de Advanced Networking.
Opta por Static IPs cuando el backend solo requiera filtrar por direcciones IP conocidas y el tráfico público sea aceptable. Utiliza Secure Compute cuando la normativa exija una VPC dedicada o VPC peering. Los planes Hobby y las arquitecturas con servicios fuera de AWS no se ven afectados por esta novedad.
Recibe los próximos cambios de arquitectura explicados con claridad.
3 sept 2026
Prefiera este sitio en Google
Marque omidsaffari.com como fuente preferida y Google lo destacará para usted en Top Stories, AI Overviews y AI Mode.
