Azure Private Link è la tecnologia che porta i servizi PaaS (Storage, SQL Database, Key Vault, Cosmos DB, App Service e decine di altri) dentro la tua rete privata, esponendoli tramite un IP privato preso dalla tua VNet invece che dall’endpoint pubblico del servizio. Il traffico resta sul backbone Microsoft e non transita mai su Internet. Le due facce della stessa tecnologia sono il private endpoint (lato consumer, chi consuma il servizio) e il Private Link service (lato provider, chi espone il servizio).

Il criterio d’esame chiave: quando un requisito parla di “accesso privato senza esposizione pubblica”, “IP privato dalla mia subnet”, “raggiungibile da on-premises” o “isolamento a livello di singola risorsa”, la risposta è quasi sempre private endpoint, non service endpoint.

Private endpoint: private-access ai PaaS

Un private endpoint è una NIC collegata a una subnet della tua VNet, a cui viene assegnato un IP privato. Quella NIC mappa una specifica risorsa PaaS e una sua sub-resource (il groupId, ad esempio blob, sqlServer, vault): un account Storage con blob e file richiede quindi due private endpoint distinti.

La connessione tra endpoint e risorsa segue un workflow di approvazione: automatica quando hai i permessi sulla risorsa (tipicamente stessa subscription/tenant) oppure manuale quando la risorsa è in un’altra subscription o tenant, dove il proprietario deve approvare la richiesta. Il private endpoint supporta NSG e UDR sulla subnet, e — punto forte rispetto ai service endpoint — è raggiungibile anche da on-premises tramite VPN o ExpressRoute, perché è un semplice IP privato instradabile.

Differenza da ricordare: il service endpoint estende l’identità della VNet verso il servizio ma il traffico raggiunge comunque l’IP pubblico del PaaS, opera a livello di servizio, è gratuito e non funziona da on-premises. Il private endpoint dà un IP privato, granularità per-risorsa, funziona cross-region e da on-prem, ma ha un costo.

Il Private Link service è il lato provider: ti permette di pubblicare un tuo servizio (una tua applicazione, non un PaaS Azure) rendendolo consumabile da altri via private endpoint, anche cross-tenant. Requisito fondamentale: il servizio deve stare dietro uno Standard Load Balancer (il Basic non è supportato). Il servizio ottiene un alias univoco che i consumer usano per creare il proprio private endpoint verso di te, senza peering di VNet e senza esporre nulla su Internet.

Integrazione DNS: il punto che fa cadere tutti

Un private endpoint senza DNS corretto non funziona: la risoluzione è la parte critica. Quando crei un private endpoint, l’FQDN pubblico del servizio (es. account.blob.core.windows.net) diventa un CNAME verso il sottodominio privatelink (account.privatelink.blob.core.windows.net). Serve quindi una Private DNS zone dedicata (es. privatelink.blob.core.windows.net, privatelink.database.windows.net) che risolva quel nome nell’IP privato. Il record A viene creato e aggiornato automaticamente se colleghi la zona al private endpoint tramite il Private DNS Zone Group.

In topologia hub-and-spoke la zona va linkata a tutte le VNet che devono risolvere (di solito centralizzata nell’hub). Per la risoluzione da on-premises, il client on-prem non vede le Private DNS zone: serve un forwarding DNS verso Azure, tipicamente un DNS server nella VNet o l’Azure DNS Private Resolver che inoltra le query all’IP 168.63.129.16.

Trappole tipiche d’esame

  • Accesso privato al PaaS anche da on-premises → private endpoint: il service endpoint non è raggiungibile da fuori Azure perché usa l’IP pubblico; solo l’IP privato dell’endpoint è instradabile via VPN/ExpressRoute.
  • Il private endpoint è creato ma la connessione “va sul pubblico” → manca la Private DNS zone: senza record A nella zona privatelink.*, l’FQDN risolve ancora sull’IP pubblico. Configura Private DNS Zone Group o forwarding.
  • Un solo endpoint per uno Storage con blob e file → sbagliato: serve un private endpoint per ogni sub-resource (groupId).
  • Esporre un mio servizio via Private Link service con Basic Load Balancer → non supportato: richiede uno Standard Load Balancer.
  • Risoluzione fallisce da on-prem ma funziona in Azure → manca il forwarding DNS: i client on-premises non interrogano le Private DNS zone direttamente; serve un resolver/forwarder verso 168.63.129.16.
  • Connessione cross-tenant che resta in “Pending” → approvazione manuale: tra subscription/tenant diversi il proprietario della risorsa deve approvare esplicitamente la private endpoint connection.