Cómo rastrear y limitar el gasto de Amazon Bedrock por entidad principal de IAM con CUR 2.0 y AWS Budgets

El gasto en IA generativa es difícil de atribuir. Antes de que una organización amplíe el acceso a la IA, los directores financieros y de tecnología suelen querer respuesta a tres preguntas: cuánto se gasta por persona o por equipo, si ese gasto se puede limitar y cuánto trabajo supone conseguirlo.

En una publicación anterior, Tokenomics at Scale: How Jamf Built Real-Time Spend Enforcement for Amazon Bedrock, se describía un bucle de aplicación personalizado basado en AWS IAM Identity Center, Amazon Athena ejecutándose sobre los registros de invocación de modelos de Amazon Bedrock y AWS Lambda. Ese diseño ofrece control casi en tiempo real, pero exige escribir código que después hay que mantener y operar. Esta publicación muestra otra vía: visibilidad de los costes de Amazon Bedrock por identidad y límites de gasto aplicables usando únicamente funciones nativas de AWS, sin código de aplicación que escribir para el caso habitual. El enfoque se apoya en tres elementos: la atribución por entidad principal de IAM, que Amazon Bedrock registra automáticamente; AWS Cost and Usage Reports (CUR) 2.0 o AWS Cost Explorer para los informes; y AWS Budgets con acciones de presupuesto para la aplicación. Al final dispondrá de informes de costes por identidad y de una barrera automática que restringe el acceso a Amazon Bedrock cuando se supera un umbral.

Descripción general de la solución

La solución tiene tres partes: atribuir, informar y aplicar.

Atribuir. Amazon Bedrock captura la identidad de la entidad principal de AWS Identity and Access Management (IAM), es decir, el usuario o rol de IAM, en cada solicitud de inferencia. Esto ocurre automáticamente, sin cambios en las llamadas de inferencia de modelos de Amazon Bedrock. Si varias personas comparten un mismo rol, el detalle por usuario se añade mediante etiquetas de sesión que se pasan al asumir el rol. Si cada persona o aplicación tiene su propio rol, bastan las etiquetas de entidad principal del rol.

Informar. Active esas etiquetas como etiquetas de asignación de costes y después lea los datos en Cost Explorer para una vista solo de consola, o en una exportación de datos de CUR 2.0 para un análisis detallado por línea de concepto y consultas SQL.

Aplicar. Cree un presupuesto de AWS Budgets con ámbito en Amazon Bedrock y filtrado a una identidad o valor de etiqueta, y adjunte una acción de presupuesto que aplique una política de denegación de IAM cuando se supere el umbral.

Requisitos previos

Para desplegar esta solución necesita:

• Una cuenta de AWS con el acceso a modelos de Amazon Bedrock habilitado.
• Permisos para etiquetar entidades principales de IAM, activar etiquetas de asignación de costes, crear exportaciones de datos y crear presupuestos y acciones de presupuesto.
• Acceso a Amazon Bedrock a través de roles o usuarios de IAM.
• La interfaz de línea de comandos de AWS (AWS CLI) configurada con las credenciales adecuadas.
• Una exportación de datos de CUR 2.0 y un bucket de Amazon Simple Storage Service (Amazon S3) para recibirla (opcional, para el análisis detallado por línea de concepto).
• Amazon Athena (opcional, para consultar la exportación).

El acceso a la consola de facturación de AWS se gestiona por separado de la mayoría de los permisos de IAM, así que confirme que lo tiene antes de empezar.

Tutorial

Antes de configurar nada, compruebe lo que ya tiene. Amazon Bedrock registra automáticamente la identidad de quien llama en cada solicitud de inferencia. Abra Cost Explorer, filtre Service por Amazon Bedrock y agrupe por la dimensión de identidad o etiqueta disponible. En las cuentas donde cada aplicación o persona ya usa un rol de IAM distinto, puede que esa sea toda la visibilidad necesaria.

Para configurar visibilidad adicional:

• El paso 1 proporciona visibilidad a nivel de identidad.
• Los pasos 2 a 4 añaden dimensiones de etiquetas e informes detallados.
• El paso 5 añade la aplicación de límites.

Paso 1: Decida cómo se corresponde la identidad con sus usuarios

La forma de etiquetar depende de cómo estén organizadas las entidades principales de IAM.

Un rol por persona o por aplicación. Adjunte etiquetas de entidad principal directamente a cada rol o usuario de IAM. Son estáticas y se aplican a todas las solicitudes de esa entidad principal. Use la consola de IAM o la AWS CLI:

aws iam tag-role \
  --role-name BedrockDeveloperRole-alice \
  --tags Key=user,[email protected] Key=team,Value=platform Key=CostCenter,Value=CC-1001

Un rol compartido por varias personas, o una puerta de enlace. Las etiquetas de entidad principal no pueden distinguir a los usuarios de un rol compartido, porque todas las sesiones llevan las mismas etiquetas. Use en su lugar etiquetas de sesión, que se pasan al asumir el rol. Las etiquetas de sesión son dinámicas y pueden variar por sesión; si una etiqueta de sesión y una de entidad principal comparten clave, la de sesión prevalece en esa sesión.

La política de confianza del rol debe permitir sts:TagSession. Las etiquetas de sesión se pueden pasar de tres maneras:

• sts:AssumeRole con --tags, para una puerta de enlace que asume un rol por usuario o inquilino.
• AssumeRoleWithWebIdentity, con las etiquetas en la reclamación https://aws.amazon.com/tags del token de ID de OpenID Connect (OIDC) (es un nombre de reclamación, no una URL que se pueda visitar).
• AssumeRoleWithSAML, asignando atributos PrincipalTag:* en la aserción de Security Assertion Markup Language (SAML) del proveedor de identidad.

Si su organización ya captura una reclamación como saml:sub para otros fines, eso por sí solo no la hace disponible aquí. El proveedor de identidad debe asignar por separado ese atributo a una declaración de atributos PrincipalTag:* de SAML, y la política de confianza del rol debe permitir sts:TagSession, antes de que fluya como etiqueta de sesión. Las dos integraciones parten de la misma aserción SAML pero se configuran de forma independiente. Las claves de etiqueta habituales son user, team, Department, CostCenter y Environment, y se pueden aplicar hasta 50 etiquetas de entidad principal o de sesión por usuario o rol de IAM.

Paso 2: Active las etiquetas de asignación de costes

Las etiquetas no aparecen en los datos de facturación hasta que se activan.

1. Abra la consola de AWS Billing and Cost Management.
2. Elija Cost allocation tags.
3. Filtre por el tipo IAM principal.
4. Seleccione sus claves de etiqueta y elija Activate.

En una AWS Organization, active las etiquetas de asignación de costes de entidad principal de IAM en la cuenta de administración (pagadora); las cuentas miembro no pueden activarlas de forma independiente.

Dos cosas que debe esperar:

• Una clave de etiqueta solo aparece en esta lista después de que la entidad principal haya realizado al menos una llamada a Amazon Bedrock, así que haga primero una llamada de prueba si la lista aparece vacía.
• Una clave de etiqueta recién aplicada puede tardar hasta 24 horas en aparecer para su activación, y después hasta otras 24 horas tras activarla antes de empezar a rellenar los datos de facturación.

La activación no se aplica de forma retroactiva por defecto, así que active las etiquetas antes de necesitar los datos.

Paso 3: Cree una exportación de datos de CUR 2.0 que incluya la identidad de quien llama

Omita este paso si Cost Explorer es suficiente para sus informes.

1. En la consola de Billing and Cost Management, elija Data Exports.
2. Elija Create y cree una exportación CUR 2.0 (Standard).
3. En Additional export content, seleccione Include caller identity (IAM principal) allocation data.
4. En Time granularity, seleccione Hourly.
5. En Report data integration, seleccione Amazon Athena. Esto fija el formato de archivo en Parquet y, lo que es importante, entrega un script de configuración en su bucket de S3 junto con los datos de la exportación.
6. Elija el bucket de Amazon S3 de destino.
7. Ejecute una vez el script de configuración entregado (o el rastreador de Glue/DDL que define). Esto es lo que realmente crea la tabla del Glue Data Catalog que consultará en el paso 4; el flujo de consola anterior no la crea automáticamente.

Si ya tiene una exportación de CUR 2.0 creada antes de habilitar la atribución de identidad, no incluirá datos de identidad de forma retroactiva, así que cree una exportación nueva con la opción de identidad de quien llama seleccionada. En la exportación, las etiquetas de entidad principal y de sesión aparecen como columnas con el prefijo iamPrincipal/, y las etiquetas de recurso como resourceTags/. Una clave de etiqueta team, por ejemplo, aparece como iamPrincipal/team. AWS publica un conjunto de consultas listas para este patrón en aws-samples/sample-cur-iam-principal-bedrock-tracking.

Paso 4: Lea los datos

Hay dos formas de leer los datos: una vía solo de consola a través de Cost Explorer y una vía SQL sobre la exportación de CUR 2.0 con Amazon Athena.

Vía de consola, sin código personalizado. Cost Explorer filtrado por Amazon Bedrock y agrupado por su clave de etiqueta muestra el gasto por equipo o por usuario en un gráfico y una tabla. Esto cubre la mayoría de las necesidades de informes recurrentes y no requiere escribir consultas.

Vía SQL, con poco código. Apunte Amazon Athena a la exportación de CUR 2.0 para agrupar el gasto por iamPrincipal/team y tipo de uso:

SELECT
    tags['iamPrincipal/team'] AS team,
    line_item_usage_type,
    SUM(line_item_unblended_cost) AS cost
FROM cur2_view
WHERE product_servicecode IN ('AmazonBedrock', 'AmazonBedrockService')
AND billing_period = '2026-09'
GROUP BY 1, 2
ORDER BY 3 DESC

Aspectos a tener en cuenta:

• Código de servicio: el gasto de Amazon Bedrock puede registrarse bajo más de un valor de product_servicecode, por ejemplo AmazonBedrock y AmazonBedrockService.
• Nombre de la tabla: el nombre de la tabla (cur2_view) es el que el script de configuración del paso 3 dio a la tabla de Glue al crearla. Compruebe el script o su catálogo de Glue si difiere. Los nombres de columna coinciden con el esquema Parquet de CUR 2.0 sea cual sea el nombre de la tabla.
• Columna de período de facturación: confirme cómo expone el período su exportación. Algunas exportaciones usan billing_period (YYYY-MM); otras particionan por una columna de fecha de inicio o de año/mes.

Dos notas aplicables a cualquier consulta que escriba:

• Cuente todos los tipos de token: Amazon Bedrock factura cuatro tipos de token, cada uno a una tarifa distinta: entrada, salida, lectura de caché y escritura de caché. Cada uno es una línea de concepto separada con su propio tipo de uso y precio unitario, así que sumar solo entrada y salida subestima el gasto. La diferencia es mayor en cargas de trabajo que usan mucho el almacenamiento en caché de prompts. Consulte el documento de AWS Understanding Amazon Bedrock pricing in CUR para la información más reciente.
• Ajuste la tarifa a la línea de concepto, no al modelo: el precio de Amazon Bedrock en CUR viene determinado por tres cosas: el tipo de token, el nivel de servicio y si la solicitud se enrutó mediante inferencia entre regiones. Las solicitudes dentro de la región y entre regiones tienen precios distintos, y el nivel de servicio también se refleja en el tipo de uso. El tipo de uso lleva un sufijo que indica el enrutamiento entre regiones y el nivel de servicio, así que si sus cargas de trabajo mezclan estos casos, ajuste la tarifa a cada línea de concepto en lugar de aplicar una sola tarifa por modelo. Consulte los ejemplos de tipos de uso de CUR.

Paso 5: Añada aplicación con AWS Budgets y acciones de presupuesto

AWS Budgets realiza el adjuntado, así que no hay código personalizado en este flujo de trabajo. Las acciones de presupuesto se adjuntan a un usuario, grupo o rol de IAM concreto, lo que aísla el acceso de una persona solo si esa persona ya tiene su propio rol. Si el tráfico de Amazon Bedrock pasa por un rol que comparten muchas personas, una acción de denegación adjuntada a ese rol bloquea a todos los que lo usan, no solo a quien superó el umbral.

AWS Budgets puede ejecutar una acción cuando se supera un umbral. Las acciones disponibles incluyen aplicar una política de IAM personalizada, aplicar una política de control de servicios (SCP) y actuar sobre instancias de Amazon Elastic Compute Cloud (Amazon EC2) o de Amazon Relational Database Service (Amazon RDS). Para este caso de uso, la acción relevante es la de política de IAM.

Primero cree la política de denegación que adjuntará la acción. Este ejemplo deniega los modelos de mayor coste dejando disponible uno de menor coste, de modo que el usuario pueda seguir trabajando:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:*::foundation-model/[HIGHER-COST-MODEL-ID]"
      ]
    }
  ]
}

Sustituya [HIGHER-COST-MODEL-ID] por el ID del modelo que quiera denegar en su entorno.

Después configure los permisos y el propio presupuesto. Aquí hay dos roles distintos, y la política gestionada de AWS solo cubre uno de ellos:

• Su propio usuario o rol (el que configura el presupuesto) necesita la política gestionada de AWS AWSBudgetsActionsWithAWSResourceControlAccess. Otorga permisos de presupuestos más el iam:PassRole condicionado necesario para entregar su rol de acción de presupuesto a AWS Budgets.
• El rol de IAM que AWS Budgets asume para ejecutar la acción no está cubierto por una única política gestionada con nombre para este caso de uso. Créelo con una política de confianza que permita a la entidad principal budgets.amazonaws.com asumirlo, delimitada con las condiciones aws:SourceArn y aws:SourceAccount, y una política de permisos que otorgue iam:AttachRolePolicy e iam:DetachRolePolicy (y organizations:AttachPolicy y organizations:DetachPolicy si también usa SCP). Consulte Setting up a role for AWS Budgets to run budget actions para conocer los permisos que se pueden otorgar.

Pasos de configuración:

1. Cree el rol de acción de presupuesto descrito antes.
2. Cree un presupuesto de costes con ámbito en Amazon Bedrock, filtrado por la identidad o el valor de etiqueta que quiera limitar.
3. En Configure alerts, añada un umbral de alerta. Elija Actual para el gasto ya realizado o Forecasted para actuar antes de que el gasto se produzca.
4. En Attach actions, elija Add Action, seleccione el rol de acciones de presupuesto y elija la acción de política de IAM. Seleccione la política de denegación y el usuario, grupo o rol de IAM al que adjuntarla.
5. Para la aplicación automática, elija Yes para ejecutar la acción automáticamente; elija No para exigir que una persona apruebe cada acción desde la página Alert details.
6. Configure al menos una notificación para que el usuario afectado sepa por qué cambió su acceso.

Puede adjuntar varias acciones a un mismo umbral y varios umbrales a un mismo presupuesto. Así se construyen niveles: por ejemplo, denegar el modelo premium al 80 por ciento y el modelo de nivel medio al 100 por ciento, sin denegar nunca el modelo de bajo coste.

Solo la cuenta de administración puede aplicar SCP, y desde la cuenta de administración se puede aplicar una SCP a otra cuenta.

Consideraciones

• AWS Budgets no funciona casi en tiempo real: los datos de presupuesto se actualizan hasta tres veces al día, así que el gasto puede superar un umbral antes de que la acción se ejecute.
• Las etiquetas de asignación de costes no son retroactivas: cuente con hasta 24 horas para que aparezca una clave de etiqueta recién aplicada y hasta otras 24 horas tras activarla antes de que empiece a rellenar los datos de facturación.
• CUR no contiene líneas de concepto por solicitud: tanto el CUR clásico como CUR 2.0 agregan el coste de Amazon Bedrock por tipo de uso, operación y atributos de precio o recurso a lo largo de una hora o un día.
• Los campos de entidad principal de IAM requieren CUR 2.0: el formato CUR heredado no los incluye. Los desgloses de coste por token están disponibles en ambos formatos.
• Las etiquetas de sesión se fijan en el momento de AssumeRole, no por solicitud: sus valores son constantes para todas las llamadas hechas con las credenciales de esa sesión y solo aparecen como datos de facturación agregados. Las etiquetas de sesión no se escriben en los registros de invocación de modelos; los registros capturan el identity.arn de quien llama. Para distinguir usuarios en una sesión compartida a nivel de solicitud, use un RoleSessionName por usuario o establezca el usuario en los metadatos de la solicitud en cada llamada.
• Las acciones de presupuesto se adjuntan a usuarios, grupos y roles de IAM: si sus usuarios están federados y no tienen una identidad de IAM permanente, la acción necesita un rol al que dirigirse. Por eso el patrón funciona mejor cuando cada persona o aplicación tiene su propio rol. Si sus usuarios comparten un rol o están federados sin rol propio, consulte la publicación anterior para un enfoque de aplicación por usuario.
• Un rol de puerta de enlace compartido colapsa la atribución por defecto: con una puerta de enlace de modelo de lenguaje grande (LLM), la identidad capturada es el rol de ejecución de la puerta de enlace.
• Los modelos nuevos requieren atención: los tipos de uso son específicos de cada modelo. Cuando habilite un modelo nuevo, confirme que aparece como se espera en sus consultas y filtros de presupuesto en lugar de dar por hecho que está cubierto.

Marco de decisión

Limpieza

Para evitar cargos continuos, elimine todos los recursos que haya creado.

Conclusión

Este tutorial mostró cómo obtener visibilidad de los costes de Amazon Bedrock por identidad y límites de gasto aplicables usando únicamente funciones nativas de AWS, sin código de aplicación que escribir para el caso habitual, y cómo estas piezas responden a las tres preguntas detrás del problema de la tokenómica: cuánto se gasta por persona o por equipo, si se puede limitar y cuánto trabajo supone conseguirlo.