Segundo curso de la serie de nubes, y el primero que se beneficia de la promesa de la serie: la arquitectura ya la aprendiste en el curso de AWS — los cuatro tiempos del agente autónomo, las jaulas independientes, el mapa antes que los servicios. Este curso no repite nada de eso: cada módulo abre con la tabla de equivalencias, dedica dos frases al recap, y gasta el espacio en lo que de verdad cambia en Google Cloud — que es menos de lo que el marketing sugiere y más de lo que un buscar-y-reemplazar tolera.

Y la primera diferencia real está exactamente donde el curso de AWS empezó: la unidad de aislamiento.

Concepto	En AWS	En GCP
Unidad de aislamiento	Cuenta	Proyecto (semántica distinta — ver abajo)
Agrupador organizacional	Organizations + OUs	Organización + carpetas
Política central	SCP	Organization Policy
Landing zone semi-armada	Control Tower	Setup de organización + blueprints
Región / AZ	Región / AZ	Región / zona (mismo concepto)

La tesis del módulo

El proyecto de GCP no es la cuenta de AWS con otro nombre: es una unidad mucho más liviana — se crean en segundos, se agrupan en carpetas, y cada uno decide qué APIs tiene habilitadas — y esa liviandad cambia la estrategia: donde en AWS racionabas cuentas porque crearlas pesaba, en GCP el proyecto por agente o por entorno es el patrón natural. La jerarquía organización → carpetas → proyectos hereda políticas y permisos hacia abajo, y diseñarla ES diseñar la landing zone.

El proyecto: la unidad que lo contiene todo

En GCP, todo recurso vive en un proyecto: el contenedor que agrupa recursos, permisos, APIs habilitadas y la conexión a facturación. Las diferencias operativas contra la cuenta AWS que importan para la plataforma de agentes:

Crear un proyecto es trivial — un comando, segundos, sin proceso de alta. La consecuencia de diseño: la separación que en AWS reservabas para dev/prod/seguridad, en GCP baja de nivel con naturalidad — un proyecto por agente en producción es un patrón razonable, con aislamiento de permisos, cuotas y facturación por agente incluido de fábrica.
Las APIs se habilitan por proyecto. Un proyecto recién creado no puede usar Vertex AI ni Pub/Sub hasta habilitar sus APIs. Molesto la primera vez, valioso después: la lista de APIs habilitadas de un proyecto es una declaración de superficie — el proyecto del clasificador de correos que solo tiene habilitadas Vertex, Pub/Sub y Firestore no puede tocar BigQuery ni por permiso equivocado, porque la API misma está apagada. Es una jaula extra que AWS no tiene.
La facturación se conecta, no se hereda. Los proyectos se enlazan a una billing account — separar quién paga de quién organiza es natural (útil en agencias/holdings, fuente de sustos si nadie es dueño del enlace).

        LA JERARQUÍA DE GCP

  organización (empresa.com)
        │
        ▼
  ┌──────────────────────────────────┐
  │ carpetas: agrupan y HEREDAN      │
  │  prod/        dev/       seg/    │
  └───────┬──────────────────────────┘
          ▼
  proyectos: agente-triaje-prod,
  agente-cotizador-prod, plataforma-dev
  (recursos + APIs + permisos + billing)

La herencia es el mecanismo central: una política o un permiso otorgado en la carpeta prod/ aplica a todos sus proyectos. Las Organization Policies (el equivalente de las SCP) se cuelgan de la jerarquía igual: “en esta carpeta, nada de IPs públicas”, “solo estas regiones” — el techo duro, ahora heredable por carpeta.

Regiones: mismo concepto, otro catálogo

Regiones y zonas funcionan como en AWS (misma lógica de ≥2 zonas para alta disponibilidad, servicios administrados que lo resuelven solos). Los tres criterios de elección del curso de AWS — datos, catálogo, latencia — aplican idénticos. La nota GCP tiene dos caras. La buena, para Chile: Google Cloud tiene región en Santiago (southamerica-west1) con Vertex AI habilitado — una ventaja concreta frente a AWS, cuya región chilena sigue anunciada para fines de 2026. La letra chica: el catálogo de modelos generativos favorece a las regiones grandes de EE.UU. y no todos los modelos llegan a todas las regiones, así que la disyuntiva residencia vs. capacidad (módulo 7) existe igual. Nada nuevo que aprender; solo verificar, modelo por modelo, contra este catálogo antes de prometer “todo en Chile”.

Ojo — la trampa del traductor: la fila más peligrosa de la tabla de equivalencias es la primera, precisamente porque parece la más simple. Equipos que migran de AWS calcan “una cuenta = un proyecto” y terminan con tres mega-proyectos sobrepoblados (desaprovechando la liviandad), o al revés, vienen de GCP a AWS y crean cuentas como si fueran gratis. La unidad se parece; la economía de la unidad — cuánto cuesta crear, mover, administrar una — es distinta, y la estrategia sale de la economía, no del nombre.

La responsabilidad compartida no cambió

El modelo de responsabilidad compartida del curso de AWS aplica palabra por palabra — incluida su última fila: lo que tu agente hace es tuyo en cualquier nube, con cualquier servicio administrado. No se re-argumenta; se recuerda.

Errores comunes

Tratar el proyecto como una cuenta AWS. Ni racionarlo (es liviano: úsalo para aislar por agente/entorno) ni inflarlo (un mega-proyecto con todo dentro tira a la basura el mejor aislamiento barato de GCP).
Ignorar las carpetas. Proyectos sueltos colgando de la organización = políticas repetidas proyecto por proyecto. La herencia por carpeta es la landing zone; se diseña el día uno.
Habilitar APIs “por si acaso”. La lista de APIs habilitadas es superficie de ataque y declaración de arquitectura. Se habilita lo que el proyecto usa; la fricción de habilitar después es el precio de una jaula gratis.
Dejar el enlace de facturación sin dueño. Proyecto sin billing account enlazada = recursos que no levantan; billing account que nadie gobierna = la sorpresa de fin de mes. El enlace es una decisión, no un trámite.
Buscar el “Control Tower de GCP”. No hay equivalente 1:1; la landing zone GCP se arma con la jerarquía + organization policies + blueprints. Menos asistente, misma disciplina.

La frase para llevarse

“En GCP la unidad de aislamiento es liviana a propósito: proyecto por agente, carpetas que heredan políticas, APIs habilitadas como declaración de superficie. Quien cruza desde AWS no necesita aprender arquitectura nueva — necesita recalibrar cuánto cuesta la unidad, porque la estrategia sale de ahí.”

Qué viene

Módulo 2: identidad — service accounts y el agente como principal. La teoría del rol mínimo ya la tienes; en GCP cambian las piezas: las service accounts como identidad de workload (con una relación con los recursos distinta a la de los roles de AWS), los roles predefinidos granulares, y la herencia de permisos por la jerarquía que acabamos de ver — que es bendición y trampa a la vez.

Arquitectura GCP — Módulo 1: el mapa de GCP