Google PCA: Networking, connettività ibrida e architettura del traffico — Guida allo studio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Gestione del traffico, DNS e sicurezza perimetrale

• Pattern di Cloud Load Balancing

  • L’External HTTP(S) Load Balancer è globale di tipo anycast con un singolo VIP anycast, failover tra region, routing basato su percorso e host, e integrazione con CDN/Armor. Da utilizzare per carichi di lavoro web e API esposti su Internet.
  • L’Internal HTTP(S) Load Balancer è regionale, per il traffico service-to-service all’interno di un VPC o tramite Private Service Connect.
  • L’External/Internal TCP/UDP Network Load Balancer è un L4 regionale; da utilizzare per protocolli non HTTP o dove è richiesta la conservazione dell’IP di origine.
  • Servizi di backend e Network Endpoint Group (NEG): utilizzare backend di gruppi di istanze di zona (zonal instance group) per pool di VM; utilizzare NEG di zona, regionali o serverless per GKE, backend ibridi o Cloud Run. Creare servizi di backend separati per ogni classe di traffico, profilo di health check o policy di capacità. Esempio: servire versioni vecchie e nuove delle API sotto lo stesso nome host tramite routing basato su percorso verso servizi di backend distinti, mantenendo entrambi distribuibili e scalabili in modo indipendente.

• Health check e problematiche comuni

  • Gli health check devono essere permessi dal firewall. Per gli health check di tipo HTTP(S) esterno, consentire il traffico da 130.211.0.0/22 e 35.191.0.0/16 verso i backend. Una regola mancante fa sì che i backend vengano contrassegnati come non integri (unhealthy) e causa rapidi riavvii delle VM se l’autoscaling reagisce ai segnali del load balancer.
  • Allineare i percorsi e le porte degli health check con gli endpoint di readiness dei container; impostare timeout e soglie per bilanciare un failover rapido con il rischio di falsi positivi.

• Architettura DNS

  • Utilizzare Cloud DNS per le zone autoritative. Creare zone private per i nomi interni; creare zone pubbliche per i nomi su Internet.
  • DNS split-horizon: fornire risposte diverse internamente ed esternamente creando zone pubbliche e private separate con nomi identici. Questo supporta in modo sicuro nomi host di servizi privati e record esposti pubblicamente.
  • Zone di forwarding e peering: integrare con il DNS on-premise utilizzando policy DNS e policy server per inoltrare query per domini specifici; usare il forwarding condizionale per evitare loop di ricorsione.
  • Service discovery: adottare convenzioni di denominazione coerenti per ogni ambiente e servizio. Per GKE, considerare i servizi headless con Cloud DNS, o mappare gli endpoint dei servizi tramite Internal HTTP(S) Load Balancer e nomi DNS privati.

• Caching perimetrale e protezione

  • Cloud CDN esegue l’offload dei contenuti memorizzabili nella cache a livello perimetrale (edge), riducendo la latenza verso l’origine e i costi di egress. Impostare con attenzione le chiavi di cache, i TTL e il negative caching; bypassare la cache per endpoint personalizzati o dinamici.
  • Cloud Armor fornisce WAF, rate limiting e controllo degli accessi basato su geolocalizzazione/IP. Associare le policy di sicurezza ai load balancer; monitorare i log di attivazione delle regole (rule hit). Utilizzare regole preconfigurate per le CVE comuni e firme personalizzate per minacce specifiche dell’applicazione.
  • La terminazione TLS a livello del load balancer centralizza la gestione dei certificati; abilitare il provisioning automatico dei certificati e i rinnovi gestiti dove possibile.

Guida operativa:

• API versionate: implementare il routing basato su percorso o host verso servizi di backend separati, in modo che ogni versione possa essere rilasciata in modo indipendente con pattern blue-green o canary.
• Utilizzare header di richiesta e cookie per l’A/B testing tramite policy di instradamento del traffico (traffic steering); verificare sempre che i log e le metriche siano correlati all’identità corretta del backend.

Connettività ibrida, accesso privato e transito

• Cloud Router e BGP

  • Cloud Router scambia dinamicamente le route con l’ambiente on-premise tramite BGP per i tunnel Cloud VPN e gli allegati Interconnect. Utilizzare la modalità di routing dinamico globale nel VPC quando è richiesta la connettività spoke multi-regionale.
  • Annunciare solo i prefissi necessari; filtrare per prevenire perdite di route. Comprendere le interazioni tra MED e priorità durante la progettazione di percorsi primari/di backup.

• Cloud VPN, Dedicated Interconnect e Partner Interconnect

  • HA VPN fornisce tunnel ridondanti su IPsec con SLA garantito, supporta il routing dinamico tramite Cloud Router ed è adatto per ambienti ibridi di produzione con esigenze di larghezza di banda moderate.
  • Dedicated Interconnect fornisce collegamenti fisici da 10/100 Gbps in una o più località; Partner Interconnect offre una soluzione simile tramite un service provider. Utilizzare almeno due interconnessioni diverse in località metropolitane separate o in zone perimetrali (edge zone) separate per l’alta disponibilità.
  • Percorsi ridondanti e failover: progettare una configurazione attivo/attivo con BGP su due Cloud Router per regione e due router on-premise; convalidare la tolleranza al routing asimmetrico. Testare regolarmente il failover; ottimizzare i timer BFD e le soglie di integrità per la convergenza desiderata.
  • Modalità di guasto: un disallineamento dell’MTU causa frammentazione e penalizzazioni delle prestazioni; assicurare il supporto ai jumbo frame end-to-end per l’Interconnect. Filtri di route configurati in modo errato possono creare un blackhole per le subnet. I circuiti partner single-homed sono un comune single point of failure.

• Cloud NAT, Private Google Access e Private Service Connect

  • Cloud NAT abilita il traffico in uscita (egress) verso Internet per le VM private senza IP esterni. Dimensionare gli IP del NAT e le allocazioni delle porte per le connessioni di picco al fine di evitare l’esaurimento delle porte; abilitare il logging per la risoluzione dei problemi.
  • Private Google Access consente alle VM private di raggiungere le API di Google utilizzando IP interni; abilitarlo sulle subnet per l’accesso delle VM e sui nodi GKE per l’accesso alle API a livello di nodo. Per i client on-premise, utilizzare Private Service Connect per le API di Google per esporre VIP privati che fungono da frontend per le API di Google.
  • Private Service Connect per i servizi producer/consumer fornisce endpoint IP privati e interni per la pubblicazione di servizi tra progetti o organizzazioni diverse; combinarlo con il DNS privato per instradare il traffico senza esporre le reti.

• Network Connectivity Center (NCC) e transito

  • NCC abilita topologie hub-and-spoke in cui gli spoke sono VPC, HA VPN o allegati Interconnect. Utilizzare un hub centrale per semplificare la distribuzione delle route e il transito multi-VPC, specialmente tra progetti o organizzazioni diverse.
  • Preferire Shared VPC per il transito all’interno della stessa organizzazione quando la governance lo consente; utilizzare NCC quando è necessario un transito flessibile e multi-dominio o l’integrazione con SD-WAN.
  • Comprendere che il VPC Peering non è transitivo; non fare affidamento su di esso per il transito. NCC o un VPC centralizzato con firewall/load balancer costituisce il nucleo del transito (transit core).

Scelte multi-regionali, latenza e costi di egress:

• Posizionare le risorse di calcolo (compute) vicino agli utenti e ai backend stateful per minimizzare l’RTT. External HTTP(S) Load Balancing fornisce un ingresso (ingress) globale con routing intelligente, ma la latenza di replica del database e la coerenza rimangono vincoli a livello applicativo.
• Il traffico tra zone (cross-zone) comporta costi all’interno di una regione; la replica tra regioni (cross-region) aggiunge costi di egress e latenza. Utilizzare Cloud CDN per ridurre l’egress verso Internet e il carico sull’origine, e mantenere i servizi “chiacchieroni” (chatty) nella stessa località.
• Per il disaster recovery, valutare un’istanza warm standby in un’altra regione rispetto ai costi di egress e alla complessità operativa. Utilizzare il bilanciamento del carico globale con policy di failover e health check che coprono più regioni solo quando il data plane e il control plane possono tollerare l’isolamento regionale.

Osservabilità, operazioni di affidabilità e controlli

• Osservabilità della rete

  • VPC Flow Logs: abilitarli a livello di subnet e regolare le opzioni di campionamento e metadati. Utilizzarli per il baselining del traffico, l’analisi del traffico in uscita (egress) e la caccia alle minacce (threat hunting). Esportare su BigQuery per analisi a lungo termine.
  • Logging delle regole firewall: abilitarlo sulle regole critiche per catturare il traffico consentito e negato; correlare con i flow log per rilevare configurazioni errate.
  • Connectivity Tests: modellare i percorsi origine-destinazione per convalidare la raggiungibilità, la selezione delle route e la valutazione del firewall. Integrare in CI/CD per rilevare deviazioni (drift) prima del deployment.
  • Dashboard di stato (Health dashboards): monitorare lo stato dei backend del load balancer, l’utilizzo delle porte di Cloud NAT, lo stato della sessione BGP di Cloud Router e l’utilizzo di Interconnect. Impostare alert in caso di deviazioni.

• Pattern di affidabilità e modalità di guasto comuni

  • Resilienza zonale: distribuire i backend su almeno due zone; utilizzare gruppi di istanze gestite (managed instance groups) o node pool multi-zona di GKE. Verificare che gli health check e i tag del firewall si applichino a tutte le zone.
  • Resilienza del routing: utilizzare il routing dinamico globale e più Cloud Router per la connettività tra regioni. Testare scenari di blackhole e assicurarsi che il monitoraggio copra la revoca delle route.
  • Resilienza DNS: implementare più name server di default con Cloud DNS; per l’ibrido, assicurarsi che i forwarder siano ridondanti ed evitare single point of failure nei resolver on-premise. Prevenire configurazioni errate di tipo split-horizon che restituiscono risposte non instradabili dalla parte sbagliata.
  • Sicurezza perimetrale (at the edge): applicare i limiti di frequenza (rate limits) di Cloud Armor per proteggere l’origine da attacchi di tipo flood; non farlo può innescare tempeste di autoscaling e picchi di costo.

• Controllo dei costi

  • Minimizzare le chiamate tra regioni, preferire il bilanciamento del carico interno per il traffico intra-VPC e considerare PSC per il traffico producer-consumer per evitare l’egress tramite NAT.
  • Utilizzare Cloud CDN per gli asset statici e semi-statici; ottimizzare la cacheability. Dimensionare la capacità di Interconnect per evitare di pagare per capacità inutilizzata (idle headroom); utilizzare i dati sul traffico per dimensionare correttamente gli impegni (commit).

Snippet operativi:

• Consentire gli health check del load balancer verso i backend privati:

undefined

• Abilitare Private Google Access su una subnet:

undefined

• Creare un Cloud Router per HA VPN:

undefined

Scenario pratico

Contoso Retail pianifica di lanciare un’API e-commerce globale con versioning senza downtime, connettività strettamente privata ai sistemi di back-office e nessuna IP pubblico sulle VM applicative. La soluzione deve fornire protezione DDoS, caching perimetrale (edge caching) e un accesso ibrido affidabile da due data center.

Approccio:

1. Progettare il VPC e la segmentazione

• Creare un Shared VPC Host Project in modalità custom con subnet dedicate per ogni livello (web, api, data) distribuite su due regioni. Motivazione: lo Shared VPC centralizza i controlli mentre i service project isolano i team. Le subnet per livello consentono di applicare il principio del privilegio minimo (least-privilege) al firewalling e di avere domini di guasto più piccoli.
• Applicare policy firewall gerarchiche a livello di organizzazione per negare l’SSH in entrata da internet e limitare il traffico in uscita (egress) alle destinazioni consentite. Motivazione: i guardrail globali riducono il rischio di configurazioni errate nei progetti.

2. Implementare l’ingresso globale basato su percorsi (path-based) e il versioning delle API

• Implementare un External HTTP(S) Load Balancer con un singolo IP anycast e terminazione HTTPS. Configurare le URL map per instradare /v1/* e /v2/* a backend service separati, supportati da NEG zonali regionali. Motivazione: backend service distinti consentono deployment e rollback indipendenti per ogni versione dell’API sotto un unico nome host e certificato TLS.
• Associare Cloud Armor WAF e i rate limit; abilitare Cloud CDN per gli endpoint memorizzabili nella cache (ad esempio, immagini dei prodotti). Motivazione: protegge l’origine e riduce la latenza e i costi di egress.

3. Garantire la raggiungibilità e lo stato dei backend

• Creare una regola firewall per consentire gli health check del load balancer verso i gruppi di istanze API sulle porte previste. Motivazione: senza questa regola, gli health check fallirebbero e gli autoscaler potrebbero entrare in un ciclo di instabilità (thrashing) poiché le istanze verrebbero considerate non integre (unhealthy).
• Distribuire le istanze su due zone per regione; impostare le soglie degli health check in modo conservativo per evitare instabilità (flapping). Motivazione: la diversità zonale e policy di health check stabili migliorano la disponibilità.

4. Costruire il DNS con split-horizon e service discovery

• Creare una zona Cloud DNS pubblica per contoso.com e una zona privata con lo stesso nome per i record solo interni (ad esempio, db.internal.contoso.com). Motivazione: lo split-horizon impedisce la fuga di nomi interni mantenendo una nomenclatura coerente.
• Configurare le policy DNS per inoltrare le query on-premise per corp.local al DNS aziendale e importare le zone private nei progetti applicativi. Motivazione: risoluzione trasparente attraverso i confini ibridi senza cicli di ricorsione (recursion loops).

5. Stabilire la connettività ibrida con ridondanza

• In ogni regione, predisporre due tunnel HA VPN verso ciascun data center, con ogni coppia su Cloud Router separati con BGP. Se la capacità e le esigenze di SLA lo giustificano, aggiungere Partner Interconnect con collegamenti (attachment) ridondanti in edge zone separate. Motivazione: percorsi multipli e diversificati forniscono failover; il BGP consente una convergenza rapida e lo scambio dinamico di route.
• Utilizzare il routing dinamico globale nello Shared VPC e applicare filtri di route per impedire la propagazione di prefissi on-premise indesiderati. Motivazione: routing coerente tra le regioni riducendo al contempo il rischio di fughe di route (route leaks).

6. Fornire accesso privato alle API di Google e a internet in uscita

• Abilitare Private Google Access sulle subnet delle applicazioni e configurare endpoint Private Service Connect per le API di Google utilizzate dai processi batch. Utilizzare Cloud NAT per il traffico in uscita (egress) non diretto alle API, dove necessario. Motivazione: i backend non mantengono IP pubblici pur potendo raggiungere i servizi necessari; PSC semplifica la risoluzione dei nomi con il DNS privato.

7. Centralizzare il transito e la connettività con terze parti

• Creare un hub Network Connectivity Center nell’Host Project; collegare HA VPN, collegamenti Interconnect ed eventuali spoke SD-WAN. Motivazione: il transito hub-and-spoke semplifica la distribuzione delle route tra più VPC e reti esterne rispetto a mesh di peering.

8. Implementare osservabilità e guardrail

• Abilitare i VPC Flow Logs su tutte le subnet con un campionamento appropriato; abilitare i log del firewall sulle regole critiche; esportare su BigQuery. Utilizzare i Connectivity Tests in CI/CD prima di promuovere nuove modifiche al firewall o alle route. Motivazione: una visibilità approfondita supporta il troubleshooting, la pianificazione della capacità e l’auditabilità.
• Impostare alert per le cadute di sessione BGP di Cloud Router, l’esaurimento delle porte di Cloud NAT, i cali di stato dei backend e gli hit sulle regole di Cloud Armor. Motivazione: il rilevamento precoce di guasti e attacchi riduce il tempo medio di ripristino (MTTR).

9. Ottimizzare per prestazioni e costi

• Collocare i servizi stateful insieme alle risorse di calcolo (compute) nella stessa regione; memorizzare nella cache i contenuti statici sul perimetro (at the edge) con Cloud CDN. Motivazione: minimizza il RTT e il traffico in uscita (egress) tra regioni.
• Rivedere periodicamente i flow log per identificare il traffico “chiacchierone” (chatter) tra zone e regolare il posizionamento o i confini dei servizi. Motivazione: riduce l’egress non necessario e la latenza.

Questo design offre un ingresso globale e sicuro con routing versionato, connettività ibrida resiliente con failover dinamico, accesso privato ai servizi richiesti e un’osservabilità completa, controllando al contempo la latenza e i costi di egress.

← Storage dei dati · Tutti i domini · Sicurezza →

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

Sfoglia Google →