Architettura di rete: VPC e Shared VPC

Una VPC in Google Cloud è una risorsa globale: le subnet sono regionali, ma la rete attraversa le region senza tunnel aggiuntivi. Per organizzazioni con più team il pattern autoritativo è Shared VPC: un host project possiede la rete, le subnet, il routing e le firewall rules, mentre più service projects vi collegano le proprie VM. Questo centralizza il controllo di rete su un team di piattaforma e lascia autonomi i team applicativi sui rispettivi progetti. Da non confondere con il VPC Network Peering, che connette due VPC separate ma non è transitivo: se A fa peering con B e B con C, A non raggiunge C. Per topologie hub-and-spoke con transitività si usa Network Connectivity Center.

Sul piano della protezione dati, VPC Service Controls crea un perimetro attorno alle API gestite (Cloud Storage, BigQuery) per prevenire l’esfiltrazione: è un perimetro logico, non un firewall, e non filtra il traffico L3/L4. Per far accedere workload alle risorse senza distribuire service account key statiche si usa Workload Identity Federation.

Connettività ibrida e distribuzione del traffico

Le opzioni di collegamento on-premises si scelgono per SLA, banda e latenza:

  • Cloud VPN (HA VPN): tunnel IPsec su Internet pubblica, rapido ed economico, banda limitata per tunnel.
  • Dedicated Interconnect: connessione fisica diretta ad alta banda e latenza prevedibile; richiede presenza in una colocation facility Google.
  • Partner Interconnect: via service provider quando non si ha presenza nella facility, con banda flessibile.

Il Cloud Load Balancing è globale con IP anycast: il global external Application Load Balancer (L7) instrada su più region da un solo IP, ideale per web multi-region; i Network Load Balancer (L4) coprono TCP/UDP. Cloud CDN si abilita sul load balancer per la cache al bordo, mentre Cloud Armor agisce al bordo come WAF e mitigazione DDoS.

Alta disponibilità e disaster recovery

L’HA si progetta partendo dai domini di guasto: distribuire le istanze su più zone protegge dal guasto di una zona; per resistere al guasto di un’intera region serve un deployment multi-region. Gli obiettivi guida sono RTO (tempo massimo di ripristino) e RPO (perdita massima di dati tollerata). Le strategie tipiche, dal costo minore al maggiore:

  • Backup & restore: RTO/RPO alti, costo minimo.
  • Warm standby (pilot light): risorse ridotte pronte a scalare.
  • Multi-region attivo/attivo: RTO/RPO prossimi a zero, costo massimo.

Per i dati: Cloud SQL è regionale con opzione HA (standby in altra zona) e read replica cross-region; per un database relazionale globale con consistenza forte e failover gestito si usa Cloud Spanner. Cloud Storage offre bucket multi-region per durabilità geografica.

Pianificazione della migrazione

Il framework Google articola le fasi (assess, plan, deploy, optimize) e le strategie:

  • Rehost (lift-and-shift): sposta le VM senza modifiche con Migrate to Virtual Machines; veloce, ma nessun beneficio cloud-native.
  • Replatform: piccole ottimizzazioni (es. da MySQL self-managed a Cloud SQL).
  • Refactor: riscrittura verso container/serverless, massimo beneficio a fronte di costo e rischio maggiori.

Per i database, il Database Migration Service esegue migrazioni con replica continua, minimizzando il downtime al cutover. I committed use discount riducono il costo dei carichi prevedibili una volta a regime.

Trappole tipiche d’esame

  • Serve transitività tra più VPC → soluzione: VPC Peering NON è transitivo; centralizza con Shared VPC o usa Network Connectivity Center per hub-and-spoke.
  • Bloccare l’esfiltrazione dati verso progetti esterni → soluzione: VPC Service Controls (perimetro sulle API gestite), non firewall rules né Cloud Armor.
  • Database relazionale globale con consistenza forte → soluzione: Cloud Spanner; Cloud SQL è regionale e non scala globalmente in scrittura.
  • Massima banda dedicata e latenza prevedibile verso on-prem → soluzione: Dedicated Interconnect; Cloud VPN copre banda modesta su Internet.
  • RPO vicino a zero cross-region → soluzione: replica multi-region attiva, non backup periodici che alzano l’RPO.
  • Migrazione VM rapida senza rewrite → soluzione: rehost con Migrate to Virtual Machines; il refactor solo quando serve davvero cloud-native.