Cierre del bloque intermedio, y el módulo que el resto del curso venía anunciando: el cómputo efímero cobra por milisegundo, el NAT por GB, los almacenes por uso, Bedrock por token — todo variable, todo automático, y todo gastado por agentes que trabajan cuando nadie mira. Esa última parte cambia el juego respecto del FinOps clásico: en una app tradicional, el gasto sigue al tráfico humano; en una plataforma de agentes autónomos, el gasto sigue a decisiones de software. Un bug no solo rompe — factura.

La teoría FinOps general está en el catálogo (presupuesto y FinOps para la disciplina; caso-04 para el costo por tarea): no se repite. Este módulo es su implementación AWS: los cuatro mecanismos concretos — etiquetar, atribuir, ver, frenar — y el diseño del freno que hace viable la autonomía.

La tesis del módulo

El FinOps de una plataforma de agentes en AWS se sostiene en una cadena de cuatro eslabones: tags que atribuyen cada recurso, inference profiles que atribuyen cada token, Cost Explorer que los convierte en respuestas, y Budgets con acciones que convierten umbrales en frenos automáticos. La cadena vale lo que su primer eslabón: sin etiquetado disciplinado desde el día uno, los otros tres muestran un número total que no responde ninguna pregunta — y el agente autónomo exige la pregunta respondida por diseño, porque su factura corre mientras duermes.

Eslabón 1: tags — el sistema nervioso de la atribución

Los cost allocation tags (etiquetas de asignación de costos) son pares clave-valor sobre cada recurso (caso=triaje-correos, entorno=prod, equipo=operaciones) que, una vez activados en Billing, parten la factura por cualquier dimensión. Son la diferencia entre “AWS: $8.400 este mes” y “el triaje cuesta $310, el cotizador $95, y ese pico del martes fue el reprocesamiento del lote”.

La arquitectura del etiquetado — porque lo es — tiene tres reglas:

Diccionario corto y obligatorio: 3-5 claves definidas (caso/agente, entorno, equipo), documentadas, idénticas en toda la organización. Veinte claves creativas = ninguna consulta útil.
Aplicado por la infraestructura, no por memoria: los tags viven en el código de infraestructura (Terraform los pone en cada recurso); las tag policies de Organizations (módulo 1) exigen su presencia. Lo etiquetado a mano se des-etiqueta solo.
Activados en Billing: el paso ritual que todos olvidan — un tag no aparece en reportes de costos hasta activarlo como cost allocation tag. Horas de “¿por qué no veo nada?” se evitan con esta línea.

Eslabón 2: inference profiles — atribuir el token

Los tags cubren recursos; falta el gasto más difícil de partir: los tokens de Bedrock, que por defecto llegan como una línea global del servicio. La pieza AWS para esto son los application inference profiles: envoltorios del modelo que creas por aplicación/equipo/agente, cada uno con sus cost allocation tags. El agente clasificador invoca su perfil, el cotizador el suyo — mismo modelo, mismo precio por token (el perfil es contabilidad, no un servicio con recargo) — y Cost Explorer parte el gasto de inferencia por agente igual que el resto.

Esto conecta la plataforma con la metodología: el costo por tarea que el caso de uso proyectó por fin se contrasta contra la realidad, caso por caso — el showback del componente 2 de la landing zone, implementado. Y si pusiste gateway propio (módulo 7), sus keys virtuales por equipo suman la misma atribución del lado del proxy.

Ojo: la atribución fina tiene bordes — hay rutas de invocación (según cómo se invoque, p. ej. vía capas de agentes administrados) donde los tags del perfil no fluyen completos a Cost Explorer. La regla de arquitectura: decide la unidad de atribución (agente/caso), créale su perfil, y verifica en la factura del primer mes que la atribución llega — antes de prometerle el showback al negocio.

Eslabón 3: ver — Cost Explorer y las preguntas que debe responder

Cost Explorer es la lupa: filtra y agrupa el gasto por servicio, tag, perfil y tiempo. La prueba de madurez de la plataforma no es “usamos Cost Explorer” sino poder responder, en cinco minutos y sin arqueología, estas cuatro preguntas:

Pregunta	Dimensión que la responde
¿Cuánto cuesta cada agente/caso al mes?	Tag `caso` + perfil de inferencia
¿En qué se va el dinero de cada uno?	Tag `caso` × servicio (tokens vs. cómputo vs. NAT…)
¿El costo por tarea real coincide con el proyectado?	Gasto del caso ÷ volumen procesado (tu métrica)
¿Qué cambió esta semana y por qué?	Series de tiempo + anomalías

Para la cuarta existe además Cost Anomaly Detection — el detector administrado que aprende el patrón de gasto y alerta desviaciones. Actívalo: es gratis, y para gasto dirigido por software (que cambia por deploy, no por estacionalidad humana), la anomalía es la señal de bug.

Eslabón 4: frenar — Budgets, acciones y el kill switch

Aquí el módulo se gana el sueldo. AWS Budgets define umbrales de gasto (por total, por tag, por servicio) con alertas — y, la parte que importa, budget actions: respuestas automáticas al cruce del umbral, como aplicar una política IAM restrictiva o detener recursos. Esa capacidad convierte el presupuesto de informe en freno, y habilita el diseño central del FinOps agéntico — el kill switch en capas:

     EL FRENO EN CAPAS DE UN AGENTE AUTÓNOMO

  capa 1 · por diseño (siempre activa)
    rate limits (API GW) · tope de escalada (mód. 7)
    reintentos con tope (mód. 5) · tope de pasos/turnos
                    │ si algo se escapa
                    ▼
  capa 2 · alerta temprana (50% / 80% del budget)
    aviso al dueño · revisión, sin frenar nada
                    │ si sigue subiendo
                    ▼
  capa 3 · freno selectivo (100% del budget del caso)
    budget action: deny de InvokeModel al rol
    del agente que se pasó — los demás siguen
                    │ si el gasto es anómalo global
                    ▼
  capa 4 · freno de emergencia (manual, documentado)
    apagar el consumo de colas / el gateway
    runbook: quién, cómo, qué se degrada

Tres decisiones de diseño dentro del esquema. Primera: el freno selectivo actúa por rol — gracias al módulo 2 (un rol por agente), negar bedrock:InvokeModel al rol del agente desbocado detiene a ese agente sin tocar al resto; el rol-por-agente paga aquí su segundo dividendo. Segunda: frenar ≠ perder trabajo — como el trabajo vive en colas (módulo 5), el agente frenado deja mensajes esperando, no correos perdidos; al levantar el freno, la cola se drena. La arquitectura asíncrona convierte el kill switch de catástrofe en pausa. Tercera: la capa 1 es la más importante — las otras tres son redes de seguridad para cuando el diseño falla; el diseño (topes en todo lo que itera) es el freno que actúa en segundos y no en horas de acumulación de factura.

Cuidado — Budgets no es tiempo real: los datos de facturación llegan con horas de retraso; un budget action al 100% puede dispararse cuando el sobregiro ya creció. Por eso el bucle rápido se ataja en la capa 1 (topes de diseño, que actúan al instante) y con métricas operativas (invocaciones/minuto en CloudWatch, módulo 11), no con la factura. Budgets frena la sangría lenta; los topes de diseño, la hemorragia.

Errores comunes

Etiquetar “después”. El recurso sin tag de hoy es la línea inexplicable de la factura del trimestre. Tags en el Terraform desde el recurso uno, con tag policies que los exijan.
Un solo perfil de inferencia para toda la empresa. Todo el gasto de tokens en una línea = el showback imposible y el caso de negocio incontrastable. Perfil por agente/caso, verificado en la primera factura.
Alertas al 100% y nada más. Enterarse cuando ya se gastó no es gobernar. 50/80/100 con dueño nombrado en cada una, y anomaly detection para lo que ningún umbral predijo.
Kill switch global como única arma. Si la sola respuesta al sobregasto es apagar la plataforma, nadie la usará hasta que sea tarde. El freno selectivo por rol existe para que frenar a uno no cueste todos.
Confiar en Budgets para el bucle rápido. Horas de retraso de facturación vs. un bucle que quema por minuto: pierde Budgets. Topes de diseño y alarmas operativas cubren los primeros minutos; Budgets, el resto.
Tratar el gasto como métrica mensual. En una plataforma de agentes, el gasto es una métrica operativa — vive en el dashboard del módulo 11 junto a latencia y errores, con la misma cadencia de revisión. La factura mensual es el postmortem, no el monitoreo.

La frase para llevarse

“Etiqueta todo, dale a cada agente su perfil de inferencia, exige a Cost Explorer las cuatro respuestas — y diseña el freno en capas: topes por diseño en segundos, alertas tempranas en horas, deny selectivo por rol al cruzar el límite. Un agente autónomo sin kill switch no es autónomo: es un cheque en blanco con acceso a APIs.”

Qué viene

Empieza el bloque avanzado con el módulo 9: los servicios de agentes administrados — Bedrock AgentCore. Hasta aquí construimos la plataforma pieza por pieza; AWS ofrece también el atajo: runtime administrado para el loop del agente, memoria administrada, gateway de herramientas, identidad para agentes y knowledge bases para el RAG. La pregunta de arquitectura que responderemos con tabla: qué te da cada pieza administrada, qué no te da, y cuándo el atajo vale el acoplamiento — la decisión build-vs-managed aplicada al corazón agéntico.

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