AWS PrivateLink na Vercel: o que muda para equipes Pro e Enterprise
Entenda como o AWS PrivateLink conecta Functions e builds da Vercel a serviços AWS por uma rota privada, quem pode usar o recurso e quanto ele custa.
Em 1 de setembro de 2026, a Vercel passou a oferecer o AWS PrivateLink a equipes Pro e Enterprise por meio do Advanced Networking. O recurso cria uma rota privada entre suas Vercel Functions e builds e os serviços AWS compatíveis, sem que esse tráfego precise atravessar a internet pública.
O que é o AWS PrivateLink na Vercel
O PrivateLink muda o caminho entre seu projeto Vercel e um backend. Ele não transfere o backend, não substitui a autenticação nem entrega uma nuvem dedicada exclusivamente à sua equipe.
Pense nele como um corredor privado entre a rede da Vercel e um serviço publicado na AWS. Um endpoint VPC é a porta de entrada desse corredor. VPC significa virtual private cloud, o limite de rede isolado da AWS. Ao usar 2 Availability Zones, a Vercel distribui o endpoint por 2 zonas compatíveis com aquele serviço.
Ao criar uma conexão, a Vercel provisiona um endpoint dedicado para sua equipe em 2 Availability Zones aceitas pelo serviço de destino. A Vercel também atribui uma AWS IAM role à equipe — essa é a identidade que o proprietário do serviço pode autorizar — e fornece um hostname estável para a conexão:
<service>.team_<team-id>.endpoints.vercel.com
Suas Functions já implantadas e seus processos de build usam esse hostname. O tráfego destinado ao serviço passa pelo endpoint privado, enquanto a Vercel registra o volume transferido nessa conexão.
É esse último detalhe que explica todo o mecanismo. Sua aplicação continua se comunicando com um hostname; a rede é que direciona os pacotes desse hostname pela rota privada.
O que realmente muda: a exposição da rede
A mudança está na exposição da rede. Uma equipe Pro agora pode manter o tráfego de backends compatíveis fora da internet pública sem precisar migrar para uma VPC dedicada.
Isso é útil quando o destino é RDS, Aurora, Neon, Redshift, Snowflake, MongoDB Atlas, Confluent, um serviço interno atrás de um AWS Network Load Balancer ou S3 e DynamoDB por meio de gateway endpoints. Ainda assim, o destino precisa publicar um serviço de endpoint do AWS PrivateLink. Sem isso, o recurso não tem a que se conectar.
Depois de confirmar o custo do Advanced Networking, o restante da cobrança é simples. A primeira conexão PrivateLink está incluída no Advanced Networking. Cada conexão adicional custa $30 por mês, e a Vercel cobra $0.04 por GB transferido pelo PrivateLink.
Para tornar a conta concreta, considere 2 conexões regionais movimentando 500 GB no total. A transferência custa $20. A conexão extra acrescenta $30, então o total publicado para a conexão PrivateLink e a transferência é de $50 por mês.
Usuários do Hobby não fazem parte deste lançamento. Também não há mudança imediata para equipes cujo backend está fora da AWS, não expõe um endpoint PrivateLink ou pode receber tráfego público com segurança.
Qual opção de rede resolve cada necessidade?
As rotas de rede da Vercel abaixo resolvem problemas diferentes.
O PrivateLink ocupa o meio-termo. Ele cria uma rota privada para um serviço, mas a VPC subjacente continua compartilhada. Se o requisito pedir uma “rede single-tenant”, use o Secure Compute. Se bastar ter um “endereço IP conhecido” e o roteamento público for aceitável, Static IPs pode ser suficiente.
Quem pode colocar o Vercel PrivateLink em prática agora
Um fundador de SaaS com banco de dados na AWS
Um fundador que mantém a aplicação no Vercel Pro e o banco de dados no RDS ou Aurora pode conectar o projeto ao serviço de endpoint do banco, autorizar a IAM role da Vercel e, por fim, trocar o host do banco na aplicação pelo hostname gerenciado pela Vercel.
O benefício é específico, mas relevante: o tráfego do banco de dados ganha uma rota privada sem que a equipe abandone seu fluxo atual de deploy na Vercel. Isso não oferece isolamento total de rede, porém pode eliminar uma rota pública que impedia a aprovação em uma análise de segurança.
Um engenheiro de plataforma que expõe uma API interna
Um engenheiro de plataforma pode posicionar um serviço interno atrás de um AWS Network Load Balancer, publicar o serviço de endpoint e adicionar a IAM role fornecida pela Vercel à lista de permissões. Assim, as Functions acessam o serviço pelo hostname estável, em vez de usar um endereço público de API.
O ganho é ter menos trabalho com o perímetro de rede: o proprietário autoriza um único principal da AWS e mantém o serviço fora da internet pública.
Uma equipe de produto de dados que usa um serviço gerenciado
Uma equipe que desenvolve um produto de dados sobre Snowflake, MongoDB Atlas ou Confluent pode usar o endpoint PrivateLink do provedor quando ele estiver disponível na AWS Region correspondente. A aplicação e seus processos de build compartilham a mesma conexão privada.
Isso deixa mais direto o caminho entre um deploy na Vercel e o serviço de dados. A viabilidade da arquitetura, porém, ainda depende da disponibilidade de endpoints do provedor.
Uma equipe de backend multirregional
Uma equipe de backend que opera perto dos usuários em várias regiões precisa de 1 conexão PrivateLink por AWS Region. O serviço deve existir em cada região correspondente ou oferecer suporte ao PrivateLink entre regiões.
O benefício é reduzir a exposição da rede sem obrigar todas as chamadas a passar por uma única região. A contrapartida também é objetiva: cada conexão regional extra acrescenta $30 por mês antes de considerar o tráfego transferido.
Configure na ordem que a rede exige
Confirme se o destino atende aos requisitos
Solicite ao proprietário ou provedor do serviço o nome do serviço de endpoint e a Região da AWS. O serviço deve aceitar todos os principals da AWS ou incluir na lista de permissões a IAM role que a Vercel atribui à sua equipe.
Ative o recurso de rede da Vercel
Abra o projeto e acesse Settings, Networking, Advanced Networking e AWS PrivateLink. Ative o Advanced Networking caso ele ainda não esteja habilitado para a equipe.
Crie a conexão
Selecione New Connection, informe o nome do serviço de endpoint, escolha a Região correspondente e decida se deseja ativar o Private DNS.
Use o hostname da Vercel
Aponte o host do serviço na aplicação para o hostname estável
endpoints.vercel.comcriado pela Vercel. Não presuma que o nome da zona hospedada privada do provedor será resolvido a partir da rede compartilhada da Vercel.Faça um novo deploy e valide
Implante o projeto novamente e confirme que tanto as requisições em runtime quanto as realizadas durante o build chegam ao backend pela conexão.
O erro mais comum está no DNS. Endpoints de interface na rede compartilhada da Vercel não podem usar a zona hospedada privada do provedor. Use o hostname gerenciado pela Vercel, não o nome de endpoint gerado pela AWS nem o hostname público do provedor.
Os limites que precisam ficar claros
Cada conexão existe em 1 AWS Region. A atribuição a um projeto vale para todos os ambientes desse projeto; portanto, não é possível ativar o PrivateLink em produção e mantê-lo desativado em preview dentro do mesmo projeto.
O Routing Middleware também fica fora dessa rota porque é executado na edge. Há suporte apenas para endpoints de interface e endpoints de gateway. Endpoints do Gateway Load Balancer e endpoints de recurso não são aceitos.
O PrivateLink resolve o roteamento de rede, não a autorização da aplicação. A senha do banco de dados, a política de IAM, o token do serviço e as permissões de usuário continuam sendo necessários. Para aplicações com agentes que precisam de credenciais gerenciadas de provedores, o Vercel Connect é a camada de autenticação separada.
O que fazer agora
Vale agir ainda esta semana se sua equipe usa Pro ou Enterprise, o destino já expõe um endpoint AWS PrivateLink e remover o salto pela rede pública resolve uma lacuna real de segurança ou conformidade. Comece com um serviço na AWS Region em que ele opera e valide o tráfego de runtime e de build antes de adicionar outras regiões.
Espere se o provedor não puder fornecer um nome de serviço de endpoint, se forem necessárias regras de rede diferentes para preview e produção no mesmo projeto ou se a equipe ainda não tiver confirmado o preço do Advanced Networking.
Use Static IPs quando o backend só precisar de uma lista de IPs permitidos e o roteamento público for aceitável. Use Secure Compute quando o requisito for uma VPC dedicada ou VPC peering. Equipes no Hobby e equipes que acessam serviços fora da AWS não são afetadas por este lançamento.
Receba as próximas mudanças de plataforma explicadas sem complicação.
2 de set. de 2026
Prefira este site no Google
Marque omidsaffari.com como fonte preferida e o Google destaca o site para você em Top Stories, AI Overviews e AI Mode.
