Amazon Bedrock elimina la fricción de desplegar modelos fundacionales en producción: sin clústeres GPU que administrar, sin versiones de PyTorch que romper. Esto es lo que un arquitecto necesita saber antes de construir sobre él.
Amazon Bedrock es un servicio completamente administrado que expone modelos fundacionales (FM) de múltiples proveedores — Anthropic, Meta, Amazon, Mistral AI, Cohere, AI21 Labs y Stability AI — a través de una API única y unificada. No hay instancias EC2 que aprovisionar ni contenedores de inferencia que mantener: Bedrock corre la inferencia dentro de la infraestructura de AWS y usted paga por token procesado (o por unidad de capacidad reservada, si usa Provisioned Throughput).
La diferencia clave frente a montar su propio servidor de inferencia es la superficie operativa. Con Bedrock, el control de acceso pasa por IAM, el tráfico puede quedarse dentro de su VPC vía AWS PrivateLink, los logs de invocación se integran con CloudWatch y CloudTrail, y el cifrado en tránsito y en reposo es responsabilidad del servicio. Para una empresa en Guatemala o Latinoamérica que necesita cumplir con marcos de protección de datos sin construir un equipo de MLOps completo, esto reduce meses de trabajo de infraestructura a días de integración.
Bedrock expone dos formas principales de invocar modelos desde el SDK (boto3 en Python, o los SDKs equivalentes en Java, Go, .NET, JavaScript). La API `invoke_model` es de bajo nivel: usted arma el payload en el formato nativo del proveedor del modelo (el body de Claude no es idéntico al de Titan ni al de Llama). La API `Converse` (y su variante `ConverseStream`) normaliza esa diferencia: un mismo esquema de mensajes funciona sin importar si detrás está Claude, Llama o Mistral, lo que facilita cambiar de modelo sin reescribir el código de integración.
Un detalle que sorprende a quienes llegan de OpenAI o Anthropic directo: en Bedrock, cada modelo debe habilitarse explícitamente por cuenta y por región en la consola (Bedrock → Model access) o vía la API `PutFoundationModelEntitlement`. Algunos modelos requieren aceptar términos de uso del proveedor (por ejemplo, los modelos Llama de Meta) antes de que el `modelId` responda. Si su primera llamada retorna `AccessDeniedException`, la causa más común no es IAM — es que el modelo simplemente no está habilitado en esa región.
Los `modelId` siguen un patrón `proveedor.nombre-version`, por ejemplo `anthropic.claude-opus-4-8`, `meta.llama3-70b-instruct-v1:0` o `amazon.titan-text-premier-v1:0`. Algunos modelos exponen un ARN de perfil de inferencia (`inference profile`) en vez de un ID directo, necesario cuando el modelo solo está disponible como enrutamiento cross-region.
El patrón más común en producción combina API Gateway, Lambda y Bedrock: la Lambda recibe la solicitud, arma el prompt (posiblemente enriquecido con una Knowledge Base), invoca Bedrock y devuelve la respuesta. Para cargas conversacionales largas, se agrega streaming vía `ConverseStream` y una conexión WebSocket con API Gateway, evitando el timeout de 30 segundos del API Gateway REST estándar.
Para flujos batch (clasificación masiva, resumen de miles de documentos), Bedrock ofrece `CreateModelInvocationJob`, un modo de inferencia asíncrona que procesa lotes desde S3 a un costo por token menor que on-demand, sin bloquear infraestructura síncrona.
El control de acceso granular se hace con políticas IAM sobre acciones como `bedrock:InvokeModel`, `bedrock:InvokeModelWithResponseStream` y `bedrock:Retrieve`, con condiciones opcionales sobre `modelId` para restringir qué modelos puede invocar cada rol. Para tráfico que no debe salir de la red privada, se crea un VPC endpoint de interfaz (`com.amazonaws.region.bedrock-runtime`) respaldado por AWS PrivateLink — el tráfico nunca toca la internet pública.
Todos los datos enviados a Bedrock se cifran con TLS en tránsito y con claves KMS administradas por AWS o por el cliente (CMK) en reposo. Un punto crítico para compliance: Amazon Bedrock no usa las entradas ni salidas de sus clientes para entrenar los modelos base, y esto aplica a todos los proveedores integrados en el servicio.
Antes de escribir una sola línea de código de aplicación, defina tres cosas: qué modelo cubre el caso de uso al menor costo aceptable (no siempre el más grande es necesario), si el caso requiere contexto propietario vía Knowledge Bases (RAG) o si el prompt engineering directo basta, y qué guardrails de contenido necesita antes de exponer el sistema a usuarios finales. Los siguientes artículos de esta serie profundizan cada una de estas piezas — Agents, Knowledge Bases, Guardrails y optimización de costos — como componentes de una misma arquitectura.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel