Módulo 2: The Bedrock Cost Model
1. Introducción: precio por token, no por hora
Descripción
ADR-001-llm-as-escalation-path.md, el documento que cerró el Módulo 1, dejó una fila de su propia tabla apuntando directamente a este módulo: "M2 — The Bedrock cost model | Prices the escalation path per token before a single resource is declared, so cost is a known input, not a surprise". Esta lección abre esa fila. Antes de declarar un solo recurso de Terraform (eso es el Módulo 3), antes de escribir un guardrail (Módulo 4), Andes Cargo necesita contestar una pregunta que ninguna de las siete guías anteriores de este ecosistema tuvo que responder de esta forma: ¿cuánto cuesta invocar un modelo de Bedrock, y por qué esa pregunta rompe la intuición que EC2, Lambda y DynamoDB ya te enseñaron?
Conexión con el módulo
Esta es la primera lección de ocho. Su trabajo es instalar, con un ejemplo concreto, la diferencia de fondo entre "pagar por tener algo prendido" y "pagar por lo que ese algo procesó" — la distinción que las lecciones 2 a 8 de este módulo van a desarrollar en detalle: los cinco modelos de precio reales de Bedrock (lección 2), el límite de cuota que ninguna factura muestra (lección 3), Infracost heredado y su intento honesto contra un recurso de Bedrock (lecciones 4 y 5), por qué esa herramienta no puede resolver esto sola (lección 6), la calculadora propia que sí lo resuelve (lección 7), y el documento que cierra el módulo con la decisión final de modelo y volumen (lección 8).
El mapa de este módulo: las 8 lecciones
M2 -- EL MODELO DE COSTO DE BEDROCK
1 Introducción precio por token, no por hora (esta lección)
2 Cómo se cobra Bedrock 5 modelos de precio reales, citados de AWS
3 Cuotas de Bedrock el límite que ninguna factura muestra
4 Manos a la obra: Infracost heredado --version / --help, cero reinstalación
5 Manos a la obra: el intento honesto infracost scan sobre bedrock.tf, de verdad
6 Por qué Infracost no puede solo ningún plan describe un supuesto de volumen
7 Manos a la obra: la calculadora propia bedrock_cost_estimate.py + pytest, determinista
8 Proyecto: GENAI-COST-PROFILE.md modelo elegido, volumen declarado, proyección| # | Lección | Qué practicas |
|---|---|---|
| 1 | Introducción (esta) | Por qué el costo de una carga de IA rompe la intuición "prendido = cuesta" |
| 2 | Cómo se cobra Bedrock | On-Demand, Provisioned Throughput, Batch, Flex, Priority — con precios citados |
| 3 | Cuotas de Bedrock | Invocaciones/tokens por minuto, nombrado, sin poder verificarse contra una cuenta real |
| 4 | Manos a la obra: Infracost heredado | Ejecutado: infracost --version, infracost scan --help |
| 5 | Manos a la obra: el intento honesto | Ejecutado (el intento) + representativo (el número): infracost scan andes-cargo-infra/ |
| 6 | Por qué Infracost no puede solo | Ningún recurso de Terraform describe "una invocación" |
| 7 | Manos a la obra: la calculadora propia | Ejecutado: bedrock_cost_estimate.py, corrido con pytest sobre casos fijos |
| 8 | Proyecto: GENAI-COST-PROFILE.md | Ejecutado (el documento): modelo, volumen, proyección — el entregable del módulo |
Fíjate en la progresión: primero entiendes cómo se factura algo que nunca facturaste antes (lecciones 2 y 3), después confirmas, de verdad, hasta dónde llega la herramienta que ya confías (lecciones 4 a 6), y cierras construyendo la pieza que faltaba (lecciones 7 y 8) — la misma disciplina de "entender antes de automatizar" que finops-and-cost-guardrails-guide ya aplicó a S3, Lambda y DynamoDB, ahora un nivel más difícil.
Analogía: la tarifa de itinerancia, no el plan fijo mensual
Cuando contratas un plan de telefonía celular con datos ilimitados en tu país, sabes exactamente qué vas a pagar cada mes — el número está fijo antes de usar un solo megabyte, y usar más o menos no cambia la factura. Ese es el modelo mental que EC2, y en buena medida Lambda y DynamoDB con capacidad reservada, ya te enseñaron: aprovisionas algo, y el costo se deriva del tiempo que ese algo existe, no de lo que hace en ese tiempo.
Ahora imagina que ese mismo teléfono cruza una frontera y activa itinerancia internacional. De repente, el plan fijo desaparece: cada megabyte que consumes tiene un precio individual, ese precio depende de qué país visitas y qué operador te atiende, y no hay forma de saber el total de la factura hasta que termina el mes — a menos que hagas la cuenta tú mismo, con un supuesto explícito de cuántos megabytes vas a usar. Nadie te manda una alerta a mitad del viaje diciendo "ya llevas $40 en itinerancia" a menos que lo hayas configurado tú.
Invocar un modelo de Bedrock es, en su estructura de costo, exactamente itinerancia, no plan fijo. No pagas por tener el modelo "prendido" — no lo prendes ni lo apagas, es un servicio gestionado por AWS que existe todo el tiempo para todos sus clientes. Pagas, por token, cada vez que le mandas texto y cada vez que te devuelve texto — y el tamaño de esa factura depende enteramente de cuánto texto entra y sale, un número que no vive en ningún archivo de Terraform, exactamente igual que "cuántos megabytes vas a consumir este viaje" no vive en el contrato de tu plan celular.
Por qué esto rompe la intuición que las siete guías anteriores instalaron
Repasa, un momento, lo que cada pieza de infraestructura de Andes Cargo te enseñó sobre costo hasta ahora:
LA PROGRESIÓN DE MODELOS DE COSTO QUE ANDES CARGO YA CONOCE
EC2 (nombrado, no construido en este ecosistema)
│ Pagas por HORA que la instancia existe.
│ 0 solicitudes procesadas cuesta lo mismo que 1 millón.
▼
Lambda (process-shipment-manifest)
│ Pagas por INVOCACIÓN + DURACIÓN.
│ 0 invocaciones = $0. El costo por invocación es predecible
│ (memoria fija × duración típica), aunque el TOTAL depende
│ de cuántas invocaciones ocurran.
▼
DynamoDB PAY_PER_REQUEST (Shipments)
│ Pagas por UNIDAD DE LECTURA/ESCRITURA.
│ Mismo patrón que Lambda: costo por unidad predecible,
│ total depende del volumen real.
▼
Bedrock (extract-shipment-manifest-fields, desde este módulo)
│ Pagas por TOKEN, de entrada y de salida, por separado.
│ El costo de UNA SOLA invocación ya no es fijo -- depende
│ de cuánto texto tiene el manifiesto que llegó y cuánto
│ texto genera el modelo al responder. Ni siquiera el costo
│ "por unidad" es una constante conocida de antemano.finops-and-cost-guardrails-guide ya te preparó para la mitad de este salto: Lambda y DynamoDB en modo bajo demanda ya son usage-based — el costo depende de cuánto tráfico real ocurre, no de cuánto tiempo existe el recurso. Ese módulo, en su lección 6, construyó infracost-usage.yml precisamente para declarar ese volumen y convertir una tarifa en un número. Bedrock lleva esa misma lógica un paso más allá, y este es el paso que rompe algo nuevo: ni siquiera el costo por unidad de una sola invocación es una constante fija. Una llamada a Lambda siempre factura la misma fórmula (memoria × duración típica); una llamada a Bedrock factura según el contenido real de esa llamada específica — un manifiesto de tres líneas cuesta una fracción de lo que cuesta uno de tres párrafos, aunque las dos sean, técnicamente, "una invocación". La lección 6 de este módulo vuelve sobre este punto exacto, con el vocabulario preciso de por qué eso deja a Infracost sin ningún recurso de Terraform al que pueda apuntar.
Lo que este módulo NO hace todavía
Esta lección, y las dos siguientes, son deliberadamente conceptuales — panorama de precio, panorama de cuota. Ningún comando corre todavía contra andes-cargo-infra/. Eso empieza en la lección 4, con Infracost heredado, y se profundiza en la lección 5, con el intento real de infracost scan contra un bedrock.tf recién declarado — el primero de esta guía entera, porque, como confirmó el cierre del Módulo 1, ni bedrock.tf existía todavía al terminar la lección anterior. Esta guía no construye la infraestructura completa de la carga de IA en este módulo — eso es el Módulo 3 — pero sí necesita una versión mínima, deliberadamente pequeña, para poder hacerle a Infracost la pregunta honesta que este módulo entero existe para contestar.
Errores comunes
Asumir que "usage-based" ya significa lo mismo que aprendiste con Lambda y DynamoDB, sin matiz nuevo (de generalización prematura). Qué pasa: alguien, familiarizado con PAY_PER_REQUEST de DynamoDB, asume que Bedrock es "lo mismo, con otro nombre" y salta directo a construir sin leer las lecciones 2 y 3. Cómo detectarlo: si tu expectativa es que la lección 7 de este módulo se va a parecer, en estructura, a infracost-usage.yml de finops-and-cost-guardrails-guide. Cómo corregirlo: hay una diferencia real, no cosmética — Lambda y DynamoDB tienen un costo por unidad fijo (aunque el total dependa del volumen); Bedrock no. El costo de una sola invocación de Bedrock varía con el contenido de esa invocación específica. La lección 6 de este módulo formaliza exactamente esa diferencia.
Pensar que "Bedrock cobra por token" significa que hay un solo precio por token para todo el catálogo (de simplificación). Qué pasa: alguien lee "cobra por token" y asume que ese precio es una constante universal, como si fuera una sola tarifa que aplica igual sin importar qué modelo invocas. Cómo detectarlo: si tu pregunta es "¿cuánto cuesta un token en Bedrock?", sin especificar de qué modelo. Cómo corregirlo: cada familia y tamaño de modelo del catálogo del Módulo 1, lección 6 (Nova Micro, Nova Lite, Nova Pro, Claude, Llama, Mistral) tiene su propio precio por millón de tokens, de entrada y de salida por separado — la lección 2 de este módulo cita los números exactos, verificados, no memorizados.
Confundir "no hay servidor que administrar" con "no hay nada que costee" (de intuición serverless mal aplicada). Qué pasa: alguien, acostumbrado a pensar en Lambda como "barato porque es serverless", asume que Bedrock hereda esa misma economía de escala automáticamente. Cómo detectarlo: si tu supuesto de partida es "como no administro un servidor, el costo va a ser marginal, igual que con Lambda para bajo volumen". Cómo corregirlo: la ausencia de servidor administrado (cierta para Bedrock, igual que para Lambda) no dice nada sobre el precio por unidad de trabajo. Un token de un modelo grande puede costar órdenes de magnitud más que una invocación completa de Lambda — el Módulo 2, lección 2 pone los números exactos uno al lado del otro para que esta comparación deje de ser una intuición y se vuelva una decisión informada.
Ejercicios
Ejercicio 1 — Explica, sin usar la palabra "prendido", la diferencia entre el modelo de costo de EC2 y el de Bedrock. Un colega, familiarizado con EC2 pero nunca con Bedrock, te pregunta cómo se factura un modelo de lenguaje. Respóndele en dos frases, sin usar la palabra "prendido" ni "apagado".
Ver solución
Una respuesta completa suena, más o menos, así: "EC2 te cobra por cuánto tiempo existe la instancia, sin importar cuánto trabajo real hizo en ese tiempo. Bedrock no tiene ningún concepto de 'tiempo que existe' — no lo aprovisionas ni lo liberas — y te cobra, en cambio, por la cantidad de texto que le mandas y que te devuelve en cada llamada individual, así que el costo depende enteramente del contenido de lo que procesas, no de cuánto tiempo pasa."
Ejercicio 2 — Ubica dónde, en la progresión de la infraestructura de Andes Cargo, aparece por primera vez un costo que varía con el CONTENIDO de una sola operación, no solo con su volumen. Repasa el diagrama de esta lección (EC2 → Lambda → DynamoDB → Bedrock) y explica qué distingue al último escalón de los tres anteriores.
Ver solución
Lambda y DynamoDB, aunque son usage-based (el total depende de cuántas invocaciones o solicitudes ocurren), tienen un costo por unidad fijo: cada invocación de process-shipment-manifest cuesta lo mismo en la fórmula de Lambda (memoria configurada × duración típica), y cada PutItem en Shipments cuesta lo mismo por unidad de escritura, sin importar qué datos específicos contiene ese ítem. Bedrock rompe eso: dos invocaciones de extract-shipment-manifest-fields, ambas "una sola llamada", pueden costar montos completamente distintos entre sí si un manifiesto es más largo que el otro — el costo por unidad individual ya no es una constante, depende del contenido específico de esa llamada.
Ejercicio 3 — Predice qué va a necesitar Andes Cargo declarar, además del volumen mensual, para poder estimar el costo de extract-shipment-manifest-fields con precisión. Basándote en la analogía de esta lección (itinerancia, no plan fijo), y sin haber leído todavía la lección 7, ¿qué otro dato —más allá de "cuántos manifiestos al mes"— crees que va a hacer falta declarar?
Ver solución
Hace falta, además del volumen mensual (cuántas veces se invoca el modelo), el tamaño promedio de cada invocación — específicamente, cuántos tokens de entrada tiene un manifiesto típico y cuántos tokens de salida produce el modelo al responder con los campos extraídos. Es exactamente la analogía de itinerancia llevada a su conclusión lógica: no basta con saber "cuántos días vas a estar de viaje" (el equivalente de volumen mensual), también hace falta saber "cuántos megabytes consumes por día" (el equivalente de tokens por invocación) para poder proyectar un total. La lección 7 de este módulo construye la calculadora exactamente con esos dos ejes — tokens por invocación y volumen declarado — como sus entradas explícitas.
Resumen y siguiente paso
Esta lección instaló la tesis central de este módulo: el costo de Bedrock no es "prendido = cuesta", ni siquiera es exactamente el mismo tipo de usage-based que ya conociste con Lambda y DynamoDB — es un costo que varía con el contenido de cada invocación individual, no solo con cuántas invocaciones hay. Viste el mapa completo de las ocho lecciones que siguen, y la analogía que las va a atravesar: itinerancia internacional, no plan fijo mensual — pagas por lo que realmente cruza la frontera, y nadie te avisa el total hasta que haces la cuenta tú mismo.
Antes de avanzar deberías poder: explicar en una frase por qué Bedrock rompe la intuición de "prendido = cuesta" incluso más que Lambda o DynamoDB; nombrar los ocho temas de este módulo en orden; y anticipar que vas a necesitar, al menos, dos tipos de dato distintos (tamaño por invocación, volumen de invocaciones) para poder estimar un costo real.
La lección 2 hace el trabajo concreto que esta lección dejó en el nivel de intuición: los cinco modelos de precio reales de Bedrock, con cifras citadas directamente de AWS, verificadas en este mismo momento de escritura — no memorizadas de una versión anterior de esta página.
Recursos
- AWS — Amazon Bedrock Pricing — la fuente que la lección 2 desarrolla en detalle.
finops-and-cost-guardrails-guide, Módulo 1 y Módulo 2 — la base de vocabulario usage-based (infracost-usage.yml) que este módulo extiende un nivel más allá.ADR-001-llm-as-escalation-path.md(Módulo 1, lección 8, esta misma guía) — el documento que le asigna a este módulo la responsabilidad de fijar el costo del camino de escalamiento.