Google PCNE: Architettura VPC, sottoreti e pianificazione degli indirizzi — Guida allo studio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fa parte della Google Professional Cloud Network Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Un Virtual Private Cloud (VPC) è una rete globale, logicamente isolata, che si estende a tutte le region di Google Cloud. Le subnet sono costrutti regionali all’interno di un VPC e ospitano intervalli di indirizzi IP a supporto di Compute Engine, GKE e altre risorse. Un’architettura VPC ben progettata bilancia l’efficienza degli indirizzi, la crescita e il controllo operativo, garantendo al contempo una connettività a bassa latenza ed economicamente vantaggiosa per i carichi di lavoro intra-progetto e inter-progetto e verso le API di Google.

Ambito del VPC, architettura delle subnet e modalità

• VPC globale, subnet regionali

  • Un singolo VPC si estende a tutte le region. Le subnet vengono create per ogni region e definiscono CIDR IPv4 primari e intervalli secondari opzionali. Le istanze ricevono indirizzi IP dalle subnet regionali ma, per impostazione predefinita, possono comunicare privatamente tra region diverse all’interno dello stesso VPC.
  • Modalità di routing dinamico
    • Regional: i Cloud Router scambiano route solo con le subnet nella loro region.
    • Global: i Cloud Router in una region annunciano le route apprese a tutte le region. Preferire la modalità global quando sono richiesti carichi di lavoro multi-regionali o un’uscita ad alta disponibilità (HA).

• Modalità auto vs modalità custom

  • La modalità auto crea una subnet per ogni region con CIDR preassegnati. È comoda per iniziare rapidamente, ma poco flessibile su larga scala. Può essere convertita in modalità custom; la conversione è unidirezionale.
  • La modalità custom offre il pieno controllo sulla creazione delle subnet e sulla scelta dei CIDR. Questo è il pattern consigliato per la pianificazione degli indirizzi in produzione, per Shared VPC, peering e per la crescita futura.
  • Nota sulla migrazione: dopo la conversione da auto a custom, gli artefatti o i template che presupponevano l’esistenza delle subnet auto spesso falliscono finché non vengono aggiornati esplicitamente per fare riferimento alle subnet custom.

• Immutabilità e crescita delle subnet

  • La region di una subnet è immutabile; non è possibile spostare una subnet da una region all’altra.
  • Gli intervalli IPv4 primari possono essere espansi sul posto (ampliando il prefisso), non possono essere ridotti e non devono sovrapporsi con altri intervalli all’interno del VPC e di qualsiasi rete connessa.
  • Gli intervalli secondari possono essere aggiunti o rimossi (a seconda del loro utilizzo), ma anch’essi non devono sovrapporsi.

Pianificazione degli indirizzi: intervalli primari/secondari, Alias IP, IPv6 e spazio privato

• Intervalli IPv4 primari e secondari

  • Intervallo primario: assegna gli indirizzi alle interfacce delle VM (nic0 per impostazione predefinita). Crea una route di subnet generata dal sistema ed è utilizzato per la maggior parte delle comunicazioni interne.
  • Intervalli secondari: associano CIDR aggiuntivi alla subnet e sono necessari per i cluster GKE VPC-native. Le route generate dal sistema per gli intervalli secondari consentono la connettività est-ovest per Pod e Service.

• Alias IP

  • Gli Alias IP consentono a una NIC di una VM di possedere più indirizzi IP dagli intervalli primari o secondari della subnet, abilitando policy rigorose basate su IP, l’assegnazione di IP ai Pod per GKE VPC-native e un utilizzo efficiente degli indirizzi IP.
  • Per GKE, pianificare CIDR secondari ampi e contigui per minimizzare la frammentazione e la necessità di futuri ridimensionamenti. Esempio: per 100 nodi con 200 Pod/nodo e 1500 Service, allocare un intervallo secondario per i Pod di almeno /17 e uno per i Service di /21 per lasciare margine di crescita.

• Progettazione RFC 1918 privata e gestione degli IP

  • Scegliere blocchi di indirizzi che non si sovrappongano tra tutti i VPC attuali e pianificati, le reti on-premise e quelle dei partner. Riservare ampi blocchi padre per ogni ambiente, quindi ricavare sottoblocchi prevedibili per ogni region e per ogni funzione.
  • Riservare capacità per la crescita, per gli intervalli secondari, per buffer di migrazione (dual-stack temporaneo/doppio NAT) e per endpoint di infrastruttura (VIP di ILB, endpoint PSC).
  • Evitare i blocchi di indirizzi più comuni in ambito enterprise se è probabile una connettività con partner; in alternativa, segmentare con NAT per risolvere i conflitti.

• Pianificazione IPv6

  • IPv6 esterno: utilizzare indirizzi IPv6 esterni globali sui global load balancer per l’accesso dei client e la raggiungibilità anycast.
  • IPv6 interno: dove disponibile, abilitare le subnet dual-stack per assegnare indirizzi IPv6 interni alle VM e adeguare di conseguenza le regole firewall. Pianificare i record DNS AAAA e garantire la parità con le policy IPv4.
  • Mantenere IPv4 per i controlli intra-cloud e le integrazioni con terze parti; introdurre IPv6 in modo incrementale tramite i load balancer e le subnet dual-stack.

Inoltro: rotte implicite, rotte personalizzate, priorità, tag e next hop

• Rotte implicite (generate dal sistema)

  • Rotte di subnet: una per ogni subnet primaria e per ogni intervallo secondario, la destinazione è uguale al CIDR, il next hop è la subnet stessa.
  • Rotta predefinita: una rotta 0.0.0.0/0 verso il gateway internet predefinito viene creata di default; il traffico in uscita (egress) verso internet richiede un IP esterno o un NAT.

• Rotte personalizzate e logica di selezione

  • Prevale la corrispondenza del prefisso più lungo (longest prefix match). Se più rotte hanno la stessa lunghezza del prefisso, prevale il numero di priorità più basso (priorità predefinita 1000).
  • Tag e service account
    • Le rotte senza tag si applicano a tutte le VM. Le rotte con ambito definito da tag (tag-scoped) si applicano solo alle istanze con tag di rete corrispondenti.
    • Le regole firewall basate sull’identità possono basarsi sui service account; utilizzarle per un controllo più granulare rispetto ai tag, ove possibile.

• Next hop

  • I next hop supportati per le rotte personalizzate includono:
    • Gateway internet predefinito (0.0.0.0/0 o prefissi di egress più specifici)
    • Istanza (richiede l’inoltro IP, o IP forwarding, per instradare il traffico per altri; utilizzata per le virtual appliance)
    • Tunnel Cloud VPN (rotte statiche)
    • Load balancer interno regionale come next hop (per pattern di appliance scalabili)
  • Non è possibile impostare un next hop verso una connessione di VPC peering; il peering gestisce il proprio scambio di rotte.

• Esempio di indirizzamento del traffico (traffic steering) con una virtual appliance

  • Creare una rotta più specifica di quella della subnet con un next hop verso un’istanza con IP forwarding abilitato, il cui ambito è definito da tag sulle VM di origine.

  • Esempio:

undefined

• Traffico in uscita (egress) verso le API di Google senza IP esterni
  • Opzione 1: Abilitare l’Accesso Privato Google (Private Google Access, PGA) sulle subnet, quindi aggiungere rotte personalizzate per i VIP delle API di Google verso il gateway internet predefinito per bypassare un percorso di egress predefinito di terze parti, se necessario.
  • Opzione 2: Usare Cloud NAT con PGA per fornire connettività in uscita (egress) alle VM private verso i servizi Google.
  • Opzione 3: Usare Private Service Connect per le API di Google per un utilizzo senza accesso a internet; il traffico rimane sulla rete di Google e utilizza un endpoint privato RFC1918 nel proprio VPC.
  • Per un accesso limitato, indirizzare i client verso i VIP limitati (restricted) delle API di Google e applicare controlli sul traffico in uscita.

Shared VPC, peering, amministrazione delegata e service account

• Shared VPC

  • Il progetto host (host project) possiede uno o più VPC e subnet gestiti centralmente. I progetti di servizio (service project) collegano i carichi di lavoro a subnet condivise selezionate.
  • Amministrazione delegata
    • L’amministratore dello Shared VPC (Shared VPC Admin) configura i collegamenti (attachment) e la condivisione delle subnet.
    • Gli amministratori di rete (Network Admin) gestiscono rotte, subnet e firewall nel progetto host.
    • L’IAM a livello di progetto nei progetti di servizio controlla il deployment dei carichi di lavoro; è possibile condividere solo le subnet necessarie per limitare il raggio d’impatto (blast radius) e la visibilità delle rotte.
  • Service account
    • Preferire policy firewall basate su service account per un controllo deterministico e basato sull’identità tra i vari team.
    • Utilizzare service account dedicati per ogni livello (tier) e ambiente, con ruoli che seguono il principio del privilegio minimo (least-privilege) per l’accesso ai dati (ad esempio, concedere il ruolo Storage Object Viewer a un service account che legge da Cloud Storage).

• VPC Network Peering

  • Vincoli
    • Non transitivo: A↔B e B↔C non implicano A↔C. Creare una topologia full mesh se necessario.
    • Nessuna sovrapposizione di intervalli IP tra le reti in peering.
    • Lo scambio è limitato alle rotte di subnet (inclusi gli intervalli secondari); l’indirizzamento tramite next hop attraverso il peering non è supportato.
  • Usare il peering per una connettività a bassa latenza, privata e intra-organizzativa con un sovraccarico operativo minimo, quando VPC separati devono rimanere amministrativamente distinti.

• Connettività ibrida

  • Centralizzare Dedicated Interconnect e Cloud Router in un progetto host di tipo Shared VPC per condividere la connettività ad alta capacità con i progetti di servizio dei vari dipartimenti.
  • Utilizzare collegamenti VLAN ad alta disponibilità (HA VLAN attachment), diverse edge location, doppi Cloud Router e l’inoltro dinamico globale (global dynamic routing) per la resilienza e la propagazione a tutte le region necessarie.

Operazioni: espansione, HA, accesso privato, verifica e risoluzione dei problemi

• Vincoli di espansione e migrazione delle subnet

  • Espandere una subnet in loco quando si avvicina alla capacità massima; convalidare tutte le reti connesse per verificare la non sovrapposizione e assicurarsi che gli intervalli secondari dipendenti di GKE rimangano adeguati.
  • Se gli intervalli si sovrappongono tra organizzazioni o partner, impiegare NAT o una rinumerazione graduale. Non è possibile eseguire il peering di VPC sovrapposti o installare route dinamiche sovrapposte.

• Posizionamento regionale e alta disponibilità

  • Posizionare le subnet nelle region più vicine agli utenti e ai dati. Per basi di utenti transatlantiche, un singolo VPC con subnet regionali in us-east1 e europe-west1 fornisce connettività privata diretta con latenza ottimale e nessun costo di egress all’interno del VPC.
  • Distribuire i carichi di lavoro tra le zone; utilizzare gruppi di istanze gestite a livello regionale e load balancer interni/esterni regionali per la tolleranza ai guasti di zona.
  • In un contesto ibrido, implementare doppi Cloud Router e collegamenti (attachment) per region o edge location; abilitare BFD dove supportato; utilizzare il routing dinamico globale per il failover.

• Private Google Access ed endpoint limitati

  • Abilitare PGA sulle subnet che ospitano istanze senza IP esterni.
  • Per impedire l’egress generale verso Internet consentendo al contempo l’accesso alle API di Google:
    • Indirizzare il traffico predefinito verso il proprio NGFW.
    • Aggiungere route statiche più specifiche per i VIP delle API di Google verso il gateway Internet predefinito o implementare endpoint PSC per le API di Google.

  • Esempio:

undefined

• Verifica della topologia e risoluzione dei problemi
  • Utilizzare Network Intelligence Center:
    • Connectivity Tests per convalidare la raggiungibilità e simulare le decisioni di routing, firewall e gateway.
    • Performance Dashboard e Topology per visualizzare i percorsi e lo stato di salute.
  • Log e telemetria:
    • VPC Flow Logs per osservare il traffico consentito/negato (allow/deny) e la latenza per interfaccia.
    • Firewall Rules Logging per confermare la corrispondenza delle regole.
    • Log e stato di salute di Cloud NAT per problemi di egress senza IP esterni.
    • Log dei load balancer e degli health-check per la prontezza dei backend.

  • Verifiche da CLI:

undefined

e

undefined

per confermare la policy effettiva. - traceroute e curl da VM di test; utilizzare il packet mirroring per un’ispezione approfondita quando necessario.

Scenario pratico

Acme Retail Group necessita di una rete Google Cloud multi-region a bassa latenza con controllo centralizzato, accesso senza Internet alle API di Google per le istanze private e un isolamento rigoroso tra i dipartimenti che non devono comunicare. Alcuni team utilizzano GKE con un’alta densità di Pod. Acme indirizza inoltre l’egress generale attraverso un firewall di terze parti, ma desidera che il traffico delle API di Google eviti il firewall.

1. Costruire un singolo Shared VPC in un progetto host in modalità custom con routing dinamico globale e creare subnet regionali in us-east1 e europe-west1 con intervalli secondari riservati per GKE.

• Motivazione: Un unico VPC fornisce connettività cross-region privata, a costo zero, su indirizzi RFC1918 per un’efficienza ottimale. La modalità custom e il routing dinamico globale supportano una pianificazione precisa degli IP e la propagazione delle route multi-regione.

2. Condividere solo le subnet specifiche necessarie con il progetto di servizio di ciascun dipartimento; creare tre progetti di servizio (Vendite, Finanza, Marketing) ed esporre a ciascuno solo le subnet richieste.

• Motivazione: La condivisione per singola subnet limita il raggio d’impatto (blast radius) e l’esposizione delle route, imponendo l’isolamento e abilitando al contempo operazioni centralizzate. L’IAM delegato consente agli amministratori di rete centrali di gestire firewall e route, mentre i team applicativi implementano i carichi di lavoro in modo indipendente.

3. Per i dipartimenti che devono comunicare, eseguire il peering dei loro VPC dedicati o posizionarli nelle stesse subnet dello Shared VPC; per i dipartimenti isolati, astenersi dal peering e non condividere subnet sovrapposte.

• Motivazione: Il peering fornisce connettività privata a bassa latenza con un minimo overhead operativo. La non transitività richiede connessioni a mesh esplicite solo dove necessario, il che preserva l’isolamento per impostazione predefinita.

4. Abilitare Private Google Access su tutte le subnet condivise e implementare endpoint Private Service Connect per le API di Google; mantenere la route predefinita verso un firewall di terze parti, e in più aggiungere route statiche più specifiche per i VIP delle API di Google verso il gateway Internet predefinito.

• Motivazione: PGA e PSC consentono l’utilizzo delle API senza accesso a Internet da VM private. Le route più specifiche assicurano che il traffico delle API bypassi l’NGFW, mentre l’egress verso Internet non destinato a Google continua a seguire il percorso di ispezione.

5. Allocare CIDR primari e secondari con margine di crescita: per GKE, dimensionare un intervallo secondario per i Pod (ad esempio, /17) e uno per i Services (/21) per ogni region ad alto traffico; utilizzare IP alias per Pod e Services e creare cluster VPC-native associati a tali intervalli.

• Motivazione: Gli intervalli secondari e gli IP alias prevengono l’esaurimento degli IP dei nodi e consentono uno scheduling denso. Il dimensionamento per la domanda futura evita ridimensionamenti dirompenti e la rinumerazione degli intervalli secondari.

6. Implementare l’HA per il traffico ibrido e degli appliance: implementare doppi Cloud Router e HA VPN o Interconnect secondo necessità; dove è richiesto l’indirizzamento attraverso un appliance virtuale, utilizzare una route custom più specifica con il next hop impostato su un load balancer interno regionale o su un’istanza con IP forwarding e applicabilità basata su tag.

• Motivazione: L’HA sull’edge garantisce la continuità durante i guasti. La limitazione dell’ambito delle route tramite tag evita l’hairpinning accidentale del traffico e consente solo alle istanze selezionate di attraversare il percorso dell’appliance.

7. Verificare e operare con Connectivity Tests di Network Intelligence Center, VPC Flow Logs e Firewall Rules Logging; applicare policy firewall basate sull’identità utilizzando i service account e mantenere registri IPAM con buffer riservati per region e funzione.

• Motivazione: La verifica proattiva previene le interruzioni durante le modifiche. Le policy basate sull’identità sono più robuste degli approcci basati solo su tag. Una disciplina IPAM rigorosa previene sovrapposizioni che bloccherebbero il peering o sopprimerebbero le route apprese.

Tutti i domini · Policy dei firewall →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →