Cómo gestionar y optimizar los costos de Amazon Bedrock: guía FinOps en cinco etapas
Introducción: un modelo para controlar los costos de Amazon Bedrock
Gestionar los costos de los modelos de inteligencia artificial requiere conocer quién consume los recursos, cuánto cuesta cada solicitud y qué mecanismos permiten mantener el gasto dentro de los presupuestos establecidos.
El 30 de octubre de 2026, AWS publicó en su blog de Machine Learning una guía dirigida a equipos de FinOps y responsables de plataformas que utilizan Amazon Bedrock.
La propuesta organiza la gestión económica de los modelos en cinco etapas conectadas entre sí:
- Atribuir cada dólar: identificar usuarios, equipos y aplicaciones responsables del consumo.
- Observar cada solicitud: analizar tokens, modelos y patrones de utilización.
- Aplicar presupuestos: establecer alertas y controles para limitar el gasto.
- Optimizar los valores predeterminados: aprovechar modelos más económicos, caché de prompts y gestión del contexto.
- Operar el ciclo continuamente: revisar indicadores, investigar anomalías y distribuir los costos.
AWS plantea estas etapas como un proceso recurrente: la información obtenida mediante la observación sirve para ajustar los controles, optimizar el consumo y mejorar la atribución de los gastos.
Paso 1. Atribuir los costos a usuarios, equipos y aplicaciones
El primer objetivo consiste en identificar qué identidades y aplicaciones generan los cargos de inferencia de Amazon Bedrock.
AWS explica que Bedrock atribuye esos costos al principal de AWS Identity and Access Management (IAM) responsable de la llamada.
En el informe AWS Cost and Usage Report (CUR 2.0), el ARN de esa identidad aparece en el campo line_item_iam_principal.
Este dato permite relacionar los costos con las identidades que realizan solicitudes.
Configuración de la atribución de costos en cuatro pasos
- Activar los datos del principal IAM en CUR 2.0. Configurar la exportación para incluir la información de identidad asociada a las solicitudes de inferencia.
- Etiquetar los principales IAM. Asociar etiquetas que identifiquen el equipo, la aplicación y el centro de costos correspondiente.
- Activar las etiquetas de asignación de costos en AWS Billing. Habilitar las etiquetas necesarias para utilizarlas en el análisis económico.
- Consultar las etiquetas en Cost Explorer. Analizar los datos identificados con el prefijo iamPrincipal/, cuya aparición puede tardar entre 24 y 48 horas.
Cómo resolver la pérdida de visibilidad con roles IAM compartidos
Una dificultad aparece cuando diferentes usuarios acceden a Bedrock a través de una pasarela que utiliza un único rol IAM.
En ese escenario, las solicitudes quedan asociadas a la misma identidad, lo que reduce la granularidad de la atribución.
El procedimiento presentado por AWS utiliza gestión de sesiones por usuario.
La pasarela asume el rol de invocación una vez por usuario y emplea nombres y etiquetas de sesión para distinguir las identidades. Las sesiones pueden mantenerse en caché durante un máximo de una hora.
De esta manera, la atribución puede conservar información diferenciada por usuario incluso cuando las solicitudes pasan por una infraestructura compartida.
Atribución por aplicación, modelo y Región
AWS también distingue mecanismos según las API utilizadas:
- API de bedrock-runtime: perfiles de inferencia de aplicación para separar el consumo por aplicación, modelo y Región.
- API bedrock-mantle de Responses y Chat Completions: proyectos y espacios de trabajo como unidades de organización.
Estas opciones complementan la atribución basada en identidades IAM.
Paso 2. Observar cada solicitud y analizar el consumo de tokens
Una vez identificados los responsables del gasto, la siguiente etapa consiste en observar el comportamiento de las solicitudes.
AWS propone habilitar el registro de invocaciones de modelos mediante Amazon CloudWatch Logs, Amazon S3 o ambos servicios.
Cada alternativa cumple una función diferente.
| Herramienta | Función dentro de la observabilidad |
|---|---|
| CloudWatch Logs | Consultas rápidas y diagnóstico del consumo |
| Amazon S3 y Athena | Análisis mediante consultas y herramientas de inteligencia empresarial |
| CUR 2.0 | Información de costos y atribución económica |
| CloudWatch y OpenTelemetry | Observabilidad casi en tiempo real |
Diferencia entre observar el consumo y analizar la facturación
Según AWS, los datos del informe CUR presentan un retraso aproximado de 24 horas.
CloudWatch combinado con OpenTelemetry permite observar el comportamiento del consumo casi en tiempo real.
Esta diferencia resulta relevante para separar el análisis económico consolidado del seguimiento operativo de las solicitudes.
Incorporar metadatos a las llamadas
El enfoque de AWS también contempla incluir metadatos que permitan identificar el contexto de cada solicitud.
Los campos propuestos son:
- Aplicación: identifica el servicio que genera la solicitud.
- Flujo de trabajo: distingue el proceso al que pertenece.
- Inquilino: permite separar solicitudes de diferentes consumidores.
- Agente: identifica el agente relacionado con la invocación.
Diagnosticar el consumo con CloudWatch Logs Insights
AWS describe dos agrupaciones de consultas especialmente útiles:
- Tokens por llamador y modelo: permite analizar qué identidades utilizan determinados modelos y cuánto consumen.
- Tokens por aplicación y flujo de trabajo: permite observar cómo se distribuye el consumo entre las diferentes actividades.
Esta información complementa los datos económicos utilizados en la atribución de costos.
Paso 3. Aplicar presupuestos mediante tres niveles de control
La tercera etapa consiste en establecer mecanismos que respondan al consumo económico.
AWS diferencia tres niveles, desde la supervisión mediante alertas hasta la aplicación síncrona de límites.
Nivel 1. Supervisión y alertas con AWS Budgets
El primer nivel utiliza AWS Budgets para monitorizar el consumo y generar alertas.
Este mecanismo permite observar la evolución del gasto sin bloquear las solicitudes.
AWS propone comenzar por este nivel para conocer el comportamiento de los usuarios y aplicaciones antes de introducir restricciones.
Nivel 2. Aplicación de límites mediante IAM, Lambda y DynamoDB
El segundo nivel introduce un mecanismo de aplicación de presupuestos basado en identidades y etiquetas IAM.
El proceso descrito utiliza los siguientes componentes:
- Un agregador AWS Lambda suma los contadores de consumo.
- Amazon DynamoDB almacena los contadores utilizados por el mecanismo.
- Una política IAM de denegación compartida incorpora la identidad cuando corresponde restringir su consumo.
- La denegación bedrock:* se mantiene hasta el restablecimiento mensual o una anulación realizada por el administrador.
AWS señala que este control es asíncrono y que su aplicación puede presentar un retraso de segundos a minutos.
Por tanto, se trata de un mecanismo de aplicación posterior al procesamiento del consumo, en lugar de una decisión síncrona para cada solicitud.
Nivel 3. Control síncrono desde una pasarela
El tercer nivel introduce la aplicación del presupuesto directamente en una pasarela.
Cuando corresponde rechazar una solicitud, el mecanismo puede responder con el código HTTP 429.
AWS menciona dos ejemplos de este enfoque:
- Pasarela de aplicaciones Claude: para flotas de Claude Code y Claude Desktop.
- LiteLLM: para entornos que utilizan diferentes modelos.
La elección entre los mecanismos depende de la conectividad disponible y de la velocidad con la que se consume el presupuesto.
Comparación de los tres niveles
| Nivel | Mecanismo | Comportamiento |
|---|---|---|
| 1 | AWS Budgets | Monitorización y alertas, sin bloqueo |
| 2 | IAM, Lambda y DynamoDB | Denegación asíncrona, con retraso de segundos a minutos |
| 3 | Pasarela de inferencia | Aplicación síncrona con respuesta HTTP 429 |
El recorrido propuesto por AWS comienza con la observación en el Nivel 1 y avanza hacia mecanismos más estrictos conforme lo requiera el comportamiento del gasto.
Paso 4. Optimizar los modelos, la caché de prompts y el contexto
La cuarta etapa busca reducir el costo de las solicitudes mediante decisiones de configuración y diseño de las aplicaciones.
AWS identifica tres áreas principales: selección de modelos, reutilización de prompts y reducción del contexto procesado.
Enrutamiento inteligente hacia modelos más económicos
El enrutamiento inteligente de prompts consiste en dirigir las tareas rutinarias hacia modelos más pequeños y económicos.
En flotas de programación agéntica, AWS plantea como objetivo que más de la mitad de las llamadas utilicen modelos de menor costo.
El enfoque busca adecuar el modelo seleccionado al tipo de trabajo realizado.
Caché de prompts: costos de escritura y lectura
La guía de AWS también analiza el almacenamiento en caché de prompts como mecanismo para aprovechar contenido reutilizado entre solicitudes.
Los datos publicados corresponden a octubre de 2026 y a modelos Claude en la Región US East (N. Virginia).
Las tarifas relativas de escritura dependen del tiempo de vida de la caché, mientras que las de lectura varían según el modelo.
| Operación de caché | Costo relativo frente a la entrada base |
|---|---|
| Escritura con TTL de 5 minutos | 1,25× |
| Escritura con TTL de 1 hora | 2× |
| Lectura en Claude Sonnet 4.6 | 0,1× |
| Lectura en Claude Haiku 4.5 | 0,1× |
| Lectura en Claude Sonnet 5.5 | 0,05× |
| Lectura en Claude Opus 5.5 | 0,05× |
TTL es el tiempo de vida de la entrada almacenada en caché.
Cuándo compensa el almacenamiento en caché
AWS explica que, con una escritura de caché de cinco minutos, una reutilización del contenido permite compensar el sobrecosto de la escritura inicial.
La guía también presenta un ejemplo de diez llamadas que comparten un prefijo estable.
| Escenario | Costo aproximado relativo |
|---|---|
| Diez llamadas con tasa de lectura en caché de 0,1× | 22 % |
| Diez llamadas con tasa de lectura en caché de 0,05× | 17 % |
Estas cifras corresponden al ejemplo económico de reutilización de un prefijo estable presentado por AWS.
El caso desfavorable se produce cuando se realizan escrituras en caché cuyo contenido nunca vuelve a leerse. En ese escenario, se paga la escritura sin obtener el beneficio de posteriores lecturas más económicas.
Reducir el consumo de contexto desde la aplicación
Además de la selección de modelos y la caché, AWS identifica tres técnicas de optimización a nivel de aplicación:
- Recuperación justo a tiempo: incorporar información cuando resulta necesaria.
- Compactación: reducir el contexto utilizado durante el procesamiento.
- Destilación: destilar flujos estables de alto volumen a modelos más pequeños.
Estas técnicas forman parte de los mecanismos que AWS incluye en la etapa de optimización de los valores predeterminados.
Paso 5. Operar un ciclo continuo de FinOps
El último paso consiste en transformar los datos de atribución, observabilidad y optimización en un proceso periódico de gestión económica.
AWS distingue cuatro señales operativas que deben aparecer en un panel de salud:
- Mezcla de modelos: distribución de las solicitudes entre los diferentes modelos.
- Tasa de solicitudes fallidas: proporción de invocaciones que terminan en error.
- Eficacia de la caché: aprovechamiento de los contenidos almacenados.
- Cobertura de metadatos: alcance de la información utilizada para identificar solicitudes.
Estas señales permiten seguir el comportamiento de la plataforma y relacionarlo con el consumo económico.
Cuadro de mando: indicadores y umbrales de referencia
AWS propone un cuadro de mando con indicadores económicos y operativos, organizados en tres estados: verde, amarillo y rojo.
| Indicador | Verde | Amarillo | Rojo |
|---|---|---|---|
| Costo por resultado exitoso | ≤ presupuesto | Más del presupuesto y hasta 1,5× | >1,5× del presupuesto |
| Gasto diario por desarrollador | Menos de US$100 | US$100–US$300 | Más de US$300 |
| Porcentaje de llamadas a modelos eficientes en costo | >50 % | 30–50 % | <30 % |
| Ratio de aciertos de lectura en caché | >60 % | 30–60 % | <30 % |
Estos umbrales son puntos de partida propuestos por AWS, no prescripciones universales. Su función es proporcionar referencias iniciales para evaluar el gasto y el comportamiento de la plataforma.
El costo por resultado exitoso relaciona el gasto con el presupuesto asignado a los resultados obtenidos, mientras que el gasto diario por desarrollador ofrece una perspectiva individual del consumo.
Los otros dos indicadores muestran qué proporción de solicitudes utiliza modelos eficientes en costo y qué porcentaje de lecturas aprovecha la caché.
Investigar anomalías y distribuir los costos
AWS describe un ciclo de gestión económica basado en la investigación de anomalías mediante clasificación y en la refacturación de los consumos a partir de agrupaciones de CUR.
Este enfoque conecta la información financiera con las identidades, equipos y aplicaciones identificados en las primeras etapas.
La atribución de costos facilita identificar a los responsables del gasto, mientras que el seguimiento de solicitudes aporta contexto sobre los patrones de utilización.
Frecuencia de revisión del cuadro de mando
La guía diferencia la periodicidad según el comportamiento del entorno:
- Flotas de alta velocidad: revisión semanal.
- Otros entornos: revisión quincenal.
El propósito es mantener un ciclo en el que los indicadores se revisan regularmente y sirven como referencia para los siguientes ajustes de atribución, presupuestos y optimización.
Cómo se conectan las cinco etapas
El modelo presentado por AWS funciona como un ciclo, en lugar de una secuencia que termina después de la configuración inicial.
| Etapa | Pregunta principal | Mecanismos destacados |
|---|---|---|
| 1. Atribuir | ¿Quién genera el costo? | IAM, CUR 2.0, etiquetas y perfiles de inferencia |
| 2. Observar | ¿Cómo se consumen los recursos? | CloudWatch Logs, S3, Athena y OpenTelemetry |
| 3. Aplicar presupuestos | ¿Cómo se controla el gasto? | AWS Budgets, IAM, Lambda, DynamoDB y pasarelas |
| 4. Optimizar | ¿Cómo reducir el costo de las solicitudes? | Enrutamiento de modelos, caché y gestión del contexto |
| 5. Operar | ¿Cómo mantener el control económico? | Indicadores, análisis de anomalías y refacturación |
La conexión entre las etapas permite que los datos de consumo sirvan tanto para evaluar los presupuestos como para identificar oportunidades de optimización.
En contexto
Amazon Bedrock es un servicio administrado de AWS para trabajar con modelos fundacionales. AWS publicó este modelo operativo para equipos de FinOps y plataformas en su blog oficial de Machine Learning el 30 de octubre de 2026.
