Las dos reglas de red del módulo de AWS — nada que piense o guarde vive expuesto, y el egress es una lista corta de destinos — son la arquitectura, y viajan intactas. GCP cambia la geometría y los nombres de las piezas, con una diferencia estructural arriba de todo: el alcance de la red.

Concepto	En AWS	En GCP
Alcance de la VPC	Regional (una por región)	Global (una red, subredes por región)
Firewall	Security groups (por recurso)	Reglas de VPC por tags / service accounts
Salida controlada de privadas	NAT Gateway	Cloud NAT
Acceso privado a servicios cloud	VPC endpoints / PrivateLink	Private Google Access / Private Service Connect
Exponer/consumir servicios privados	PrivateLink	Private Service Connect

La tesis del módulo

La VPC global de GCP elimina una categoría entera de plomería — peering y túneles entre regiones para una misma plataforma — pero no elimina ninguna decisión de seguridad: subredes privadas, salida por NAT controlada y la lista corta de egress se diseñan igual. Y el firewall de GCP tiene un regalo para plataformas de agentes: las reglas se declaran contra service accounts — “solo la SA del gateway habla con la SA de los agentes” — uniendo identidad y red en la misma frase.

La VPC global: qué te ahorra y qué no

Una VPC de GCP es una sola red lógica mundial; sus subredes son regionales. El agente en us-central1 y la base en southamerica-east1 conviven en la misma red sin peering, sin túneles, sin duplicar topología — lo que en AWS multi-región era un proyecto, aquí es el default. Qué no te ahorra: la latencia entre regiones sigue existiendo (la física no lee documentación), los criterios de elección de región del módulo 1 siguen mandando, y el aislamiento entre entornos ya no lo da la región — lo dan VPCs separadas por entorno (recuerda: los proyectos son livianos, y una VPC por proyecto de entorno es el patrón limpio).

El firewall por identidad

Las reglas de firewall de GCP viven a nivel de red y seleccionan sus objetivos por tags de red o por service account. La segunda opción es la joya para esta serie: la topología de quién-habla-con-quién se declara contra las identidades del módulo 2 —

“acepta tráfico hacia los agentes solo desde la service account del API gateway”,
“la base acepta solo desde la SA de los agentes”

— sin IPs, sin grupos que mantener, y con la propiedad elegante de que la regla de red y la identidad IAM nombran al mismo actor. Es el security-group-referenciado de AWS llevado un paso más lejos: la referencia es directamente el principal.

Hablar con Google sin salir: dos piezas

El equivalente de los VPC endpoints tiene en GCP dos mecanismos complementarios:

Private Google Access: el interruptor de subred que permite a recursos sin IP pública alcanzar las APIs de Google (Vertex, Pub/Sub, Storage) por la red interna. Es la versión “activa y listo”: cubre el caso principal — tu plataforma privada consumiendo servicios de Google — sin crear endpoints uno por uno.
Private Service Connect (PSC): el mecanismo fino — endpoints privados con IP propia dentro de tu VPC hacia APIs de Google, servicios de terceros o servicios tuyos publicados a otras VPCs. Es el PrivateLink de GCP: entra cuando necesitas control por-endpoint, consumir servicios de un tercero en privado, o publicar tu propio servicio (tu LLM gateway, por ejemplo) a consumidores externos sin exponerlo a internet.

La regla práctica: Private Google Access para el grueso, PSC para lo fino — y la servilleta del módulo de AWS (“con qué habla mi plataforma”) sigue siendo el artefacto: solo cambia con qué mecanismo se implementa cada línea.

El egress: mismo guardrail, mismas razones

Cloud NAT da la salida controlada de las subredes privadas; las reglas de firewall de egress (denegar por defecto, permitir la lista corta) cierran la jaula — por IP/rango o, de nuevo, por service account de origen. La trifecta letal no lee logos de nube: el agente con datos sensibles, contenido no confiable y salida libre es el mismo canal de exfiltración aquí que en AWS, y la lista corta escrita es la misma arquitectura. GCP agrega un nivel superior para quien lo necesita — los VPC Service Controls, perímetros que encierran servicios y datos completos — pero esos son protagonistas del módulo 10; por ahora, la jaula de egress básica es obligatoria y suficiente para empezar.

     LA RED GCP DE LA PLATAFORMA (una VPC global)

  internet ── solo lo que el gateway expone
     │
     ▼
  ┌─────────────────────────────────────────┐
  │ subred privada (región A)               │
  │   agentes en Cloud Run + bases          │
  │   firewall: solo desde SA del gateway   │
  └─────────────────────────────────────────┘
     │ Private Google Access
     ▼
   Vertex AI · Pub/Sub · Storage (sin internet)
     │
     ▼
   Cloud NAT ── egress: lista corta, por SA

Errores comunes

Asumir que “global” significa “sin diseño”. La VPC global ahorra peering, no decisiones: subredes por región con propósito, VPCs separadas por entorno, y la misma disciplina de privado-por-defecto.
Reglas de firewall por IP. Con tags y service accounts disponibles, las IPs son el mecanismo más frágil de los tres. Por identidad siempre que se pueda; es también la regla más legible en una auditoría.
Ignorar Private Google Access por buscar “endpoints”. El traductor de AWS busca crear un endpoint por servicio; en GCP la mayor parte se resuelve con un interruptor de subred. PSC es para lo fino, no para todo.
Egress abierto “porque la VPC es privada”. Privado hacia adentro no es controlado hacia afuera. La lista corta de egress se declara igual que en AWS, con las mismas consecuencias si falta.
Olvidar que el aislamiento de entornos cambió de eje. En AWS la región y la cuenta aislaban de facto; en GCP con VPC global, el aislamiento es VPC/proyecto por entorno — se decide, no se hereda del mapa.

La frase para llevarse

“Una red global te ahorra los túneles, no las decisiones: privado por defecto, Private Google Access para hablar con Google sin salir, y el egress como lista corta — ahora declarable por service account, que es la forma más honesta de escribir quién habla con quién.”

Qué viene

Módulo 5: integración — Pub/Sub y los despertadores. La arquitectura del despertar (colas, eventos, reloj) ya la tienes; GCP la implementa con un giro: Pub/Sub unifica en un solo servicio lo que AWS reparte entre SQS y SNS, Cloud Tasks aporta un tipo de cola que AWS no tiene (con destino HTTP y control de ritmo), y Eventarc + Scheduler completan el cuadro. Mismo patrón, piezas reagrupadas.

Arquitectura GCP — Módulo 4: redes, la VPC global