Módulo 2: The Bedrock Cost Model
3. Cuotas de Bedrock: el límite que ninguna factura muestra
Descripción
La lección 2 contestó "¿cuánto cuesta invocar Bedrock?". Esta lección contesta una pregunta distinta, que ningún precio de la lección anterior menciona: ¿cuántas veces por minuto puedes invocarlo, sin importar cuánto estés dispuesto a pagar? Una cuota (quota) de AWS es un límite de tasa —no de dinero—, y Bedrock tiene cuotas propias, documentadas, verificadas contra la documentación oficial de AWS en el momento de escribir esta guía. Esta lección las nombra con precisión, incluida una honestidad que vale la pena decir de entrada: el número exacto que le corresponde a tu cuenta específica no está publicado en ningún documento estático — vive únicamente en la consola de Service Quotas de tu propia cuenta AWS, algo que este laboratorio $0 no puede verificar.
Conexión con el módulo
Las lecciones 1 y 2 dieron el modelo de costo completo. Esta lección cierra el bloque conceptual del módulo con la pieza que un presupuesto, por generoso que sea, no puede comprar: velocidad de invocación. Las lecciones 4 a 6 vuelven a terreno ejecutable — Infracost, heredado y puesto a prueba contra un recurso de Bedrock real.
Qué es una cuota, y por qué no es lo mismo que un precio
Un precio te dice cuánto cuesta cada unidad. Una cuota te dice cuántas unidades por minuto tu cuenta tiene permitido consumir, sin importar si tienes el dinero para pagar más. Son dos preguntas completamente independientes: puedes tener un presupuesto mensual de $10,000 sin usar ni un 1% de él, y aun así recibir un error de ThrottlingException si intentas invocar un modelo más rápido de lo que tu cuota permite en un minuto específico. Es la misma disciplina de separar "cuánto cuesta" de "cuánto puedo hacer" que ya viste, con otro nombre, en finops-and-cost-guardrails-guide cuando distinguió el costo de un recurso de su comportamiento operativo bajo carga.
DOS PREGUNTAS INDEPENDIENTES, DOS RESPUESTAS DISTINTAS
"¿Cuánto cuesta una invocación?" --> Lección 2 (precio por token)
"¿Cuántas invocaciones puedo hacer
en un minuto?" --> Esta lección (cuota)
Tener presupuesto sobrante no aumenta tu cuota.
Tener cuota sobrante no reduce tu factura.Los tipos de cuota que Bedrock aplica, verificados contra AWS Docs
La documentación oficial de Bedrock (docs.aws.amazon.com/bedrock/latest/userguide/quotas-runtime.html, verificada en el momento de escribir esta guía) describe las cuotas del endpoint bedrock-runtime —el que usa extract-shipment-manifest-fields para invocar un modelo— con esta estructura, citada casi textual:
| Tipo de cuota | Alcance | Qué mide |
|---|---|---|
| On-demand InvokeModel tokens per minute | Por modelo, por región | Tokens de entrada + salida, combinados, que tu cuenta puede procesar por minuto, invocando en una sola región |
| Cross-Region InvokeModel tokens per minute | Por modelo, por región | La misma medida, pero para invocaciones a través de un perfil de inferencia entre regiones — una cuota separada de la anterior |
| Model invocation max tokens per day | Por modelo, por región | Por defecto, la cuota por minuto multiplicada por 24 × 60 — el techo diario |
| InvokeModel requests per minute | Por modelo, por región | Cuántas solicitudes (no tokens) por minuto — pero, según la documentación oficial, no todos los modelos tienen esta cuota: algunos se gobiernan únicamente por tokens por minuto |
Fíjate en dos detalles verificados que cambian cómo lees cualquier cifra de cuota que encuentres: primero, la cuota de tokens por minuto cuenta entrada y salida juntas contra un solo límite — no son dos cuotas separadas, como sí lo son en otro endpoint distinto de Bedrock (bedrock-mantle, fuera del alcance de esta guía). Segundo, la cuota de invocaciones a través de un perfil de inferencia entre regiones (cross-Region inference profile) es independiente de la cuota de invocación en una sola región — agotar una no agota la otra, y viceversa.
El hallazgo honesto: el número exacto no está en ningún documento estático
Aquí es donde esta lección se vuelve más precisa que "busca el número en la documentación". Se intentó, para escribir esta lección, encontrar el valor numérico exacto de la cuota On-demand InvokeModel tokens per minute para Amazon Nova Lite, publicado en una tabla estática. No se encontró — y la razón está documentada, no es un vacío accidental de esta guía.
La cita exacta, verificada contra docs.aws.amazon.com/bedrock/latest/userguide/quotas-runtime.html: "RPM quotas on the bedrock-runtime endpoint are model-specific. [...] For models that do have an RPM quota, view the exact value in the Service Quotas console." La documentación oficial de Bedrock remite, explícitamente, a la consola de Service Quotas de tu propia cuenta para el valor numérico — no a una tabla pública. Y una segunda cita, todavía más específica, de docs.aws.amazon.com/nova/latest/userguide/quotas.html: "The On-demand model invocation quotas [...] aren't adjustable through Service Quotas. Contact your AWS account manager to be considered for an increase."
Esto confirma dos cosas a la vez, verificadas por lectura directa de la documentación, no asumidas:
- El número exacto de tu cuota On-Demand es específico de tu cuenta, no un valor universal publicado — es literalmente imposible citarlo con precisión en una lección genérica como esta, y cualquier tutorial que cite "la cuota de Nova Lite es X tokens por minuto" está citando, en el mejor caso, un valor que aplicó a una cuenta específica en un momento específico.
- Las cuotas de invocación On-Demand no son autoservicio. A diferencia de muchas otras cuotas de AWS que puedes aumentar tú mismo desde la consola de Service Quotas con un formulario, un aumento de la cuota de invocación On-Demand de Bedrock requiere contactar a tu account manager de AWS — un proceso manual, no automatizado.
Un ejemplo numérico real que SÍ está publicado, para ilustrar la forma de una cuota de Bedrock aunque sea de una categoría distinta a la que Andes Cargo usaría en producción: las cuotas de implementación de modelo personalizado (custom model deployment), verificadas contra la tabla pública de docs.aws.amazon.com/general/latest/gr/bedrock.html:
| Modelo | Solicitudes por minuto | Tokens por minuto | Tokens por día |
|---|---|---|---|
| Amazon Nova Micro / Nova Lite | 2,000 | 4,000,000 | 5,760,000,000 |
| Amazon Nova Pro | 200 | 800,000 | — |
Estas cifras son reales y públicas —pero son la cuota de un escenario distinto (invocar un modelo personalizado, propio, desplegado sobre Bedrock, no el modelo base On-Demand que extract-shipment-manifest-fields invoca). Se citan aquí únicamente para mostrar la forma que toma una cuota publicada de Bedrock —solicitudes/minuto, tokens/minuto, tokens/día, por modelo, por región—, no como el número que aplicaría a Andes Cargo.
Por qué esto importa para extract-shipment-manifest-fields, aunque el volumen sea bajo
ADR-001 fija a extract-shipment-manifest-fields como un camino de escalamiento de bajo volumen — la mayoría de los manifiestos nunca lo tocan. Sería razonable pensar que, con volumen bajo, una cuota de tasa nunca es un problema real. Pero fíjate en la palabra clave de toda esta lección: por minuto, no por mes. Un volumen mensual bajo puede, de todas formas, concentrarse en una ráfaga: si un socio logístico grande cambia su formato de envío de golpe, o si ocurre un incidente que hace que muchos manifiestos fallen el parseo determinista al mismo tiempo (por ejemplo, un cambio no anunciado en el formato de un socio), decenas de eventos ManifestParseFailed podrían dispararse en el mismo minuto — y ahí es donde una cuota de tokens por minuto, no el presupuesto mensual, se vuelve el límite real.
PRESUPUESTO MENSUAL SOBRANTE CUOTA POR MINUTO AGOTADA
($10,000 asignados, $40 gastados) (ráfaga de 50 invocaciones
en el mismo minuto)
│ │
▼ ▼
"Tengo margen de sobra" ThrottlingException
-- ninguna relación con
el presupuesto disponibleEsta es la razón exacta del título de esta lección: ninguna factura muestra este límite. Un ThrottlingException no aparece en Cost Explorer, no aparece en GENAI-COST-PROFILE.md de la lección 8, y no lo detiene ningún presupuesto configurado en el Módulo 6. Es un fallo de disponibilidad, no de costo — el Módulo 7 de esta guía retoma esta distinción cuando define los SLI de la carga de IA, incluida la tasa de bloqueo, un concepto distinto pero relacionado.
Errores comunes
Asumir que, si el presupuesto de GENAI-COST-PROFILE.md tiene margen, cualquier volumen de invocaciones va a funcionar (de confusión costo/cuota). Qué pasa: alguien revisa el presupuesto mensual, ve que hay margen de sobra, y concluye que no hay riesgo de que extract-shipment-manifest-fields falle por volumen. Cómo detectarlo: si tu única verificación antes de un pico de tráfico esperado es el saldo del presupuesto. Cómo corregirlo: presupuesto y cuota son dos límites completamente independientes, como esta lección mostró desde el diagrama inicial. Tener margen de sobra en el presupuesto mensual no dice nada sobre si una ráfaga de invocaciones en un minuto específico va a superar la cuota de tokens por minuto de tu cuenta.
Citar un número específico de cuota como si fuera universal, sin haberlo verificado contra tu propia cuenta (de fuente equivocada). Qué pasa: alguien encuentra, en un blog o un tutorial, "la cuota de Nova Lite es X tokens por minuto" y lo usa como planificación de capacidad sin verificarlo. Cómo detectarlo: si tu plan de capacidad se basa en un número de cuota que no viste tú mismo en la consola de Service Quotas de tu propia cuenta AWS. Cómo corregirlo: esta lección mostró, con la cita textual de la documentación oficial, que la cuota On-Demand es específica de cada cuenta, no un valor publicado universal — la única fuente confiable es tu propia consola de Service Quotas, nunca una cifra citada en un artículo de terceros.
Esperar poder aumentar la cuota de invocación On-Demand con un formulario de autoservicio, igual que otras cuotas de AWS (de expectativa). Qué pasa: alguien intenta subir la cuota de Bedrock desde la consola de Service Quotas, con el mismo flujo que ya usó para otro servicio, y se sorprende cuando la opción no está disponible como autoservicio. Cómo detectarlo: si buscas un botón de "Request increase" y esperas una aprobación automática o casi automática. Cómo corregirlo: la documentación oficial de Bedrock, citada arriba, es explícita — las cuotas de invocación On-Demand no son ajustables por Service Quotas; requieren contacto directo con tu account manager de AWS, un proceso manual con tiempos distintos a un formulario de autoservicio.
Ejercicios
Ejercicio 1 — Explica, sin usar la palabra "dinero", qué mide una cuota de Bedrock. Un colega, después de leer la lección 2 sobre precios, pregunta qué agrega esta lección que la anterior no cubrió. Explícaselo sin mencionar dinero ni presupuesto.
Ver solución
Una cuota mide velocidad de invocación permitida, no costo — específicamente, cuántos tokens (o, para algunos modelos, cuántas solicitudes) tu cuenta puede procesar en un minuto, para un modelo y una región específicos. Es un límite de tasa —cuánto puedes hacer en el tiempo—, completamente separado de cuánto te cobran por hacerlo. Puedes tener toda la capacidad de pago del mundo y aun así recibir un error si intentas invocar más rápido de lo que tu cuota permite.
Ejercicio 2 — Predice qué pasaría, en términos de cuota (no de presupuesto), si un socio logístico grande de Andes Cargo cambiara su formato de envío de clave=valor a texto libre de un día para otro, para todos sus envíos. Basándote en el diagrama de "ráfaga" de esta lección, describe el riesgo específico, distinto del riesgo de presupuesto que ya conoces del Módulo 6 de finops-and-cost-guardrails-guide.
Ver solución
Si ese socio envía, de golpe, un volumen alto de manifiestos en texto libre en un período corto (por ejemplo, procesando en lote los envíos acumulados de un día completo al arrancar su sistema), process-shipment-manifest publicaría muchos eventos ManifestParseFailed en un intervalo breve, y extract-shipment-manifest-fields intentaría invocar Bedrock para todos ellos casi simultáneamente. El riesgo específico de esta lección no es que el presupuesto mensual se agote (eso lo cubre el Módulo 6, con un umbral distinto) — es que la cuota de tokens por minuto de la cuenta se agote primero, generando ThrottlingException en las invocaciones que excedan ese límite de tasa, sin importar cuánto presupuesto quede disponible ese mes.
Ejercicio 3 — Explica por qué esta lección cita cifras de cuota de "implementación de modelo personalizado" en vez de la cuota On-Demand exacta que Andes Cargo usaría. ¿Por qué esta lección eligió mostrar un número real de una categoría distinta, en vez de simplemente omitir cualquier cifra numérica?
Ver solución
Porque la documentación oficial confirma, con cita textual, que la cuota On-Demand exacta es específica de cada cuenta y no está publicada en ninguna tabla estática — citar un número inventado para esa cuota específica sería exactamente el tipo de honestidad rota que esta guía entera evita. La cifra de implementación de modelo personalizado, en cambio, sí está publicada de forma pública y verificable en la documentación oficial — se usa aquí únicamente para mostrar la forma real que toma una cuota de Bedrock (solicitudes/minuto, tokens/minuto, tokens/día, por modelo), con un número real y citable, dejando explícito que no es la cifra que aplicaría al escenario On-Demand de Andes Cargo. Es la misma disciplina que el resto de esta guía: mostrar algo real y verificado, etiquetado con precisión, en vez de inventar el número que faltaría para completar una tabla más "limpia".
Resumen y siguiente paso
Esta lección nombró las cuotas de Bedrock, verificadas contra la documentación oficial de AWS: tokens por minuto (entrada + salida combinados) como la medida principal, solicitudes por minuto solo para algunos modelos, un techo diario derivado del límite por minuto, y una cuota separada para invocaciones entre regiones. Confirmaste el hallazgo central, citado textual: el valor numérico exacto de la cuota On-Demand no está publicado en ningún documento estático —vive en la consola de Service Quotas de cada cuenta específica— y, a diferencia de muchas otras cuotas de AWS, no es ajustable por autoservicio.
Antes de avanzar deberías poder: explicar la diferencia entre un límite de costo y un límite de cuota sin usar la palabra "dinero"; nombrar los cuatro tipos de cuota de bedrock-runtime citados en esta lección; y explicar por qué "presupuesto con margen" no significa "sin riesgo de ThrottlingException".
Las lecciones 4 a 6 vuelven a terreno ejecutable: Infracost, la herramienta que el resto de este ecosistema ya confía, puesta a prueba contra un recurso de Bedrock de verdad — con el resultado real de ese intento, sea cual sea.
Recursos
- AWS Docs — Quotas for the bedrock-runtime endpoint — la fuente de los cuatro tipos de cuota citados en esta lección.
- AWS Docs — Quotas for Amazon Nova — la fuente de la cita sobre por qué las cuotas On-Demand no son ajustables por autoservicio.
- AWS General Reference — Amazon Bedrock endpoints and quotas — la tabla pública donde se verificaron las cifras de implementación de modelo personalizado citadas en esta lección.
- AWS Docs — Requesting a Quota Increase — el proceso de autoservicio que sí aplica a otras cuotas de AWS, para contraste.