Semana 9 · Módulo 9 de 11

Coste, rendimiento y monitorización de aplicaciones de IA generativa

Aprenderás a calcular y recortar la factura de una aplicación de IA generativa (tokens, caché, lotes, niveles de servicio, routing), a bajar la latencia y a montar la observabilidad completa con CloudWatch, invocation logging, trazas OpenTelemetry y detección de anomalías de coste. Es todo el dominio 4 del examen (12 %).

Reparto de la semana

Por qué importa

El dominio 4 (Operational Efficiency and Optimization for GenAI Applications) vale el 12 % de la nota, pero sus ideas aparecen como restricción en preguntas de todos los dominios: «la solución MOST cost-effective», «con LOWEST latency», «without increasing operational overhead». Una aplicación de IA generativa tiene una economía distinta a la de un microservicio clásico:

• Pagas por token, no por petición ni por hora. Un prompt mal diseñado multiplica la factura sin que cambie el tráfico.
• La latencia depende de la longitud de la respuesta. Un modelo genera la salida token a token; 1.000 tokens de salida tardan mucho más que 100.
• Los fallos son silenciosos. Una respuesta alucinada devuelve HTTP 200. Sin métricas de calidad y registros de las invocaciones no te enteras.

Este módulo cubre los task statements 4.1 (coste y eficiencia), 4.2 (rendimiento) y 4.3 (monitorización). Todas las cifras de precio son estimaciones de la región us-east-1 consultadas el 1 de octubre de 2026 en la API oficial de precios y en la página de precios de Bedrock; en Europa suelen ser algo más altas (por ejemplo, Nova Lite cuesta 0,066/0,264 USD por millón en eu-south-2 frente a 0,06/0,24 en us-east-1).

Economía de tokens desde cero

Qué es un token y por qué manda en la factura

Un token es el trozo de texto con el que trabaja el modelo: una palabra corta, parte de una palabra larga, un signo de puntuación. Como regla orientativa en inglés, 1 token equivale a unos 4 caracteres; en español la proporción es algo peor (más tokens por palabra). No uses reglas fijas para facturar: mide.

En Amazon Bedrock on-demand pagas por separado:

• Input tokens (tokens de entrada): todo lo que envías. No solo la pregunta del usuario: también el system prompt, los ejemplos few-shot, el historial de la conversación, los fragmentos recuperados en RAG y las definiciones de herramientas de un agente.
• Output tokens (tokens de salida): lo que genera el modelo. Son entre 4 y 5 veces más caros que los de entrada en casi todos los modelos (Nova Lite: 0,06 USD entrada frente a 0,24 USD salida por millón; Claude Haiku 4.5 global: 1,00 frente a 5,00).

Para medir antes de enviar tienes la API CountTokens de bedrock-runtime (count_tokens en boto3). Recibe el mismo cuerpo que InvokeModel o Converse, devuelve inputTokens y no tiene coste. El soporte depende del modelo (lo indica su model card). Después de invocar, la respuesta de Converse trae el bloque usage con inputTokens, outputTokens y, si usas caché, cacheReadInputTokens y cacheWriteInputTokens.

Todas las piezas de la factura

Una aplicación real no es solo el modelo. Estas son las partidas típicas:

Ejemplo numérico: asistente RAG de soporte

Una empresa monta un asistente de soporte con RAG (Retrieval Augmented Generation: se buscan fragmentos relevantes en un almacén vectorial y se añaden al prompt). Datos:

• 100.000 preguntas al mes.
• Por pregunta: system prompt de 1.500 tokens, 5 fragmentos recuperados de 400 tokens (2.000), historial de 450 tokens y pregunta de 50 tokens. Total de entrada: 4.000 tokens. Respuesta media: 300 tokens.
• Modelo de generación: Amazon Nova Lite (0,06 USD entrada / 0,24 USD salida por millón, us-east-1).
• Embeddings de la pregunta con Titan Text Embeddings V2 (0,02 USD por millón en us-east-1).
• Reranking con Cohere Rerank 3.5 en cada pregunta (2,00 USD por 1.000 consultas).
• Guardrail con filtros de contenido sobre la pregunta (1 text unit) y la respuesta (unos 1.200 caracteres = 2 text units).
• Almacén: S3 Vectors con 50.000 vectores.

La lección es clara: el modelo solo supone unos 31 USD. El reranking y el guardrail cuestan más que la generación. Esto es exactamente lo que el examen quiere que sepas ver:

• Si reranqueas solo cuando la búsqueda devuelve puntuaciones ambiguas, o usas Amazon Rerank 1.0 (1,00 USD por 1.000 consultas en us-west-2), el reranking se reduce a la mitad o menos.
• Si el guardrail evaluara todo el prompt (4.000 tokens ≈ 16.000 caracteres = 16 text units) en lugar de solo la pregunta, el coste del guardrail se multiplicaría por más de 5. En Converse puedes marcar con bloques guardContent qué parte se evalúa; en InvokeModel, con etiquetas de entrada.
• Si la carga pudiera esperar (por ejemplo, resúmenes nocturnos), con batch inference el mismo volumen de tokens de Nova Lite costaría la mitad: 0,03/0,12 USD por millón → 15,60 USD en lugar de 31,20.

La ingesta inicial es un coste único: 10.000 documentos de 2.000 tokens son 20 M tokens de embeddings × 0,02 = 0,40 USD. Barato; lo caro es reindexar a menudo sin necesidad.

Ejemplo numérico: coste de un agente

Un agente resuelve cada tarea en 3 vueltas (el modelo decide, llama a una herramienta, recibe el resultado y vuelve a decidir). En cada vuelta reenvía todo el contexto. Modelo: Claude Haiku 4.5 con perfil global (1,00 USD entrada, 5,00 USD salida por millón; lectura de caché 0,10; escritura de caché de 5 minutos 1,25).

• System prompt + definiciones de herramientas: 5.000 tokens fijos.
• Vuelta 1: 5.000 + 500 de la petición = 5.500 de entrada; 200 de salida.
• Vuelta 2: añade el resultado de la herramienta y la vuelta anterior: 6.500 de entrada; 200 de salida.
• Vuelta 3: 7.500 de entrada; 300 de salida.

Sin caché: 19.500 tokens de entrada × 1,00 / 1 M = 0,0195 USD, más 700 de salida × 5,00 / 1 M = 0,0035 USD. Total: 0,0230 USD por tarea.

Con prompt caching del prefijo de 5.000 tokens (supera el mínimo de 4.096 tokens por checkpoint que exige Claude Haiku 4.5):

• Vuelta 1: escribe 5.000 tokens en caché (× 1,25 = 0,00625) + 500 normales (0,0005).
• Vueltas 2 y 3: leen 5.000 de caché cada una (× 0,10 = 0,0005 cada una) + 1.500 y 2.500 normales (0,004).
• Entrada: 0,00625 + 0,0005 + 0,001 + 0,004 = 0,01175 USD. Salida: 0,0035. Total: 0,01525 USD (≈ 34 % menos).

Y si llegan más tareas en menos de 5 minutos, el prefijo sigue «caliente» y también la vuelta 1 lee de caché. Con 1 millón de tareas al mes, la diferencia es de 23.000 a unos 15.000 USD, y a menos aún con caché compartida entre tareas.

Palancas de ahorro

Tabla de decisión

Elegir el modelo por coste y capacidad

Selección de modelo con criterio económico (cost-effective model selection framework, skill 4.1.2):

1. Define la calidad mínima aceptable con un conjunto de evaluación (módulo 10).
2. Evalúa varios modelos con ese conjunto y mide calidad, latencia y coste por respuesta.
3. Calcula la relación precio-rendimiento (price-to-performance ratio): coste por respuesta correcta, no por token.
4. Elige el modelo más barato que supere el listón y deja la puerta abierta a subir de nivel solo cuando haga falta.

El patrón tiered FM usage (uso escalonado según la complejidad) combina modelos: un modelo muy barato (o reglas) clasifica la consulta; las simples van a Nova Micro/Lite y las complejas a un modelo grande. Es un model routing hecho por ti, con la lógica que quieras (Lambda, Step Functions, un nodo de condición de Bedrock Flows).

Amazon Bedrock Intelligent Prompt Routing es la versión gestionada:

• Un prompt router es un endpoint serverless que, en cada petición, predice la calidad de respuesta de dos modelos de la misma familia y elige el más barato que dé calidad suficiente.
• Hay routers por defecto (familias Anthropic y Meta) y routers configurados con CreatePromptRouter: dos modelos, un modelo de fallback y el criterio responseQualityDifference. El router solo abandona el fallback si el otro modelo se prevé mejor por al menos ese margen.
• Se invoca pasando el ARN del router como modelId; la traza de la respuesta (trace.promptRouter.invokedModelId) dice qué modelo contestó.
• Limitaciones documentadas: familias concretas (Nova Lite/Pro, varios Claude y Llama), optimizado para inglés y no aprende de los datos de rendimiento de tu aplicación.

Prompt caching a fondo

El prompt caching guarda el procesamiento de un prefijo del prompt para que las siguientes peticiones con el mismo prefijo no lo recalculen. Reduce coste y latencia (el modelo no reprocesa esos tokens).

• Implicit prompt caching: automático y best effort; no pones marcas. Nova lo aplica a todos los prompts de texto.
• Explicit prompt caching: colocas cache checkpoints. En Converse es un bloque cachePoint dentro de system, messages o tools; en InvokeModel con Claude es cache_control.
• TTL (time to live): 5 minutos por defecto, que se reinicia en cada acierto. Varios Claude recientes (Haiku 4.5, Sonnet 4.5/4.6, Opus 4.5 en adelante) admiten "ttl": "1h".
• Mínimo de tokens por checkpoint, acumulado sobre todo el prefijo anterior: 4.096 en Claude Haiku 4.5 y Opus 4.5-4.7; 1.024 en Sonnet 4.5/4.6; 512 en Opus 5. Nova: 1.000 tokens aproximadamente y hasta 20.000 tokens cacheados. Máximo 4 checkpoints por petición en estos modelos.
• Orden de evaluación: tools → system → messages. Si cambias las herramientas, invalidas también la caché del system y de los mensajes. Coloca lo estable delante y lo variable al final.
• Facturación: la lectura se cobra a la tarifa de caché (Claude Haiku 4.5: 0,10 USD frente a 1,00; Nova Micro: 0,00875 frente a 0,035). La escritura puede ser más cara que la entrada normal (Claude: 1,25 × para 5 minutos, 2 × para 1 hora); en Nova la escritura no tiene recargo.
• Cuotas: los tokens leídos de caché no cuentan para la cuota de tokens por minuto (TPM); los escritos sí.
• No funciona en batch inference. Con cross-Region inference puede haber más escrituras.

Ejemplo de checkpoint en Converse con boto3:

import boto3

brt = boto3.client("bedrock-runtime", region_name="eu-central-1")
manual = open("manual_producto.txt", encoding="utf-8").read()  # texto largo y estable

resp = brt.converse(
    modelId="eu.amazon.nova-lite-v1:0",
    system=[
        {"text": "Eres el asistente de soporte. Responde solo con el manual."},
        {"text": manual},
        {"cachePoint": {"type": "default"}},
    ],
    messages=[{"role": "user", "content": [{"text": "¿Cómo reinicio el router?"}]}],
    inferenceConfig={"maxTokens": 300},
)
print(resp["usage"])  # inputTokens, outputTokens, cacheReadInputTokens, cacheWriteInputTokens

Recuerda la fórmula: entrada total = inputTokens + cacheReadInputTokens + cacheWriteInputTokens. Con caché activa, inputTokens solo cuenta lo no cacheado.

Batch inference

Batch inference procesa muchas peticiones de forma asíncrona:

• Subes a S3 ficheros JSONL, una línea por petición: {"recordId": "...", "modelInput": {...}}. El modelInput usa el formato de InvokeModel o el de Converse (modelInvocationType).
• Creas el trabajo con CreateModelInvocationJob; el resultado aparece en S3 (sin orden garantizado). Estados: Submitted, Validating, Scheduled, InProgress, Completed, PartiallyCompleted, Failed, Stopping, Stopped, Expired. Puedes recibir los cambios de estado por EventBridge.
• Precio: 50 % menos que on-demand.
• Limitaciones: no admite modelos con Provisioned Throughput, ni tool calling (cada registro se procesa de forma independiente, sin ida y vuelta entre el modelo y tu código), ni prompt caching.
• Salida estructurada: la página actual de structured outputs marca batch inference como compatible («works without any additional setup»), aunque una nota antigua de la página de batch inference todavía dice lo contrario para response_format. A 1 de octubre de 2026, toma como referencia la tabla de funciones de structured outputs y comprueba la ficha del modelo; lo que es seguro es que batch no sirve para herramientas.
• Tiene cuotas de registros mínimos y máximos por trabajo y de tamaño de fichero, que dependen del modelo (por ejemplo, con Claude Haiku 4.5: mínimo 100 registros, máximo 100.000 por trabajo y ficheros de hasta 1 GB); consúltalas en Service Quotas.

Niveles de servicio (service tiers)

Bedrock ofrece cuatro service tiers para la inferencia on-demand:

En Converse el parámetro es "serviceTier": {"type": "flex"} y la respuesta indica el tier aplicado; en InvokeModel es la cabecera X-Amzn-Bedrock-Service-Tier. Priority, Standard y Flex comparten la cuota on-demand. En CloudWatch tienes las dimensiones ServiceTier y ResolvedServiceTier. El soporte varía por modelo: Nova Micro, por ejemplo, solo ofrece Standard.

¿Flex o batch? Los dos cuestan la mitad. Batch es asíncrono (ficheros en S3, horas) y no admite herramientas; Flex mantiene la API síncrona normal pero acepta esperas y throttling. Para un pipeline de enriquecimiento que ya llama a Converse y tolera reintentos, Flex evita rediseñarlo.

Caché semántica y otras cachés

Una caché semántica guarda pares pregunta-respuesta junto al embedding de la pregunta. Ante una nueva pregunta, se calcula su embedding, se busca el vecino más parecido y, si la similitud supera un umbral, se devuelve la respuesta guardada sin invocar el modelo.

• Amazon ElastiCache ofrece búsqueda vectorial (GA desde octubre de 2025, en clústeres basados en nodos con Valkey 8.2 o posterior, sin coste adicional). AWS publica una guía y un blog con el patrón: embeddings de Titan V2, índice HNSW con distancia coseno, umbral de similitud en torno a 0,75-0,8 y TTL para caducar respuestas. El blog habla de reducciones de coste de hasta el 86 % y de latencia de hasta el 88 % en su escenario.
• El umbral es la clave: demasiado bajo devuelve respuestas de otra pregunta; demasiado alto casi nunca acierta.
• No cachees respuestas personalizadas (datos del usuario) sin incluir el usuario o sus permisos en la clave.

Otras técnicas de la skill 4.1.4:

• Deterministic request hashing / result fingerprinting: normalizas la petición (modelo, parámetros, prompt) y usas su hash como clave en DynamoDB o ElastiCache. Solo acierta con peticiones idénticas; ideal si la temperatura es 0 y el contenido es repetitivo.
• Edge caching: respuestas precalculadas o poco cambiantes servidas desde Amazon CloudFront (por ejemplo, la descripción generada de un producto).
• Prompt caching: caché del prefijo dentro del modelo; se sigue invocando, pero más barato y rápido.

Eficiencia de tokens (token efficiency)

Técnicas de la skill 4.1.1, todas aplicables sin cambiar de modelo:

• Context window optimization: la ventana de contexto es el máximo de tokens (entrada + salida) que acepta el modelo: 128.000 en Nova Micro, 300.000 en Nova Lite y Pro, 200.000 en Claude Haiku 4.5. Que quepa no significa que convenga llenarla.
• Context pruning: recupera 3 fragmentos buenos en lugar de 10 mediocres (con reranking o filtros de metadatos); resume el historial de la conversación cada N turnos; elimina de los resultados de herramientas los campos que el modelo no necesita.
• Prompt compression: instrucciones concisas, sin repeticiones, ejemplos few-shot justos.
• Response size controls / response limiting: maxTokens en inferenceConfig, instrucciones como «responde en 3 viñetas», salida estructurada con esquema. Vigila stopReason = max_tokens: significa que la respuesta se cortó.
• Token estimation: CountTokens antes de enviar para decidir si hay que recortar.

maxTokens también afecta a la cuota: al empezar la petición, Bedrock descuenta de tu cuota de TPM la entrada más max_tokens y después ajusta al consumo real. Un max_tokens exageradamente alto agota la cuota antes de tiempo aunque no se facture.

Destilación de modelos

Amazon Bedrock Model Distillation usa un modelo grande (teacher) para generar respuestas sintéticas con las que se ajusta un modelo pequeño (student). Puedes aportar tus prompts o usar tus invocation logs como fuente (filtrando por requestMetadata). Pagas la inferencia del profesor, el entrenamiento y el almacenamiento del modelo resultante; a cambio, el alumno cuesta mucho menos por token. Para usar un modelo personalizado necesitas Provisioned Throughput o, si el modelo lo admite, despliegue on-demand de modelos personalizados (lo verás en el módulo 6).

Rendimiento: latencia y throughput

Anatomía de la latencia de un LLM

• Time to first token (TTFT): tiempo hasta el primer token. Depende sobre todo de la longitud de la entrada (el modelo procesa todo el prompt antes de generar) y de la carga.
• Tiempo de generación: aproximadamente proporcional a los tokens de salida.
• Latencia total (InvocationLatency): desde la petición hasta el último token.

En una aplicación RAG súmale el embedding de la pregunta, la búsqueda vectorial, el reranking y los guardrails. Un agente multiplica todo por el número de vueltas.

flowchart LR
    U["Usuario"] --> G["API Gateway / Lambda"]
    G --> E["Embedding de la pregunta"]
    E --> V["Búsqueda vectorial"]
    V --> R["Reranking (opcional)"]
    R --> M["Modelo: TTFT + generación"]
    M --> GR["Guardrail de salida"]
    GR --> U

Técnicas para una respuesta ágil (skill 4.2.1)

Parámetros del modelo según el caso (skill 4.2.4)

• Temperature: aleatoriedad. Baja (0-0,3) para extracción, clasificación y respuestas factuales; alta para creatividad.
• Top-p (nucleus sampling): solo considera los tokens cuya probabilidad acumulada llega a p. Top-k: solo los k más probables. Ajusta temperatura o top-p, no los dos a la vez sin motivo.
• maxTokens y stop sequences: controlan longitud, coste y latencia.
• En Converse, temperature, topP, maxTokens y stopSequences van en inferenceConfig; los parámetros propios de un modelo (como top_k en Claude) van en additionalModelRequestFields.
• Valida las mejoras con pruebas A/B: dos variantes de configuración con tráfico real y métricas de calidad, latencia y coste.

Throughput: cuotas, cross-Region inference y Provisioned Throughput

Bedrock on-demand limita por modelo y región:

• Tokens por minuto (TPM) y peticiones por minuto (RPM), además de un máximo de tokens por día por cuenta y región. Todas las APIs (InvokeModel, Converse…) comparten la cuota.
• Token burndown: al empezar, se reserva entrada + max_tokens; al terminar, se descuenta entrada + escritura en caché + salida × factor. El factor es 1 en la mayoría de modelos, pero en los de Anthropic la salida pesa más: 5 × en Claude 4.7 e inferiores, 10 × en Opus 5/Sonnet 5 y 15 × en Claude 4.8. Ejemplo de la documentación: con Claude Sonnet 4, 1.000 de entrada y 100 de salida consumen 1.500 de cuota pero se facturan 1.100.
• Los modelos de embeddings se limitan por RPM.
• Superar la cuota devuelve ThrottlingException (HTTP 429). Las cuotas ajustables se amplían en Service Quotas.

Formas de ganar throughput:

Provisioned Throughput es obligatorio para usar modelos personalizados (salvo los que admiten on-demand) y útil cuando necesitas throughput garantizado constante. No se combina con perfiles de inferencia. Se paga aunque no lo uses: haz planificación de capacidad (capacity planning) midiendo tokens por minuto reales en tus picos y la utilización (utilization monitoring) para no sobredimensionar.

Gestión de la concurrencia (skill 4.2.3)

• Colas (SQS) delante del modelo para absorber picos y controlar cuántos consumidores invocan a la vez (concurrencia reservada de Lambda como «válvula»).
• Reintentos con backoff exponencial y jitter: el SDK lo hace por defecto (modo standard, 3 intentos); el modo adaptive añade un limitador de tasa en el cliente.
• Token processing optimization: agrupar varias tareas pequeñas en un solo prompt cuando el modelo lo admite (clasificar 20 frases en una llamada en lugar de 20 llamadas) reduce la sobrecarga del prefijo repetido.
• Batch inference para lo diferible.

Modelos en Amazon SageMaker AI: auto scaling de endpoints

Si alojas un modelo propio o de JumpStart en un SageMaker AI real-time endpoint, pagas por instancia-hora y el escalado es cosa tuya, con Application Auto Scaling:

• Registras el objetivo: --service-namespace sagemaker, --resource-id endpoint/NOMBRE/variant/VARIANTE, --scalable-dimension sagemaker:variant:DesiredInstanceCount.
• Política de target tracking con la métrica predefinida SageMakerVariantInvocationsPerInstance (cada minuto) o, para LLM, las de alta resolución basadas en concurrencia (SageMakerVariantConcurrentRequestsPerModelHighResolution, cada 10 segundos), que escalan antes. En un LLM, una petición puede durar muchos segundos: la concurrencia refleja mejor la carga que las invocaciones por minuto (auto-scaling configurations optimized for GenAI traffic patterns).
• Escalado a cero: con inference components y MinInstanceCount = 0; el escalado desde cero usa una política por pasos disparada por una alarma sobre NoCapacityInvocationFailures.

aws application-autoscaling register-scalable-target \
  --service-namespace sagemaker \
  --resource-id endpoint/mi-llm/variant/AllTraffic \
  --scalable-dimension sagemaker:variant:DesiredInstanceCount \
  --min-capacity 1 --max-capacity 4

Rendimiento de la recuperación (skills 4.2.2 y 4.2.6)

La búsqueda vectorial también tiene latencia y calidad:

• Index optimization: elige el algoritmo y parámetros del índice (HNSW en OpenSearch, pgvector) buscando el equilibrio entre recall y latencia; usa la dimensión de embedding mínima que mantenga la calidad (Titan V2 admite 256, 512 o 1.024).
• Query preprocessing: reformular o descomponer la pregunta (query decomposition en Knowledge Bases), corregir, expandir términos.
• Hybrid search: combina búsqueda semántica y por palabras clave. En Knowledge Bases, overrideSearchType = HYBRID (con OpenSearch Serverless, RDS o MongoDB); en OpenSearch Service puedes definir tu propia puntuación con una search pipeline que normaliza y pondera los resultados (custom scoring).
• Filtros de metadatos: reducen el espacio de búsqueda y mejoran la precisión.
• Número de resultados: Retrieve devuelve 5 por defecto (de 1 a 100). Más resultados = más tokens y más latencia.

Monitorización y observabilidad

Las tres capas de la observabilidad de IA generativa

flowchart TB
    subgraph Operacion["Operación"]
        A["Métricas AWS/Bedrock: Invocations, latencia, throttles, tokens"]
    end
    subgraph Detalle["Detalle de cada interacción"]
        B["Model invocation logs: prompt, respuesta, tokens, identidad"]
        C["Trazas OpenTelemetry: pasos, herramientas, agentes"]
    end
    subgraph Negocio["Calidad y negocio"]
        D["Métricas propias: valoración del usuario, tasa de alucinación, coste por conversación"]
    end
    A --> P["Dashboards y alarmas en CloudWatch o Managed Grafana"]
    B --> P
    C --> P
    D --> P

Métricas de Amazon Bedrock en CloudWatch

Namespace AWS/Bedrock, dimensión ModelId (y ServiceTier/ResolvedServiceTier para los tiers). Métricas del endpoint bedrock-runtime:

Además hay métricas de entrega de los invocation logs (ModelInvocationLogsCloudWatchDeliveryFailure…), de Guardrails (namespace AWS/Bedrock/Guardrails: InvocationsIntervened, TextUnitCount…) y de Agents Classic (AWS/Bedrock/Agents). CloudWatch trae un dashboard automático de Bedrock (Automatic dashboards → Bedrock) con tokens por modelo.

Lo que no trae ninguna métrica nativa: la calidad de la respuesta, la tasa de alucinación o la satisfacción del usuario. Esas las publicas tú como métricas personalizadas (PutMetricData o Embedded Metric Format) desde tu aplicación o desde un proceso de evaluación.

Model invocation logging

El model invocation logging registra cada llamada a Converse, ConverseStream, InvokeModel e InvokeModelWithResponseStream del endpoint bedrock-runtime:

• Está desactivado por defecto y se configura por cuenta y región.
• Destinos: CloudWatch Logs, S3 o ambos, en la misma cuenta y región.
• Cuerpos de entrada y salida de hasta 100 KB van en línea; los mayores y los datos binarios (imágenes) van a S3 (con destino CloudWatch necesitas largeDataDeliveryS3Config).
• Eliges qué tipos de datos incluir: texto, imagen, embeddings, vídeo y audio.
• Cada registro incluye modelId, requestId, operation, identity.arn (quién llamó), requestMetadata (etiquetas que añade tu aplicación), input.inputTokenCount, output.outputTokenCount y los cuerpos completos.

aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/bedrock/invocaciones",
      "roleArn": "arn:aws:iam::111122223333:role/BedrockLogsRole"
    },
    "textDataDeliveryEnabled": true,
    "imageDataDeliveryEnabled": false,
    "embeddingDataDeliveryEnabled": false
  }'

El rol debe confiar en bedrock.amazonaws.com (con condiciones aws:SourceAccount y aws:SourceArn) y permitir logs:CreateLogStream y logs:PutLogEvents. Para S3, la política del bucket concede s3:PutObject a bedrock.amazonaws.com (y kms:GenerateDataKey si cifras con SSE-KMS).

Consulta de CloudWatch Logs Insights para ver quién consume tokens:

fields identity.arn as principal, input.inputTokenCount as inTokens, output.outputTokenCount as outTokens
| stats sum(inTokens) as totalInput, sum(outTokens) as totalOutput, count() as calls by principal
| sort totalInput desc

requestMetadata: puedes añadir hasta 16 pares clave-valor por petición (campo requestMetadata o cabecera X-Amzn-Bedrock-Request-Metadata), por ejemplo el identificador de inquilino o de funcionalidad. Aparece solo en los invocation logs; no se convierte en etiqueta de coste ni aparece en Cost Explorer.

CloudWatch generative AI observability

Amazon CloudWatch generative AI observability (GA desde octubre de 2025, sin cargo adicional más allá de la telemetría normal de CloudWatch) agrupa en la consola de CloudWatch dos vistas preconstruidas:

• Model Invocations: dashboards de uso, tokens y latencia por modelo y una tabla con los invocation logs. Requiere invocation logging hacia CloudWatch Logs.
• Amazon Bedrock AgentCore agents: agentes, memoria, herramientas integradas, gateways e identidad, con trazado de extremo a extremo de cada petición (prompt, llamadas al modelo, herramientas).

Admite agentes hechos con Strands, LangChain o LangGraph y trazas de terceros enviadas con el SDK de ADOT.

AgentCore Observability y trazas OpenTelemetry

Amazon Bedrock AgentCore Observability da visibilidad de los agentes:

• Métricas integradas de Runtime, Memory, Gateway, herramientas e Identity (namespace AWS/Bedrock-AgentCore: invocaciones, latencia, errores, sesiones, vCPU-horas…), emitidas por defecto.
• Spans y trazas compatibles con OpenTelemetry (OTEL): cada paso del razonamiento, cada llamada al modelo y a cada herramienta. Para verlas hay que activar una vez CloudWatch Transaction Search, que ingiere los spans como logs estructurados en el grupo aws/spans.
• La instrumentación se hace con ADOT (AWS Distro for OpenTelemetry): pip install aws-opentelemetry-distro y arrancar el agente con opentelemetry-instrument python agente.py. Para agentes fuera de AgentCore se activan variables como AGENT_OBSERVABILITY_ENABLED=true.

aws xray update-trace-segment-destination --destination CloudWatchLogs

AWS X-Ray sigue siendo el motor de trazas y mapas de servicio, pero los SDK y el daemon de X-Ray están en modo mantenimiento desde el 25/02/2026 y AWS recomienda instrumentar con OpenTelemetry. En el examen, «X-Ray» y «trazado distribuido» siguen siendo la respuesta a «ver qué paso de la cadena (API Gateway, Lambda, recuperación, modelo, herramienta) añade la latencia» y a construir prompt observability pipelines (skill 5.2.5).

Observabilidad de herramientas y agentes (skill 4.3.4)

• Call pattern tracking: cuántas veces se llama a cada herramienta, con qué parámetros y en qué orden (spans de la traza; métricas personalizadas por herramienta).
• Performance metric collection: latencia y tasa de error por herramienta (Lambda y AgentCore Gateway publican las suyas).
• Multi-agent coordination tracking: en sistemas multiagente, la traza une los spans del orquestador y de los subagentes con el mismo identificador de sesión.
• Usage baselines: con la detección de anomalías de CloudWatch aprendes el patrón normal de llamadas por herramienta y alertas cuando un agente entra en bucle (dispara cientos de llamadas) o deja de usar una herramienta.

Operación del vector store (skill 4.3.5)

• OpenSearch Serverless (AWS/AOSS): SearchRequestLatency, SearchRequestErrors, SearchOCU, IndexingOCU, SearchableDocuments, IngestionDocumentErrors.
• Knowledge Bases: logs de ingesta (vended logs a CloudWatch Logs, S3 o Firehose) con el estado de cada documento (EMBEDDING_FAILED, INDEXING_FAILED, RESOURCE_IGNORED…) y estadísticas del trabajo de ingesta (numberOfDocumentsFailed…).
• Automated index optimization routines: sincronizaciones programadas (EventBridge Scheduler + StartIngestionJob), reindexado tras cambiar de modelo de embeddings y tareas de mantenimiento del índice.
• Data quality validation: comprobar antes de ingerir que los documentos no están vacíos, duplicados o mal extraídos, y alarmar si crecen los documentos fallidos.

Monitorización de calidad (skills 4.3.2 y 4.3.6)

Lo que distingue la monitorización de IA generativa de la de un servicio tradicional:

• Hallucination rates y response quality: se estiman con evaluaciones periódicas (LLM como juez sobre una muestra de tráfico, contextual grounding de Guardrails) y se publican como métricas personalizadas.
• Golden datasets: un conjunto fijo de preguntas con respuesta conocida que ejecutas a diario; si la puntuación cae, algo ha cambiado (modelo, prompt, datos).
• Output diffing: comparar respuestas de dos versiones a las mismas preguntas para detectar inconsistencias.
• Response drift: cambios graduales en la longitud, el tono o el contenido de las respuestas. Detección de anomalías sobre OutputTokenCount o sobre métricas de calidad.
• Token burst patterns: picos de tokens (un bucle de agente, un abuso) detectados con CloudWatch anomaly detection (banda con ANOMALY_DETECTION_BAND).
• Reasoning path tracing: revisar en la traza los pasos del agente para localizar el razonamiento erróneo.
• Prompt effectiveness: comparar versiones de prompt (Prompt Management) con las mismas métricas.

CloudWatch Logs anomaly detection aprende los patrones de un grupo de logs y señala patrones nuevos o raros (por ejemplo, un nuevo tipo de error de herramienta), sin coste adicional por el detector.

Observabilidad accionable (skill 4.3.3)

La skill 4.3.3 pide que la observabilidad sirva para decidir, no solo para mirar. Cada ejemplo de la guía con su pieza en AWS:

SageMaker Model Monitor (estado actual)

Amazon SageMaker Model Monitor vigilaba modelos desplegados en SageMaker AI: calidad de datos, calidad del modelo, deriva de sesgo y deriva de atribución de características. Desde el 30 de junio de 2026 está en modo mantenimiento y desde el 30 de julio de 2026 no admite clientes nuevos; los existentes pueden seguir usándolo, sin funciones nuevas. AWS propone como alternativas soluciones de ejemplo con MLflow y Evidently AI, dashboards de Quick Sight y la detección de anomalías de CloudWatch. En el examen puede aparecer como la herramienta para detectar deriva de datos en un endpoint de SageMaker AI; reconócelo, pero para modelos de Bedrock la respuesta es CloudWatch + invocation logs + evaluaciones.

Synthetics, Managed Grafana y Systems Manager

• Amazon CloudWatch Synthetics: canaries (scripts programados en Node.js, Python o Java que se ejecutan como Lambda, incluso cada minuto) que simulan a un usuario: llaman a tu API de chat con una pregunta de referencia y comprueban el tiempo y el contenido de la respuesta. Detectan fallos antes que los usuarios y sirven para validar despliegues (synthetic user workflows).
• Amazon Managed Grafana: Grafana gestionado para dashboards que combinan CloudWatch, X-Ray, OpenSearch y Prometheus, útil para business impact visualizations y vistas multicuenta; autenticación con IAM Identity Center o SAML.
• AWS Systems Manager: Parameter Store para guardar configuración de la aplicación (el ID del modelo, el umbral de similitud de la caché, el ID del guardrail) y cambiarla sin redesplegar; Automation para runbooks de respuesta (por ejemplo, cambiar a otro modelo cuando salta una alarma de throttling). Para configuración con despliegue gradual y rollback, AWS recomienda AWS AppConfig.

Alarmas útiles

Las notificaciones van a SNS y de ahí a correo, Lambda o canales de chat (AWS Chatbot, ahora Amazon Q Developer in chat applications).

Imputar y vigilar los costes

Application inference profiles y etiquetas

Las métricas de CloudWatch y la factura agrupan por modelo, no por aplicación. Para saber cuánto gasta cada equipo o producto en Bedrock:

• Crea un application inference profile por aplicación con CreateInferenceProfile: le das un nombre, un modelSource (un modelo fundacional o un perfil de cross-Region inference del sistema) y etiquetas.
• La aplicación invoca usando el ARN del perfil como modelId.
• Activa las etiquetas como cost allocation tags en Billing y filtra en AWS Cost Explorer o en los informes de costes (CUR).

aws bedrock create-inference-profile \
  --inference-profile-name soporte-chatbot \
  --model-source copyFrom=arn:aws:bedrock:eu-central-1:111122223333:inference-profile/eu.amazon.nova-lite-v1:0 \
  --tags key=CostCenter,value=soporte key=App,value=chatbot

(En el endpoint bedrock-mantle, con las APIs compatibles con OpenAI, existen además los Projects para aislar acceso y costes.)

Cost Explorer, Budgets y Cost Anomaly Detection

• AWS Cost Explorer: análisis de coste por servicio, tipo de uso, región y etiqueta; previsiones. Para Bedrock verás tipos de uso separados de tokens de entrada, salida, caché, etc.
• AWS Budgets: presupuestos de coste o uso con alertas (reales o previstas) por correo o SNS y budget actions (por ejemplo, aplicar una política de IAM que deniegue invocaciones).
• AWS Cost Anomaly Detection: modelos de ML que aprenden el gasto normal (con estacionalidad) y avisan de desviaciones con análisis de causa (servicio, cuenta, región, tipo de uso).
  • Tipos de monitor: por servicio de AWS, cuenta vinculada, cost allocation tag o cost category.
  • Alertas individuales por SNS, resúmenes diarios o semanales por correo; umbrales absolutos o porcentuales.
  • Se evalúa unas tres veces al día y la detección puede tardar hasta 24 horas; un servicio nuevo necesita unos 10 días de histórico.

aws ce create-anomaly-monitor --anomaly-monitor '{
  "MonitorName": "bedrock-por-app",
  "MonitorType": "CUSTOM",
  "MonitorSpecification": {"Tags": {"Key": "App", "Values": ["chatbot"]}}
}'

Trampas típicas del examen

• «Reducir latencia» ≠ «reducir coste». El streaming mejora la latencia percibida pero no abarata nada; batch abarata pero empeora la latencia.
• Provisioned Throughput no es una palanca de ahorro para tráfico variable: se paga por hora aunque no se use. Encaja con tráfico constante alto, modelos personalizados o cuando se exige capacidad garantizada.
• Prompt caching necesita prefijos largos, estables y al principio. Si el enunciado dice que el system prompt cambia en cada petición (por ejemplo, incluye la fecha y hora al principio), la caché no acierta: mueve lo variable al final.
• Batch no admite tool calling ni prompt caching (ni modelos con Provisioned Throughput). Sobre structured outputs la documentación se contradice (la página de structured outputs dice que batch es compatible y la de batch dice que no): si lo usas en batch, valida siempre el JSON de salida.
• Perfil global de cross-Region inference abarata y da capacidad, pero incumple residencia de datos: con «los datos deben permanecer en la UE», usa el perfil eu..
• Las métricas de Bedrock no tienen dimensión de usuario o aplicación. Para imputar costes: application inference profiles + etiquetas; para analizar por usuario: invocation logs (identity.arn, requestMetadata).
• requestMetadata no llega a Cost Explorer.
• CloudTrail no registra el contenido de prompts y respuestas: para eso, invocation logging.
• Invocation logging viene desactivado y es por región: si el enunciado dice «no hay registro de los prompts», esa es la causa.
• Caché semántica con umbral bajo = respuestas equivocadas servidas con total confianza.
• SageMaker Model Monitor está cerrado a clientes nuevos; para Bedrock, la monitorización de calidad se construye con evaluaciones y métricas personalizadas.
• Latency-optimized inference sigue en preview y con pocos modelos y regiones: si el enunciado exige producción en la UE, no es la respuesta.
• Palabras clave: near real-time → streaming/on-demand; overnight, no latency requirement → batch; spiky traffic → on-demand + cross-Region; steady, predictable high volume → Reserved o Provisioned Throughput; repeated long context → prompt caching; similar questions asked by many users → caché semántica.

Resumen

• El coste de una aplicación de IA generativa = tokens de entrada + tokens de salida (más caros) + embeddings + vector store + reranking + guardrails + orquestación; el modelo no siempre es la partida mayor.
• Mide tokens con CountTokens, el campo usage, las métricas AWS/Bedrock y los invocation logs.
• Palancas: modelo más pequeño, routing (propio o Intelligent Prompt Routing), prompt caching, batch (−50 %), Flex (−50 %), perfil global (≈ −10 %), destilación, cachés semántica y exacta, recorte de contexto y límites de salida.
• Latencia: streaming (percibida), TTFT, modelos pequeños, entrada corta, paralelismo, precomputación y latency-optimized inference (preview).
• Throughput: cuotas TPM/RPM con burndown, cross-Region inference, Reserved tier, Provisioned Throughput, colas y reintentos; en SageMaker AI, auto scaling con métricas de concurrencia.
• Observabilidad: métricas de Bedrock, invocation logging (desactivado por defecto), CloudWatch generative AI observability, AgentCore Observability con OpenTelemetry y Transaction Search, X-Ray, Synthetics y Managed Grafana.
• Costes: application inference profiles + cost allocation tags + Cost Explorer; Budgets para límites; Cost Anomaly Detection para desviaciones.

Cobertura del temario

Servicios dueños de este módulo y dónde se tratan: Amazon CloudWatch, CloudWatch Logs y CloudWatch Synthetics («Métricas…», «Model invocation logging», «Synthetics…»), AWS X-Ray («AgentCore Observability y trazas»), Amazon Managed Grafana y AWS Systems Manager («Synthetics, Managed Grafana y Systems Manager»), AWS Cost Explorer y AWS Cost Anomaly Detection («Imputar y vigilar los costes»), SageMaker Model Monitor («estado actual»), AWS Auto Scaling («Auto scaling de endpoints»), Amazon ElastiCache («Caché semántica»).

Practica lo aprendido

Documentación oficial para ampliar

• Amazon Bedrock pricing
• Prompt caching for faster model inference
• Service tiers for inference
• Batch inference
• How tokens are counted in Amazon Bedrock
• Amazon Bedrock runtime metrics
• Model invocation logging
• CloudWatch generative AI observability
• AgentCore Observability
• AWS Cost Anomaly Detection