Semana 6 · Módulo 6 de 11

Despliegue de modelos, integración empresarial y herramientas de desarrollo

Cómo se pone un modelo en producción (Bedrock on-demand, Provisioned Throughput, modelos importados o personalizados, SageMaker AI, contenedores y edge), cómo se integra en los sistemas de una empresa (APIs, colas, eventos, contact center, frontend) y con qué herramientas se construye y se despliega (Kiro, CDK, CI/CD y AppConfig). Cubre los task statements 2.2, 2.3 y 2.5.

Reparto de la semana

Por qué importa

Este módulo junta tres task statements del dominio 2 (26 % del examen):

• 2.2 Implement model deployment strategies: dónde y cómo se sirve el modelo.
• 2.3 Design and implement enterprise integration architectures: cómo se conecta la IA generativa con lo que la empresa ya tiene.
• 2.5 Implement application integration patterns and development tools: interfaces, productividad del desarrollador, CI/CD y troubleshooting.

Aquí tu SAA-C03 rinde mucho: API Gateway, Lambda, SQS, EventBridge, CloudFront, Route 53 o Auto Scaling ya los conoces. Lo nuevo es cómo cambian con un LLM: respuestas lentas y largas (streaming, timeouts), cargas pesadas en GPU, coste por token, modelos que se actualizan y prompts que son configuración.

Parte 1. Estrategias de despliegue de modelos (2.2)

Por qué un LLM se despliega distinto (skill 2.2.2)

Un modelo de ML clásico (un clasificador de fraude, por ejemplo) pesa megas, responde en milisegundos y cabe en una CPU. Un LLM es otra cosa:

Consecuencias de diseño:

• Contenedores optimizados para LLM: en SageMaker AI, los contenedores LMI (Large Model Inference) traen motores como vLLM o TensorRT-LLM con paralelismo de tensores (repartir el modelo entre varias GPU), batching continuo (juntar peticiones al vuelo para usar la GPU al máximo) y cuantización (pesos con menos bits: menos memoria, algo de pérdida de calidad).
• Estrategias de carga: imágenes de contenedor ligeras y pesos aparte en S3; cachés locales; evitar arranques en frío con capacidad mínima caliente; escalar con tiempo de antelación porque un nodo nuevo tarda minutos.
• Dimensionar por tokens: la capacidad se planifica en tokens de entrada y salida por minuto, no en peticiones.
• Adaptadores (LoRA, low-rank adaptation): en vez de desplegar una copia completa por cada variante afinada, se despliega el modelo base y pequeños adaptadores intercambiables (skill 1.2.4, módulo 01).

Tabla de estrategias de despliegue

Amazon Bedrock: on-demand frente a Provisioned Throughput (skill 2.2.1)

• On-demand: pagas por token de entrada y salida. Hay niveles de servicio (service tiers): Standard, Priority (prima de precio a cambio de prioridad), Flex (más barato, menos prioridad) y Reserved (capacidad reservada con el equipo de cuenta). Los límites de tasa son cuotas por cuenta y región.
• Provisioned Throughput: compras un número de Model Units; cada MU garantiza cierto número de tokens de entrada y de salida por minuto para ese modelo. Compromisos: sin compromiso, 1 mes o 6 meses (más compromiso, precio por hora más bajo). Se factura por hora hasta que lo borras. Para invocarlo usas el ARN del provisioned model como modelId. Los perfiles de inferencia entre regiones no admiten Provisioned Throughput.
• Modelos personalizados en Bedrock: para servirlos, compras Provisioned Throughput o, si el modelo lo admite, creas un despliegue on-demand del modelo personalizado (custom model deployment) y lo invocas con su ARN, pagando solo por uso. Ojo: hoy solo existe para algunos modelos (Nova Micro, Lite, Pro y Nova 2 Lite; Llama 3.3 70B en Oregón) y en regiones de EE. UU. (us-east-1 y us-west-2), no en regiones europeas.

Personalización: fine-tuning, continued pre-training y destilación

Datos verificados de la destilación en Bedrock: el conjunto de entrenamiento son prompts en .jsonl; Bedrock genera respuestas del profesor (con técnicas de síntesis de datos que pueden ampliar el conjunto hasta 15.000 pares y facturan inferencia del profesor) o reutiliza pares prompt-respuesta de los invocation logs (filtrables por requestMetadata).

Datos verificados de Custom Model Import: arquitecturas Mistral, Mixtral, Flan-T5, Llama (2, 3, 3.1, 3.2, 3.3 y Mllama), GPTBigCode, Qwen (2, 2.5, VL y Qwen3 con restricciones) y GPT-OSS (solo us-east-1); pesos de menos de 200 GB (100 GB si es multimodal); contexto de menos de 128.000 tokens; no admite modelos de embeddings, ni batch inference, ni CloudFormation. En Europa, solo en eu-central-1.

SageMaker AI para LLMs (skills 2.2.1 y 2.2.2)

Opciones de inferencia verificadas en la documentación:

Piezas específicas de IA generativa:

• SageMaker JumpStart: catálogo de modelos preentrenados (abiertos y propietarios) desplegables con un clic y afinables.
• Componentes de inferencia (inference components): varios modelos en un mismo endpoint, con aceleradores, CPU y memoria asignados a cada modelo, escalado por modelo y escala a cero de un modelo para liberar sitio a otro. Ahorra cuando tienes muchos modelos con tráfico irregular.
• Soluciones híbridas (skill 2.2.1): Bedrock para modelos gestionados + SageMaker AI para el modelo propio o especializado, detrás de la misma API.
• Auto Scaling de endpoints con target tracking (invocaciones por instancia, concurrencia o utilización de GPU); con LLM, escala con margen porque cada instancia nueva tarda en cargar el modelo.
• SageMaker Model Registry: grupos de paquetes de modelo con versiones, metadatos y estado de aprobación (pendiente, aprobado, rechazado). Una aprobación puede disparar (vía EventBridge) el pipeline que despliega; volver a una versión anterior es tu rollback.
• Despliegue seguro de endpoints: blue/green con desplazamiento de tráfico canario o lineal y rollback automático con alarmas de CloudWatch.
• SageMaker Neo: compila y optimiza un modelo para un hardware destino (instancias en la nube o dispositivos edge), reduciendo latencia y memoria. En el examen encaja con «modelo pequeño que debe correr rápido en un dispositivo o en un hardware concreto»; no se aplica a modelos de Bedrock ni es la respuesta para servir un LLM grande (para eso, contenedores LMI con cuantización y paralelismo).

Contenedores, Lambda y App Runner

• Amazon ECR: registro de imágenes para todos los casos (SageMaker AI con contenedor propio, ECS, EKS, AgentCore Runtime con contenedor).
• Amazon ECS / Amazon EKS sobre EC2 con GPU: control total del servidor de inferencia. AWS Fargate es cómodo para la capa de aplicación (API, orquestación, servidores MCP complejos), pero no es el sitio para alojar un LLM en GPU.
• AWS Lambda: no aloja LLMs; es la capa de invocación perfecta (skill 2.2.1: «Lambda functions for on-demand invocation»): valida, construye el prompt, llama a Bedrock y post-procesa. Máximo 15 minutos por ejecución.
• AWS App Runner: contenedores web gestionados; cerrado a clientes nuevos. Para un frontal o API en contenedor sin gestionar infraestructura, la alternativa actual es ECS Express Mode (ECS en Fargate + Application Load Balancer + escalado con una sola llamada).

Almacenamiento para modelos autoalojados: S3, EBS y EFS

Cuando el modelo es tuyo (SageMaker AI, EC2, ECS o EKS con GPU), los pesos tienen que vivir en algún sitio y cargarse rápido. Del SAA ya conoces los tres servicios; aquí importa su papel:

Estrategias de carga (model loading strategies, skill 2.2.2): imagen de contenedor ligera y pesos aparte; caché local (EBS o almacenamiento de instancia) o compartida (EFS) para acelerar el arranque en frío; mantener capacidad mínima caliente cuando el tiempo de carga supera lo que tolera el usuario.

Optimizar el despliegue: el modelo justo (skill 2.2.3)

• Elige el modelo más pequeño que cumpla: un modelo pequeño bien instruido resuelve clasificación, extracción y resúmenes cortos por una fracción del coste.
• Modelos preentrenados pequeños para tareas concretas: un modelo especializado (por ejemplo, de embeddings o de clasificación) en lugar de un LLM generalista.
• Cascada por API (API-based model cascading): el modelo barato responde las consultas rutinarias; si la confianza es baja o la tarea es compleja, se escala al modelo caro.

flowchart LR
    Q["Consulta"] --> C{"Clasificador barato: ¿rutinaria?"}
    C -->|"sí"| S["Modelo pequeño (Nova Micro)"]
    C -->|"no"| G["Modelo grande"]
    S --> V{"¿Confianza suficiente?"}
    V -->|"sí"| R["Respuesta"]
    V -->|"no"| G
    G --> R

• Enrutado configurable: la tabla «tipo de consulta → modelo» en AWS AppConfig para cambiarla sin desplegar (skill 1.2.2).

Edge e híbrido (skill 2.3.4)

Enrutado seguro entre nube y local: conectividad privada hasta la región, PrivateLink (VPC endpoints de interfaz para bedrock-runtime) para que el tráfico a Bedrock no salga a internet, y perfiles de inferencia geográficos (por ejemplo eu.) para que la inferencia se quede en la UE.

Parte 2. Arquitecturas de integración empresarial (2.3)

Patrón síncrono: API + Lambda + Bedrock

flowchart LR
    App["App o microservicio"] -->|"HTTPS + auth"| APIGW["API Gateway: validación, throttling, API keys"]
    APIGW --> L["Lambda: prompt, llamada, post-proceso"]
    L -->|"Converse"| BR["Amazon Bedrock"]
    L --> CW["CloudWatch Logs y X-Ray"]

Bueno para respuestas cortas y usuarios esperando. Cuidado con el timeout de integración de API Gateway (29 s por defecto): una generación larga lo supera. Soluciones: streaming, maxTokens acotado o pasar a asíncrono. Es el patrón del lab 11.

Patrón asíncrono con colas

flowchart LR
    P["Productor (app, carga masiva)"] --> Q["Amazon SQS"]
    Q --> W["Lambda trabajador (concurrencia limitada)"]
    W -->|"Converse con reintentos"| BR["Amazon Bedrock"]
    W --> DB["DynamoDB o S3: resultado"]
    W --> N["SNS o EventBridge: aviso de fin"]
    Q -.->|"tras N fallos"| DLQ["Cola de mensajes fallidos (DLQ)"]

Cuándo: trabajos largos, picos que superarían las cuotas de Bedrock, desacoplar al productor (decouple). La cola absorbe picos, la concurrencia máxima de la Lambda protege la cuota de tokens por minuto, los reintentos con backoff gestionan el throttling y la DLQ aísla lo que falla. El cliente consulta el resultado o recibe un aviso (webhook, WebSocket, correo). Para volúmenes enormes y sin urgencia, Bedrock batch inference es más barato.

Patrón orientado a eventos

flowchart LR
    S3["S3: nuevo documento"] --> EB["Amazon EventBridge"]
    CRM["CRM: ticket creado"] --> EB
    EB -->|"regla: tipo = ticket"| SF["Step Functions: clasificar, resumir, enrutar"]
    EB -->|"regla: tipo = documento"| L["Lambda: extraer con BDA y Bedrock"]
    SF --> EB2["EventBridge: ticket.enriquecido"]
    EB2 --> CRM2["CRM actualizado (API)"]

Acoplamiento débil (loose coupling): el sistema legado emite eventos y no sabe que existe un LLM. EventBridge filtra y enruta; SNS difunde a varios consumidores; Amazon AppFlow trae datos de SaaS (Salesforce, Zendesk…) a S3 o los devuelve; DynamoDB Streams reacciona a cambios de datos (por ejemplo, reindexar en el almacén vectorial).

Otros patrones de la skill 2.3.1 y 2.3.2

Gateway de IA generativa centralizado (skill 2.3.5)

Una empresa con muchos equipos no quiere que cada uno llame a Bedrock a su manera. La solución es una capa de abstracción central (GenAI gateway):

flowchart LR
    T1["Equipo A"] --> GW["Gateway de IA: API Gateway + Lambda"]
    T2["Equipo B"] --> GW
    GW --> CFG["AppConfig: modelos permitidos, rutas, límites"]
    GW --> GR["Bedrock Guardrails"]
    GW --> BR["Bedrock"]
    GW --> SM["SageMaker AI endpoint"]
    GW --> OBS["CloudWatch, X-Ray, logs de invocación"]

Qué centraliza: autenticación y cuotas por equipo (planes de uso, claves), modelos aprobados y enrutado (AppConfig), guardrails comunes, registro y coste por equipo (etiquetas, requestMetadata), reintentos y fallback. Es la «centralized abstraction layer, observability and control mechanisms» de la guía. Para agentes, AgentCore Gateway cumple un papel equivalente con herramientas y modelos.

Acceso seguro (skill 2.3.3)

• Federación de identidades: los empleados entran con el IdP corporativo mediante IAM Identity Center (SAML u OIDC) y reciben roles; los usuarios de una app, con Amazon Cognito (grupos de usuarios y, para credenciales de AWS temporales, grupos de identidades). En agentes, AgentCore Identity para OAuth de entrada y salida.
• RBAC (control de acceso basado en roles) y ABAC (basado en atributos o etiquetas): qué rol puede invocar qué modelo y qué datos (por ejemplo, filtros de metadatos en la Knowledge Base según el grupo del usuario).
• Mínimo privilegio en la API del modelo: bedrock:InvokeModel solo sobre los ARN de los modelos y perfiles de inferencia necesarios, nunca bedrock:* sobre *. Con SCP en AWS Organizations puedes denegar modelos no aprobados en toda la organización.
• Red privada: VPC endpoints (PrivateLink) para bedrock-runtime, con políticas de endpoint.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": [
        "arn:aws:bedrock:eu-central-1:111122223333:inference-profile/eu.amazon.nova-micro-v1:0",
        "arn:aws:bedrock:*::foundation-model/amazon.nova-micro-v1:0"
      ]
    }
  ]
}

Con un perfil de inferencia geográfico necesitas permiso sobre el perfil y sobre el modelo en las regiones de destino (de ahí el * en la región del ARN del modelo).

Contact center: Amazon Connect + Amazon Lex + Bedrock

Amazon Connect es el contact center en la nube de AWS (voz, chat y otros canales; AWS lo comercializa hoy como parte de la familia Amazon Connect, con «Connect Customer» para experiencia de cliente). Amazon Lex V2 es el servicio de bots conversacionales (reconocimiento de voz y de intención). Lex V2 integra IA generativa de Bedrock:

• AMAZON.QnAIntent: responde preguntas con un FM a partir de una Bedrock Knowledge Base u otras fuentes.
• AMAZON.BedrockAgentIntent: pasa la conversación a un agente de Bedrock.
• Assisted slot resolution y assisted NLU: el FM ayuda a entender valores y la intención.
• Descriptive bot builder y generación de enunciados de ejemplo para crear el bot más rápido.

flowchart LR
    C["Cliente llama"] --> CON["Amazon Connect: flujo de contacto"]
    CON --> LEX["Amazon Lex V2: intención y slots"]
    LEX -->|"intención clásica"| LF["Lambda: consulta el CRM"]
    LEX -->|"QnAIntent"| KB["Bedrock Knowledge Base + FM"]
    LEX -->|"sin resolver"| AG["Agente humano con resumen generado"]
    CON --> TR["Transcripción y análisis posterior (resumen, sentimiento)"]

Patrón: el bot resuelve lo frecuente, la Lambda de fulfillment consulta sistemas internos, y si hay que escalar, el agente humano recibe resumen y contexto generados (aumento humano). Tras la llamada, se generan resúmenes y se actualiza el CRM (skill 2.5.3).

Frontend: Amplify + Cognito

• AWS Amplify despliega el frontend y, con el Amplify AI Kit, crea el backend de IA de forma declarativa: rutas de conversación (API asíncrona multiturno cuyo historial se guarda en DynamoDB) y rutas de generación (petición-respuesta síncrona que devuelve datos estructurados), sobre AWS AppSync, Lambda y Bedrock, con componentes de interfaz para React.
• Amazon Cognito autentica a los usuarios; las reglas de autorización deciden quién usa cada ruta.
• CloudFront sirve el frontend; AWS WAF protege la API.

flowchart LR
    B["Navegador (React)"] --> CF["CloudFront + WAF"]
    B -->|"login"| COG["Amazon Cognito"]
    B -->|"GraphQL con token"| AS["AWS AppSync"]
    AS --> L["Lambda de conversación"]
    L --> BR["Amazon Bedrock"]
    L --> DDB["DynamoDB: historial"]

Red y escalado: quién hace qué

Cómo se eligen en un enunciado de IA generativa:

• Elastic Load Balancing: ALB para HTTP delante de contenedores que sirven la app, un agente propio o un servidor de inferencia (vLLM, TGI); NLB para TCP o gRPC con latencia mínima. Con respuestas en streaming largas, revisa el idle timeout del balanceador (en ALB es configurable) para que no corte la conexión a mitad de respuesta.
• Route 53 frente a Global Accelerator para una app de IA desplegada en dos regiones: Route 53 enruta por DNS (latencia, geolocalización, failover con comprobaciones de estado, pesos para canarios), sujeto al TTL de caché de los clientes; Global Accelerator da dos IP estáticas anycast y conmuta en segundos sin depender de la caché DNS. «Clientes que solo admiten IP fijas en su lista blanca» o «failover entre regiones en segundos» → Global Accelerator.
• CloudFront: frontend y caché en el borde; no acelera ni abarata la inferencia del modelo salvo que cachees respuestas deterministas (edge caching, módulo 09).
• AWS Auto Scaling: para lo que tú alojas (endpoints de SageMaker AI, servicios ECS, grupos EC2 con GPU). Bedrock on-demand no se escala: se gestiona con cuotas, perfiles de inferencia o capacidad reservada.

Parte 3. Integración de aplicaciones y herramientas de desarrollo (2.5)

Interfaces de API para modelos (skill 2.5.1)

Problemas propios de un LLM detrás de una API y cómo se resuelven:

Datos verificados sobre streaming:

• API Gateway (REST): pon el modo de transferencia de respuesta de la integración en STREAM (por defecto BUFFERED). Solo integraciones proxy (HTTP_PROXY o AWS_PROXY, incluida Lambda proxy). Hasta 15 minutos de stream; idle timeout de 5 minutos en endpoints regionales y privados (30 s en edge-optimized). Sin caché de endpoint, sin compresión de contenido y sin transformación VTL de la respuesta. Útil para server-sent events (SSE).
• Lambda: response streaming nativo en los runtimes gestionados de Node.js; para Python, runtime personalizado o Lambda Web Adapter. Se invoca con function URLs, InvokeWithResponseStream o API Gateway. Hasta 200 MB de respuesta en streaming (6 MB en modo buffered).
• WebSocket API de API Gateway: canal bidireccional; la Lambda recibe el mensaje, llama a ConverseStream y envía cada fragmento al cliente con la API de conexiones.

Interfaces accesibles (skill 2.5.2)

• Amplify: componentes de interfaz declarativos (chat incluido) conectados al backend de IA.
• OpenAPI y enfoque API-first: primero el contrato (esquema OpenAPI), luego el código. Sirve para generar clientes, documentar, importar en API Gateway y convertir la API en herramienta de agente (AgentCore Gateway admite destinos OpenAPI).
• Amazon Bedrock Prompt Flows (ahora Bedrock Flows): constructor visual no-code para encadenar prompts, KBs, Lambdas y condiciones (módulo 04).

Mejoras de sistemas de negocio (skill 2.5.3)

• Lambda para mejorar el CRM: al crear un caso, resume el historial, clasifica la prioridad, propone respuesta y extrae entidades; escribe de vuelta en el CRM por su API.
• Step Functions para procesar documentos: recibir → extraer (Textract o Bedrock Data Automation) → validar → resumir o clasificar con Bedrock → revisión humana si la confianza es baja → guardar.
• Bedrock Data Automation (BDA): extracción estructurada de documentos, imágenes, audio y vídeo con blueprints (módulo 02).

Productividad del desarrollador (skill 2.5.4)

• Kiro: el IDE y CLI agéntico de AWS que sustituye a Q Developer en el IDE. Claves: specs (el desarrollo se planifica en documentos de requisitos, diseño y tareas antes de generar código), steering (reglas y estándares del proyecto que el agente siempre respeta), hooks (automatizaciones al cambiar ficheros, usar herramientas o completar tareas, por ejemplo «genera tests al guardar»), soporte MCP para conectar herramientas y un modo headless de la CLI para integrarlo en CI. Útil para generar y refactorizar código, sugerir llamadas a APIs, crear tests de componentes de IA y optimizar rendimiento.
• Amazon Q Developer (lo que cita la guía): asistente de código de AWS; en el IDE está en retirada a favor de Kiro, pero en la consola sigue ayudando a diagnosticar errores y a entender recursos. En un enunciado, «generar y refactorizar código con un asistente de IA de AWS» → Q Developer o Kiro.
• Amazon Q Developer in chat applications (antes AWS Chatbot): notificaciones y comandos de AWS en canales de chat como Slack o Microsoft Teams; útil para alertas de pipelines y alarmas de coste o throttling.

Aplicaciones avanzadas (skill 2.5.5)

Strands Agents y Agent Squad para orquestación nativa en AWS, Step Functions para patrones de agentes (ReAct, aprobación humana) y prompt chaining con Bedrock (Flows o código): todo está en el módulo 05.

Troubleshooting de aplicaciones con FMs (skill 2.5.6)

• CloudWatch Logs Insights sobre los logs de invocación de Bedrock (model invocation logging, que guarda petición y respuesta) o sobre tus logs estructurados:

fields @timestamp, modelId, input.inputTokenCount, output.outputTokenCount
| filter modelId like /nova-micro/
| stats avg(output.outputTokenCount) as salida_media, count(*) as llamadas by bin(5m)

• AWS X-Ray: trazas de extremo a extremo (API Gateway → Lambda → Bedrock) para ver qué tramo añade latencia o falla.
• Amazon Q Developer en la consola para interpretar errores; la guía lo cita como «GenAI-specific error pattern recognition».
• Errores típicos que reconocer: ThrottlingException (cuota), ValidationException (formato de petición, contexto demasiado largo), AccessDeniedException (IAM o modelo no habilitado), ModelTimeoutException, stopReason = max_tokens (respuesta cortada).

Infraestructura como código

• AWS CDK: define la infraestructura en Python o TypeScript y la sintetiza a CloudFormation; ideal para componentes reutilizables (constructs) de IA generativa (skill 1.1.3: componentes estandarizados). La AgentCore CLI usa CDK por debajo.
• AWS CloudFormation: plantillas YAML o JSON; es lo que usan los labs 11 y 12.
• AWS Service Catalog: publica productos aprobados (por ejemplo, «stack de RAG con guardrails y logging») para que los equipos se autoaprovisionen dentro de las normas.
• AWS CodeArtifact: repositorio privado de paquetes (pip, npm): versiones aprobadas de boto3, strands-agents, etc., y proxy de PyPI para builds reproducibles.

CI/CD para aplicaciones de IA generativa (skill 2.3.5)

Además de lo clásico (tests, build, despliegue), una app de IA generativa necesita puertas de calidad propias: los prompts y los modelos son código.

flowchart LR
    SRC["Repositorio (código, prompts, IaC)"] --> B["CodeBuild: tests unitarios con el modelo simulado"]
    B --> SEC["Escaneo de seguridad (dependencias, IaC, secretos)"]
    SEC --> EV["Puerta de calidad: evaluación de prompts con casos de referencia"]
    EV --> DEP["Despliegue canario (CodeDeploy o CloudFormation)"]
    DEP --> MON["Alarmas de CloudWatch: errores, latencia, calidad"]
    MON -->|"alarma"| RB["Rollback automático"]

AWS AppConfig: modelos, prompts y feature flags sin redesplegar

AWS AppConfig cambia el comportamiento de la aplicación en producción sin desplegar código. Dos tipos de perfil: feature flags y configuración libre (freeform), almacenada en AppConfig, S3, Parameter Store o Secrets Manager. Ventajas clave:

• Validadores (esquema JSON o Lambda) antes de desplegar la configuración.
• Estrategias de despliegue graduales (por ejemplo, lineales durante N minutos) con rollback automático si salta una alarma de CloudWatch.
• Experimentación y A/B testing con tráfico real.
• La app lee la configuración a través del AppConfig Agent (también como extensión de Lambda), que la cachea localmente y abarata las lecturas.

Configuración típica de una app de IA generativa:

{
  "modelo_por_defecto": "eu.amazon.nova-micro-v1:0",
  "modelo_complejo": "eu.amazon.nova-lite-v1:0",
  "max_tokens": 400,
  "temperature": 0.2,
  "prompt_version": "resumen-v3",
  "flags": { "usar_guardrail": true, "cascada_de_modelos": false }
}

Lectura desde Lambda con la extensión del AppConfig Agent (escucha en localhost, puerto 2772):

import json
import urllib.request

URL = "http://localhost:2772/applications/app-resumen/environments/prod/configurations/modelos"

def leer_config() -> dict:
    with urllib.request.urlopen(URL, timeout=2) as r:
        return json.loads(r.read())

Con esto consigues la «arquitectura flexible para cambiar de modelo o proveedor sin modificar código» de la skill 1.2.2 y feature flags para activar gradualmente una función de IA.

Amazon SageMaker Unified Studio

Es la experiencia unificada de la «nueva generación» de Amazon SageMaker: un único entorno, organizado en dominios y proyectos con gobierno de acceso, que reúne datos, analítica, ML e IA generativa (incluido el desarrollo de aplicaciones con Bedrock). Para el examen: colaboración entre equipos de datos y de IA con gobierno centralizado (lo retomarás en el módulo 08).

Trampas típicas del examen

• Provisioned Throughput para tráfico variable: pagas por hora aunque no se use. Tráfico bajo o irregular → on-demand. Tráfico alto y constante o modelo personalizado → Provisioned Throughput.
• SageMaker serverless para un LLM grande: sin GPU y con 6 GB máximo. Para LLM con tráfico intermitente, asíncrono (escala a cero) o componentes de inferencia.
• Lambda como «servidor del modelo»: Lambda invoca; no aloja LLMs.
• Fine-tuning para datos que cambian: eso es RAG. Fine-tuning cambia estilo, formato o tarea.
• Timeouts: una generación larga detrás de API Gateway en modo buffered choca con los 29 s; usa streaming, WebSocket o asíncrono con SQS.
• Streaming en Lambda Python: no es nativo; Node.js sí. En Python, Lambda Web Adapter o runtime personalizado.
• Cuotas de Bedrock: picos masivos → cola SQS + concurrencia limitada, batch inference o perfiles de inferencia entre regiones; no «más Lambdas».
• Residencia de datos: perfil de inferencia geográfico (eu.), no global; datos que no pueden salir de las instalaciones → Outposts.
• Cambiar de modelo sin desplegar: AppConfig (o Parameter Store), no variables de entorno fijas ni código.
• App Runner y Q Developer (IDE) en diseños nuevos: están cerrados a altas nuevas; alternativas ECS Express Mode y Kiro. Si el enunciado los nombra, razona con lo que hacen.
• CI/CD de IA sin puerta de calidad: tests unitarios verdes no garantizan que el prompt siga funcionando; añade regresión de prompts y evaluación.
• Lambda@Edge para inferencia: no; sirve para lógica ligera en el borde.

Resumen

• Un LLM se despliega distinto: GPU, pesos enormes, carga lenta, capacidad medida en tokens por minuto y memoria que crece con el contexto.
• Bedrock on-demand por defecto; Provisioned Throughput para tráfico constante alto o modelos personalizados; batch para volumen sin prisa.
• Personalización: fine-tuning (etiquetado), reinforcement fine-tuning (recompensas), continued pre-training (sin etiquetar, concepto), destilación (grande → pequeño) y Custom Model Import (tus pesos en Bedrock).
• SageMaker AI: real-time (25 MB, 60 s), serverless (sin GPU), asíncrono (1 GB, 1 h, escala a cero), batch transform; componentes de inferencia, Model Registry, Neo.
• Integración: síncrona (API Gateway + Lambda), asíncrona (SQS + DLQ), eventos (EventBridge, AppFlow, DynamoDB Streams), contact center (Connect + Lex + Bedrock) y frontend (Amplify + Cognito + AppSync).
• Acceso seguro: federación (Identity Center, Cognito), RBAC/ABAC, bedrock:InvokeModel solo sobre ARN concretos, PrivateLink, SCP.
• Interfaces para FMs: streaming (REST response streaming hasta 15 min, WebSocket), límites de tokens, reintentos con backoff.
• Herramientas: Kiro (sustituye a Q Developer en el IDE), CDK/CloudFormation, Service Catalog, CodeArtifact.
• CI/CD de IA: CodePipeline + CodeBuild con tests simulados, regresión de prompts y despliegue gradual con rollback.
• AppConfig: modelos, prompts y feature flags con validación, despliegue gradual y rollback, sin tocar código.

Cobertura del temario

Practica lo aprendido

Documentación oficial para ampliar

• Provisioned Throughput en Amazon Bedrock
• Custom Model Import
• Personalización de modelos en Bedrock
• Model distillation en Bedrock
• Opciones de inferencia de SageMaker AI
• SageMaker Serverless Inference
• Response streaming en API Gateway (REST)
• Response streaming en Lambda
• What is AWS AppConfig?
• Funciones de IA generativa de Amazon Lex V2
• Amplify AI Kit
• Kiro
• Acción CloudFormation en CodePipeline
• AWS App Runner availability change