Reti VPC e subnet

Una rete VPC in Google Cloud è una risorsa globale, mentre le subnet sono regionali: una singola VPC può estendersi su più region senza gateway o tunnel intermedi. Esistono due modalità. In auto mode Google crea automaticamente una subnet per ogni region da range predefiniti (in 10.128.0.0/9) e ne aggiunge quando nascono nuove region. In custom mode definisci tu ogni subnet, scegliendo region e CIDR: è la scelta consigliata in produzione perché evita sovrapposizioni di range e ti dà controllo sull’indirizzamento. Puoi convertire una VPC da auto a custom, ma non il contrario. Ogni subnet ha un range primario e può avere range secondari (usati ad esempio dagli alias IP dei Pod GKE).

Firewall rule e indirizzi IP

Le firewall rule della VPC sono stateful e agiscono a livello di rete, non della singola VM. Ogni rule ha un’azione allow o deny, una priority (0–65535, dove il numero più basso vince, default 1000), una direction (INGRESS o EGRESS) e un target che può essere tutte le istanze, un target tag oppure un service account. La sorgente per l’ingress si esprime con range IP, source tag o source service account. Esistono rule implicite non rimovibili: deny su tutto l’ingress e allow su tutto l’egress.

Gli indirizzi IP possono essere interni o esterni e, per ognuno, effimeri o statici (riservati). Un IP esterno effimero viene rilasciato quando la VM è arrestata o eliminata; se ti serve un indirizzo stabile riservi uno statico. Gli IP esterni statici sono regionali (VM, LB regionali) o globali (solo per i load balancer globali). Attenzione: un IP statico riservato ma non associato continua a essere fatturato.

Cloud Load Balancing

Cloud Load Balancing si sceglie lungo tre assi: esterno vs interno, globale vs regionale e livello 7 (HTTP/S) vs livello 4 (TCP/UDP). L’Application Load Balancer opera a livello 7: nella variante global external fa routing per host/path tramite URL map, integra Cloud CDN e i Google-managed certificates; esiste anche come internal per traffico solo interno alla VPC. Il Network Load Balancer opera a livello 4: la variante passthrough è regionale, preserva l’IP del client ed è ideale per TCP/UDP non proxato, mentre la variante proxy termina la connessione. Il backend è un instance group (idealmente un managed instance group, che dà autoscaling e self-healing) oppure un NEG, e ogni backend service richiede un health check.

Cloud DNS, Cloud NAT e connettività ibrida

Cloud DNS è il servizio DNS autoritativo gestito: crei zone pubbliche (risolvibili da internet) o zone private (risolvibili solo dalle VPC associate), gestisci i record set (A, AAAA, CNAME, MX, TXT) e puoi attivare DNSSEC sulle zone pubbliche, oltre a forwarding e DNS peering.

Cloud NAT dà connettività egress verso internet alle VM prive di IP esterno, senza esporle a connessioni entranti. È un servizio gestito regionale, associato a un Cloud Router, che elimina la necessità di gateway NAT su VM.

Per la connettività ibrida: Cloud VPN crea tunnel IPsec cifrati sopra internet (HA VPN, con SLA 99,99%, usa BGP tramite Cloud Router); Cloud Interconnect offre un collegamento privato ad alta banda e bassa latenza, nelle varianti Dedicated (fisico diretto) o Partner (tramite provider); VPC Network Peering collega due VPC via IP interni senza attraversare internet, è non transitivo e non ammette range sovrapposti.

Trappole tipiche d’esame

  • VM senza IP pubblico che deve scaricare aggiornamenti da internet → Cloud NAT: dà egress senza esporre le istanze; assegnare un IP esterno le renderebbe raggiungibili dall’esterno.
  • Due firewall rule in conflitto, una allow e una deny → vince la priority più bassa: il numero minore ha precedenza, non l’azione deny in quanto tale.
  • Serve routing per host/path in HTTPS a livello globale → global external Application Load Balancer: il Network Load Balancer è L4 e regionale, non fa URL map.
  • Collegare più VPC ma il traffico non “rimbalza” su una terza rete → il peering è non transitivo: ogni coppia va peered esplicitamente e i range non devono sovrapporsi.
  • Range sovrapposti o subnet indesiderate ovunque → usa custom mode: l’auto mode crea una subnet in ogni region e complica peering e connettività ibrida.
  • Indirizzo IP statico riservato ma inutilizzato → viene comunque fatturato: rilascia gli IP statici non associati per evitare costi.