Módulo 6: Finops For Tokens

1. Introducción al módulo: el cost gate ya existe, los tokens son lo nuevo

Descripción

finops-and-cost-guardrails-guide ya dejó, terminado y verificado, un cost gate completo para Andes Cargo: cost-policy/ (hermano de policy/, cero archivos compartidos), Infracost 2.16.1 ya instalado con su límite de autenticación ya documentado, COST-PROFILE.md con los supuestos de volumen de los tres recursos facturables originales (S3, Lambda, DynamoDB), y tres jobs de CI —cost-estimate, cost-check, cost-tags— que ya corrieron, de verdad, contra el proyecto completo. Este módulo no reinstala nada de eso. Lo extiende con la única pieza que ese gate, tal como está, no puede resolver solo: el presupuesto de una carga usage-based de tokens, donde ni siquiera existe un recurso de Terraform que represente "una invocación" para que Infracost lo lea.

Conexión con el módulo

El Módulo 2 de esta misma guía ya construyó dos piezas que este módulo reusa sin reescribir: scripts/bedrock_cost_estimate.py (la calculadora determinista de costo por token, con su suite de pytest) y GENAI-COST-PROFILE.md (el documento que declaró el modelo elegido, el precio citado, y dos escenarios de volumen —realista y de estrés— para extract-shipment-manifest-fields). El Módulo 5 ya extendió el security gate heredado con bedrock-least-privilege.rego, agregado a policy/, sin ningún job nuevo. Este módulo hace, en el dominio de costo, exactamente lo que el Módulo 5 ya hizo en el de seguridad: agrega una política nueva a un directorio que ya existe (cost-policy/), y una pieza de ejecución nueva (el presupuesto de tokens) a un job que ya existe (cost-check) — nunca un carril nuevo, nunca una herramienta nueva.

Analogía: el presupuesto de tokens es el tope de datos móviles, pero sin un "plan" que lo represente

Ya conoces el tope de datos de un plan de celular: contratas "10 GB al mes", el operador sabe exactamente cuánto has consumido en cualquier momento, y te avisa —o te corta— antes de que factures de más. Ese tope existe porque hay un plan: un contrato explícito, con un número fijo, que el sistema entero puede consultar en cualquier momento. El presupuesto de tokens que este módulo construye se parece a ese tope en el propósito —avisar, o cortar, antes de que la factura sorprenda a alguien—, pero se parece a la telefonía prepaga de hace veinte años en la mecánica: no hay ningún "plan" declarado en ningún sistema de AWS que diga, de antemano, "Andes Cargo va a consumir X tokens este mes". Nadie lo sabe hasta que alguien lo declara explícitamente, a mano, en un documento — exactamente el vacío que GENAI-COST-PROFILE.md (Módulo 2) ya llenó con un supuesto declarado, y que este módulo convierte, por primera vez, en un número que un pipeline puede hacer cumplir automáticamente, no solo leer.

   TOPE DE DATOS MÓVILES                    PRESUPUESTO DE TOKENS DE BEDROCK

   El operador SABE tu consumo en           NINGÚN sistema de AWS sabe, de
   tiempo real -- hay un contador           antemano, cuántos tokens vas a
   nativo del servicio                      consumir -- no hay contador nativo
        │                                   que un pipeline pueda leer antes
        ▼                                   de que la factura ya exista
   El "plan" (10 GB) es un dato                   │
   que el sistema ya conoce                       ▼
        │                                   El "plan" (el presupuesto) es un
        ▼                                   NÚMERO QUE UN HUMANO DECLARA A MANO
   Corta o avisa automáticamente            (GENAI-COST-PROFILE.md, Módulo 2)
   antes de facturar de más                       │
                                                   ▼
                                             Este módulo construye el mecanismo
                                             que hace cumplir ESE número declarado
                                             -- antes del `apply`, no después

Qué hereda este módulo, sin reinstalar nada

Pieza	Origen	Qué hace este módulo con ella
`cost-policy/` (directorio, hermano de `policy/`)	`finops-and-cost-guardrails-guide`, Módulo 4	Agrega `bedrock-budget.rego` (lección 3) — un archivo nuevo, cero archivos existentes tocados
`required-cost-tags.rego`	`finops-and-cost-guardrails-guide`, Módulo 4, lección 4	Queda exactamente igual — sigue evaluando `aws_s3_bucket`/`aws_lambda_function`/`aws_dynamodb_table`, nunca `aws_bedrock_guardrail`
Infracost `2.16.1`, instalado y con su límite de autenticación documentado	`finops-and-cost-guardrails-guide`, Módulo 2	No se vuelve a instalar. Este módulo confirma, otra vez, por qué Infracost no puede resolver el presupuesto de tokens por sí solo — la lección 2 lo explica con precisión técnica nueva
`COST-PROFILE.md` (los tres recursos facturables originales)	`finops-and-cost-guardrails-guide`, Módulo 1	Sigue intacto. `GENAI-COST-PROFILE.md` (abajo) lo complementa, nunca lo reemplaza
`scripts/bedrock_cost_estimate.py` + `pytest`	Este mismo curso, Módulo 2, lección 7	Gana un argumento nuevo, `--monthly-budget` (lección 4) — el mismo archivo, extendido, nunca reescrito
`GENAI-COST-PROFILE.md`	Este mismo curso, Módulo 2, lección 8	Su escenario de estrés (5.000 invocaciones/mes) es el volumen que el pipeline verifica contra el presupuesto (lecciones 4 y 6)
Jobs `cost-estimate`/`cost-check`/`cost-tags` en `ci.yml`	`finops-and-cost-guardrails-guide`, Módulos 3 y 4	`cost-tags` evalúa `bedrock-budget.rego` automáticamente, sin ningún cambio de YAML (mismo mecanismo que `policy-check` con `bedrock-least-privilege.rego` en el Módulo 5). `cost-check` gana *un step* nuevo** (lección 4) — nunca un job nuevo
El security gate completo (`policy-check`/`iac-scan`/`verify-artifact`)	Módulo 5 de esta guía	Sigue corriendo en paralelo, sin ningún `needs:` cruzado hacia el carril de costo — la lección 8 lo confirma con `act` real

Fíjate en el patrón que se repite en cada fila: este módulo nunca crea un directorio nuevo, nunca instala una herramienta nueva, nunca abre un job nuevo de CI. Cada pieza nueva entra en un lugar que ya existe, siguiendo exactamente la misma disciplina de "extender, no reconstruir" que el Módulo 5 ya demostró con el security gate.

Mapa de las ocho lecciones

  M6.1  Introducción (esta lección) -- qué hereda, qué falta
  M6.2  Por qué un token es el recurso usage-based más extremo -- ni
        siquiera hay un recurso de Terraform para "una invocación"
  M6.3  Manos a la obra: bedrock-budget.rego, agregada a cost-policy/
        -- EJECUTADO, FAIL real contra el estado actual
  M6.4  Manos a la obra: la calculadora de costo por token, integrada
        al gate -- EJECUTADO, --monthly-budget nuevo, pytest real
  M6.5  Tagging de asignación de costo para la carga de IA -- EJECUTADO,
        el FAIL de la lección 3 se convierte en PASS real
  M6.6  Manos a la obra: un cambio de volumen que dispara el presupuesto
        -- EJECUTADO, el step de la lección 4 falla de verdad
  M6.7  On-demand vs. Provisioned Throughput -- números reales,
        verificados en este mismo momento contra AWS
  M6.8  Proyecto: el cost gate de Andes Cargo, extendido a tokens
        -- EJECUTADO, act pull_request en paralelo al security gate

Las lecciones 3 a 6 son manos a la obra puras, cada una construyendo sobre la anterior: la política (3), la calculadora integrada como step (4), el HCL tagueado de verdad que cierra el FAIL de la lección 3 (5), y la prueba, en ambas direcciones, de que el presupuesto corta antes del apply (6). La lección 7 es la única puramente conceptual del módulo — pero con números reales, no una regla de bolsillo. La lección 8, el proyecto, reúne todo con act real.

Por qué esto importa: el gate de costo, hasta ahora, nunca vio un recurso usage-based de verdad

Vale la pena decirlo con precisión, porque es la tensión central que abre este módulo: los tres recursos facturables que finops-and-cost-guardrails-guide protegió (S3, Lambda, DynamoDB) tienen algo en común que Bedrock no tiene — cada uno de ellos, en algún punto de su configuración de Terraform, declara un atributo que se acerca a "cuánto vas a usar esto" (billing_mode = "PAY_PER_REQUEST" en DynamoDB, por ejemplo, es al menos un modo declarado en el HCL, aunque el volumen en sí siga viviendo en infracost-usage.yml). Bedrock, facturado on-demand, no tiene ningún atributo equivalente en bedrock.tf — ni siquiera un modo. La lección 2 desarrolla esta diferencia con precisión técnica completa; por ahora, basta con entender que este módulo existe exactamente para esa diferencia: el gate que ya funciona para "cuánta capacidad reservaste" no puede, por diseño, funcionar igual para "cuántas veces vas a llamar a un modelo" — y este módulo construye el mecanismo que sí puede.

Errores comunes

Asumir que este módulo necesita su propio Infracost, su propia versión, o su propia sesión (de expectativa de reinstalación). Qué pasa: alguien, viendo que este módulo trabaja con costo, busca instrucciones para instalar Infracost de nuevo, o para autenticar una sesión distinta. Cómo detectarlo: si buscas un comando de instalación en este módulo antes de la lección 4. Cómo corregirlo: no existe tal comando — Infracost 2.16.1 ya está instalado desde finops-and-cost-guardrails-guide Módulo 2, y el límite de autenticación (infracost auth login, PKCE por navegador, sin completar en este entorno) ya está documentado ahí. Este módulo no repite esa instalación en ningún lugar.

Confundir GENAI-COST-PROFILE.md con COST-PROFILE.md, o pensar que uno reemplaza al otro. Qué pasa: alguien, al necesitar un supuesto de volumen, no sabe en cuál de los dos documentos buscarlo. Cómo detectarlo: si tu PR modifica COST-PROFILE.md para agregar un supuesto sobre tokens, o GENAI-COST-PROFILE.md para agregar un supuesto sobre S3. Cómo corregirlo: COST-PROFILE.md (finops-and-cost-guardrails-guide, Módulo 1) cubre los tres recursos facturables "clásicos" de Andes Cargo. GENAI-COST-PROFILE.md (este curso, Módulo 2, lección 8) cubre, exclusivamente, el costo por token de extract-shipment-manifest-fields. Son complementarios, nunca superpuestos — la misma relación exacta que el Módulo 2, lección 8 de esta guía ya estableció en su Paso 1.

Esperar que cost-tags necesite un cambio de YAML para evaluar bedrock-budget.rego (de no entender -p cost-policy/). Qué pasa: alguien, al escribir la política de la lección 3, busca dónde en ci.yml hay que "registrar" el archivo nuevo. Cómo detectarlo: si editas .github/workflows/ci.yml antes de la lección 4. Cómo corregirlo: conftest test tfplan.json -p cost-policy/ (el comando que cost-tags ya corre, sin cambios, desde finops-and-cost-guardrails-guide Módulo 4) apunta al directorio completo — cualquier archivo .rego nuevo dentro de cost-policy/ se evalúa automáticamente, la próxima vez que el job corra, sin tocar una sola línea de YAML. Exactamente el mismo mecanismo que policy-check ya demostró con bedrock-least-privilege.rego en el Módulo 5.

Ejercicios

Ejercicio 1 — Enumera, de memoria, las tres piezas que este módulo hereda de finops-and-cost-guardrails-guide sin reinstalar, y las dos que hereda del Módulo 2 de esta misma guía. No mires la tabla de esta lección hasta haber intentado la lista completa.

Ver solución

De finops-and-cost-guardrails-guide: cost-policy/ (con required-cost-tags.rego ya dentro), Infracost 2.16.1 ya instalado (con su límite de autenticación ya documentado), y los jobs cost-estimate/cost-check/cost-tags en ci.yml. Del Módulo 2 de esta misma guía: scripts/bedrock_cost_estimate.py (con su suite de pytest) y GENAI-COST-PROFILE.md. Si tu lista tiene las cinco piezas, sin inventar ninguna sexta, tienes clara la base exacta sobre la que se construye todo este módulo.

Ejercicio 2 — Explica por qué required-cost-tags.rego (heredado, sin cambios) nunca evalúa aws_bedrock_guardrail, y qué política sí lo hace. Basándote en lo que ya sabes de finops-and-cost-guardrails-guide Módulo 4, ¿por qué el conjunto billable_resource_types de esa política nunca incluyó el tipo de recurso de un guardrail de Bedrock?

Ver solución

Porque required-cost-tags.rego se escribió en finops-and-cost-guardrails-guide, antes de que esta guía existiera — en ese momento, Andes Cargo no tenía ninguna carga de IA generativa, así que su conjunto billable_resource_types (aws_s3_bucket, aws_lambda_function, aws_dynamodb_table) reflejaba, con precisión, los únicos tres tipos de recurso facturables que existían entonces. aws_bedrock_guardrail es un tipo de recurso que ese archivo nunca tuvo motivo de conocer. La política que sí lo evalúa es la que este módulo escribe en la lección 3 — bedrock-budget.rego, un archivo nuevo, nunca una modificación al archivo heredado.

Ejercicio 3 — Predice qué pasaría si, por error, alguien escribiera bedrock-budget.rego dentro de policy/ en vez de cost-policy/. Usando lo que ya sabes de la arquitectura de directorios hermanos (finops-and-cost-guardrails-guide Módulo 4, lección 1; Módulo 5 de esta guía, lección 3), ¿qué job de CI empezaría a evaluar esa política sin que nadie se lo pidiera?

Ver solución

policy-check — el job que corre conftest test tfplan.json -p policy/, evaluando recursivamente todo archivo .rego dentro de ese directorio, incluida cualquier política de costo puesta ahí por error. cost-tags, en cambio, nunca la vería, porque apunta exclusivamente a -p cost-policy/. El resultado sería una política de asignación de costo evaluándose dentro del security gate — una mezcla de dominios exactamente igual a la que la arquitectura de directorios hermanos existe para prevenir, la misma lección que finops-and-cost-guardrails-guide Módulo 4, lección 1 ya adelantó con su propio diagrama de "opción descartada".

Resumen y siguiente paso

Esta lección mapeó las ocho lecciones del módulo y confirmó, tabla por tabla, exactamente qué hereda sin reinstalar: cost-policy/ y los tres jobs de finops-and-cost-guardrails-guide, más bedrock_cost_estimate.py y GENAI-COST-PROFILE.md de esta misma guía. Ninguna herramienta nueva, ningún job nuevo, ningún directorio nuevo — solo dos archivos nuevos (bedrock-budget.rego, un --monthly-budget agregado al script existente) en lugares que ya existen.

Antes de avanzar deberías poder: nombrar las cinco piezas heredadas sin ayuda; explicar por qué required-cost-tags.rego nunca necesita cambiar para que este módulo funcione; y predecir en qué job de CI aparecería una política mal ubicada.

La lección 2 se aleja del código por un momento para desarrollar, con precisión técnica completa, por qué un token es el recurso más extremo del ecosistema en términos de usage-based billing — un paso más allá de lo que PAY_PER_REQUEST de DynamoDB ya mostró.

Recursos

finops-and-cost-guardrails-guide, Módulo 4, lección 1 — el origen de la arquitectura cost-policy/ hermano de policy/, que este módulo extiende.
finops-and-cost-guardrails-guide, Módulos 2 y 3 — el origen de Infracost 2.16.1 y de los jobs cost-estimate/cost-check.
Este curso, Módulo 2, lecciones 7 y 8 — el origen de bedrock_cost_estimate.py y GENAI-COST-PROFILE.md.
Este curso, Módulo 5, lección 3 — el precedente exacto de "un archivo nuevo en un directorio heredado, sin ningún job nuevo", aplicado ahí a seguridad.

← Anterior8. Proyecto: el security gate de Andes Cargo, extendido Siguiente →2. Por qué un token es el recurso *usage-based* más extremo del ecosistema