Scegliere il modello di VPC: standalone vs Shared VPC

La VPC in Google Cloud è una risorsa globale: le subnet sono regionali ma appartengono a un’unica rete che si estende su tutte le regioni senza tunnel. La prima decisione di design è quante VPC creare e con quale modello di ownership.

Una VPC standalone vive in un singolo project: adatta a workload isolati, ambienti sandbox o team autonomi. Quando serve centralizzare il networking mantenendo isolamento amministrativo si usa Shared VPC: un host project possiede la rete e le subnet condivise, mentre i service project vi collegano le proprie istanze. Il risultato è governance centralizzata (un solo team gestisce subnet, routing e firewall) con IAM e billing separati per applicazione. È il pattern preferito nelle organizzazioni enterprise con molti team, in alternativa al moltiplicare VPC standalone poi collegate a fatica.

Interconnettere le VPC: peering, NCC e PSC

VPC Network Peering collega due VPC in modo diretto e privato, scambiando le subnet route senza passare da Internet. Il vincolo chiave è che il peering NON è transitivo: se A fa peering con B e B con C, A non raggiunge C. Inoltre gli IP range non possono sovrapporsi e ogni lato mantiene i propri firewall.

Per topologie mesh, star o hub-and-spoke con transitività si usa Network Connectivity Center (NCC): un hub logico a cui si collegano spoke, che possono essere VPC oppure risorse ibride (VLAN attachment di Cloud Interconnect, tunnel HA VPN, router appliance). NCC abilita la connettività transitiva site-to-site e VPC-to-VPC che il peering da solo non offre.

Private Service Connect (PSC) risolve un problema diverso: consumare servizi (managed, di terze parti o pubblicati internamente) tramite private endpoint senza peering e senza rischio di overlap. È la scelta quando due parti hanno spazi IP sovrapposti o quando si vuole esporre un singolo servizio, non l’intera rete.

IPAM: pianificare lo spazio di indirizzamento

Un buon IPAM previene problemi che peering e connettività ibrida rendono irreparabili. Assegna range non sovrapposti fra VPC, on-prem e altri cloud fin dall’inizio: due reti con subnet coincidenti non potranno mai fare peering né BGP pulito. Ogni subnet ha un primary range e può avere secondary range (per alias IP, es. pod e service GKE).

Quando gli indirizzi RFC 1918 scarseggiano, i PUPI (Privately Used Public IP) permettono di usare IP pubblici privatamente dentro la VPC senza annunciarli. Private NAT serve a tradurre indirizzi in scenari di overlap o verso hybrid, distinto dal Cloud NAT classico che fa solo egress verso Internet per istanze senza IP esterno. Per l’IPv6 valuta subnet dual-stack con indirizzi interni o esterni a seconda che il traffico resti privato o vada su Internet.

Connettività ibrida e multicloud

La scelta dipende da banda, SLA e presenza fisica. Cloud VPN va su Internet: HA VPN offre SLA 99,99% (Classic VPN no) e usa BGP tramite Cloud Router. Per banda dedicata e latenza prevedibile si passa a Cloud Interconnect: Dedicated Interconnect è una connessione fisica diretta (circuiti da 10 o 100 Gbps) e richiede presenza in una colocation facility; Partner Interconnect passa da un service provider con tagli di banda inferiori, utile quando non si raggiunge la struttura di Google. Per il target SLA 99,99% servono connessioni ridondate in metro/zone diverse. Cross-Cloud Interconnect fornisce un collegamento fisico dedicato verso un altro cloud provider.

Il Cloud Router gestisce il dynamic routing BGP: in regional mode annuncia/apprende solo route della sua regione, in global mode su tutte le regioni della VPC. Per il DNS ibrido, Cloud DNS offre outbound forwarding (query verso resolver on-prem), inbound forwarding (on-prem interroga Cloud DNS) e DNS peering (una VPC delega la risoluzione alla config DNS di un’altra, tipico in hub-and-spoke o Shared VPC).

Trappole tipiche d’esame

  • Raggiungere C da A passando dal peering con B → NCC: VPC Peering non è transitivo; per la transitività serve Network Connectivity Center (VPC spoke) o un hub, non un secondo peering.
  • Due reti con subnet sovrapposte da integrare → PSC o Private NAT: il peering rifiuta range in overlap; usa Private Service Connect per esporre il singolo servizio o Private NAT per tradurre.
  • SLA 99,99% sul collegamento on-prem → HA VPN o Interconnect ridondato: Classic VPN non ha lo SLA 99,99% e una singola VLAN attachment nemmeno; serve ridondanza in metro/zone diverse.
  • Istanze senza IP esterno devono uscire su Internet → Cloud NAT: è solo egress; non fa ingress, non è un firewall e non sostituisce PSC o Private Google Access.
  • Governance centralizzata del networking con team separati → Shared VPC: host project per la rete, service project per i workload; evita la proliferazione di VPC standalone in peering.
  • On-prem deve risolvere nomi privati di Cloud DNS → inbound forwarding: per il percorso inverso (Cloud verso on-prem) si usa outbound forwarding; non confondere le due direzioni.