Direct VPC Egress su Cloud Run & Functions Gen 2: Addio al Vecchio VPC Connector

Per anni, collegare un servizio serverless su Google Cloud (come Cloud Run o Cloud Functions) alle risorse private all’interno di una Virtual Private Cloud (VPC) – ad esempio database PostgreSQL, istanze Redis Memorystore o cluster MongoDB privati – ha richiesto l’utilizzo del Serverless VPC Access Connector.
Sebbene funzionale, il vecchio connettore introduceva diversi svantaggi operativi:
- Costi Fissi Obbligatori: Richiedeva il mantenimento di un gruppo di macchine virtuali dedicate (
e2-microof1-micro) sempre accese, con costi fissi anche a traffico zero. - Latenza di Connessione: Il traffico doveva attraversare il connettore prima di raggiungere la VPC, aggiungendo millisecondi preziosi a ogni query.
- Complessità di Sizing: Rischio di colli di bottiglia o saturazione della banda durante improvvisi picchi di carico (spike di richieste).
Con l’introduzione di Direct VPC Egress su Google Cloud Run e Cloud Functions (Gen 2), l’architettura serverless compie un salto generazionale.
1. Come Funziona il Direct VPC Egress
Con il Direct VPC Egress, il container Cloud Run viene collegato direttamente alla subnet VPC attraverso un’interfaccia di rete virtuale nativa:
[ Architettura Direct VPC Egress ]
+-------------------------------+
| Google Cloud Run (Gen 2) |
| |
| vpc_access { |
| network_interfaces { ... } |
| egress = PRIVATE_RANGES_ONLY|
| } |
+-------------------------------+
|
| (Connessione Diretta Zero-Hop)
v
+-----------------------------------------------------------------------------------+
| Google Cloud VPC Network (europe-west1) |
| |
| +---------------------------+ +------------------------+ +----------------+ |
| | Cloud SQL / PostgreSQL | | Redis Memorystore | | Cloud NAT | |
| | (IP Privato Interno) | | (IP Privato Interno) | | (Uscita Web) | |
| +---------------------------+ +------------------------+ +----------------+ |
+-----------------------------------------------------------------------------------+
2. I Vantaggi Chiave Rispetto al Vecchio VPC Connector
- Abbattimento della Latenza: Eliminando il passaggio attraverso le VM del connettore intermedio (zero-hop routing), la latenza di rete verso Redis e database SQL si riduce drasticamente.
- Zero Costi Fissi: Nessuna istanza Compute Engine dedicata da pagare h24. I costi di rete scalano proporzionalmente all’effettivo volume di traffico scambiato.
- Throughput Scalabile: Nessun limite di throughput imposto dalla taglia delle VM del connettore; la banda scala dinamicamente con le istanze del servizio Cloud Run.
3. Configurazione Terraform: Da VPC Connector a Direct Egress
La transizione nei manifest Terraform richiede poche righe di codice:
# Configurazione Moderna con Direct VPC Egress su Google Cloud Run
resource "google_cloud_run_v2_service" "api_service" {
name = "core-api-service"
location = "europe-west1"
template {
containers {
image = "europe-west1-docker.pkg.dev/my-project/apps/api:v1.4.0"
resources {
limits = {
cpu = "2"
memory = "2Gi"
}
cpu_idle = true
}
}
# Collegamento diretto alla subnet privata senza VPC Access Connector
vpc_access {
network_interfaces {
network = "projects/my-project/global/networks/main-vpc"
subnetwork = "projects/my-project/regions/europe-west1/subnetworks/app-subnet"
}
# Inoltra verso la VPC solo gli indirizzi di rete privati RFC 1918
egress = "PRIVATE_RANGES_ONLY"
}
}
}
Impostando egress = "PRIVATE_RANGES_ONLY", le chiamate ai database e microservizi interni transitano privatamente nella VPC, mentre le chiamate verso API esterne escono direttamente su Internet (o tramite Cloud NAT con IP statico garantito).
Conclusioni
Il passaggio a Direct VPC Egress è una best practice imprescindibile per qualsiasi workload serverless su Google Cloud: semplifica l’architettura IaC, abbatte i costi fissi ed eroga prestazioni ottimali.