AWS PrivateLink su Vercel: cosa cambia per i team Pro ed Enterprise
Scopri come AWS PrivateLink collega Functions e build Vercel ai servizi AWS senza passare dalla rete pubblica, con costi, limiti e casi d'uso.
Dal 1 settembre 2026, Vercel rende AWS PrivateLink disponibile ai team Pro ed Enterprise tramite Advanced Networking. AWS PrivateLink offre a Vercel Functions e alle build un percorso privato verso i servizi AWS supportati, evitando che il traffico attraversi la rete Internet pubblica.
Che cos'è davvero AWS PrivateLink su Vercel
PrivateLink cambia il percorso tra un progetto Vercel e il suo backend. Non sposta il backend, non ne sostituisce l'accesso e non assegna al team un cloud Vercel dedicato.
È un corridoio privato dalla rete di Vercel a un servizio pubblicato su AWS. Un endpoint VPC è la porta d'ingresso a questo corridoio. VPC significa Virtual Private Cloud, il perimetro di rete isolato di AWS. Con 2 Availability Zone, Vercel distribuisce l'endpoint su 2 zone supportate dal servizio.
Quando si crea una connessione, Vercel configura un endpoint dedicato al team in 2 Availability Zone supportate dal servizio di destinazione. Vercel assegna inoltre al team un ruolo AWS IAM, cioè l'identità che il proprietario del servizio può autorizzare, e fornisce alla connessione un hostname stabile:
<service>.team_<team-id>.endpoints.vercel.com
Le Functions distribuite e i job di build usano questo hostname. Il traffico diretto al servizio passa dall'endpoint privato, mentre Vercel registra i dati trasferiti dalla connessione.
È qui che sta l'intero meccanismo. L'applicazione continua a comunicare con un hostname; è la rete a instradare i pacchetti destinati a quell'hostname sul percorso privato.
Cosa cambia davvero: l'esposizione di rete
Il cambiamento riguarda l'esposizione di rete. Un team Pro può ora evitare Internet pubblico per il traffico verso i backend supportati, senza dover passare a una VPC dedicata.
La funzione è utile quando la destinazione è RDS, Aurora, Neon, Redshift, Snowflake, MongoDB Atlas, Confluent, un servizio interno dietro un AWS Network Load Balancer oppure S3 e DynamoDB tramite gateway endpoint. La destinazione deve comunque pubblicare un servizio endpoint AWS PrivateLink: in caso contrario, non c'è nulla a cui questa funzione possa collegarsi.
I prezzi AWS PrivateLink sono semplici, una volta chiarito il costo di Advanced Networking. La prima connessione PrivateLink è inclusa in Advanced Networking. Ogni connessione aggiuntiva costa $30 al mese e Vercel addebita $0.04 per ogni GB trasferito tramite PrivateLink.
In un esempio concreto, 2 connessioni regionali trasferiscono complessivamente 500 GB. Il trasferimento costa $20. La connessione aggiuntiva costa $30: la voce pubblicata per connessioni e trasferimento PrivateLink arriva quindi a $50 al mese.
Gli utenti Hobby non rientrano in questo rilascio. Non cambia nulla nell'immediato neppure per i team il cui backend è fuori da AWS, non espone un endpoint PrivateLink o può accettare senza rischi traffico pubblico.
Scegliere la soluzione di rete in base al requisito
Le diverse opzioni di rete Vercel rispondono a esigenze differenti.
PrivateLink si colloca nel mezzo: assegna a un singolo servizio un percorso privato, ma la VPC sottostante resta condivisa. Se il requisito è una “rete single-tenant”, la scelta corretta è Secure Compute. Se basta un “indirizzo IP noto” e il routing pubblico è accettabile, Static IPs può essere sufficiente.
Chi può usare Vercel PrivateLink da subito
Un founder SaaS con un database AWS
Chi esegue l'app su Vercel Pro e il database su RDS o Aurora può collegare il progetto al servizio endpoint del database, autorizzare il ruolo IAM di Vercel e poi sostituire l'host del database nell'applicazione con l'hostname gestito da Vercel.
Il vantaggio è circoscritto ma concreto: il traffico del database ottiene un percorso privato, mentre il team mantiene l'attuale flusso di deployment su Vercel. Non equivale a un isolamento completo della rete, ma può eliminare un percorso pubblico che impediva di superare una verifica di sicurezza.
Un platform engineer che espone un'API interna
Un platform engineer può collocare un servizio interno dietro un AWS Network Load Balancer, pubblicare il servizio endpoint e autorizzare il ruolo IAM fornito da Vercel. Le Functions possono quindi chiamare il servizio tramite l'hostname stabile, anziché usare l'indirizzo di un'API pubblica.
Il risultato è un perimetro più semplice da gestire. Il proprietario del servizio approva un solo principal AWS e mantiene il servizio fuori da Internet pubblico.
Un team data product che usa un servizio gestito
Un team data product basato su Snowflake, MongoDB Atlas o Confluent può usare l'endpoint PrivateLink del provider, se disponibile nella stessa AWS Region. L'applicazione e i suoi job di build condividono la medesima connessione privata.
Si ottiene così un percorso più lineare dal deployment Vercel al servizio dati. La fattibilità dell'architettura dipende comunque dalla disponibilità dell'endpoint presso il provider.
Un team backend multi-region
Un team backend che opera vicino agli utenti in più regioni necessita di 1 connessione PrivateLink per ogni AWS Region. Il servizio deve essere presente in tutte le regioni corrispondenti oppure supportare PrivateLink cross-region.
Il vantaggio è una minore esposizione di rete, senza obbligare tutte le chiamate a transitare da un'unica regione. Il compromesso è altrettanto chiaro: ogni connessione regionale aggiuntiva costa $30 al mese prima del trasferimento dati.
Configurare AWS PrivateLink nell'ordine corretto
Verificare che la destinazione sia idonea
Richiedere al proprietario del servizio o al provider il nome del servizio endpoint AWS e la Region. Il servizio deve accettare tutti i principal AWS oppure autorizzare il ruolo IAM che Vercel assegna al team.
Attivare la funzione di rete Vercel
Aprire il progetto, quindi accedere a Settings, Networking, Advanced Networking e AWS PrivateLink. Se Advanced Networking non è già attivo per il team, abilitarlo.
Creare la connessione
Selezionare New Connection, inserire il nome del servizio endpoint, scegliere la Region corrispondente e decidere se attivare Private DNS.
Usare l'hostname di Vercel
Impostare come host del servizio dell'applicazione l'hostname stabile
endpoints.vercel.comcreato da Vercel. Non dare per scontato che il nome della private hosted zone del provider sia risolvibile dalla rete condivisa di Vercel.Eseguire nuovamente il deployment e verificare
Eseguire un nuovo deployment del progetto, quindi controllare che sia le richieste a runtime sia quelle effettuate durante la build raggiungano correttamente il backend tramite la connessione.
L'errore più comune riguarda il DNS. Gli interface endpoint nella rete condivisa di Vercel non possono usare la private hosted zone del provider. Occorre usare l'hostname gestito da Vercel, non il nome dell'endpoint generato da AWS né l'hostname pubblico del provider.
I limiti da conoscere
Ogni connessione esiste in 1 AWS Region. L'assegnazione a un progetto si applica a tutti gli ambienti del progetto: non è quindi possibile attivare PrivateLink in produzione e lasciarlo disattivato in preview all'interno dello stesso progetto.
Anche Routing Middleware resta fuori dal percorso, perché viene eseguito all'edge. Sono supportati soltanto interface endpoint e gateway endpoint; Gateway Load Balancer endpoint e resource endpoint non lo sono.
PrivateLink risolve il routing di rete, non l'autorizzazione dell'applicazione. La password del database, la policy IAM, il token del servizio e i permessi degli utenti restano necessari. Per le app basate su agent che richiedono credenziali gestite del provider, Vercel Connect costituisce un livello di autenticazione separato.
Cosa fare adesso
Conviene intervenire questa settimana se il team usa Pro o Enterprise, la destinazione espone già un endpoint AWS PrivateLink e la rimozione del passaggio sulla rete pubblica risolve un problema concreto di sicurezza o conformità. È meglio partire da un servizio nella sua AWS Region e verificare il traffico a runtime e durante la build prima di aggiungere altre regioni.
È invece opportuno attendere se il provider non può fornire il nome di un servizio endpoint, se servono regole di rete diverse per preview e produzione nello stesso progetto o se il team non ha ancora verificato il prezzo di Advanced Networking.
Static IPs è l'alternativa adatta quando il backend richiede soltanto un elenco di IP autorizzati e il routing pubblico è accettabile. Secure Compute serve invece quando il requisito è una VPC dedicata o il peering VPC. Per i team Hobby e quelli che chiamano servizi esterni ad AWS, questo rilascio non cambia nulla.
Ricevi una spiegazione chiara del prossimo cambiamento di piattaforma.
2 set 2026
Preferisca questo sito su Google
Segni omidsaffari.com come fonte preferita e Google lo mette in evidenza per lei in Top Stories, AI Overviews e AI Mode.
