Para gestionar los costes de Amazon Bedrock, atribuye las llamadas a usuarios o aplicaciones, observa el consumo operativo y elige un control presupuestario según cómo se envían las solicitudes y cuánto riesgo de exceso acepta el equipo. AWS organiza este trabajo en cinco fases: atribuir, observar, aplicar controles, optimizar y operar.
1. Atribuye el gasto a usuarios y aplicaciones
En CUR 2.0, AWS describe el campo line_item_iam_principal para identificar el principal de IAM asociado al consumo. También recomienda activar las etiquetas de asignación de costes correspondientes; en Cost Explorer pueden tardar entre 24 y 48 horas en aparecer.
Un rol IAM compartido en una pasarela puede hacer que el gasto quede atribuido a ese rol, en lugar de a cada persona. Para recuperar la atribución por usuario, AWS propone asumir un rol de invocación por persona: el nombre de la sesión identifica al usuario y las etiquetas de sesión recogen dimensiones de negocio, como el equipo.
Para separar aplicaciones, AWS describe perfiles de inferencia de aplicaciones asociados a cada aplicación, modelo y región en bedrock-runtime; las llamadas usan el ARN del perfil. Projects responde a otro caso: cargas aptas de bedrock-mantle que utilizan Responses API o Chat Completions API. Un Project puede abarcar varios modelos.
El recorrido en inglés de AWS por perfiles de inferencia, etiquetas de costes y Cost Explorer, publicado en marzo de 2025 muestra la configuración de perfiles y la consulta de costes en la consola.
2. Observa el consumo antes de que llegue la atribución de facturación
CUR sirve para analizar la facturación, pero AWS describe un retraso de aproximadamente 24 horas en la atribución. En un ejemplo distinto, un panel con CloudWatch y OpenTelemetry muestra el gasto por desarrollador en cuestión de minutos.
AWS propone enviar los registros de invocación, con datos de solicitud, respuesta y metadatos, a CloudWatch Logs, a S3 o a ambos. CloudWatch encaja en consultas operativas; para análisis de inteligencia empresarial a más largo plazo, AWS propone S3 junto con Athena.
Los metadatos de una solicitud pueden identificar la aplicación, el flujo de trabajo o el usuario cliente. Sin embargo, Bedrock no impone un esquema uniforme: el equipo debe acordar nombres y campos coherentes para que esos datos sirvan al análisis.
3. Elige cómo actuar al alcanzar el presupuesto
AWS describe tres opciones. La decisión depende, sobre todo, de si las aplicaciones pueden enviar sus llamadas a través de una pasarela y de si basta con recibir un aviso o hace falta bloquear nuevas solicitudes.
| Control | Qué ocurre al alcanzar el límite | Aplicación y requisito operativo |
| Presupuestos y alertas | Se envía un aviso, pero las llamadas no se bloquean. | Adecuado si el equipo puede revisar el aviso e intervenir sin un corte automático. |
| Denegación mediante IAM | Una actualización de política puede denegar llamadas; también se pueden retener credenciales. | Es asíncrona: la actualización puede tardar de segundos a minutos, o la denegación puede esperar a la renovación de credenciales. No exige añadir una pasarela al recorrido de inferencia. |
| Control mediante pasarela | La pasarela bloquea la solicitud de forma síncrona y puede responder con HTTP 429 al superar el presupuesto. | AWS describe una aplicación inferior a un segundo. Los clientes deben encaminar las llamadas por la pasarela, que hay que desplegar, escalar y revisar en materia de seguridad. |
Si el cliente llama directamente a Bedrock, las alertas o el control IAM evitan introducir una pasarela en la ruta de inferencia. Si el requisito es bloquear una solicitud al alcanzar el límite, AWS describe el control síncrono mediante pasarela; su condición es que las llamadas pasen por ella.
4. Optimiza modelos y evalúa la caché de prompts
AWS recomienda comprobar la calidad de un modelo más barato con la carga de trabajo concreta antes de dirigirle solicitudes. La proporción de llamadas que conviene enrutar no es una cifra universal: el resultado depende de que ese modelo responda bien a la tarea.
Las tarifas de caché que AWS publicó para octubre de 2026 se refieren a Anthropic Claude en US East (N. Virginia). Una escritura en caché cuesta 1,25 veces la tarifa base de entrada con un TTL de cinco minutos, o 2 veces con un TTL de una hora. Las lecturas se indican a 0,1 veces la tarifa base para Claude Sonnet 4.6 y Claude Haiku 4.5, y a 0,05 veces para Claude Sonnet 5.5 y Claude Opus 5.5.
Con una escritura a 1,25 veces la tarifa base y nueve lecturas de igual volumen, el cálculo para diez llamadas queda así:
- Lectura a 0,1 veces:
(1,25 + 9 × 0,1) / 10 = 0,215, es decir, el 21,5 % del coste de entrada sin caché del prefijo. - Lectura a 0,05 veces:
(1,25 + 9 × 0,05) / 10 = 0,17, es decir, el 17 % del coste de entrada sin caché del prefijo.
La estimación supone que el prefijo se reutiliza en las nueve lecturas y que las diez llamadas procesan el mismo volumen de entrada. Solo calcula el coste de los tokens de entrada de ese prefijo: no incluye los tokens de salida ni otros cargos. Una escritura que no se reutilice puede generar el coste de escritura sin lecturas que lo compensen.
5. Revisa los indicadores con FinOps y plataforma
AWS propone seguir el gasto diario por desarrollador, la proporción de solicitudes enviadas a modelos de menor coste, la tasa de lecturas de caché y el coste por resultado satisfactorio. Presenta sus umbrales como puntos de partida que cada equipo debe ajustar, no como objetivos universales.
AWS sugiere revisar semanalmente las flotas con cambios rápidos de consumo y cada dos semanas las demás.
