1. Dónde encaja AWS Bedrock

AWS Bedrock es el servicio de AWS para usar modelos de IA generativa sin gestionar GPUs. Lo que empezó como “un API para llamar a Claude y otros modelos desde AWS” se ha convertido en una plataforma con muchas piezas, y esa es justo la dificultad: saber cuáles necesitas y cuáles no.

En esta guía veremos todo lo que hace falta para llevar una aplicación con AWS Bedrock a producción: elegir modelo, escribir prompts, RAG, agentes, seguridad, costes, observabilidad y arquitectura. En cada capítulo aprenderemos cómo funciona cada pieza o servicio para poder decidir cuando usarlo y cuando no.

Para quién es esta guía

Para quien tiene que llevar una aplicación con IA generativa a producción dentro de AWS:

• Equipos de desarrollo en empresas que ya trabajan con AWS.
• Arquitectos y equipos de plataforma que tienen que dar a otros equipos una forma segura de usar modelos.
• Quien prepara la certificación AWS Certified Generative AI Developer – Professional (AIP-C01) y quiere ver cómo se aplica en la práctica.

Antes de empezar:

• Una cuenta de AWS de pruebas (no la de producción) y soltura con la consola.
• Python 3.11 o superior; algunos ejemplos tienen también versión en TypeScript.
• Nociones de IAM: usuarios, roles y políticas.

Al terminar la guía sabrás elegir modelo con datos, proteger la aplicación con Guardrails, medir y reducir su coste, vigilarla en producción y desplegarla con una arquitectura que puedas defender en una revisión.

Si en algún momento te parece que AWS Bedrock tiene demasiadas piezas, es normal: tiene muchas. Por eso el segundo capítulo las repasa una a una.

Qué es AWS Bedrock (y qué no es)

AWS Bedrock te da acceso a modelos de varios proveedores (Anthropic, Amazon, OpenAI, Meta, Mistral y otros) con una sola API, pagando por uso y con los datos dentro de tu cuenta y tu región. Alrededor de esa API hay cuatro capas:

flowchart TB
    APP[Tu aplicación] --> AG[Agentes<br/>AgentCore]
    APP --> CO[Conocimiento y herramientas<br/>Knowledge Bases, tool use]
    APP --> SE[Seguridad y control<br/>Guardrails, IAM, logs]
    AG --> INF
    CO --> INF
    SE --> INF[Inferencia<br/>Converse, batch, tiers]
    INF --> M[(Modelos<br/>Claude, Nova, OpenAI…)]

Lo que AWS Bedrock no es: no es un modelo (no “entrenas Bedrock”), no guarda tus conversaciones por ti (la API no tiene memoria) y no hace que una mala idea de producto funcione. Es infraestructura: te quita el trabajo de servir modelos, no el de diseñar la aplicación.

Ocho conceptos antes de empezar

Estas ocho ideas explican casi todas las decisiones de diseño, coste y seguridad del resto de la guía.

1. Token. La unidad en la que el modelo lee y escribe. En español, 1.000 tokens son aproximadamente 650–750 palabras, según el modelo. Todo se mide en tokens: el precio, la cuota (TPM, tokens por minuto) y el tamaño máximo de una petición. Las imágenes y los PDF también se convierten en tokens.

2. Ventana de contexto. Lo máximo que el modelo ve de una vez: instrucciones, historial, documentos y respuesta. Los modelos actuales llegan a cientos de miles de tokens o a 1 millón, pero que quepa no significa que convenga: más contexto es más caro, más lento y, a partir de cierto punto, el modelo presta menos atención a lo que queda en medio.

3. Parámetros de inferencia.

4. La API no tiene memoria. Cada llamada es independiente. Si quieres que el modelo “recuerde” la conversación, tu aplicación le reenvía el historial en cada turno, y lo pagas cada vez. Por eso existen la caché de prompts, los resúmenes de historial y AgentCore Memory.

5. Embeddings. Un modelo de embeddings convierte un texto o una imagen en una lista de números que representa su significado: textos parecidos dan números parecidos. Es la base de la búsqueda semántica y del RAG. No genera texto, solo sirve para buscar y comparar.

6. Razonamiento ampliado. Algunos modelos pueden “pensar” antes de responder (extended thinking). Mejora problemas de varios pasos, pero esos tokens se cobran como salida y añaden latencia. Lo activo solo donde una evaluación demuestra que ayuda.

7. Privacidad de los datos. AWS Bedrock no usa tus prompts ni tus respuestas para entrenar los modelos base ni los comparte con los proveedores de modelos. Los datos se procesan en la región o geografía que elijas y puedes cifrar con tus propias claves de KMS. Lo que sí controlas tú es dónde guardas los registros de las llamadas.

8. Ciclo de vida de los modelos. Cada modelo pasa por Active, Legacy y End of Life. En Legacy sigue funcionando pero ya tiene fecha de retirada; después, las llamadas fallan. La métrica LegacyModelInvocations te avisa si sigues usando uno. Yo planificaría al menos una migración de modelo al año.

Prompt, RAG, herramientas o fine-tuning

Es la decisión de arquitectura más importante y es fácil equivocarse: por ejemplo, empezar entrenando un modelo cuando un buen prompt o un RAG sencillo bastaban. Me ayuda imaginarlo como una escalera: solo subo un peldaño cuando el anterior no basta.

flowchart TB
    P1[1. Prompt<br/>instrucciones y ejemplos] -->|el contexto fijo<br/>es grande| P2[2. Prompt + caché<br/>documentos fijos]
    P2 -->|no cabe o<br/>cambia a menudo| P3[3. RAG<br/>Knowledge Base]
    P3 -->|datos vivos<br/>o acciones| P4[4. Herramientas<br/>o agente]
    P4 -->|la calidad<br/>no llega| P5[5. Fine-tuning<br/>o destilación]

Los peldaños se combinan: un asistente real suele usar los cuatro primeros a la vez. Un buen prompt, caché de las instrucciones, RAG para la documentación y herramientas para los datos del cliente.

Los modelos de AWS Bedrock

Según la página Models at a glance, en noviembre de 2026 las familias principales son:

• Anthropic Claude: generación 5.x (Haiku 5.5, Sonnet 5.5, Opus 5.5…) y la 4.x todavía activa (Haiku 4.5, Sonnet 4.6, Opus 4.8…).
• Amazon Nova: Nova 2 Lite (texto y multimodal), Nova 2 y 2.5 Sonic (voz a voz), Nova Multimodal Embeddings y la primera generación (Micro, Lite, Pro, Canvas, Reel).
• OpenAI: GPT-6.x, GPT-5.x y los modelos de pesos abiertos gpt-oss-20b y gpt-oss-120b.
• Otros: Meta Llama 4, Mistral Large 3, DeepSeek, Qwen3 y Google Gemma, entre otros.

Mi recomendación para empezar: el modelo más pequeño y barato (Haiku o Nova 2 Lite) y subir de tamaño solo si la evaluación lo justifica. En Elegir modelo está la tabla de modelos por escenario y cómo compararlos con tus datos.

Las formas de llamar a un modelo

La ventaja de Converse es que cambiar de modelo es cambiar un texto (modelId). Eso es lo que hace posible comparar modelos y migrar sin reescribir la aplicación.

Inferencia entre regiones y datos en la UE

Muchos modelos nuevos solo se pueden llamar a través de un perfil de inferencia (inference profile), que reparte las peticiones entre varias regiones para dar más capacidad:

• Geográfico (prefijos eu., us., apac.…): los datos se procesan solo dentro de esa geografía. Con datos personales de la UE es mi opción por defecto.
• Global (prefijo global.): puede enrutar a cualquier región comercial. Más capacidad y, en los modelos de Claude recientes, un 10 % más barato que el geográfico. Solo si tu política de residencia de datos lo permite.

Un ejemplo de identificador: eu.anthropic.claude-haiku-4-5-20251001-v1:0 frente a anthropic.claude-haiku-4-5-20251001-v1:0 (el modelo base). Copia siempre el identificador exacto de la ficha del modelo: cambian con cada versión.

Resumen

• AWS Bedrock da acceso a modelos de varios proveedores con una sola API y los datos dentro de tu cuenta.
• Tiene cuatro capas; al principio te bastan inferencia y seguridad.
• Antes de RAG, agentes o fine-tuning, exprime el prompt: es el peldaño más barato.
• Siguiente capítulo: los servicios de AWS Bedrock uno a uno.

Recursos

• Guía de usuario de AWS Bedrock
• Models at a glance: modelos, regiones y perfiles
• Endpoint compatible con OpenAI (bedrock-mantle)