Amazon Bedrock cobra por cada token de entrada y de salida procesado, con costos que varían según el modelo, el modo de Precios y el patrón del workload. El modo on-demand se ajusta a usos impredecibles o de bajo volumen; el provisioned throughput entrega capacidad garantizada para workloads de producción consistentes y de alto volumen; la inferencia por lotes ofrece descuentos de hasta el 50 % para tareas que no requieren tiempo real. La personalización y el fine-tuning de modelos generan cargos aparte por entrenamiento, almacenamiento e inferencia. Como el comportamiento de los costos de IA no se parece al del cómputo tradicional, los equipos de CloudOps necesitan visibilidad a nivel de token y controles automáticos de presupuesto para que el gasto en Bedrock siga siendo predecible.
El presupuesto tradicional de la nube se construyó sobre unidades predecibles: horas de instancia, gigabytes de almacenamiento, salida de red. Amazon Bedrock no encaja en ese modelo. Tu factura depende de cuántas palabras escriben tus usuarios, qué tan extensos son tus prompts, qué modelo fundacional elegiste y con qué frecuencia tu aplicación reintenta llamadas fallidas. Una sola decisión de arquitectura, como elegir Claude 3 Opus en lugar de Claude 3 Haiku, puede alterar los costos en un orden de magnitud a escala.
Esto no es una crítica a Bedrock. Es una realidad estructural de los Precios basados en inferencia que la mayoría de los equipos de CloudOps y FinOps no había tenido que analizar antes. Los Engineers que construyeron tus funcionalidades de IA entienden los tokens. Quienes aprueban tu presupuesto de nube probablemente no. Cerrar esa brecha es urgente: el informe State of FinOps 2026 de la FinOps Foundation reveló que el 98 % de las organizaciones ya gestiona activamente el gasto en IA, frente a apenas el 31 % de hace dos años. La visibilidad de costos no es algo opcional. Es lo que hace posible la conversación sobre el crecimiento de la IA.
Esta guía explica cómo funcionan los Precios de Bedrock, cómo estimar los costos antes de que aparezcan en tu factura y cómo construir el monitoreo y los controles que mantengan el gasto en IA bajo control.
¿Cómo funcionan los Precios de Amazon Bedrock?
Amazon Bedrock cobra por inferencia: el proceso de enviar un prompt a un modelo fundacional y recibir una respuesta. La unidad de Precio principal es el token, un fragmento de texto equivalente a unos cuatro caracteres o tres cuartos de una palabra. Cada solicitud tiene tokens de entrada (tu prompt, el mensaje del sistema y cualquier historial de conversación) y tokens de salida (la respuesta del modelo). Se paga por ambos, a tarifas distintas.
Lo que vuelve más impredecibles los costos de Bedrock frente a los de cómputo es que los tokens no son fijos. Un usuario que escribe una pregunta de dos oraciones consume muchos menos tokens de entrada que uno que pega un documento de 3.000 palabras. Una aplicación que le pide al modelo "resumir brevemente" produce menos tokens de salida que una que pide un análisis detallado. Si multiplicas esa variabilidad por miles de solicitudes diarias, pronosticar el presupuesto se vuelve realmente complicado sin la instrumentación adecuada.
Hay dos factores adicionales que complican el panorama. Primero, los tokens de salida suelen costar más que los de entrada en muchos modelos, porque generar texto pesa más en términos computacionales que procesarlo. Esto varía según el proveedor: algunos modelos cobran lo mismo por tokens de entrada y de salida, mientras que otros cobran bastante más por la salida. Segundo, la elección del modelo tiene un efecto enorme sobre las tarifas por token. Un modelo liviano cuesta una fracción de lo que cuesta un modelo de frontera de la misma familia por millón de tokens. El modelo correcto para una tarea de clasificación suele ser el equivocado para una tarea de razonamiento complejo, y viceversa. Elegir solo por capacidad, sin considerar el costo, es una de las fuentes más comunes de gasto innecesario en Bedrock.
Modelos de Precios y estructuras tarifarias de Amazon Bedrock
Bedrock ofrece tres modos de Precios principales: on-demand, provisioned throughput e inferencia por lotes. Cada uno responde a un perfil de workload distinto. Entender los trade-offs entre ellos es clave tanto para el control de costos como para la confiabilidad operativa.
Modo de Precios
Cómo se paga
Compromiso
Latencia
Ideal para
On-demand
Por token procesado
Ninguno
Variable; riesgo de throttling en picos
Workloads con picos, experimentales o de bajo volumen
Provisioned throughput
Tarifa fija por hora por unidad de modelo
1 o 6 meses
Garantizada; sin throttling
Workloads consistentes y de alto volumen; obligatorio para modelos personalizados
Inferencia por lotes
Por token (hasta 50 % de descuento vs. on-demand)
Ninguno
Asíncrona; no en tiempo real
Procesamiento de documentos, tareas nocturnas, pipelines de enriquecimiento asíncronos
Precios on-demand para modelos fundacionales
On-demand es el modo predeterminado. Pagas por cada 1.000 tokens procesados, sin compromiso por adelantado y sin gasto mínimo. Es ideal para workloads exploratorios, con picos o que aún no son lo suficientemente predecibles para justificar reservas de capacidad.
El riesgo operativo del on-demand es el throttling. AWS aplica límites de concurrencia al acceso a los modelos fundacionales y, en períodos de demanda pico, las solicitudes pueden quedar en cola o fallar. Para herramientas internas o aplicaciones de bajo riesgo, este trade-off es aceptable. Para funcionalidades de cara al cliente con requisitos de latencia, no lo es.
Las tarifas por token varían bastante según la familia y la generación del modelo. Dentro de la línea Anthropic Claude en Bedrock, por ejemplo, los modelos más livianos pueden costar un orden de magnitud menos por millón de tokens que los modelos de frontera de la misma familia. Las tarifas también difieren entre tokens de entrada y de salida en la mayoría de los modelos, aunque algunos proveedores los cobran igual. Elegir el modelo adecuado para la tarea, no solo el más capaz disponible, es la decisión de costo de mayor impacto que puede tomar un equipo. Verifica siempre las tarifas vigentes en la página de Precios de AWS Bedrock antes de definir una estrategia de selección de modelos, ya que las tarifas y las versiones disponibles cambian con frecuencia.*
Opciones de Precios de provisioned throughput
El provisioned throughput funciona como una instancia reservada para inferencia. Compras unidades de modelo, cada una con un throughput de tokens por minuto garantizado, y pagas una tarifa fija por hora uses esa capacidad o no. Los compromisos son de uno o seis meses, y los plazos más largos ofrecen mejores tarifas.
El caso financiero del provisioned throughput depende de la utilización. Si tu workload corre con un volumen consistente durante el horario laboral, la tarifa fija por hora puede generar ahorros relevantes frente al on-demand al mismo nivel de throughput. Pero el compromiso es real. La capacidad provisionada sin usar cuesta lo mismo que la capacidad totalmente utilizada. Los equipos que provisionan para carga pico y operan al 30 % de utilización promedio no ahorran dinero.
El provisioned throughput también es la única opción de inferencia para modelos personalizados y con fine-tuning. Si tu equipo planea desplegar un modelo fundacional adaptado a un dominio, eso obliga a usar provisioned throughput sin importar tu perfil de volumen.
Costos de personalización y fine-tuning de modelos
Hacer fine-tuning de un modelo fundacional en Bedrock genera tres eventos de costo distintos: entrenamiento, almacenamiento e inferencia. Los costos de entrenamiento se calculan según el total de tokens procesados sobre tu dataset y la cantidad de épocas de entrenamiento. Una vez entrenado, el modelo personalizado queda en almacenamiento con una tarifa mensual. Servir el modelo con fine-tuning requiere provisioned throughput, con al menos una unidad de modelo, sin necesidad de compromiso a largo plazo.
Antes de comprometerse con la personalización, conviene correr una prueba de concepto sobre un dataset reducido para validar si las mejoras de rendimiento justifican la estructura de costos adicional. La destilación de modelos, que comprime las capacidades de un modelo grande en uno más pequeño y rápido, puede reducir los costos de inferencia a largo plazo. Pero los modelos destilados tienen sus propios costos de entrenamiento y también requieren provisioned throughput para su despliegue.
Cómo calcular y estimar los costos de Amazon Bedrock
Una estimación precisa de costos exige pasar de suposiciones vagas a volúmenes de tokens medidos. Los equipos que pronostican el gasto en Bedrock a partir de la "cantidad de llamadas a la API" se equivocan. La cantidad de tokens por llamada, y la proporción entre entrada y salida, importa mucho más que el conteo de llamadas.
Cálculo de Precios por tokens de entrada y salida
La fórmula central es directa. El costo mensual equivale a los tokens de entrada multiplicados por la tarifa de tokens de entrada, más los tokens de salida multiplicados por la tarifa de tokens de salida, ambos expresados por millón de tokens. El reto está en estimar esos volúmenes con precisión antes de tener datos de producción.
Empieza por la arquitectura de prompts de tu aplicación. Un system prompt de 500 tokens se cobra en cada solicitud. Una configuración de retrieval-augmented generation (RAG) que inyecta 2.000 tokens de contexto por consulta escala ese costo en cada invocación. Audita tus plantillas de prompt y cuenta los tokens con el tokenizador de Bedrock o un contador específico del modelo antes del lanzamiento.
Para estimar la salida, analiza qué le pides al modelo que produzca. Las tareas de clasificación de respuesta única generan muchos menos tokens de salida que las respuestas conversacionales o el contenido extenso. Arma una muestra representativa de solicitudes, mide los conteos reales de tokens de entrada y salida, y úsalo como tu línea base. Después, aplica un multiplicador para el volumen esperado de solicitudes.
Un ejemplo práctico: una aplicación que envía 100.000 solicitudes diarias a un modelo fundacional de gama media, con un promedio de 800 tokens de entrada y 400 tokens de salida, genera 80 millones de tokens de entrada y 40 millones de tokens de salida por día. Según el modelo y su tarifa de tokens de salida, el gasto diario total puede ir de decenas a cientos de dólares y acumularse hasta cifras de cinco dígitos al mes. El costo de los tokens de salida, por lo general más alto que la tarifa de entrada para el mismo modelo, concentra la mayor parte de esa cifra.* Para conocer las tarifas vigentes de todos los modelos fundacionales disponibles, consulta la página de Precios de AWS Bedrock.
Herramientas y métodos de estimación de costos
AWS ofrece una calculadora de Precios de Bedrock y una herramienta de estimación de tokens en la consola, ambas útiles para el modelado inicial. Para visibilidad continua, AWS Cost Explorer muestra el gasto en Bedrock, pero no desglosa los costos por modelo, aplicación o equipo sin etiquetado de recursos. Las etiquetas son esenciales. Etiqueta cada invocación de Bedrock con los identificadores de aplicación, equipo y entorno que correspondan a tu estructura de asignación de costos, antes de que los workloads pasen a producción.
DoiT Cloud Intelligence va más allá del etiquetado y los dashboards. Ofrece visibilidad en tiempo real de los costos de IA en todo tu uso de Bedrock, con analítica que muestra cómo la elección del modelo, los patrones de prompts y los picos de uso impactan el gasto a un nivel granular. Esa visibilidad conecta los datos de costos con las decisiones de Engineering de un modo que los reportes estáticos no logran.
En entornos multi-modelo donde diferentes aplicaciones usan distintos modelos fundacionales, define presupuestos de costos por modelo y umbrales de alerta por separado. Un pico en los costos de un modelo de frontera se ve muy distinto a un pico en uno liviano, y juntarlos en una sola línea de presupuesto dificulta el análisis de causa raíz.
Estrategias de optimización de costos de Amazon Bedrock para equipos CloudOps
La optimización en Bedrock no es una auditoría puntual. Es una disciplina operativa. Los workloads de IA evolucionan rápido. Un prompt que era eficiente al lanzamiento puede volverse caro a medida que se expanden los casos de uso, las ventanas de contexto crecen y los historiales de conversación se acumulan. Los equipos que controlan los costos de Bedrock lo abordan igual que el right-sizing de cómputo: de forma continua, con señales automatizadas que disparan la acción.
Right-sizing en la elección del modelo según el workload
El right-sizing de modelos es la optimización de mayor impacto disponible, y la mayoría de los equipos invierte poco en ella. Lo habitual es elegir el modelo más capaz de una familia y desplegarlo en todos los casos de uso. El mejor enfoque es ajustar la capacidad del modelo a la complejidad de la tarea.
Clasifica tus casos de uso según lo que realmente requieren. Las tareas simples de extracción, clasificación y resumen no necesitan un modelo de frontera. Un modelo más pequeño y económico las maneja con precisión a una fracción del costo. Reserva los modelos grandes para razonamiento complejo, resolución de problemas en varios pasos y tareas donde la calidad de la salida afecta de verdad los resultados del negocio.
Pruébalo con rigor. Corre tus workloads reales contra un conjunto escalonado de modelos, mide la calidad de la salida frente a tus criterios de aceptación y calcula la diferencia de costo. En muchos casos, se logra un umbral del 90 % de calidad con un modelo que cuesta entre 10 y 20 veces menos que la alternativa de gama alta. Eso no es una mejora menor de eficiencia. A escala, transforma el presupuesto.
Considera también la inferencia por lotes para workloads que no requieren respuestas en tiempo real. El modo batch de Bedrock reduce los costos de tokens hasta un 50 % en los modelos compatibles. El procesamiento de documentos, las tareas de análisis nocturnas y los pipelines de enriquecimiento asíncronos son fuertes candidatos. El trade-off es la latencia: las tareas batch corren de forma asíncrona, así que no son apropiadas para funcionalidades de cara al usuario que esperan respuestas inmediatas.
Implementación de monitoreo de uso y controles de presupuesto
Monitorear Bedrock sin telemetría a nivel de token es como monitorear EC2 sin métricas de CPU. AWS CloudWatch muestra los conteos de invocaciones y errores de Bedrock. Agrega métricas personalizadas para el consumo de tokens por modelo, por aplicación y por entorno. Define alarmas en umbrales de tokens que se disparen antes de que los costos se conviertan en un problema, no después de que llegue la factura.
El prompt caching reduce los cargos por tokens de entrada para contenido repetido o estático. Los system prompts, los documentos de referencia y el contexto compartido que no cambia entre solicitudes se pueden cachear. La porción cacheada se cobra a una tarifa reducida, lo que genera ahorros reales en aplicaciones donde el mismo system prompt aparece en cada llamada. Activa el prompt caching para cualquier contenido que se ajuste a este patrón.
La inferencia entre regiones enruta solicitudes a la capacidad de modelo disponible en otras regiones de AWS cuando tu región principal está con throttling o al límite de capacidad. Esto mejora la confiabilidad bajo carga sin requerir compromisos separados de provisioned throughput. Evalúalo para workloads de producción donde la tolerancia al throttling sea baja.
Los controles de presupuesto en AWS Budgets pueden alertar sobre el gasto en Bedrock, pero reaccionan a un gasto que ya ocurrió. El control más fuerte es el rate limiting a nivel de aplicación, que evita el uso descontrolado antes de que llegue a tu factura. Define límites de tokens por usuario, por sesión y por aplicación en tu capa de aplicación, y aplícalos antes de que las solicitudes lleguen a la API de Bedrock. Esa es la diferencia entre una señal de monitoreo y una verdadera barrera de protección.
DoiT Cloud Intelligence ofrece detección automatizada de anomalías para el gasto en IA, mostrando desviaciones de los patrones de costos esperados en tiempo real. Eso significa que los equipos de CloudOps se enteran de los problemas de costos en horas, no al cierre de mes.
Vuelve los costos de Amazon Bedrock predecibles y defendibles
El gasto impredecible en IA no es solo un problema financiero. Es un problema de credibilidad. Cuando los líderes de Engineering no pueden explicar qué causó un aumento del 40 % en los costos de Bedrock de un mes al siguiente, se genera fricción con finanzas, se ralentizan las decisiones de inversión en IA y se debilita el caso para expandir las iniciativas de IA. La visibilidad de costos no es un costo extra. Es lo que hace posible la conversación sobre el crecimiento de la IA.
Los equipos que lo hacen bien tratan la gestión de costos de Bedrock como una práctica de Engineering, no como una función financiera. Instrumentan el uso de tokens en la fase de construcción, no después de la primera factura inesperada. Validan la elección del modelo frente a los trade-offs de costo y calidad antes del lanzamiento. Construyen barreras automatizadas que aplican límites de gasto sin intervención manual. Y miden el costo por resultado, no solo el costo por llamada, para demostrar el ROI en términos que tanto Engineers como ejecutivos comprendan.
Esa es la madurez operativa que convierte a Bedrock de un riesgo de costos en una capacidad sostenible.
DoiT ayuda a los equipos de CloudOps y FinOps a cerrar la brecha entre los datos de costos de IA y la acción. DoiT Cloud Intelligence muestra el gasto de Bedrock en tiempo real por modelo, aplicación y equipo, con alertas y recomendaciones automatizadas que no requieren un experto en FinOps para interpretarlas. DoiT cuenta con la AWS Generative AI Competency y está disponible directamente a través del AWS Marketplace, así que los equipos pueden desplegar Cloud Intelligence dentro de su flujo actual de Procurement de AWS sin sumar una nueva relación con un proveedor.
Explora DoiT Cloud Intelligence para la gestión de costos de IA y descubre cómo la visibilidad sobre tus Precios de Bedrock puede pasar de reactiva a predictiva.
Preguntas frecuentes sobre los Precios de Amazon Bedrock
¿Cuál es la forma más económica de usar Amazon Bedrock?
El enfoque más económico combina el right-sizing de modelos con la inferencia por lotes cuando sea posible. Usar un modelo más pequeño y apropiado para la tarea en lugar de un modelo de frontera puede reducir los costos por token entre 10 y 20 veces. Activar la inferencia por lotes para workloads que no requieren tiempo real suma hasta un 50 % de ahorro adicional. El prompt caching para system prompts y contexto repetidos reduce aún más los cargos por tokens de entrada. Empieza por auditar qué casos de uso realmente requieren un modelo grande y migra todo lo demás al modelo más pequeño que cumpla con tu estándar de calidad.
¿Cómo se compara el provisioned throughput de Amazon Bedrock con los Precios on-demand?
On-demand cobra por token procesado sin compromiso. El provisioned throughput reserva capacidad dedicada a una tarifa fija por hora, facturada uses esa capacidad o no. El provisioned se vuelve costo-eficiente con niveles de utilización altos y consistentes, normalmente cuando los costos on-demand superarían la tarifa del compromiso por hora. Para los modelos personalizados y con fine-tuning, el provisioned throughput es obligatorio sin importar el volumen. On-demand es la opción adecuada por defecto para workloads variables, aplicaciones en etapa temprana y cualquier caso de uso donde los patrones de uso aún no sean predecibles.
¿Cómo afectan los tokens de entrada y de salida a los costos de Amazon Bedrock?
Los tokens de entrada y de salida tienen Precios separados, y los tokens de salida suelen costar entre tres y cinco veces más por millón que los de entrada. Esto significa que la verbosidad de la salida, cuánto se le pide al modelo que produzca por solicitud, tiene un impacto desproporcionado en tu factura. Las aplicaciones que solicitan explicaciones detalladas, contenido extenso o salidas estructuradas verbosas se inclinarán fuertemente hacia los costos de tokens de salida. Diseñar prompts que limiten la longitud de la salida sin sacrificar la calidad es un control directo de costos.
¿Amazon Bedrock cobra por las llamadas a la API que fallan?
Bedrock cobra por los tokens que se procesan con éxito. Las solicitudes que fallan antes de que comience la inferencia, como errores de autenticación o solicitudes con throttling, no generan cargos por tokens. Sin embargo, los reintentos de llamadas fallidas que llegan a la inferencia antes de fallar, por ejemplo por violaciones de longitud de contexto, pueden generar cargos parciales. Monitorear las tasas de reintento y los modos de falla es parte de una gestión responsable de costos.
¿Qué herramientas ayudan a rastrear y controlar el gasto en Amazon Bedrock?
AWS Cost Explorer muestra el gasto en Bedrock a nivel de servicio, y AWS Budgets puede alertar sobre umbrales de costo. CloudWatch captura métricas de invocación. Para visibilidad a nivel de token, es esencial el logging del lado de la aplicación de los conteos de tokens de entrada y salida por solicitud. El etiquetado de recursos por aplicación, equipo y entorno permite la asignación de costos. Plataformas como DoiT Cloud Intelligence ofrecen analítica de costos de IA en tiempo real y detección automatizada de anomalías en todo tu uso de Bedrock.