Cómo construir operaciones de IA autónomas en Amazon Bedrock a escala

Amazon Bedrock impulsa la IA generativa para más de 100 000 organizaciones en todo el mundo, desde nuevas empresas hasta empresas globales de todos los sectores. Proporciona la infraestructura comprobada y las capacidades integrales para crear con confianza aplicaciones y agentes que funcionen en producción con la flexibilidad, la seguridad empresarial y la escalabilidad comprobada que necesita para innovar con audacia y ofrecer una IA que impulse un impacto empresarial real. A medida que las organizaciones escalan sus aplicaciones de IA generativa impulsadas por Amazon Bedrock en múltiples modelos básicos y cargas de trabajo de producción, la gestión operativa proactiva se vuelve clave para mantener la velocidad de la innovación.

A medida que crece la adopción de IA generativa en todos los equipos, las organizaciones pueden beneficiarse de una solución de monitoreo operativo diseñada específicamente que ofrece: 1) monitoreo proactivo de múltiples capas que anticipa las necesidades de aumento de cuotas a medida que crece la adopción mediante el seguimiento de patrones de uso y acelera la clasificación de problemas operativos para cargas de trabajo de IA generativa impulsadas por Amazon Bedrock; 2) automatización de casos de soporte contextual que acelera el tiempo medio de resolución al equipar a los ingenieros de soporte de AWS con la información que necesitan; 3) prevención de casos duplicados que suprime la creación de nuevos casos cuando ya existe un caso no resuelto de la misma categoría de alarma, evitando distracciones de las investigaciones activas; 4) notificaciones contextualizadas que permiten a los equipos de AI SRE actuar rápidamente; y 5) enfoque continuo en la innovación mediante la reducción de los gastos operativos manuales.

En esta publicación, presentamos Amazon Bedrock Ops Alert, una solución de monitoreo automatizado de tres capas que detecta proactivamente problemas operativos, ajusta dinámicamente los umbrales de alarma, clasifica las alarmas por categoría, crea automáticamente casos de soporte contextuales, ayuda a evitar casos duplicados cuando un caso no resuelto de la misma categoría de alarma ya está activo y entrega notificaciones contextualizadas a los equipos de AI SRE. Analizamos la arquitectura de la solución y cómo puede implementarla en su propio entorno.

Ampliación de la madurez operativa para cargas de trabajo de IA generativa

Amazon Bedrock proporciona cuotas de servicio para solicitudes por minuto (RPM) y tokens por minuto (TPM) para ayudar a administrar la asignación de recursos entre los clientes. Estas cuotas se pueden aumentar a través de casos de AWS Support a medida que aumentan las cargas de trabajo. Un enfoque inicial común utiliza soluciones de paneles de terceros respaldadas por métricas de Amazon CloudWatch, combinadas con procesos manuales para monitorear el consumo de cuotas y solicitar aumentos cuando sea necesario. Este enfoque resulta útil para los equipos durante la adopción temprana.

A medida que crece la adopción, las organizaciones suelen descubrir que la optimización de la carga de trabajo aborda las necesidades de capacidad de manera más efectiva que los aumentos de cuotas. La inferencia entre regiones ayuda a las organizaciones a gestionar ráfagas de tráfico no planificadas mediante el uso de computación en diferentes regiones de AWS. Cuando se utiliza un perfil de inferencia vinculado a una geografía específica, Amazon Bedrock selecciona automáticamente la región comercial óptima de AWS dentro de esa geografía para procesar la solicitud de inferencia. La inferencia global entre regiones extiende esto más allá de los límites geográficos al enrutar solicitudes de inferencia para respaldar las regiones comerciales de AWS en todo el mundo, optimizando los recursos disponibles y proporcionando un mayor rendimiento del modelo. Con perfiles de inferencia global, las cargas de trabajo ya no están limitadas por la capacidad regional individual, lo que brinda acceso a un conjunto mucho mayor de recursos y aproximadamente un 10 % de ahorro de costos en comparación con la inferencia geográfica entre regiones. En la publicación Desbloquee la escalabilidad global de la inferencia de IA utilizando la nueva inferencia global entre regiones en Amazon Bedrock con Claude Sonnet 4.5 de Anthropic, detallamos cómo los perfiles de inferencia global enrutan dinámicamente las solicitudes a través de la infraestructura global de AWS para absorber la demanda que de otro modo requeriría aumentos de cuota.

El almacenamiento en caché rápido es una característica opcional que reduce la latencia de la respuesta de inferencia y los costos de los tokens de entrada. Al agregar partes del contexto a una caché, el modelo omite el recálculo de las entradas, lo que permite a Amazon Bedrock compartir los ahorros de computación y reducir las latencias de respuesta. El almacenamiento en caché rápido ayuda cuando las cargas de trabajo tienen contextos largos y repetidos que se reutilizan con frecuencia para múltiples consultas, lo que reduce los costos hasta en un 90 % y la latencia hasta en un 85 %, lo que reduce directamente el consumo de tokens por minuto. En la publicación Utilice eficazmente el almacenamiento en caché de avisos en Amazon Bedrock, explicamos cómo estructurar los avisos para maximizar los accesos al caché en múltiples llamadas API. Técnicas adicionales como la inferencia por lotes y el enrutamiento de avisos inteligente reducen aún más la sobrecarga por solicitud al seleccionar dinámicamente el modelo más rentable para cada llamada.

A medida que las organizaciones adoptan estas estrategias de optimización y se expanden a través de múltiples modelos básicos y cargas de trabajo de producción, los equipos de AI SRE buscan complementarlas con monitoreo operativo automatizado para mantener la velocidad de innovación y reducir el tiempo medio de resolución. Específicamente, los equipos comúnmente identifican cuatro áreas de mejora:

Operaciones reactivas: los equipos de AI SRE a menudo se enteran de los problemas operativos solo cuando los usuarios comerciales informan del impacto. Esto obliga al equipo a operar de forma reactiva, con tiempo limitado para investigar y responder antes de que el impacto aumente. Oportunidad de enriquecimiento del contexto del caso: cuando surgen problemas de cuota, los casos de soporte pueden beneficiarse de un contexto más rico, distinguiendo aumentos de cuota simples de problemas que requieren una investigación más profunda, para ayudar a los ingenieros de soporte a resolver los casos más rápido. Multiplicar el esfuerzo operativo: a medida que las organizaciones adoptan nuevos modelos básicos para diferentes casos de uso, cada nuevo modelo requiere su propia configuración de monitoreo y solicitudes de aumento de cuota. Este trabajo pesado indiferenciado crece linealmente con la cartera de modelos. Objetivo móvil para los umbrales de alarma: cada aumento de cuota aprobado requiere que el equipo de AI SRE recalcule y actualice manualmente los umbrales de alarma de CloudWatch, lo que genera una sobrecarga operativa y el riesgo de una desviación de la configuración.

Descripción general de la solución

Amazon Bedrock Ops Alert es una solución basada en AWS CloudFormation que implementa una observabilidad integral de IA generativa a través de tres capas de detección complementarias. Cada capa proporciona una visibilidad diferente de las cargas de trabajo de IA generativa, desde la detección inmediata de problemas operativos hasta la identificación predictiva de anomalías.

La solución utiliza alarmas de Amazon CloudWatch, funciones de AWS Lambda, Amazon Simple Notification Service (Amazon SNS), la API de cuotas de servicio y la API de AWS Support.

El siguiente diagrama ilustra la arquitectura de la solución.

Los pasos del flujo de trabajo son los siguientes:

Durante la implementación, una función Lambda (Calculadora de cuotas) consulta la API de cuotas de servicio para conocer los valores de cuota actuales de RPM y TPM y calcula los umbrales de alarma aplicando porcentajes configurados. Los umbrales calculados se almacenan en el almacén de parámetros de AWS Systems Manager y los contactos de correo electrónico del equipo de AI SRE se almacenan en AWS Secrets Manager. Amazon Bedrock publica métricas de tiempo de ejecución (invocaciones, recuentos de tokens, errores, limitaciones y latencia) en CloudWatch. Tres capas de monitoreo independientes evalúan estas métricas: La Capa 1 (Detección de errores críticos) monitorea las limitaciones, los errores del cliente y los errores del servidor para generar alertas inmediatas. La capa 2 (supervisión de la tasa de uso) compara RPM, TPM y latencia con los umbrales calculados dinámicamente. La capa 3 (detección de anomalías) utiliza el aprendizaje automático de CloudWatch para identificar patrones inusuales en todas las métricas. Cuando se activa una alarma infantil, una alarma compuesta agrega el estado. La alarma compuesta se publica en un tema de SNS (tema de alarma sin formato). El tema de SNS invoca una función de procesador de notificaciones Lambda, que sondea la alarma compuesta para identificar qué alarmas secundarias se activaron y determina la gravedad de la alarma (crítica o advertencia). El procesador de notificaciones consulta la API de cuotas de servicio para conocer los valores de cuota de RPM y TPM actuales. El procesador de notificaciones consulta a CloudWatch para conocer las métricas de uso actuales, incluidas las RPM/TPM máximas y de estado estable durante los últimos 14 días y los tokens promedio por solicitud. También lee los umbrales de alarma almacenados en Parameter Store y compara el uso máximo con los umbrales para determinar el escenario del caso de soporte. Si la creación automatizada de casos de soporte está habilitada, la función clasifica la alarma como relacionada con la cuota o sin cuota, verifica si existen casos no resueltos mediante la detección de duplicados con reconocimiento de categorías (ventana retrospectiva configurable, valor predeterminado de 60 días) y agrega una comunicación al caso existente o crea un nuevo caso de AWS Support. Para las alarmas relacionadas con cuotas, el caso incluye datos de cuotas precargados con contenido validado por uso. Para alarmas fuera de cuota (como errores persistentes o anomalías de latencia), proporcionar contexto para ayudar con el análisis de la causa raíz. Una vez que se completa el procesamiento del caso de soporte, la función envía notificaciones por correo electrónico formateadas a las partes interesadas a través de un segundo tema de SNS (tema de notificación formateado), filtrado por preferencia de notificación (todas, críticas o advertencia). Si se creó un caso de soporte, el correo electrónico incluye el ID del caso y un enlace directo a la consola de AWS Support. La notificación formateada se envía por correo electrónico a las partes interesadas suscritas. En una programación configurable, una regla de Amazon EventBridge activa una función Lambda (Actualizador de alarmas). El Actualizador de alarmas consulta la API de cuotas de servicio para conocer los valores actuales de cuota de RPM y TPM. El Actualizador de alarmas recalcula los umbrales de alarma aplicando porcentajes configurados y actualiza las alarmas de CloudWatch con nuevos umbrales. Los umbrales actualizados se almacenan en Parameter Store con marcas de tiempo para el historial de seguimiento.

Arquitectura de monitoreo de tres capas

La solución implementa tres capas de monitoreo mediante alarmas de CloudWatch que funcionan de forma independiente para detectar problemas operativos en diferentes etapas.

Capa 1: Detección de errores críticos

La primera capa monitorea las métricas de error que indican problemas operativos:

Alarma ClientErrors: monitorea la métrica InvocationClientErrors para identificar solicitudes rechazadas debido a problemas del lado del cliente, como límites de cuota excedidos, errores de validación o parámetros no válidos. Alarma ServerErrors: monitorea la métrica InvocationServerErrors para identificar errores del lado del servicio que pueden requerir investigación. Alarma de aceleración: monitorea la métrica InvocationThrottles para identificar las solicitudes aceleradas explícitamente cuando se alcanza el límite de velocidad.

Estas alarmas utilizan umbrales configurables y períodos de evaluación. Establecer el umbral de error en 0 con un único período de evaluación activa alertas inmediatas cuando ocurre un error, mientras que los valores más altos brindan tolerancia para problemas transitorios.

Capa 2: Monitoreo de la tasa de uso

La segunda capa monitorea las métricas de uso frente a umbrales calculados dinámicamente y proporciona alertas proactivas antes de alcanzar el límite de cuota:

Alarma HighInvocationRate: monitorea la métrica de Invocaciones y se activa cuando la tasa de solicitudes de API supera el porcentaje de umbral de RPM configurado de su cuota. Alarma HighTPMQuotaUsage: supervisa la métrica EstimatedTPMQuotaUsage y se activa cuando el consumo estimado de cuota de tokens por minuto supera el porcentaje de umbral de TPM configurado de su cuota (incluye tokens de escritura de caché y multiplicadores de quemado de salida). Alarma de alta latencia: monitorea la métrica de InvocationLatency y se activa cuando el tiempo de respuesta supera el umbral de latencia configurado.

La solución calcula automáticamente los umbrales de alarma consultando la API de cuotas de servicio y aplicando porcentajes configurables. Por ejemplo, con un umbral del 80 % y una cuota de 100 RPM, la alarma de RPM se activa a 80 solicitudes por minuto. Para TPM, el mismo umbral del 80% en una cuota de 1.000.000 de TPM da un umbral de 800.000 tokens efectivos. La alarma de TPM utiliza la métrica EstimatedTPMQuotaUsage que rastrea el consumo estimado de cuota de TPM, incluidos los tokens de escritura de caché y los multiplicadores de consumo de salida.

Capa 3: Detección de anomalías

La tercera capa utiliza la detección de anomalías de CloudWatch como tipo de umbral para identificar patrones inusuales en todas las métricas:

Alarma de anomalía de invocación: monitorea la métrica de invocaciones mediante la detección de anomalías para identificar cambios inusuales en el volumen de solicitudes. Alarma InputTokenAnomaly: monitorea la métrica InputTokenCount mediante la detección de anomalías para identificar el uso anormal del token de entrada. Alarma OutputTokenAnomaly: monitorea la métrica OutputTokenCount mediante la detección de anomalías para identificar el uso anormal del token de salida. Alarma LatencyAnomaly: monitorea la métrica InvocationLatency utilizando la detección de anomalías para identificar tendencias de degradación del rendimiento.

El aprendizaje automático de CloudWatch analiza datos históricos para establecer líneas de base de comportamiento normal y luego alerta cuando las métricas actuales exceden el umbral superior del rango esperado. La solución sólo controla las desviaciones al alza: las caídas de consumo son señales positivas que no requieren intervención. Este enfoque detecta problemas que los umbrales estáticos pasan por alto, como aumentos graduales del consumo de cuotas o aumentos repentinos de uso inesperados.

Gestión de umbrales automatizada

La solución se adapta dinámicamente a los cambios de cuota mediante el recálculo automatizado del umbral:

Cálculo inicial: durante la implementación, una función Lambda consulta la API de cuotas de servicio y calcula los umbrales de alarma en función de las cuotas actuales y los porcentajes configurados. Actualizaciones programadas: una regla de EventBridge activa el recálculo del umbral en un cronograma configurable (predeterminado: cada 1 día). Actualizaciones automáticas de alarmas: cuando los aumentos de cuota aprobados cambian los valores de cuota, la solución actualiza las alarmas de CloudWatch con nuevos umbrales. Historial de umbrales: los umbrales calculados se almacenan en Parameter Store, una capacidad de AWS Systems Manager, con marcas de tiempo.

Esta automatización alivia el mantenimiento manual del umbral cuando se aprueban más solicitudes de aumento de cuota. Los equipos de AI SRE ya no necesitan realizar un seguimiento de los cambios de cuota y actualizar manualmente las configuraciones de alarma: el sistema se autocorrige.

La siguiente tabla describe cómo se derivan los umbrales de alarma a partir de los valores de Cuotas de servicio.

Ejemplo de fórmula de umbral Umbral de RPM Cuota de RPM × (RequestsPerMinuteThresholdPercent / 100) Cuota de 10 000 RPM × 80 % = Umbral de 8 000 TPM Cuota de TPM × (TokensPerMinuteThresholdPercent / 100) 6 250 000 Cuota de TPM × 80 % = 5 000 000

El porcentaje de umbral de TPM se aplica directamente a la cuota de TPM. La validación de uso compara el TPM máximo de 14 días con este umbral al determinar el escenario del caso de soporte.

Creación automatizada de casos de soporte

Opcionalmente, la solución automatiza la creación de casos de AWS Support cuando se detectan problemas operativos. Esta característica requiere un plan de AWS Business o Enterprise Support para acceder a la API de soporte.

El flujo de trabajo funciona de la siguiente manera:

La alarma compuesta se activa cuando una alarma infantil entra en estado de ALARMA. Una función Lambda sondea el estado de la alarma compuesta y busca alarmas infantiles elegibles. La función lee los umbrales de alarma almacenados en Parameter Store y compara el uso máximo de 14 días con los umbrales para determinar el escenario del caso de soporte. La función clasifica la alarma como relacionada con la cuota o sin cuota y verifica la API de soporte para detectar casos no resueltos existentes mediante la detección de duplicados con reconocimiento de categoría (ventana retrospectiva configurable, valor predeterminado de 60 días). Si existe un caso no resuelto de la misma categoría, el sistema agrega una comunicación al caso existente con detalles completos de la alarma, métricas actualizadas y contexto de urgencia. Si no existe ningún duplicado, el sistema crea un nuevo caso de soporte con contenido apropiado para el escenario, ya sea una solicitud de aumento de cuota con detalles validados por el uso o una solicitud de investigación de servicio sin detalles de cuota.

El sistema clasifica las alarmas en dos categorías y determina la respuesta adecuada.

Las alarmas relacionadas con las cuotas activan un caso de soporte de “Solicitud de cuota” con contenido validado por el uso:

Las alarmas específicas de RPM (HighInvocationRate, InvocationAnomaly) solicitan únicamente un aumento de cuota de RPM. Las alarmas específicas de TPM (HighTPMQuotaUsage, InputTokenAnomaly, OutputTokenAnomaly) solicitan únicamente un aumento de cuota de TPM. Las alarmas de cuota indeterminada (reguladores, errores de cliente) solicitan aumentos de cuota tanto de RPM como de TPM, lo que proporciona contexto para ayudar a identificar qué límite se alcanzó.

Las alarmas fuera de cuota (ServerErrors, HighLatency, LatencyAnomaly) activan un caso de soporte de “Solicitud de investigación” que proporciona contexto de alarma y datos de uso para ayudar con el análisis de la causa raíz, sin detalles de aumento de cuota.

La siguiente tabla resume la clasificación de alarmas y el enrutamiento de cuotas.

Clasificación Alarmas Tipo de caso Cuota solicitada Alarmas específicas de RPM HighInvocationRate, InvocationAnomaly Solicitud de cuota Solo aumento de cuota de RPM Alarmas específicas de TPM HighTPMQuotaUsage, InputTokenAnomaly, OutputTokenAnomaly Solicitud de cuota Solo aumento de cuota de TPM Alarmas de cuota indeterminadas Reguladores, ClientErrors Solicitud de cuota Aumentos de cuota de RPM y TPM Alarmas sin cuota ServerErrors, HighLatency, Solicitud de investigación de anomalía de latencia No se solicita aumento de cuota

Árbol de decisión de escenarios validados por uso

Antes de crear un caso de soporte relacionado con la cuota, la solución compara las métricas de uso máximo de 14 días con los umbrales de alarma almacenados para determinar la respuesta adecuada. Esta validación de uso garantiza que los casos de soporte incluyan el contexto y el tono correctos para el ingeniero de soporte.

El siguiente diagrama ilustra el árbol de decisión del escenario.

Detalles del escenario validado por uso

Las siguientes secciones describen cada escenario en detalle, incluidas las condiciones desencadenantes, el contenido del caso de soporte y ejemplos.

Sin cuota: se activan ServerErrors, HighLatency o LatencyAnomaly y ningún otro tipo de alarma. No se incluyen detalles sobre el aumento de cuota. El caso proporciona al ingeniero de soporte el contexto de la alarma, métricas de uso y condiciones de activación para ayudar con el análisis de la causa raíz.

Campo Detalle Tipo de caso Solicitud de investigación Alarmas ServerErrors-Critical (InvocationServerErrors), HighLatency-Warning (InvocationLatency), LatencyAnomaly-Warning (InvocationLatency) Cuota solicitada No se solicita aumento de cuota Justificación Estas alarmas indican errores del servidor, como errores 5xx o degradación de la latencia, no límites de cuota

Ejemplos

Alarma ServerErrors activada:

Campo Valor Alarma {CustomerName}-Bedrock-ServerErrors-Critical-{ModelName} Métrica InvocationServerErrors (Suma por minuto) Gravedad Decisión CRÍTICA Las alarmas activadas son sin cuota → sin cuota (métricas de uso no evaluadas) Solicitud de investigación de resultados sin detalles de aumento de cuota

Nuevo modelo: se activó una alarma relacionada con la cuota, pero el modelo no tiene historial de uso (RPM máximo = 0, TPM máximo = 0) o no se pudieron recuperar métricas y umbrales. El caso de soporte pasa por alto la protección de uso e incluye detalles de aumento de cuota, teniendo en cuenta que el modelo se implementó recientemente con un historial de uso limitado. El caso señala que el modelo se implementó recientemente con un historial de uso limitado e incluye detalles de aumento de cuota para la revisión del ingeniero de soporte.

Campo Detalle Tipo de caso Alarmas de solicitud de cuota Cualquiera de: ClientErrors-Critical, Throttles-Critical, HighInvocationRate-Warning, HighTPMQuotaUsage-Warning, InvocationAnomaly-Warning, InputTokenAnomaly-Warning, OutputTokenAnomaly-Warning Cuota solicitada alarmas específicas de RPM → RPM solamente. Alarmas específicas de TPM → Solo TPM. Alarmas de cuota indeterminada (reguladores, errores de cliente) → Tanto RPM como TPM Justificación El caso de soporte pasa por alto la protección de uso porque el modelo no tiene un historial de uso para validar.

Ejemplo

Alarma InputTokenAnomaly activada en un modelo recién implementado:

Campo Valor Alarma {CustomerName}-Bedrock-InputTokenAnomaly-Warning-{ModelName} Métrica InputTokenCount (Suma por minuto) Clasificación Alarma específica de TPM → solo aumento de cuota de TPM Cuota de RPM 200 RPM pico 0 (sin historial de uso) Cuota de TPM 500 000 TPM pico 0 (sin historial de uso) Decisión pico_rpm = 0 Y pico_tpm = 0 → nuevo_modelo Resultado Cuota Solicitud. Detalles de aumento de TPM incluidos

Uso elevado (el pico alcanza o supera el umbral): se activó una alarma relacionada con la cuota Y el pico de RPM de 14 días alcanza o supera el umbral de RPM O el pico de TPM de 14 días alcanza o supera el umbral de TPM. El caso de soporte incluye detalles del aumento de cuota con datos de uso que confirman tendencias de consumo sostenidas. Para gravedad CRÍTICA, el caso incluye una nota que indica que el uso se está acercando a los límites de velocidad.

Campo Detalle Tipo de caso Alarmas de solicitud de cuota Cualquiera de: ClientErrors-Critical, Throttles-Critical, HighInvocationRate-Warning, HighTPMQuotaUsage-Warning, InvocationAnomaly-Warning, InputTokenAnomaly-Warning, OutputTokenAnomaly-Warning Cuota solicitada alarmas específicas de RPM → RPM solamente. Alarmas específicas de TPM → Solo TPM. Alarmas de cuota indeterminada (reguladores, errores de cliente) → Tanto RPM como TPM Justificación El uso máximo alcanza o supera el umbral de alarma, lo que confirma las tendencias sostenidas de uso de cuota

Ejemplos

Alarma de acelerador activada:

Campo Valor Alarma {CustomerName}-Bedrock-Throttles-Critical-{ModelName} Métrica InvocationThrottles (Suma por minuto) Clasificación Alarma de cuota indeterminada → Aumentos de cuota de RPM y TPM Gravedad Cuota de RPM CRÍTICA Umbral de 10 000 RPM 8 000 (80 % de la cuota) RPM máxima Cuota de 9 500 TPM Umbral de 6 250 000 TPM 5 000 000 (80 % de la cuota) TPM máximo 3 000 000 Decisión pico_rpm (9 500) >= umbral_rpm (8 000) → solicitud de cuota de resultado de uso alto. Se incluyen detalles de aumento de RPM y TPM. “Procesamiento acelerado”

Alarma HighTPMQuotaUsage activada:

Campo Valor Alarma {CustomerName}-Bedrock-HighTPMQuotaUsage-Warning-{ModelName} Métrica EstimadoTPMQuotaUsage (Suma por minuto) Clasificación Alarma específica de TPM → Solo aumento de cuota de TPM Cuota de RPM Umbral de 200 RPM 160 (80 % de la cuota) RPM máximo 150 Cuota de TPM 200 000 Umbral de TPM 160 000 (80 % de cuota) Pico TPM 210 000 Decisión pico_tpm (210 000) >= tpm_threshold (160 000) → solicitud de cuota de resultado de uso alto. Detalles de aumento de TPM incluidos

Uso bajo (pico por debajo del umbral): se activó una alarma relacionada con la cuota, pero el RPM máximo de 14 días está por debajo del umbral de RPM Y el TPM máximo de 14 días está por debajo del umbral de TPM. Dado que las métricas de uso sugieren un evento transitorio en lugar de tendencias sostenidas de consumo de cuotas, la solución envía una notificación por correo electrónico al equipo de AI SRE para investigar primero la causa raíz y colaborar con el ingeniero de soporte, si es necesario. El caso de soporte incluye detalles del aumento de cuota solo como referencia, en caso de que la investigación confirme la necesidad.

Campo Detalle Tipo de caso Alarmas de solicitud de cuota Cualquiera de: ClientErrors-Critical, Throttles-Critical, HighInvocationRate-Warning, HighTPMQuotaUsage-Warning, InvocationAnomaly-Warning, InputTokenAnomaly-Warning, OutputTokenAnomaly-Warning Cuota solicitada alarmas específicas de RPM → RPM solamente (como referencia). Alarmas específicas de TPM → Solo TPM (como referencia). Alarmas de cuota indeterminada (reguladores, errores de cliente) → Tanto RPM como TPM (como referencia) Justificación Las métricas de uso sugieren un evento transitorio en lugar de tendencias de uso sostenidas. Los detalles de la cuota se proporcionan como referencia en caso de que la investigación confirme la necesidad.

Ejemplos

Alarma de anomalía de invocación activada:

Campo Valor Alarma {CustomerName}-Bedrock-InvocationAnomaly-Warning-{ModelName} Invocaciones de métricas (suma por minuto) Clasificación Alarma específica de RPM → Solo aumento de cuota de RPM Cuota de RPM 10 001 Umbral de RPM 8000 (80 % de la cuota) RPM máximo 5578 Cuota de TPM 6 250 000 Umbral de TPM 5 000 000 (80 % de cuota) Pico TPM 3,404,691 Decisión pico_rpm (5,578) < rpm_threshold (8,000) AND pico_tpm (3,404,691) < tpm_threshold (5,000,000) → low_usage Resultado Solicitud de cuota con tono de investigación primero. Detalles de aumento de RPM incluidos como referencia.

Alarma ClientErrors activada:

Campo Valor Alarma {CustomerName}-Bedrock-ClientErrors-Critical-{ModelName} Clasificación Alarma de cuota indeterminada → Aumentos de cuota de RPM y TPM Gravedad Cuota de RPM CRÍTICA Umbral de 200 RPM 160 (80 % de la cuota) RPM máximo Cuota de 50 TPM 200 000 Umbral de TPM 160 000 (80 % de la cuota) TPM máximo 80 000 Decisión pico_rpm (50) < rpm_threshold (160) AND pico_tpm (80,000) < tpm_threshold (160,000) → low_usage Solicitud de cuota de resultados con tono de investigación primero. Se incluyen detalles de aumento tanto de RPM como de TPM como referencia

Esta validación confirma que las solicitudes de aumento de cuota reflejan patrones de uso reales y, al mismo tiempo, proporciona detalles de la cuota como referencia para la investigación del ingeniero de soporte.

Gestión de casos de soporte y notificaciones por correo electrónico

La solución utiliza detección de duplicados con reconocimiento de categorías para ayudar a prevenir casos redundantes. Cuando se activa una nueva alarma y ya existe un caso no resuelto de la misma categoría (Solicitud de cuota o Solicitud de investigación), el sistema agrega una comunicación al caso existente en lugar de crear un duplicado. La comunicación adjunta incluye detalles completos de la alarma, métricas de uso actualizadas y solicitudes de aumento de cuota (si corresponde), precedidas de un contexto de urgencia que indica que la situación está empeorando. Esto garantiza que el ingeniero de soporte esté informado de las nuevas señales sin crear casos conflictivos. Un caso de solicitud de cuota para un tipo de alarma no bloquea un caso de solicitud de investigación para un tipo de alarma diferente y lo contrario también ocurre.

Los parámetros del caso de soporte se almacenan en Parameter Store y se pueden actualizar sin volver a implementar la pila de CloudFormation. Puede habilitar o deshabilitar la creación automatizada de casos, ajustar los porcentajes de aumento de cuota (0 a 100 %) y configurar el filtrado de notificaciones por correo electrónico (todas las alertas, solo críticas o solo advertencia).

La siguiente captura de pantalla muestra un caso de soporte automatizado de “Solicitud de cuota” creado para una alarma relacionada con la cuota, precargado con datos de cuota validados por el uso y detalles de la solicitud de aumento. Este contexto precargado ayuda al ingeniero de soporte a resolver el caso más rápido al proporcionar la información necesaria por adelantado. Esta captura de pantalla muestra el formato del caso de soporte generado por la solución.

La siguiente captura de pantalla muestra un caso de soporte de “Solicitud de investigación” automatizado creado para una alarma fuera de cuota (como errores del servidor o problemas de latencia), que proporciona contexto de alarma y métricas relevantes para permitir una investigación eficiente de la causa raíz. Esta captura de pantalla muestra el formato del caso de soporte generado por la solución.

Las notificaciones por correo electrónico se envían una vez que se completa el procesamiento del caso de soporte. Si se creó un caso de soporte, el correo electrónico incluye el ID del caso y un enlace directo a la consola de AWS Support, lo que brinda al equipo de AI SRE visibilidad inmediata del caso automatizado y respalda el seguimiento coordinado. El contenido del correo electrónico está diseñado para la perspectiva del equipo de AI SRE, mientras que el contenido del caso de soporte está diseñado para el ingeniero de soporte.

Resultados

Amazon Bedrock Ops Alert ofrece los siguientes resultados:

Eficiencia operativa mejorada: el equipo de AI SRE pasa del monitoreo manual a un trabajo de mayor valor. Clasificación de alarmas inteligente: las alarmas fuera de cuota (errores del servidor, anomalías de latencia) se dirigen a casos de investigación en lugar de solicitudes de aumento de cuota, lo que proporciona a los ingenieros de soporte un contexto de caso específico y acelera la resolución de la causa raíz. Casos de soporte validados por uso: la solución compara el uso máximo con los umbrales antes de crear casos de soporte, validando que las solicitudes de aumento de cuota reflejan patrones de uso reales e incluyen el contexto adecuado para el ingeniero de soporte. Reducción del tiempo medio de resolución: la creación automatizada de casos reduce el esfuerzo manual para cada incidente de horas a minutos. Gestión proactiva de cuotas: las solicitudes de aumento de cuotas se inician antes de que el uso alcance los límites de velocidad en las aplicaciones de producción. Sin mantenimiento de umbral manual: las alarmas se mantienen precisas a medida que los aumentos de cuota aprobados cambian el objetivo, sin necesidad de intervención del ingeniero. Base escalable: se pueden monitorear modelos Bedrock adicionales mediante la implementación de instancias de pila adicionales, lo que respalda una cartera de IA generativa en expansión.

Implementar la solución

Para obtener instrucciones de implementación paso a paso, incluidos requisitos previos, empaquetado, implementación de la pila de CloudFormation, referencia de parámetros, pruebas y limpieza, consulte la Guía de implementación en el repositorio de GitHub.

Conclusión

El monitoreo generativo de IA es diferente al monitoreo de infraestructura tradicional. A medida que la adopción de la IA generativa desdibuja los límites entre los equipos de negocios y de tecnología, y los equipos que no son de ingeniería ahora utilizan aplicaciones de IA generativa personalizadas impulsadas por modelos básicos alojados en Amazon Bedrock, las organizaciones deben repensar su estrategia de monitoreo operativo para adaptarse a esta nueva realidad.

En esta publicación, presentamos Amazon Bedrock Ops Alert, una solución de monitoreo operativo multicapa compuesta por servicios nativos de AWS, para abordar las necesidades operativas de ejecutar cargas de trabajo de IA generativa a escala. La arquitectura de monitoreo de tres capas, que consta de detección de errores críticos, monitoreo de la tasa de uso y reconocimiento de patrones de anomalías, brinda visibilidad integral de las cargas de trabajo de IA generativa en relación con problemas operativos, tendencias de uso y comportamientos inusuales. La clasificación de alarmas inteligente de la solución dirige los problemas del lado del cliente, los problemas de latencia y las señales relacionadas con las cuotas al tipo de caso de soporte adecuado, cada uno de los cuales está enriquecido con el contexto que un ingeniero de soporte necesita para actuar rápidamente. Antes de crear un caso de soporte, la protección de validación de uso compara el uso máximo reciente con los umbrales almacenados para confirmar que el caso está justificado, y la prevención de casos duplicados suprime los casos nuevos cuando un caso no resuelto de la misma categoría de alarma ya está activo, manteniendo las investigaciones enfocadas. Las notificaciones contextualizadas por correo electrónico mantienen al equipo de AI SRE informado y alineado con el caso automatizado en todo momento. Al automatizar el recálculo del umbral de alarma de CloudWatch, la solución también elimina el esfuerzo manual de investigar el nuevo valor de cuota, calcular el umbral de alarma apropiado y actualizar las alarmas después de cada aumento de cuota aprobado, manteniendo las alarmas precisas y aliviando el riesgo de umbrales obsoletos.

Juntas, estas capacidades cambian las operaciones del monitoreo reactivo al monitoreo operativo proactivo, lo que reduce el tiempo medio de resolución, anticipa mayores necesidades de aumento de cuotas a medida que crece la adopción y libera a los equipos de AI SRE para que se concentren en crear aplicaciones de IA generativas en lugar de monitorear la infraestructura.

Puede ampliar esta solución integrándola con sistemas de gestión de incidentes, monitoreando múltiples modelos de Bedrock con implementaciones de pilas separadas, personalizando patrones de alarma para casos de uso específicos e implementando escalamiento predictivo basado en patrones de uso históricos.

Para comenzar, visite el repositorio de alertas de Amazon Bedrock Ops en GitHub. Para obtener más información sobre las cuotas de Amazon Bedrock, consulte Cuotas y puntos de enlace de Amazon Bedrock. Para explorar Amazon Bedrock, visite la página de detalles de Amazon Bedrock.

Descargo de responsabilidad: esta solución se proporciona tal cual para fines educativos. Usted es responsable de evaluar, probar y validar todas las soluciones en entornos que no son de producción antes de implementarlas en sistemas de producción. Realice pruebas exhaustivas que incluyan validación del rendimiento, evaluaciones de seguridad y verificación del cumplimiento para asegurarse de que las soluciones cumplan con sus requisitos y obligaciones reglamentarias específicas.

Sobre los autores