AWS publica una plantilla de data lake para Bedrock: cada prompt, cada token y su coste, a la vista

La historia es conocida: a final de mes llega la factura de Bedrock, el importe ha subido y nadie puede responder a la pregunta «quién y por qué». Se ve el agregado, pero no el contenido de las llamadas. No está claro qué prompt se envió, qué devolvió el modelo ni cuántos tokens consumió. AWS propone una solución lista para usar: un data lake central para todas las llamadas a Bedrock de una organización. Las plantillas de CloudFormation, el código de Lambda y las consultas SQL están en el repositorio AWS Sample Bedrock Invocation Data Lake.

Qué viene de serie y qué falta

Bedrock cuenta con model invocation logging, que registra el rastro completo de solicitudes y respuestas en S3 o CloudWatch. Pero hay que activarlo por separado en cada cuenta, y los datos se quedan en ella. Si hay una decena de cuentas, el resultado es una decena de islas aisladas. Comparar equipos, encontrar un prompt derrochador o analizar un pico de gasto por equipo resulta difícil.

Cómo funciona el pipeline

El recorrido de cada llamada tiene cinco etapas:

• Bedrock, en la cuenta de origen, escribe el log en un grupo de CloudWatch.
• Un subscription filter funciona como una regla de reenvío permanente: cada evento nuevo va a un CloudWatch Logs destination en la cuenta central. Las cuentas de origen no obtienen permisos sobre el pipeline central; solo envían eventos.
• Una pequeña Lambda descomprime los paquetes de CloudWatch, que llegan comprimidos y codificados. Descarta el ruido de servicio, como el mensaje «Permissions are correctly set», y sube al nivel superior el campo anidado con la identidad del llamante.
• Amazon Data Firehose almacena los registros en búfer, convierte el JSON a Parquet y los guarda en S3 organizados por fecha (year/month/day).
• Una tabla de Glue le explica a Athena cómo leer esos archivos, y a partir de ahí basta con SQL normal.

El resultado es una tabla en la que cada llamada tiene su prompt, su respuesta, el número de tokens de entrada y de salida, el modelo, el motivo de parada, la cuenta, la hora y el rol de IAM. Ya no se trata de «hemos gastado X tokens», sino de «esto es lo que hubo en cada llamada».

Qué hacer con esto en la práctica

Estos son algunos de los escenarios que describe la publicación:

• Depuración. Se obtiene el prompt y la respuesta exactos de una llamada concreta, sin rebuscar en logs sin procesar.
• Eficiencia. Se comparan los tokens de entrada (input) y de salida (output) por equipo y modelo, y se detecta dónde se desperdician.
• Ingeniería de prompts. Se buscan respuestas con stop_reason = max_tokens: se cortaron, así que conviene revisar el prompt o la configuración.
• Coste. La tabla se cruza con el AWS Cost and Usage Report 2.0 mediante el IAM ARN, lo que permite ver el gasto por equipo y por día, además del coste de las llamadas menos eficientes.

Para facilitar la visualización hay un dashboard en Quick Sight, que se instala con el comando cid-cmd deploy. Se le pueden añadir metadatos de la organización, por ejemplo los nombres de los equipos.

Los autores relacionan todo esto con la tokenomics: según ellos, en la conferencia de la FinOps Foundation de 2026 se la declaró un dominio independiente de FinOps. La lógica es sencilla: no se pueden optimizar los tokens hasta que se miden. El data lake aporta precisamente esa base.

Limitaciones y trampas

El principal riesgo es la seguridad. Todos los prompts y respuestas completos de todos los equipos acaban en un único bucket, y pueden contener PII. El bucket se cifra con KMS, pero el acceso a él y a los resultados de Athena hay que restringirlo por cuenta propia con políticas de IAM.

También hay matices operativos:

• El logging de Bedrock es una configuración a nivel de cuenta, no un recurso de CloudFormation. Debe activarse con una llamada de API independiente en cada origen, y solo con entrega a CloudWatch.
• Los datos no aparecen al instante: Firehose vacía el búfer aproximadamente al cabo de un minuto, a veces más. Para investigaciones es aceptable; para alertas en tiempo real, no.
• La vista de Athena se crea a mano: hay que ejecutar una vez la consulta guardada.
• El cruce con el coste se hace por IAM ARN. Si todos los equipos acceden a Bedrock con un mismo rol, el desglose por equipo será meramente orientativo. Esta es una conclusión nuestra; la publicación no lo trata directamente.
• Al eliminar el despliegue, primero hay que vaciar los buckets, y el Athena workgroup se borra manualmente.

Conclusión

Si usa Bedrock en varias cuentas y no sabe decir qué equipo quema más tokens, la plantilla merece la pena. El consejo de los autores: no intente abarcarlo todo de golpe. Empiece con una o dos cuentas, domine las consultas a la tabla y solo después amplíe a toda la organización. De paso, revise las políticas de IAM y el bucket mientras todavía haya pocos datos.