Módulo 2: The Bedrock Cost Model
2. Cómo se cobra Bedrock: on-demand, Provisioned Throughput, Batch, Flex, Priority
Descripción
Bedrock no tiene un solo modelo de precio — tiene cinco, y elegir el correcto para extract-shipment-manifest-fields es una decisión de arquitectura, no un detalle administrativo. Esta lección los nombra los cinco, con cifras citadas de la página oficial de precios de AWS y del catálogo público de precios de Bedrock, verificadas en el momento de escribir esta guía — nunca memorizadas de una versión anterior de esta página, porque, como advirtió la lección 1, estos números cambian.
Conexión con el módulo
La lección 1 instaló la intuición: Bedrock cobra por token, no por hora. Esta lección le pone números exactos a esa intuición, y agrega una pieza que la lección 1 todavía no mencionó: no hay un solo precio por token — hay cinco estructuras de precio distintas, cada una pensada para un patrón de uso diferente. La lección 3, inmediatamente después, agrega la pieza que ningún precio cubre: el límite de cuánto puedes invocar por minuto, sin importar cuánto estés dispuesto a pagar.
Los cinco modelos de precio, de un vistazo
LOS CINCO MODELOS DE PRECIO DE BEDROCK
On-Demand Pagas por token, cuando lo usas. Sin compromiso,
sin reserva. El default de esta guía.
Batch Igual que On-Demand, pero procesado en lote,
de forma asíncrona (no en tiempo real).
~50% más barato que On-Demand.
Flex Precio reducido a cambio de tolerar más
latencia -- Bedrock puede demorar la respuesta
si el sistema está ocupado. ~50% más barato
que On-Demand.
Priority Lo opuesto de Flex: pagas una prima por
garantizar menor latencia bajo carga.
~75% más caro que On-Demand.
Provisioned Throughput Reservas capacidad por hora, a un precio fijo,
sin importar cuántos tokens proceses con ella.
El único de los cinco que vuelve a parecerse
a "prendido = cuesta".On-Demand: el default, pagado por token real
On-Demand es exactamente lo que la lección 1 describió: pagas, por millón de tokens, un precio de entrada y un precio de salida distintos, sin ningún compromiso previo. No reservas nada, no te comprometes a un volumen mínimo, y no hay descuento por usar más — cada token cuesta lo mismo que el anterior. Es el modelo de precio que extract-shipment-manifest-fields usa por defecto en esta guía, y el que la calculadora de la lección 7 modela.
Precios citados, verificados contra el catálogo oficial de AWS al momento de escribir esta guía (agosto de 2026, us-east-1):
| Modelo | Precio de entrada (por 1M tokens) | Precio de salida (por 1M tokens) |
|---|---|---|
| Amazon Nova Micro | $0.035 | $0.14 |
| Amazon Nova Lite | $0.06 | $0.24 |
| Amazon Nova Pro | $0.80 | $3.20 |
| Amazon Nova Premier | $2.50 | $12.50 |
Fíjate en dos cosas antes de seguir. Primero, el precio de salida siempre es más alto que el de entrada para el mismo modelo — típicamente entre 4 y 5 veces más, en toda la tabla de arriba. Esto no es casualidad: generar texto (salida) es computacionalmente más costoso para el modelo que leerlo (entrada), y el precio lo refleja. Segundo, la diferencia entre el modelo más barato de la tabla (Nova Micro) y el más caro (Nova Premier) es de más de 70 veces en el precio de entrada, y casi 90 veces en el de salida — la elección de modelo, no solo el volumen, es la palanca de costo más grande que Andes Cargo controla, exactamente el criterio que el Módulo 1, lección 6 ya instaló sin darle números.
Cómo se verificó esta tabla. Los cuatro precios de Nova se extrajeron directamente del catálogo público de precios de AWS (la misma API que alimenta la página oficial de precios), consultado en vivo el 13 de agosto de 2026 — no de un tutorial de terceros ni de la memoria de entrenamiento de quien escribe esta guía. Todos estos números están marcados VARIABLE — van a cambiar. La fuente para verificar el precio vigente el día que lo necesites siempre es aws.amazon.com/bedrock/pricing/, nunca esta lección.
Batch: el mismo precio con la mitad de descuento, sin tiempo real
Batch reduce el precio On-Demand aproximadamente a la mitad, a cambio de una condición: el procesamiento no es en tiempo real — se envía como un trabajo asíncrono que Bedrock procesa cuando tiene capacidad disponible, típicamente en un plazo de horas, no segundos. Verificado contra el mismo catálogo de precios:
| Modelo | Precio de entrada Batch (por 1M tokens) | Precio de salida Batch (por 1M tokens) | Descuento vs. On-Demand |
|---|---|---|---|
| Amazon Nova Micro | $0.0175 | $0.07 | 50% |
| Amazon Nova Lite | $0.03 | $0.12 | 50% |
| Amazon Nova Pro | $0.40 | $1.60 | 50% |
| Amazon Nova Premier | — | $6.25 | 50% |
El descuento del 50% se confirma, exacto, en cada fila de esta tabla contra la fila correspondiente de On-Demand de arriba. Para extract-shipment-manifest-fields, Batch no es una opción realista — el flujo completo de Andes Cargo es: un manifiesto en texto libre llega, process-shipment-manifest falla en parsearlo, publica ManifestParseFailed, y extract-shipment-manifest-fields necesita responder en el mismo ciclo de procesamiento del envío, no horas después. Batch tiene sentido para cargas que sí toleran ese retraso — por ejemplo, si Andes Cargo alguna vez necesitara reprocesar en bloque miles de manifiestos históricos, no manifiestos que llegan uno por uno en producción.
Flex: el mismo descuento, con una condición distinta
Flex también reduce el precio aproximadamente a la mitad, pero con una condición diferente a Batch: la solicitud sigue siendo síncrona (esperas la respuesta en la misma llamada), pero Bedrock puede demorarla si el sistema está bajo carga alta — no hay garantía de latencia. Verificado contra Nova Pro, el único modelo de la tabla de arriba donde se confirmó una entrada Flex explícita en el catálogo:
| Modelo | Precio de entrada Flex (por 1M tokens) | Precio de salida Flex (por 1M tokens) | Descuento vs. On-Demand |
|---|---|---|---|
| Amazon Nova Pro | $0.40 | $1.60 | 50% |
Para una tarea como extract-shipment-manifest-fields — extraer campos de un manifiesto para completar el procesamiento de un envío — la latencia sí importa: el envío está esperando ese resultado para continuar su flujo. Flex sería razonable si Andes Cargo decidiera, más adelante, que el camino de escalamiento puede tolerar unos segundos adicionales de demora a cambio de la mitad del costo — una decisión de negocio, no técnica, que esta guía nombra sin tomarla.
Priority: la prima por garantizar menor latencia
Priority es lo opuesto de Flex: paga una prima — verificada en +75% sobre el precio On-Demand — a cambio de una prioridad más alta en la cola de procesamiento de Bedrock, con menor latencia esperada bajo carga.
| Modelo | Precio de entrada Priority (por 1M tokens) | Precio de salida Priority (por 1M tokens) | Prima vs. On-Demand |
|---|---|---|---|
| Amazon Nova Pro | $1.40 | $5.60 | +75% |
| Amazon Nova Premier | $4.375 | $21.875 | +75% |
El +75% se confirma exacto en ambas filas: $0.80 × 1.75 = $1.40 (Nova Pro, entrada); $3.20 × 1.75 = $5.60 (Nova Pro, salida). Priority tendría sentido si extract-shipment-manifest-fields alguna vez se volviera parte de un flujo con un SLA de latencia estricto y contractual — por ejemplo, si un socio logístico grande exigiera confirmación de envío en menos de un segundo garantizado. Con el volumen y la criticidad actual de Andes Cargo (un camino de escalamiento, no el default, según ADR-001), pagar una prima del 75% por garantía de latencia no está justificado todavía — otra decisión que esta guía nombra, no toma por Andes Cargo.
Provisioned Throughput: el único que vuelve a "prendido = cuesta"
Provisioned Throughput rompe el patrón de los otros cuatro: en vez de pagar por token, reservas capacidad de cómputo dedicada — medida en "Model Units" — por hora, a un precio fijo que no depende de cuántos tokens proceses con esa capacidad. Es, de los cinco, el único modelo de precio de Bedrock que se parece a lo que EC2 ya te enseñó: pagas por el tiempo que la capacidad existe, la uses o no.
Precios citados, verificados contra el catálogo oficial (por Model Unit, por hora, us-east-1, idénticos en este momento para Nova Micro, Nova Lite y Nova Pro):
| Compromiso | Precio por Model Unit / hora |
|---|---|
| Sin compromiso | $60.50 |
| Compromiso de 1 mes | $55.00 |
| Compromiso de 6 meses | $30.25 |
Fíjate en algo real y verificado: los tres modelos de Nova en esta tabla —Micro, Lite y Pro, con precios On-Demand que difieren hasta 20 veces entre sí— tienen exactamente el mismo precio de Provisioned Throughput por Model Unit. Esto tiene sentido una vez que entiendes qué compras: no compras "tokens de un modelo específico a un precio distinto", compras capacidad de cómputo dedicada — el precio por hora refleja el costo de esa capacidad, no el modelo que corre encima. Provisioned Throughput tiene sentido cuando el volumen sostenido de invocaciones es tan alto que el costo por hora reservada termina siendo menor que la suma de miles de invocaciones On-Demand — el Módulo 6, lección 7 de esta guía vuelve sobre esta comparación con números reales aplicados al volumen específico de Andes Cargo.
Cuándo tiene sentido cada uno: el criterio, no la moda
¿QUÉ MODELO DE PRECIO ELEGIR?
¿Necesita respuesta en tiempo real (síncrona)?
│
NO ────────────► Batch (~50% más barato, horas de espera OK)
│
SÍ
│
¿Tolera latencia variable bajo carga?
│
SÍ ────────────► Flex (~50% más barato, sin garantía de latencia)
│
NO
│
¿El volumen sostenido justifica capacidad reservada?
│
SÍ ────────────► Provisioned Throughput (precio fijo por hora,
│ sin importar el volumen -- el Módulo 6 hace
│ la cuenta exacta de dónde está ese punto)
│
NO
│
¿Hay un SLA contractual de latencia mínima?
│
SÍ ────────────► Priority (+75%, garantiza prioridad en la cola)
│
NO
│
▼
On-Demand (el default de esta guía para extract-shipment-manifest-fields)Para extract-shipment-manifest-fields, tal como ADR-001 lo definió — un camino de escalamiento síncrono, de bajo volumen inicial, sin SLA contractual todavía —, On-Demand es la decisión correcta, y es la que la calculadora de la lección 7 y el GENAI-COST-PROFILE.md de la lección 8 usan como base. Esto no es una elección permanente: si el volumen creciera lo suficiente, Provisioned Throughput entraría en la conversación con números reales, exactamente como el Módulo 6, lección 7 lo desarrolla.
Errores comunes
Asumir que Batch y Flex son intercambiables porque ambos dan ~50% de descuento (de simplificación). Qué pasa: alguien lee "ambos son ~50% más baratos" y concluye que son la misma opción con nombre distinto. Cómo detectarlo: si tu pregunta es "¿cuál de los dos uso, Batch o Flex?", sin considerar la diferencia de mecanismo. Cómo corregirlo: Batch es asíncrono (envías un trabajo, lo recoges horas después); Flex es síncrono con latencia variable (esperas la respuesta en la misma llamada, pero puede demorar más bajo carga). Para extract-shipment-manifest-fields, que necesita responder dentro del mismo flujo de procesamiento de un envío, Batch queda descartado por diseño — Flex sigue siendo, al menos técnicamente, una opción síncrona.
Pensar que Provisioned Throughput siempre es más caro porque "reservar" suena a comprometerse de más (de intuición sin números). Qué pasa: alguien descarta Provisioned Throughput de entrada, asumiendo que pagar por hora reservada siempre sale más caro que pagar solo por lo que se usa. Cómo detectarlo: si tu razonamiento es "pagar por adelantado siempre es peor que pagar por uso", sin haber hecho la cuenta cruzada. Cómo corregirlo: a volumen suficientemente alto y sostenido, el costo total de miles de invocaciones On-Demand puede superar el costo de una capacidad reservada por hora — es exactamente la misma lógica que ya viste con instancias reservadas de EC2 frente a on-demand, aplicada aquí a Bedrock. El punto de cruce depende del volumen real, no de una regla general; el Módulo 6, lección 7 hace esa cuenta con los números de Andes Cargo.
Memorizar los números de esta lección como si fueran permanentes (de expectativa, el mismo error que la lección 6 del Módulo 1 ya nombró para el catálogo de modelos). Qué pasa: alguien, meses después de leer esta guía, sigue citando "$0.06 por millón de tokens de entrada de Nova Lite" como si fuera un hecho fijo. Cómo detectarlo: si estás tomando una decisión de presupuesto real basada en un número de esta lección sin haberlo verificado de nuevo. Cómo corregirlo: cada precio de esta lección está marcado VARIABLE por una razón explícita — verifica contra aws.amazon.com/bedrock/pricing/ el día que necesites el número real, exactamente la misma disciplina que finops-and-cost-guardrails-guide ya exigió para los precios de S3, Lambda y DynamoDB.
Ejercicios
Ejercicio 1 — Calcula, sin la calculadora de la lección 7, el descuento exacto de Batch sobre Nova Lite. Usando la tabla On-Demand y la tabla Batch de esta lección, calcula el porcentaje exacto de descuento del precio de entrada de Nova Lite en Batch frente a On-Demand. ¿Coincide con el 50% citado?
Ver solución
On-Demand, entrada, Nova Lite: $0.06 por millón de tokens. Batch, entrada, Nova Lite: $0.03 por millón de tokens. $0.03 / $0.06 = 0.5, es decir, exactamente 50% del precio On-Demand — un descuento del 50%, coincide exacto con lo citado. La misma proporción se sostiene en la columna de salida ($0.24 → $0.12) y en las demás filas de Nova de la tabla — el 50% no es una aproximación de mercadeo, es la proporción real y consistente en todo el catálogo verificado.
Ejercicio 2 — Explica, con tus propias palabras, por qué Nova Micro, Nova Lite y Nova Pro comparten el mismo precio de Provisioned Throughput por hora, a pesar de tener precios On-Demand muy distintos entre sí. Un colega, viendo la tabla de Provisioned Throughput, pregunta por qué el modelo más grande (Nova Pro) no cuesta más por hora reservada que el más chico (Nova Micro). Explícale la razón.
Ver solución
Provisioned Throughput no vende "tokens de un modelo específico" — vende capacidad de cómputo dedicada, medida en Model Units, independientemente de qué modelo corre sobre esa capacidad. El precio por Model Unit por hora refleja el costo de esa infraestructura reservada, no las diferencias de tamaño o capacidad entre Nova Micro y Nova Pro. La diferencia entre esos modelos, en un escenario de Provisioned Throughput, se expresaría en cuántas Model Units necesita cada uno para sostener el mismo volumen de tokens por minuto (un modelo más grande probablemente necesita más Model Units para el mismo throughput), no en un precio por unidad distinto.
Ejercicio 3 — Justifica, citando ADR-001, por qué esta lección elige On-Demand como el modelo de precio de extract-shipment-manifest-fields, y no Priority. Alguien en el equipo de Andes Cargo propone usar Priority desde el día uno, "para que los envíos con manifiestos en texto libre se procesen más rápido". Usa el criterio de ADR-001 para responder si eso está justificado hoy.
Ver solución
ADR-001 define extract-shipment-manifest-fields explícitamente como un camino de escalamiento, no el default — se invoca solo cuando el parser determinista ya falló, y se espera que sea una fracción minoritaria del tráfico total de manifiestos. Priority tiene sentido cuando existe un SLA contractual de latencia mínima que justifica pagar una prima del 75% — Andes Cargo, en el estado actual de esta guía, no tiene ese compromiso contractual declarado en ningún documento anterior. Pagar Priority "por si acaso" contradice directamente la disciplina de ADR-001: la decisión de arquitectura completa de esta guía es evitar gastar de más en el camino que ya es, por diseño, el más caro del sistema. La respuesta correcta es empezar con On-Demand, y reconsiderar Priority solo si aparece, con evidencia, un requisito real de latencia garantizada — no antes.
Resumen y siguiente paso
Esta lección citó los cinco modelos de precio reales de Bedrock, con cifras verificadas en vivo contra el catálogo oficial de AWS: On-Demand (el default, pagado por token, sin compromiso), Batch (~50% más barato, asíncrono), Flex (~50% más barato, latencia variable), Priority (+75%, prioridad garantizada), y Provisioned Throughput (precio fijo por hora de capacidad reservada, el único que vuelve a parecerse a "prendido = cuesta"). Confirmaste, con la tabla exacta, que On-Demand es la decisión correcta para extract-shipment-manifest-fields según el criterio de ADR-001 — un camino de escalamiento, no un servicio con SLA contractual todavía.
Antes de avanzar deberías poder: nombrar los cinco modelos de precio y el patrón de uso que cada uno favorece; calcular, dado un precio On-Demand, el precio aproximado en Batch/Flex/Priority sin consultar una tabla; y explicar por qué Provisioned Throughput es el único de los cinco que no depende del contenido de cada invocación individual.
La lección 3 agrega la pieza que ningún modelo de precio de esta lección cubre: el límite de cuántas invocaciones por minuto tu cuenta puede hacer, sin importar cuánto estés dispuesto a pagar — el límite que ninguna factura muestra.
Recursos
- AWS — Amazon Bedrock Pricing — la fuente oficial de todos los precios de esta lección; verifica aquí el número vigente antes de cualquier decisión real.
- AWS Price List API — Amazon Bedrock — el catálogo de precios programático, la fuente primaria consultada para los precios de Nova de esta lección (
us-east-1, publicado 2026-08-13). - AWS Docs — Increase model invocation capacity with Provisioned Throughput in Amazon Bedrock — referencia oficial de Provisioned Throughput, retomada con números aplicados en el Módulo 6, lección 7.
- Este módulo, lección 1 — la analogía de itinerancia que esta lección le pone números.