Network tier e topologia VPC

Il network tier decide il percorso del traffico ed è una scelta di costo/latenza. Il Premium tier trasporta il traffico end-to-end sul backbone globale di Google (cold-potato routing): latenza minima, IP anycast globali e global external load balancing. Lo Standard tier instrada sulla rete pubblica il più vicino possibile alla sorgente (hot-potato), costa meno ma è regionale: niente global load balancing, IP legato a una regione. Regola: reach globale o bassa latenza → Premium; workload regionale cost-sensitive → Standard.

La VPC è globale, mentre le subnet sono regionali con range IP regionali. La Shared VPC centralizza la rete in un host project e condivide le subnet con i service project: ideale per governance org-wide. Il VPC Network Peering collega due VPC ma non è transitivo (A↔B e B↔C non danno A↔C); per una topologia hub-and-spoke transitiva serve Network Connectivity Center.

Alta disponibilità, DNS e connettività ibrida

Il design HA/DR distribuisce i backend su più region/zone e usa un load balancer globale con health check per il failover automatico. Cloud DNS è il DNS gestito con public e private zone: supporta routing policy (geolocation, weighted) e DNS-based failover; le private zone risolvono i nomi interni dentro la VPC, mentre DNS peering e forwarding gestiscono la risoluzione ibrida verso on-prem.

Per l’ibrido: HA VPN offre SLA 99.99% (il Classic VPN no), con due interfacce e BGP tramite Cloud Router. Cloud Interconnect esiste come Dedicated (fisico diretto) e Partner (via provider, L2 o L3), più Cross-Cloud Interconnect verso altri cloud. Il Cloud Router fa BGP dynamic routing: in global mode annuncia tutte le subnet, in regional mode solo quelle della region.

Scelta del load balancer

La scelta dipende da tre assi:

  • Internal vs external: client privato dentro la VPC oppure da internet.
  • Global vs regional.
  • Tipo/livello: Application Load Balancer (L7, HTTP/S, routing per host/path, TLS termination, integra Cloud Armor e Cloud CDN); proxy Network Load Balancer (L4 TCP/SSL, termina la connessione); passthrough Network Load Balancer (L4, non termina e preserva l’IP client sorgente).

Esempi: sito HTTP pubblico con WAF → external Application LB globale; traffico TCP che deve conservare l’IP client → passthrough Network LB; microservizio HTTP interno → internal Application LB. Cloud Armor protegge solo i backend di un external Application LB.

GKE networking, IAM di rete e servizi gestiti

I cluster GKE VPC-native usano alias IP con secondary range: uno per i Pod, uno per i Service, più il primary per i nodi. Dimensiona questi range in anticipo: densità dei Pod e scala del cluster consumano spazio IP e un sottodimensionamento blocca la crescita.

Ruoli IAM di rete: Network Admin (rete, esclusi firewall e SSL), Security Admin (firewall e certificati SSL), compute.networkUser (uso delle subnet, indispensabile per i service project in Shared VPC). Servono a separare i compiti.

Connettività ai servizi gestiti, da non confondere:

  • Private Google Access: istanze senza IP esterno raggiungono le API Google.
  • private services access: range in peering per servizi gestiti (es. Cloud SQL).
  • Private Service Connect (PSC): private endpoint con IP interno verso API Google o servizi pubblicati, senza peering e senza problemi di overlap.
  • Serverless VPC Access: connector che porta Cloud Run/Functions/App Engine dentro la VPC.

Trappole tipiche d’esame

  • Comunicazione tra spoke in hub-and-spoke → Network Connectivity Center: il VPC Peering non è transitivo; aggiungere peering multipli non collega gli spoke tra loro.
  • Preservare l’IP client sorgente a L4 → passthrough Network LB: i proxy (Application LB e proxy Network LB) terminano la connessione e mascherano l’IP; solo il passthrough lo mantiene.
  • IP singolo globale con backend multi-region → Premium tier: lo Standard tier è regionale e non supporta il global load balancing con anycast.
  • Requisito SLA 99.99% sulla VPN → HA VPN: il Classic VPN non offre quello SLA; se lo scenario lo cita, scegli HA VPN.
  • Egress per istanze senza IP esterno → Cloud NAT: Cloud NAT è solo egress, non fa ingress e non è un firewall; per le API Google serve Private Google Access.
  • Bloccare l’esfiltrazione dati verso progetti esterni → VPC Service Controls: è un perimetro, non un firewall né un controllo IAM; le firewall rules non fermano l’esfiltrazione via API.