La cadena del FinOps de AWS — atribuir cada recurso y cada token, ver con preguntas concretas, alertar temprano, frenar en capas — es la disciplina, y viaja completa. GCP la implementa con dos ventajas estructurales que conviene explotar y un hueco que conviene conocer.

Eslabón	En AWS	En GCP
Atribuir recursos	Cost allocation tags (+ activarlos)	Labels + el proyecto mismo
Atribuir tokens por agente	Application inference profiles	Proyecto por agente + labels
Ver y analizar	Cost Explorer	Reportes de Billing + export a BigQuery
Detección de anomalías	Cost Anomaly Detection	Detección de anomalías de Cloud Billing (GA nov. 2025; gratis y activa por defecto)
Alertar y frenar	Budgets + budget actions	Presupuestos → Pub/Sub → tu acción
Freno duro adicional	Rate limits propios	Cuotas de API por proyecto

La tesis del módulo

GCP te regala el primer eslabón si seguiste el módulo 1: con un proyecto por agente, la atribución gruesa viene de fábrica — cada factura ya se parte por proyecto sin etiquetar nada — y la exportación a BigQuery convierte el análisis del gasto en consultas SQL en vez de clics en un explorador. Lo que AWS resolvía con perfiles y tags disciplinados, GCP lo resuelve con estructura más consultas; lo que GCP no trae armado — el freno automático del presupuesto — se ensambla en minutos con la tubería Pub/Sub que ya conoces.

Atribuir: el proyecto trabaja gratis

Dos niveles, del grueso al fino:

El proyecto como unidad de costo. Si cada agente vive en su proyecto (módulo 1), la pregunta “¿cuánto cuesta el agente de triaje?” es una fila del reporte de facturación — sin perfiles de inferencia, sin activar tags, sin ritual. Es la recompensa más concreta de la liviandad del proyecto, y la razón por la que el patrón proyecto-por-agente se paga solo.
Labels para el corte fino. Dentro de un proyecto compartido (o cruzando proyectos por dimensión: entorno, equipo, caso), los labels son los tags de GCP: mismo diccionario corto obligatorio, misma regla de aplicarlos por Terraform, misma inutilidad si cada equipo inventa claves. La disciplina del curso de AWS, sin cambios.

Ver: la factura es una tabla de BigQuery

La pieza diferencial de GCP: la exportación de facturación a BigQuery — cada línea de gasto (servicio, SKU, proyecto, labels, hora) como filas consultables. Las cuatro preguntas de madurez del curso de AWS dejan de ser navegación en un explorador y se vuelven consultas guardadas:

-- ¿Costo por agente este mes, partido por servicio?
SELECT project.id, service.description,
       ROUND(SUM(cost), 2) AS costo
FROM `billing.gcp_billing_export_v1_XXXX`
WHERE invoice.month = '202609'
GROUP BY 1, 2
ORDER BY costo DESC;

Y la quinta pregunta — ¿el costo por tarea real coincide con el proyectado? — encuentra aquí su mejor casa de toda la serie: el gasto (billing export) y el volumen procesado (las métricas operativas exportadas, módulo 6) viven en la misma base, así que el costo por tarea del caso de uso es un JOIN, actualizable a diario, no una planilla trimestral. Activa la exportación el día uno: solo acumula datos desde que existe, y el FinOps sin historia es adivinación.

Frenar: la tubería presupuesto → Pub/Sub → acción

Aquí el contraste honesto con AWS: los presupuestos de GCP alertan (por umbral, a correo y a Pub/Sub) pero no traen el catálogo de budget actions listas de AWS. La respuesta de arquitectura es la tubería que este curso ya domina — el presupuesto publica, una Cloud Run function suscrita ejecuta:

   EL FRENO PROGRAMABLE (GCP)

  presupuesto del proyecto del agente
        │ umbral 50/80/100%
        ▼
  ┌────────────┐     ┌──────────────────┐
  │  Pub/Sub   │ ──► │ Cloud Run func.  │
  │  (topic de │     │ decide la capa:  │
  │  billing)  │     │ avisar · frenar  │
  └────────────┘     └────────┬─────────┘
                              ▼
        quitar rol a la SA del agente /
        bajar cuota de Vertex / avisar al dueño

Las capas del kill switch del curso de AWS se ensamblan así: capa 2 (avisos al 50/80%) la da el presupuesto solo; capa 3 (freno selectivo al 100%) es la función quitando el binding de Vertex a la service account del agente desbocado — el rol-por-agente y el proyecto-por-agente pagando su tercer dividendo: frenar a uno sin tocar al resto. Y la capa 4 (emergencia) sigue siendo runbook humano.

Dos frenos más que GCP trae de fábrica y AWS no regalaba igual:

Cuotas de API por proyecto: Vertex AI (y toda API) tiene cuotas ajustables hacia abajo por proyecto — “este proyecto no puede pasar de X peticiones/minuto” es un dial, no un desarrollo. Es la capa 1 (topes por diseño) con soporte nativo: el agente de triaje con su cuota dimensionada a su volumen legítimo no puede protagonizar el bucle de la factura récord.
Desconexión de facturación: el botón nuclear — desenlazar el proyecto de la billing account detiene sus servicios. Existe, es drástico (para el proyecto entero), y pertenece al runbook de emergencia con letras rojas, no a la automatización alegre.

Cuidado — la misma letra chica de latencia: los datos de facturación de GCP también llegan con horas de rezago; el presupuesto frena la sangría lenta, no la hemorragia del bucle. Los primeros minutos los cubren las cuotas de API (instantáneas) y las alarmas operativas del módulo 11 (invocaciones/minuto). La jerarquía de frenos por velocidad — diseño en segundos, operación en minutos, facturación en horas — es idéntica en todas las nubes porque el rezago de billing lo es.

Errores comunes

Desaprovechar el proyecto como atributo. Agentes amontonados en un proyecto compartido + labels artesanales = reconstruir a mano lo que la estructura regalaba. El proyecto-por-agente es la decisión FinOps más rentable del curso.
No activar el billing export el día uno. Solo registra desde que existe. Actívalo antes de necesitarlo, porque cuando lo necesites querrás la historia.
Presupuestos que solo mandan correos. El correo al 100% es la capa 2 disfrazada de sistema completo. La tubería Pub/Sub → función → freno selectivo se arma en una tarde y es la diferencia entre avisar y gobernar.
Cuotas de API en su valor por defecto. El default es generoso para no estorbar — es decir, generoso para el bucle también. Dimensionar la cuota de Vertex por proyecto al volumen legítimo del agente es un dial gratis de capa 1.
El JOIN que nunca se hace. Gasto en BigQuery, volumen en BigQuery, y el costo por tarea real sin calcular. Es una consulta guardada; el business case del caso de uso la está esperando.
Automatizar la desconexión de billing. El botón nuclear en manos de una función con un bug apaga el proyecto equivocado un viernes. Emergencia = humano + runbook; la automatización llega hasta el freno selectivo.

La frase para llevarse

“En GCP la atribución te la regala la estructura (proyecto por agente), el análisis te lo da SQL (billing export a BigQuery), y el freno lo ensamblas tú: presupuesto que publica, función que decide, cuota que limita de fábrica. Cuatro eslabones, mismas capas — y el mismo reloj: billing tarda horas, así que los primeros minutos son de las cuotas y las alarmas.”

Qué viene

Empieza el bloque avanzado con el módulo 9: los agentes administrados de Google — el Agent Builder con su ADK (el framework open source multi-lenguaje), Agent Engine como runtime administrado, Agent Garden y Studio, y las piezas de gobernanza (Model Armor, Agent Gateway). El mapa contra AgentCore de AWS, y la misma decisión de siempre — pieza por pieza, compra lo peligroso, guarda tu diferencial — ejecutada contra el catálogo de Google.

Arquitectura GCP — Módulo 8: FinOps de la plataforma