El costo de Bedrock no se controla eligiendo el modelo más barato — se controla diseñando la arquitectura para que cada token que se paga aporte valor.
Bedrock cobra principalmente por dos vías: on-demand, por token de entrada y de salida procesado (con precios distintos por modelo — los tokens de salida siempre cuestan más que los de entrada), y Provisioned Throughput, una capacidad reservada por hora o por mes medida en "model units" que garantiza rendimiento constante a un costo fijo independiente del volumen exacto de tráfico. Existe además el modo de inferencia batch, que procesa trabajos asíncronos desde S3 a un descuento significativo sobre el precio on-demand, sin garantía de latencia baja.
Antes de optimizar, identifique en qué régimen está gastando: si el 80% del costo es de tokens de salida en respuestas largas, la palanca principal es reducir la longitud de salida o cambiar de modelo; si el costo es de tokens de entrada por contexto repetido, la palanca es prompt caching.
Cuando una aplicación reenvía el mismo contexto extenso en cada llamada — un system prompt largo, documentos de referencia, definiciones de herramientas — Bedrock permite cachear ese prefijo con `cache_control` (disponible en los modelos Claude vía la API nativa de Anthropic, y en otros modelos según soporte del proveedor). Los tokens que se leen desde caché cuestan una fracción del precio de un token procesado por primera vez.
En arquitecturas de Agents o RAG donde el mismo contexto documental se reutiliza en muchas invocaciones consecutivas, el prompt caching puede reducir el costo de tokens de entrada en 70-90% después de la primera invocación dentro de la ventana de vigencia del caché.
Si el caso de uso no requiere respuesta en tiempo real — clasificación masiva de tickets históricos, generación de resúmenes de miles de documentos, extracción de datos de un archivo completo — el modo batch de Bedrock (`CreateModelInvocationJob`) procesa el lote completo desde S3 a un costo por token sensiblemente menor que on-demand. La contrapartida es tiempo de procesamiento no garantizado en minutos, sino en un rango de horas, aceptable para la mayoría de los flujos de back-office.
Muchas arquitecturas usan un único modelo caro para todas las tareas cuando en realidad podrían segmentar: un modelo económico y rápido para clasificación inicial de intención (¿esta consulta es simple o compleja?), y solo escalar al modelo de mayor capacidad para el subconjunto de solicitudes que realmente lo requiere. Este patrón de "cascada de modelos" puede reducir el costo total de una arquitectura conversacional en 40-60% sin degradar la experiencia percibida, porque la mayoría de las consultas reales de un sistema de atención al cliente son simples.
Provisioned Throughput garantiza una capacidad de procesamiento fija a un precio fijo, independiente del volumen real procesado dentro de esa capacidad. Tiene sentido cuando el tráfico es predecible y sostenido y el volumen es lo suficientemente alto como para que el costo por token efectivo de la capacidad reservada sea menor que el equivalente on-demand — generalmente a partir de volúmenes de decenas de millones de tokens mensuales sostenidos, aunque el punto de equilibrio exacto depende del modelo y del compromiso de plazo (1 o 6 meses). Para tráfico intermitente o en crecimiento incierto, on-demand sigue siendo más seguro financieramente.
Etiquete cada invocación de Bedrock por proyecto, equipo o aplicación usando tags de recursos y, cuando aplique, el parámetro de request metadata en las llamadas, de modo que Cost Explorer pueda desglosar el gasto por unidad de negocio. Configure alarmas de CloudWatch sobre métricas de invocación (número de invocaciones, tokens procesados) para detectar picos anómalos de consumo antes de que aparezcan en la factura mensual — un bug en un loop de reintentos sin backoff puede multiplicar el costo de un endpoint en horas sin que nadie lo note hasta el corte de facturación.
Antes de escalar cualquier arquitectura Bedrock a producción, verifique: ¿está usando el modelo más barato que cumple el umbral de calidad por segmento de tarea? ¿Está cacheando el contexto repetido con prompt caching? ¿Las cargas no interactivas están en batch en vez de on-demand? ¿Tiene alarmas de gasto configuradas? ¿Ha corrido el volumen esperado contra el punto de equilibrio de Provisioned Throughput? Estas cinco preguntas capturan la mayoría de las oportunidades reales de ahorro sin sacrificar calidad de respuesta.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel