Costo y facturación

En Airframe, cada producto tiene un único presupuesto mensual, escrito una vez en su entrada del catálogo, y un cambio que costaría más que ese presupuesto no puede hacer el merge. Esta página es la guía práctica para vivir con esa regla: leer el precio que lleva un merge request, subir el presupuesto cuando el producto lo necesita, poner un producto en la cuenta de facturación o sacarlo, y vigilar lo que de verdad gasta. Las razones están en la página de FinOps.

Dónde vive el presupuesto

Dónde: el repositorio del catálogo, la entrada del producto, products/<journey>.<domain>.<context>.<product>.yaml, campo monthly_budget.

La cifra está en dólares estadounidenses por mes, producción y no producción juntas. El lint del catálogo verifica que los presupuestos de todos los productos y de los espacios de prueba sigan cabiendo en el presupuesto mensual de la organización en catalog.yaml. Todo lo demás lee la entrada: las reglas de costo, los umbrales del panel de costos y los presupuestos de Google Cloud en los proyectos del producto.

1. Lee el costo en un merge request

Cuando un responsable aprueba el merge request de un producto, el ejecutor planifica cada raíz del producto, infra/np, infra/prod e infra/sandbox, calcula el precio de cada plan con Infracost, y publica una nota por raíz. Las líneas de costo de una nota se ven como en la ilustración de abajo, que pone en el formato de hoy las cifras del ensayo registrado de la verificación de costo de la plataforma, una base de datos pequeña contra un presupuesto de 20 dólares:

Cost: USD 27.27 a month, from USD 0 (delta USD 27.27,
no base to compare); budget USD 20. 5 usage-based and
3 unsupported resources are not in the number.

Debajo vienen los recursos cuyo costo mensual cambió, y el veredicto de las reglas de costo:

WARN cuando el cambio agrega más de 10 dólares por mes o más del 25 por ciento. Está pensado para necesitar la aprobación del equipo de plataforma, lo que está diseñado: hoy no detiene nada.
FAIL cuando esa raíz sola supera el presupuesto.
Cost: not estimated cuando no se pudo calcular el precio del plan. El cambio no se admite sin precio.

El merge request también lleva una verificación de estado llamada “Airframe cost”, que la compuerta de aprobación fija cuando terminó el plan de cada raíz. Pasa solo cuando cada raíz tiene precio y su suma está dentro del presupuesto. Falla cuando una raíz es rechazada, un plan falló, una raíz no tiene precio, o la suma supera el presupuesto. Hasta que pase, GitLab mantiene cerrado el merge (aplicado: la opción del proyecto según la cual las verificaciones de estado tienen que pasar). El rechazo de una suma nombra el total, la parte de cada raíz y lo que queda fuera; queda registrado en las ejecuciones de plan e impreso en el registro del trabajo del ejecutor, mientras que cada nota da la cifra de una raíz.

2. Sube el presupuesto

Cuando la verificación falla por el costo, hay dos salidas: hacer el cambio más pequeño, o subir el presupuesto.

Dónde: el repositorio del catálogo. Cambia monthly_budget en la entrada del producto, en un merge request.
Quién aprueba: un líder del dominio del producto, porque la cifra sube, más un responsable de la entrada (el equipo del producto, los líderes del contexto o los del dominio) que no sea el autor. La aprobación de un líder del dominio cubre las dos. Donde los líderes del dominio no tienen cuenta de GitLab, el equipo de plataforma los reemplaza. Después la compuerta de aprobación agrega la suya (aplicado). Hoy esas aprobaciones son de las propias cuentas del mantenedor: el mecanismo está aplicado, pero la separación entre dos personas todavía no es real.
Si el lint dice que los productos ya no caben en el presupuesto de la organización, subir ese presupuesto en catalog.yaml es un cambio aparte, que el equipo de plataforma aprueba dos veces; hoy son dos de las propias cuentas del mantenedor.
Cuando el merge request del catálogo tenga el merge, aprueba otra vez el merge request del producto. La nueva aprobación planifica y calcula el precio de cada raíz contra el presupuesto nuevo, y la verificación se resuelve otra vez.

El ejecutor lee el presupuesto de la entrada del catálogo en main, nunca de la copia que está dentro del repositorio del producto.

3. Pon un producto en facturación

Los dos proyectos de un producto nuevo existen sin facturación, con sus identidades y permisos. Su pipeline planifica de verdad, y su apply se detiene en el primer servicio que necesita facturación.

Dónde: landing-zone, la fábrica de proyectos del dominio, roots/project-factory/<journey>-<domain>/variables.tf. Agrega el nombre del producto a billed_products.
Quién aprueba: el equipo de plataforma, y después la compuerta de aprobación.
El propio pipeline de landing-zone del merge aplica solo la raíz de la fábrica, porque un push a main aplica solo las raíces cuyo directorio cambió. La fábrica habilita los servicios del producto y crea un presupuesto de Google Cloud en cada proyecto a partir de monthly_budget: 70 por ciento para producción y 30 para no producción, con alertas al 80 y al 100 por ciento.
La raíz de red conecta los proyectos a la red compartida en un pipeline posterior de landing-zone. Para un producto nuevo cuya entrada del catálogo tiene el merge después de la facturación, lo ejecuta la cadena de reconciliadores del catálogo, como en el ensayo de la plataforma del 2026-09-20. Si no, ejecuta el pipeline de landing-zone en main a demanda. GitLab deja ejecutar un pipeline en un main protegido solo a quienes pueden hacer merge en él: para landing-zone, los desarrolladores y líderes del equipo de plataforma con cuenta de GitLab, y la cuenta de administración. Hoy son las propias cuentas del mantenedor.
Inicia un pipeline nuevo en el main del producto. Pueden hacerlo las personas autorizadas a hacer merge en el producto. Ese pipeline aplica.

La cuota de proyectos. La cuenta de facturación solo puede vincular una cantidad limitada de proyectos, y cada producto ocupa dos. Al momento de escribir esto la cuota es de catorce, y los proyectos propios de la plataforma usan nueve. Subirla es una solicitud a Google, presentada a mano por la cuenta de administración mediante un formulario de la consola de Google Cloud, y registrada con la respuesta de Google en docs/bootstrap-log.md de landing-zone.

4. Quita un producto de la facturación

El orden importa, porque Google Cloud se niega a desconectar un proyecto mientras algo en él siga usando la red compartida.

Detén primero el entorno de ejecución del producto. La guía del ciclo de vida de los productos de landing-zone da la forma de detener un producto en marcha sin eliminarlo: retirarlo, en un merge request del catálogo que fija su ciclo de vida en retiring con un retire_after lejano. Ese merge request lleva la etiqueta lifecycle y necesita dos aprobaciones: una del equipo y una de un líder del dominio o del equipo de plataforma; hoy las dos vienen de las propias cuentas del mantenedor. El retiro lleva sus servicios a cero y retira sus rutas.
Espera. Cloud Run libera las direcciones de red que reservaron sus servicios hasta dos horas después de que se detienen, y hasta entonces los proyectos no pueden salir de la red compartida.
Dónde: landing-zone. Quita el producto de billed_products, en un merge request que aprueban el equipo de plataforma y la compuerta de aprobación. Su propio pipeline aplica solo la raíz de la fábrica.
Pide a alguien autorizado a ejecutar pipelines en el main de landing-zone (sección 3, paso 4) que ejecute dos ahí a demanda: en el primero, la fábrica libera los proyectos y la raíz de red los desconecta; en el segundo, la fábrica desvincula la facturación y elimina el presupuesto. El programa diario solo planifica y nunca aplica.

Los proyectos, las identidades, los secretos y las claves se quedan; los nombres de host dejan de responder. Los planes del pipeline siguen ejecutándose y cada apply falla en el primer servicio que necesita facturación. Mientras el estado de Terraform del producto siga teniendo recursos que necesitan facturación, sus planes fallan y la verificación de costo rechaza todos sus merge requests.

5. Vigila el gasto

El panel de costos. La carpeta de cada producto en Grafana tiene <product> cost: lo acumulado del mes y la previsión contra monthly_budget, en naranja al 80 por ciento y en rojo al 100. Un trabajo diario, cost:report, lee la exportación de facturación y envía el costo de cada producto como métricas. Sus cifras son lo que factura Google, descontados los créditos. El platform cost de la carpeta de la plataforma muestra la organización contra su presupuesto. Consulta Observabilidad.

Los presupuestos de Google Cloud. Cada proyecto de producto con facturación tiene un presupuesto a partir de monthly_budget. Hoy sus alertas van por correo a los administradores y usuarios de la cuenta de facturación, el comportamiento por defecto de Google; que lleguen al equipo del producto está diseñado. La cuenta de facturación tiene su propio presupuesto de 150 dólares por mes, que avisa al grupo de plataforma al 50, al 80 y al 100 por ciento.

Lo que queda fuera de la cifra del merge request. La vista previa, que es temporal; los recursos de uso variable, como las solicitudes, el tiempo de Cloud Run, las copias de seguridad y los datos de registros; y los recursos a los que Infracost no les pone precio. La nota cuenta los dos últimos. Los costos compartidos de la plataforma, como el borde y los runners, no pertenecen a ningún producto. El panel muestra lo que de verdad se facturó.

Hoy ningún producto de la demo tiene facturación, así que ninguno tiene todavía series de costo ni presupuestos de proyecto.

Dónde está

En el repositorio control-plane:

En el repositorio landing-zone:

En el repositorio operations:

roots/cost/: la exportación de facturación