Seis módulos rodeando al protagonista y recién ahora lo tocamos — a propósito: el error de las plataformas inmaduras es empezar por “conectarse al modelo” y descubrir después que faltan identidad, red y estado. Con esos cimientos puestos, la pregunta de este módulo es limpia: ¿cómo accede la plataforma entera a los modelos de lenguaje? Y la respuesta tiene dos capas: qué te da AWS administrado (Bedrock) y qué encima de eso sigue siendo tu problema de arquitectura (el gateway).

Este módulo aterriza en AWS el componente 1 de la landing zone — el LLM gateway como punto único de paso — así que la teoría no se repite: aquí decidimos su implementación.

La tesis del módulo

Bedrock resuelve el acceso administrado a los modelos — catálogo, API unificada, capacidad, seguridad de datos — pero el gateway como pieza de arquitectura sigue siendo tuyo: el punto único por donde pasan todas las llamadas de todos los agentes, con routing, fallback, presupuesto y auditoría. A veces ese punto único se implementa con Bedrock y unas políticas; a veces exige un proxy propio delante. La decisión depende de tres preguntas — ¿multi-proveedor?, ¿multi-equipo?, ¿lógica de routing propia? — y de nada más.

Bedrock, glosado: qué te da el administrado

Amazon Bedrock es el servicio de modelos como API de AWS: un catálogo de modelos de varios proveedores (Anthropic, Meta, Mistral, los Nova de Amazon, los modelos de pesos abiertos de OpenAI, entre otros) consumidos por API, sin administrar infraestructura de inferencia, y — el argumento de peso enterprise — con la garantía contractual de que tus prompts y salidas no entrenan los modelos y no salen del perímetro AWS (con IAM del módulo 2 y los endpoints privados del módulo 4 aplicando igual que a cualquier servicio).

Las piezas que importan para la arquitectura:

Converse API: la API unificada de conversación — el mismo contrato (mensajes, herramientas, streaming) sobre cualquier modelo del catálogo. Cambiar de modelo es cambiar un identificador, no reescribir la integración. Es “normalización multi-proveedor” administrada… dentro del catálogo de Bedrock.
Inferencia cross-region: perfiles que enrutan la llamada entre regiones — de un mismo ámbito geográfico (EE. UU., Europa, APAC) o, en los perfiles globales disponibles desde septiembre de 2025 para algunos modelos, hacia cualquier región comercial — para conseguir capacidad y resiliencia. Gratis en esfuerzo, con la letra chica del módulo 1: tu prompt cruza regiones — verifícalo contra tu política de residencia.
On-demand vs. throughput aprovisionado: pago por token (el default sano) vs. capacidad reservada con descuento para volúmenes altos y sostenidos — la misma decisión fijo-vs-variable de siempre; se gradúa con datos de uso, nunca al inicio.
Batch: inferencia por lotes a ~50% del precio para todo lo que no es interactivo — el analizador nocturno de llamadas es el cliente perfecto.
Guardrails y Knowledge Bases: los servicios adjuntos de filtrado (entrada/salida, PII) y RAG administrado — protagonistas de los módulos 10 y 9 respectivamente.

La pregunta del módulo: ¿Bedrock ya es mi gateway?

Recordemos qué pedía el componente gateway de la landing zone: punto único, normalización, routing/fallback, credenciales centralizadas, auditoría, y el enganche para FinOps y guardrails. Contrastemos:

Función del gateway	¿Bedrock la cubre?	Cómo / con qué límite
Normalización de API	✅ dentro de su catálogo	Converse API; pero solo modelos en Bedrock
Credenciales centralizadas	✅	No hay API keys: es IAM puro (módulo 2)
Auditoría de llamadas	✅	CloudTrail + invocation logging (módulo 11)
Atribución de costos	✅ con trabajo	Application inference profiles + tags (módulo 8)
Routing por regla propia	⚠️ parcial	Cross-region sí; “barato para lo fácil, caro para lo difícil” es tuyo
Fallback entre proveedores externos	❌	Si el fallback es “salir de Bedrock a otra API”, no existe
Modelos fuera del catálogo	❌	Los GPT de la API de OpenAI, Gemini u otro modelo que no se publique en Bedrock: fuera del alcance

La lectura: si toda tu plataforma consume modelos del catálogo de Bedrock, Bedrock + IAM + inference profiles ES tu gateway — punto único por diseño (todos llegan por el mismo servicio), credenciales resueltas, auditoría nativa. Agregar un proxy propio encima sería duplicar administrado con artesanal.

El gateway propio — típicamente LiteLLM (el proxy open source del patrón de referencia de AWS, corriendo en tu ECS del módulo 3) u otro equivalente — entra cuando respondes sí a alguna de estas:

¿Multi-proveedor real? Necesitas modelos fuera de Bedrock (la API de OpenAI o de Google, un proveedor de embeddings específico, un modelo propio). El proxy normaliza lo que Bedrock no alcanza.
¿Multi-equipo con presupuestos propios? Decenas de equipos/aplicaciones con límites de gasto, keys virtuales y cuotas por equipo: el proxy da esa capa multi-tenant que IAM puro vuelve engorrosa.
¿Routing con lógica tuya? La cascada económica de caso-04 (intentar con el barato, escalar al caro según confianza), A/B de modelos, reglas por tipo de tarea: eso es código de routing, y necesita un lugar donde vivir.

   ¿NECESITO GATEWAY PROPIO DELANTE DE BEDROCK?

START ──► ┌────────────────────┐
          │ ¿modelos fuera de  │ ──► sí: proxy propio
          │ Bedrock?           │
          └─────────┬──────────┘
               no   ▼
          ┌────────────────────┐
          │ ¿multi-equipo con  │ ──► sí: proxy propio
          │ cuotas propias?    │
          └─────────┬──────────┘
               no   ▼
          ┌────────────────────┐
          │ ¿routing con       │ ──► sí: proxy propio
          │ lógica propia?     │
          └─────────┬──────────┘
               no   ▼
          ┌────────────────────┐
          │ Bedrock + IAM +    │
          │ profiles ES el     │
          │ gateway            │
          └────────────────────┘

  proxy propio = LiteLLM en tu ECS, delante de Bedrock

Ojo: las tres preguntas se re-responden con el tiempo. La plataforma que hoy vive feliz solo-Bedrock puede necesitar el proxy el año próximo (un modelo externo, un tercer equipo). La decisión barata de hoy: aunque no pongas proxy, centraliza el acceso en una librería/módulo interno único — que ningún agente llame a Bedrock “a mano” con su propio código de cliente. Si mañana llega el proxy, cambias un endpoint en un lugar, no en veinte repos. El punto único puede ser lógico antes de ser físico.

Routing y fallback: el diseño mínimo

Sea Bedrock directo o proxy delante, la política de acceso a modelos de la plataforma se escribe — una página, no un tomo:

Ruta por defecto por tipo de tarea: clasificación → gama económica; redacción/razonamiento → gama media; casos marcados → gama alta. (La tabla costo-calidad de caso-04, ahora como configuración.)
Escalada: cuándo un resultado de gama económica se reintenta en la superior (validación fallida, confianza baja). Con tope — la escalada infinita es el bucle de gasto del módulo 8.
Fallback de capacidad: modelo primario saturado → cross-region primero, modelo alternativo del catálogo después, encolar y reintentar al final. Para el agente autónomo, “esperar en la cola” es un fallback perfectamente digno — nadie está mirando.
Fallback de calidad: si toda la cadena falla → la degradación honesta del módulo 5: derivar a humano, nunca inventar.

Cuidado — el gateway propio es infraestructura crítica: si pones LiteLLM delante de todo, ese proxy hereda la disponibilidad de la plataforma entera: su caída es la caída de todos los agentes. Corre en múltiples AZs (módulo 1), con auto-scaling (módulo 3), tras el patrón de salud del módulo 11 — o habrás centralizado el punto único de fallo junto con el punto único de paso. Es el precio del proxy, y es exactamente el tipo de costo operativo que la pregunta “¿de verdad lo necesito?” existe para pesar.

Errores comunes

Proxy propio “porque el patrón lo dice”. Si todo vive en Bedrock, un solo equipo y routing simple, el proxy duplica lo administrado y agrega un servicio crítico que operar. El patrón de la landing zone pide el punto único, no una pieza específica.
Bedrock directo desde veinte repos distintos. Sin proxy está bien; sin capa común no: el día que necesites cambiar el acceso, serán veinte PRs. Librería interna única desde el día uno.
Ignorar la letra chica del cross-region. Capacidad gratis a cambio de que el prompt viaje. Si hay política de residencia de datos, se verifica antes de activar el perfil, no después de la auditoría.
Aprovisionar throughput el día uno. Capacidad reservada sin curva de uso medida es costo fijo comprado con optimismo. On-demand hasta que los datos griten lo contrario.
Olvidar el batch para lo nocturno. Todo lo no-interactivo al 50% de descuento es la palanca más fácil del stack de IA; dejarla sin usar en los lotes del módulo 3 es FinOps negativo.
Escalada de modelos sin tope. “Reintenta con el caro si falla” sin límite convierte una degradación de calidad en un incidente de facturación. Todo routing lleva presupuesto — puente directo al módulo 8.

La frase para llevarse

“Bedrock te administra los modelos; el gateway — punto único, routing, fallback, presupuesto — sigue siendo una decisión tuya. A veces se implementa con tres políticas sobre Bedrock, a veces con un proxy delante; lo que nunca puede pasar es que no exista: veinte agentes llamando modelos por su cuenta no es una plataforma — es veinte facturas con un logo común.”

Qué viene

Módulo 8: FinOps en AWS. Todos los módulos anteriores dejaron cuentas por pagar: cómputo, NAT, almacenes, tokens. Ahora, el sistema para verlas y gobernarlas: los cost allocation tags como sistema nervioso, Cost Explorer y los application inference profiles para saber qué agente gasta qué, Budgets con acciones automáticas como freno, y el diseño del kill switch — porque el agente autónomo que gasta solo necesita, por simetría, un mecanismo que lo detenga solo.

Arquitectura AWS — Módulo 7: el LLM gateway y Bedrock