Google ACE: Networking VPC, connettività e gestione del traffico — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Panoramica

Il networking Virtual Private Cloud (VPC) su Google Cloud fornisce primitive di networking globali e definite dal software con un controllo granulare su indirizzamento, routing, sicurezza e gestione del traffico. Questa sezione si concentra su argomenti pratici di progettazione e operatività che utilizzerai per costruire reti resilienti, sicure e osservabili che interconnettono i servizi Google Cloud, gli ambienti on-premise e la rete internet pubblica.

Architettura VPC Core e Pianificazione IP

Reti VPC e subnet
- Una VPC è una risorsa globale; le sue subnet sono regionali e possono estendersi tra più zone. Le istanze in qualsiasi zona della regione possono utilizzare una subnet.
- Utilizzare VPC in modalità custom per la produzione. La modalità auto pre-crea una subnet per regione utilizzando un set predefinito di intervalli CIDR e può portare a vincoli di IP sovrapposti, spreco di spazio di indirizzamento e difficoltà di refactoring durante l’espansione.
- Gli intervalli IP secondari sulle subnet abilitano gli IP per Pod/Service di GKE e gli IP alias per le VM. Pianificare in anticipo i CIDR primari e secondari per evitare la rinumerazione.
Pianificazione degli indirizzi IP
- Scegliere uno spazio RFC1918 non sovrapposto per tutte le VPC attuali e future e per le reti on-premise che potresti connettere. Riservare blocchi per la crescita futura di regioni e servizi.
- Dimensionare correttamente le subnet (ad es., da /24 a /20) per la crescita ed evitare intervalli eccessivamente ampi che complicano le ACL e la diagnostica.
- Documentare l’uso degli IP: intervalli primari per i workload, intervalli secondari per GKE e blocchi riservati per pool NAT o endpoint di servizio.
Esempio
- gcloud compute networks create prod-net –subnet-mode=custom
- gcloud compute networks subnets create app-us-central1 –network=prod-net –region=us-central1 –range=10.10.0.0/20 –secondary-range=gke-pods=10.20.0.0/16,gke-svcs=10.21.0.0/20

Routing, Firewall e Gerarchia delle Policy

Route e modalità di routing dinamico
- Ogni VPC ha una tabella di routing composta da route di subnet generate dal sistema, route predefinite e route personalizzate statiche o dinamiche.
- Modalità di routing dinamico:
  - Regionale: le route dinamiche (BGP) apprese tramite Cloud Router sono utilizzabili solo dalle risorse nella stessa regione.
  - Globale: le route dinamiche sono utilizzabili dalle risorse in tutte le regioni della VPC. Preferire la modalità globale per le reti ibride che devono raggiungere l’ambiente on-premise da più regioni.
- Next hop: gateway internet predefinito (0.0.0.0/0), tunnel VPN, Cloud Router (BGP), istanza (appliance di routing) o next hop di un bilanciatore di carico interno per appliance virtuali.
- Priorità della route: i numeri più bassi hanno la precedenza. Priorità configurate in modo errato possono scartare il traffico (blackholing) o instradarlo verso un next hop non previsto. Utilizzare convenzioni chiare (ad es., 1000 per l’egress predefinito, 900 per le route più specifiche).
Gerarchia dei firewall
- Le regole firewall VPC sono stateful e vengono valutate prima dell’inoltro dei pacchetti. Esistono a livello di VPC e si applicano a tutte le subnet.
- Le policy firewall gerarchiche (associate a un’organizzazione, una cartella o un progetto) applicano regole di allow/deny prima delle regole VPC. Usale per implementare guardrail centralizzati (ad es., negare le porte di amministrazione esposte su internet).
- Regole implicite: esistono una regola implicita di allow egress e una di deny ingress con la priorità più bassa; non possono essere rimosse. Tutta la connettività richiede regole di allow ingress esplicite.
Regole firewall, tag, service account, secure tag
- Targeting: utilizzare i tag di rete o i service account per applicare le regole a VM specifiche; il targeting tramite service account offre un controllo più stretto basato sull’identità.
- I secure tag forniscono etichette gestite centralmente e protette da IAM per il targeting delle policy; impediscono l’auto-assegnazione da parte dei workload e supportano la segmentazione zero-trust.
- Logging: abilitare il logging del firewall in modo selettivo per le regole di alto valore per bilanciare la visibilità con i costi; campionare i pacchetti, non i payload completi.
- Modalità di fallimento comuni: mancanza degli intervalli di origine per gli health check, routing asimmetrico che causa la perdita dei pacchetti di risposta, intervalli di origine eccessivamente ampi che creano un’esposizione non intenzionale.
Esempio
- gcloud compute firewall-rules create allow-ilb-hc –network=prod-net –direction=INGRESS –action=ALLOW –priority=1000 –rules=tcp:80 –source-ranges=load-balancer-health-checks –target-service-accounts=web-sa@proj.iam.gserviceaccount.com

Bilanciamento del carico, IP, DNS e gestione del traffico

Tipi e comportamento di Cloud Load Balancing
- Basati su proxy globali: External HTTP(S), External TCP Proxy, External SSL Proxy. Terminano le connessioni dei client sull’edge di Google, supportano VIP globali anycast e inseriscono header (es. X-Forwarded-For). L’IP originale del client è disponibile tramite gli header o il protocollo PROXY (per TCP) anziché essere conservato come sorgente L3.
- Passthrough regionali: External Network Load Balancer e Internal TCP/UDP Load Balancer instradano il traffico a livello L4 e conservano l’IP del client. Da utilizzare quando è richiesta la visibilità dell’IP di origine sui backend senza il protocollo PROXY.
- Internal HTTP(S) Load Balancer: proxy L7 regionale per servizi interni con opzioni di routing avanzato e mTLS.
Servizi di backend, health check e policy di traffico
- I servizi di backend definiscono i backend (gruppi di istanze, NEG/VM/Endpoint, servizi GKE), la modalità di bilanciamento (UTILIZATION o RATE), i limiti di capacità, la session affinity e il connection draining.
- Gli health check devono essere autorizzati attraverso i firewall dai sistemi di health-checking di Google. I backend non integri (unhealthy) vengono rimossi automaticamente; health check configurati in modo errato possono causare un’interruzione totale del servizio.
- Le policy di traffico includono la località (regione/zona), i backend di overflow e failover e la suddivisione ponderata del traffico per rollout graduali su alcuni tipi di LB.
IP esterni e interni, regole di forwarding
- Gli indirizzi esterni e interni possono essere effimeri o statici riservati. Gli indirizzi esterni statici globali sono utilizzati dai LB globali; la maggior parte degli altri è regionale.
- Le regole di forwarding mappano un IP:porta a una destinazione (es. targetHttpProxy o servizio di backend). Scegliere regole globali o regionali in base al tipo di LB; una mancata corrispondenza ne impedisce la creazione.
Cloud DNS
- Zone: le zone pubbliche risolvono sull’internet pubblico; le zone private sono risolvibili solo dai VPC autorizzati. Utilizzare record gestiti (A/AAAA, CNAME, TXT, MX, SRV, ecc.).
- Split-horizon: creare sia zone pubbliche che private per lo stesso dominio in modo che i resolver interni ricevano risposte private (es. IP di un ILB) mentre gli utenti pubblici ottengono IP esposti su internet.
- Forwarding DNS privato: utilizzare le policy di Cloud DNS per il forwarding in entrata e in uscita per l’integrazione con i resolver on-premise; utilizzare il DNS peering tra VPC per condividere zone private senza una connettività di peering completa.
Esempio

undefined

Connettività ibrida e privata

Cloud Router, Cloud NAT e Private Google Access
- Cloud Router scambia le route con l’ambiente on-premise tramite BGP, annuncia le subnet del VPC e importa i prefissi on-premise. Utilizzare il routing dinamico globale quando più regioni necessitano di raggiungibilità verso l’on-premise.
- Cloud NAT fornisce l’uscita (egress) verso internet per VM private e nodi GKE senza IP esterni. Dimensionare i pool di IP del NAT per evitare l’esaurimento delle porte; monitorare i log per le connessioni interrotte e scalare gli indirizzi di conseguenza.
- Private Google Access (PGA) consente alle VM private di raggiungere le API di Google senza IP esterni tramite il percorso di routing predefinito. Private Service Connect (PSC) per le API di Google fornisce endpoint con IP privato nel proprio VPC con controllo tramite policy ed evita completamente l’egress pubblico; preferire gli endpoint PSC per un controllo dell’egress più rigoroso e un DNS coerente.
Private Service Connect (servizi producer e consumer)
- Esporre i servizi interni dietro un service attachment in un progetto producer e consumarli tramite endpoint privati in progetti consumer. La mappatura DNS e le policy di autorizzazione esplicite (allow policies) controllano l’accesso. Questo migliora l’isolamento rispetto al VPC Peering e centralizza la pubblicazione dei servizi.
VPC Network Peering, Shared VPC e segmentazione
- VPC Peering offre connettività privata a bassa latenza tra VPC. Non è transitivo e non consente IP sovrapposti. L’importazione/esportazione opzionale di route personalizzate estende la raggiungibilità ma non crea comunque un routing transitivo; pianificare attentamente l’architettura hub-and-spoke.
- Shared VPC centralizza le subnet in un progetto host per l’utilizzo da parte dei progetti di servizio. Ciò consente di centralizzare routing, firewall, NAT e LB, delegando al contempo l’IAM per singola applicazione. Combinare con firewall gerarchici e secure tag per la segmentazione.
- Network Connectivity Center (NCC) fornisce un hub per orchestrare gli spoke (VPN, Interconnect, router appliance, VPC spoke) e gestire in modo coerente le topologie WAN aziendali.
Cloud VPN, Cloud Interconnect e BGP
- Cloud VPN: utilizzare HA VPN con routing dinamico (BGP) per la disponibilità e il failover automatico delle route. Creare due tunnel per peer su interfacce Cloud VPN indipendenti e dispositivi/link on-premise distinti, quando possibile.
- Cloud Interconnect: Dedicated Interconnect fornisce link privati da 10–100 Gbps; Partner Interconnect utilizza un service provider. Per la resilienza, implementare interconnessioni ridondanti in domini di disponibilità edge diversi e utilizzare BFD con BGP dove supportato.
- Domini di errore (failure domains): isolare per regione, zona, dispositivo e provider. Testare regolarmente il failover; percorsi asimmetrici possono compromettere i firewall stateful on-premise.
Esempi

undefined

Osservabilità e Risoluzione dei Problemi

Connectivity Tests
- Simula e verifica la raggiungibilità tra origini e destinazioni attraverso VPC, on-premise (tramite link ibridi) e load balancer. Lo strumento valuta route, regole firewall e configurazioni per individuare interruzioni o traffico instradato in modo errato prima delle modifiche in produzione.
- Esempio:

undefined

VPC Flow Logs
- Abilita a livello di subnet per ottenere insight in tempo reale su flussi a 5-tuple, byte, pacchetti scartati (drop) e latenza. Esporta su Cloud Logging, Pub/Sub o BigQuery per l’analisi. Regola i livelli di campionamento e metadati per controllare i costi.
- Casi d’uso: convalidare l’efficacia del firewall, rilevare l’esfiltrazione di dati, pianificare la capacità e monitorare gli SLO.
Packet Mirroring
- Esegui il mirror del traffico di VM o GKE verso endpoint collettori per ispezione approfondita dei pacchetti (deep packet inspection) o IDS. Definisci l’ambito dei mirror per subnet, tag o istanza. Comprendi l’overhead prestazionale e assicurati che i collettori possano gestire il volume di traffico specchiato. Evita di eseguire il mirror del traffico post-NAT quando hai bisogno degli header originali.
Pattern di diagnostica comuni
- Blackhole: la rotta esiste ma il percorso di risposta è bloccato da un firewall o da un routing asimmetrico; convalida con Connectivity Tests e flow log su entrambi i lati.
- Fallimenti degli health check: conferma che il firewall consenta il traffico proveniente dagli health-checker e che i backend siano in ascolto sulle porte corrette; testa localmente da una VM nella stessa subnet.
- Esaurimento delle porte NAT: cerca flussi negati con motivo “no available NAT ports”; aggiungi più IP NAT o riduci il limite di porte per VM.

Scenario Pratico

Acme Retail gestisce una piattaforma e-commerce multiregione con backend privati, un punto di accesso web pubblico e un ERP on-premise. Deve segmentare i carichi di lavoro, fornire egress privato verso le API di Google, abilitare la raggiungibilità ibrida da tutte le regioni e rafforzare la sicurezza mantenendo l’osservabilità.

Creare uno Shared VPC in modalità custom per il controllo centralizzato

undefined

Motivazione: La modalità custom evita i CIDR assegnati automaticamente e permette una pianificazione deliberata degli indirizzi IP. Lo Shared VPC centralizza routing, firewall e NAT in un progetto host, consentendo ai progetti di servizio di effettuare il deploy in sicurezza.

Pianificare e creare subnet con intervalli secondari per GKE

undefined

Motivazione: Intervalli primari e secondari non sovrapposti prevengono futuri conflitti di peering e consentono l’uso di IP alias per GKE senza esaurire gli indirizzi IP.

Impostare il routing dinamico del VPC su global e distribuire Cloud Router

undefined

Motivazione: La modalità global rende le route on-premise apprese tramite BGP utilizzabili da tutte le regioni, semplificando la raggiungibilità ibrida e il failover.

Stabilire una HA VPN verso l’on-premise e annunciare le subnet

Crea due tunnel HA VPN attraverso dispositivi on-premise diversificati. Usa BGP per scambiare i prefissi e abilitare un failover controllato (graceful failover).
Motivazione: I doppi tunnel eliminano i single point of failure; BGP fa convergere le rotte rapidamente durante la manutenzione o le interruzioni.

Distribuire Cloud NAT per l’egress privato e PSC per le API di Google

undefined

Crea endpoint Private Service Connect per le API di Google e aggiorna il DNS privato per mappare gli endpoint delle API al PSC.
Motivazione: Il NAT consente l’egress verso Internet senza IP esterni sulle VM; il PSC mantiene il traffico delle API su IP privati e sotto il controllo di policy esplicite, eliminando i percorsi di egress pubblici.

Frontend con External HTTP(S) Load Balancer globale; servizi interni tramite Internal HTTP(S)

Crea un External HTTP(S) LB globale con un certificato gestito e un backend service che punta a backend NEG.
Crea Internal HTTP(S) LB regionali per il traffico service-to-service con mTLS tra i microservizi.
Motivazione: Il proxy LB globale fornisce anycast, autoscaling e CDN; l’LB L7 interno offre routing avanzato e sicurezza per il traffico east-west.

Implementare policy firewall gerarchiche e targeting basato sull’identità dei workload

Collega una policy a livello di organizzazione che nega le porte amministrative da Internet; consenti solo le sorgenti degli health-check del LB.
Crea regole VPC che hanno come target i service account per un accesso basato sul principio del privilegio minimo (least-privilege) tra i tier; usa i secure tag per la segmentazione dinamica.
Motivazione: La gerarchia impone dei guardrail a livello centrale; il targeting basato sull’identità resiste allo spoofing dei tag e semplifica l’automazione.

Configurare Cloud DNS con split-horizon e forwarding

Crea una zona pubblica acme.com per il VIP web e una zona privata acme.com per i nomi dei servizi interni mappati sugli ILB.
Configura il forwarding in uscita (outbound) verso il DNS on-premise e in entrata (inbound) per consentire all’on-premise di risolvere le zone private.
Motivazione: Lo split-horizon previene la fuga di dati e garantisce la corretta risoluzione dei nomi in base alla rete di origine; il forwarding integra i namespace legacy.

Usare Connectivity Tests, flow log e packet mirroring per la visibilità

Crea test per i percorsi critici (utente verso web LB, web verso servizi interni, servizi verso ERP on-premise).
Abilita i flow log sulle subnet; esportali su BigQuery per l’analisi dei trend. Abilita il packet mirroring temporaneamente durante la gestione di un incidente.
Motivazione: La validazione proattiva e la telemetria riducono il MTTR, rivelano errori di configurazione e forniscono insight sulla capacità.

Documentare e testare gli scenari di fallimento

Simula la perdita di un tunnel VPN, di una regione e di un MIG di backend. Verifica il failover BGP, la rimozione tramite health-check del LB e la correttezza del DNS.
Motivazione: Esercitazioni regolari (game days) confermano le ipotesi sulla ridondanza ed espongono derive di configurazione (configuration drift) prima che causino interruzioni.

← Container · Tutti i domini · Archiviazione →

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