Reducir el tiempo entre la detección, la investigación y la remediación de incidentes es una prioridad crítica para las organizaciones que ejecutan cargas de trabajo de producción en AWS. Cuando surge un problema, los ingenieros de guardia a menudo necesitan diagnosticar rápidamente el problema en los componentes de la aplicación, identificar la causa raíz y aplicar la corrección, muchas veces en medio de la noche.
AWS DevOps Agent, un agente impulsado por IA que realiza triaje de incidentes de forma autónoma durante todo el día basándose en métricas correlacionadas, logs y topología de aplicaciones, aborda la primera parte de esta prioridad al proporcionar análisis de causa raíz (RCA) y acciones recomendadas para la resolución. Sin embargo, para mantener el control y ayudar a prevenir cambios no deseados, las organizaciones normalmente mantienen sus agentes de observabilidad, incluido AWS DevOps Agent, en un modo de observación y reporte, donde el agente diagnostica problemas pero no modifica directamente los recursos de producción. En esta publicación, demostramos cómo usar AWS Lambda Durable Functions, una capacidad de AWS Lambda, Amazon EventBridgey Amazon Bedrock para crear un flujo de trabajo de remediación automatizado que complementa a AWS DevOps Agent para completar el paso de resolución del problema. Este flujo de trabajo transforma los resúmenes de investigación en correcciones prevalidadas listas para una acción de aprobación única, ayudándole a reducir el tiempo medio de resolución (MTTR) y liberar a sus ingenieros de guardia del trabajo diagnóstico repetitivo.
Descripción general de la solución
Con AWS Lambda Durable Functions, puede crear aplicaciones de múltiples pasos resilientes y flujos de trabajo de IA que pueden ejecutarse durante hasta un año sin que tenga que gestionar infraestructura adicional ni escribir código personalizado de gestión de estado y manejo de errores. Estas funciones crean automáticamente puntos de control del progreso, suspenden la ejecución durante tareas de larga duración y se recuperan de fallos manteniendo un progreso confiable a pesar de las interrupciones.
El siguiente diagrama ilustra la arquitectura de la solución.
Figura 1: Flujo de trabajo de remediación automatizada desde una investigación de AWS DevOps Agent a través de Amazon EventBridge, AWS Lambda y Amazon Bedrock, con aprobación humana opcional antes de que los cambios lleguen a la infraestructura
El flujo de trabajo consta de los siguientes pasos:
- AWS DevOps Agent completa una investigación de incidentes y emite un evento que contiene síntomas, hallazgos y análisis de causa raíz.
- Amazon EventBridge recibe el evento de finalización de la investigación y activa la función
devops-agent-triggercon el contenido de la investigación. - La función de Lambda empaqueta el resumen de la investigación e invoca la función
devops-agent-remediation-durabledurable. - La función durable envía el contexto de la investigación a Amazon Bedrock, que analiza los hallazgos y busca remediaciones aplicables.
- Amazon Bedrock identifica y enumera las herramientas de remediación disponibles a partir de una lista de funciones de Lambda aprobadas previamente seleccionadas:
devops-agent-lambda-tool. - Amazon Bedrock propone acciones de remediación específicas basadas en los hallazgos de la investigación y en las herramientas disponibles.
- Para acciones de solo lectura, la función durable ejecuta las herramientas de remediación de forma autónoma. Para cambios de infraestructura, el flujo de trabajo se suspende y espera la aprobación humana antes de continuar.
- Después de la aprobación, la función durable aplica las acciones de remediación a la infraestructura utilizando las herramientas seleccionadas.
La función durable se ejecuta como un bucle agéntico, llamando iterativamente a Amazon Bedrock, ejecutando las herramientas aprobadas y retroalimentando los resultados en la conversación hasta que la remediación esté completa. Para mantener las acciones automatizadas seguras y auditables, el orquestador aplica una lista de permitidos cuidadosamente seleccionada de herramientas de remediación. Cada herramienta es una función Lambda diseñada para un propósito específico y bien delimitado, como leer la configuración de una función Lambda o actualizar una declaración de política de AWS Identity and Access Management (IAM). Amazon Bedrock solo puede seleccionar e invocar herramientas de este conjunto aprobado, lo que mantiene el alcance de las acciones automatizadas bajo control. El flujo de trabajo distingue además entre operaciones de solo lectura y operaciones de modificación. Las herramientas de solo lectura se ejecutan de manera autónoma sin intervención humana. Las acciones de modificación que alterarían el estado de la infraestructura hacen que la función durable suspenda la ejecución y espere la aprobación humana. Aquí es donde AWS Lambda Durable Functions ofrece una ventaja clave. La función puntos de control progreso y hace pausas de minutos, horas o incluso días sin consumir recursos de cómputo, y luego se reanuda exactamente donde lo dejó después de recibir la señal de aprobación. Para cuando el ingeniero de guardia interviene, el sistema ya ha recopilado las configuraciones relevantes, correlacionado la causa raíz con las acciones de remediación disponibles y preparado un conjunto de cambios prevalidados listos para su aprobación con un solo clic. La implementación actual utiliza una señal de aprobar o rechazar. Dado que el callback acepta un payload JSON arbitrario, puede extender la aprobación para incluir anulaciones de parámetros u observaciones del revisor. Estas pueden retroalimentarse en la conversación de Bedrock para refinar la remediación propuesta antes de su ejecución.
En las siguientes secciones, repasamos los detalles de la implementación, incluida la configuración de la regla de Amazon EventBridge y la lógica de orquestación de la función durable. Luego desplegamos la solución usando la AWS Cloud Development Kit (AWS CDK).
Requisitos previos
Antes de implementar esta solución, verifique que cumple los siguientes requisitos previos:
- El Interfaz de línea de comandos de AWS (AWS CLI) instalada y configurada.
- Python 3.14 o posterior.
- El AWS CDK instalado.
- Un activo Espacio de AWS DevOps Agent.
- (Opcional) Kiro con el Kit de herramientas de agente para AWS. El Agent Toolkit brinda a Kiro acceso seguro a las API de AWS a través de un MCP Server administrado con controles de acceso basados en IAM. Si usa Kiro, los pasos de simulación del incidente, despliegue y limpieza de esta publicación se pueden completar con mensajes de lenguaje natural en lugar de ejecutar comandos de la CLI manualmente. Para configurarlo, agregue el AWS MCP Server a
~/.kiro/settings/mcp.json(instrucciones de configuración). El repositorio incluye un archivo de reglas de Kiro y de agentes que proporciona a Kiro el contexto del proyecto, la secuencia de despliegue y las convenciones de seguridad automáticamente.
Simule el incidente
Para demostrar el flujo de trabajo de extremo a extremo, simulamos un escenario común: una función de Lambda que excede su tiempo de espera configurado. Esto le da a AWS DevOps Agent un incidente real que investigar y pone en marcha el flujo de trabajo de remediación.
Para mantener el enfoque en la propia solución de remediación, los pasos para crear e invocar esta función de prueba se mantienen en la repositorio. Incluye un devops-agent-timeout función e instrucciones paso a paso para desplegarla, invocarla y confirmar el error de timeout en Amazon CloudWatch Logs. Para ver la guía completa, consulte el Sección “Simulate the incident” del README.
Después de que la función se haya desplegado y haya producido al menos un error de timeout, estará listo para iniciar una investigación con AWS DevOps Agent.
Despliegue la solución usando AWS CDK
Complete los siguientes pasos para desplegar los recursos restantes de la solución:
Kiro: Si tiene Kiro con el Agent Toolkit for AWS configurado (consulte los Prerequisites), abra el repositorio clonado en Kiro y pregunte: “Configura el entorno de Python y despliega el stack de CDK. Muéstrame qué recursos se crearán antes de desplegar.” Kiro lee las reglas del proyecto desde el repositorio, configura el entorno virtual, instala las dependencias y le muestra los recursos planificados antes de desplegar. Confirma cada cambio de infraestructura antes de ejecutarlo, siguiendo el mismo patrón de human-in-the-loop que la propia solución de remediación utiliza. Para desplegar manualmente, siga estos pasos.
- Clone el código de AWS CDK alojado en GitHub:
$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git - Navegue al directorio
sample-automate-remediation-post-devops-agent-investigation:$ cd sample-automate-remediation-post-devops-agent-investigation - Inicialice (bootstrap) el AWS CDK. Esto es necesario la primera vez que utiliza el AWS CDK en una región de AWS específica (una combinación de una cuenta de AWS y una Región de AWS).
$ cdk bootstrap - Despliegue la pila:
$ cdk deploy
El AWS CDK aprovisiona y configura automáticamente los siguientes recursos:
- Tres funciones Lambda:
devops-agent-trigger.devops-agent-remediation-durable.devops-agent-lambda-tool.
- Regla de Amazon EventBridge.
El AWS CDK gestiona automáticamente los permisos de IAM utilizando principios de privilegio mínimo y las mejores prácticas de seguridad de AWS. Por ejemplo, se conceden a Amazon EventBridge lambda:InvokeFunction permisos para la devops-agent-trigger función. La pila concede el permiso aidevops:ListJournalRecords a la devops-agent-trigger función para que pueda obtener resúmenes de investigación del diario de AWS DevOps Agent. También concede el permiso bedrock:InvokeModel a la devops-agent-remediation-durable función para que pueda invocar Amazon Bedrock.
Valide la solución
Con la pila de remediación desplegada y la devops-agent-timeout función fallando con errores de tiempo de espera, ahora podemos recorrer el flujo de trabajo de extremo a extremo.
Inicie una investigación con AWS DevOps Agent
Abra la consola de AWS DevOps Agent, navegue hasta su espacio de agente y pregunte: «¿Qué está sucediendo con la función devops-agent-timeout?”
Figura 2: Inicio de una investigación desde la consola de AWS DevOps Agent
La investigación se inicia y tarda unos minutos en completarse. Durante este tiempo, AWS DevOps Agent correlaciona de manera autónoma las métricas de CloudWatch, los registros y la configuración de la función para determinar la causa raíz.
Figura 3: AWS DevOps Agent correlacionando señales durante la investigación
Una vez completada la investigación, AWS DevOps Agent presenta el análisis de causa raíz, identificando que el tiempo de espera de la función es insuficiente para la carga de trabajo.
Figura 4: El análisis de causa raíz que identifica el tiempo de espera insuficiente de la función
Verifique la ejecución de la Lambda de activación
La finalización de la investigación emite un evento Investigation Completed a Amazon EventBridge.
La regla activa la devops-agent-trigger Función Lambda, que obtiene el resumen de la investigación del journal de AWS DevOps Agent. En el /aws/lambda/devops-agent-trigger grupo de logs de CloudWatch, puede ver el resumen analizado que se envía a la devops-agent-remediation-durable función durable, incluidos los síntomas, las causas raíz, las causas contribuyentes y las brechas de la investigación.
Figura 5: El resumen de investigación analizado en el grupo de logs de CloudWatch de la función de activación
Monitorear la ejecución de la función durable
Vaya a la consola de Lambda, abra la devops-agent-remediation-durable función y elija la pestaña Durable executions . Elija la nueva ejecución para inspeccionar sus pasos con checkpoints.
Figura 6: La ejecución de la función durable y sus pasos con checkpoints en la consola de Lambda
El orquestador durable comienza su bucle agéntico enviando el contexto de la investigación a Amazon Bedrock. En la primera llamada a Bedrock, el modelo analiza el resumen de la investigación y determina que debe inspeccionar la configuración actual de la función antes de proponer una corrección. Selecciona la herramienta lambda_get_function_configuration de la lista de permitidos. Como se trata de una operación de solo lectura, se ejecuta de forma autónoma sin requerir aprobación humana. El resultado del paso muestra la configuración actual de la función devops-agent-timeout , confirmando un valor de timeout de 3 segundos.
Figura 7: La llamada a la herramienta de solo lectura que devuelve la configuración actual de timeout de 3 segundos
Amazon Bedrock propone la remediación
Con la configuración actual confirmada, Amazon Bedrock procede a la siguiente iteración. Razona que el timeout de 3 segundos es la causa raíz de los fallos y propone aumentarlo a 30 segundos. La respuesta de Amazon Bedrock contiene tanto el razonamiento como la llamada a la herramienta:
{
....
},
"output": {
"message": {
"role": "assistant",
"content": [
{
"text": "Now I can see the current configuration confirms the issue - the function has a 3-second timeout. Given that this appears to be a test function for timeout scenarios (based on the name \"devops-agent-timeout\" and its association with \"DevOps Agent Test Infrastructure\"), I'll increase the timeout to a reasonable value that should allow the function to complete successfully. I'll set it to 30 seconds, which is a common timeout for Lambda functions that need more execution time."
},
{
"toolUse": {
"toolUseId": "tooluse_lcGHbWDxng5HiLpmhWagDS",
"name": "lambda_update_function_configuration",
"input": {
"FunctionName": "devops-agent-timeout",
"Timeout": 30
},
"type": "tool_use"
}
}
...
}Como lambda_update_function_configuration es una acción de modificación, la función durable suspende la ejecución y espera la aprobación humana.
Figura 8: Salida de los logs de cloudwatch de la función durable de lambda para la solicitud de aprobación
Importante: El investigation_summary enviado a Amazon Bedrock, y la remediación que propone, son generados por IA y siempre deben revisarse antes de la aprobación. La puerta de aprobación humana es el control de seguridad: el aprobador debe inspeccionar todos los parámetros de la herramienta (por ejemplo, el FunctionName exacto y el Timeout en una llamada a lambda_update_function_configuration ) y confirmar que el cambio es correcto.
Usando la AWS CLI:
$ aws lambda send-durable-execution-callback-success \
--callback-id <callback-id> \
--cli-binary-format raw-in-base64-out \
--result '{"approved": true}'Usando la AWS Console:
Vaya a la durable execution, seleccione el callback pendiente y elija Send success para confirmar:
Figura 9: Aprobación de la remediación eligiendo Send success en la consola de Lambda
En el campo de entrada, escriba {'approved': true} y confirme.
Figura 10: Introducción del payload de aprobación para confirmar el callback
Verifique la corrección
Después de la aprobación, la durable function se reanuda, invoca la Lambda de la herramienta para actualizar la configuración, y Amazon Bedrock confirma que la remediación está completa. La función actualizada devops-agent-timeout ahora muestra el nuevo valor de timeout:
Figura 11: La configuración de la función devops-agent-timeout actualizada a un timeout de 30 segundos
La salida del paso final (bedrock-call-4) confirma la remediación exitosa:
{
"EventType": "StepSucceeded",
"Name": "bedrock-call-4",
....
},
"output": {
"message": {
"role": "assistant",
"content": [
{
"text": "## Remediation Complete
**Issue Identified:** The Lambda function `devops-agent-timeout` in eu-west-1 was configured with a 3-second timeout that was insufficient for its execution time, causing timeout errors at exactly 3000ms.
**Action Taken:** Successfully updated the Lambda function configuration to increase the timeout from 3 seconds to 30 seconds.
**Verification:** Confirmed the configuration change was applied successfully. The function now has:
- **Timeout:** 30 seconds (increased from 3 seconds)
- **Status:** Successful update completion
- **LastModified:** 2026-05-22T11:11:28.000+0000
This remediation should resolve the timeout errors by providing the function with adequate time to complete its execution. The 30-second timeout provides a 10x increase from the original 3-second limit, which should be sufficient for most operations while still maintaining reasonable execution bounds for a Lambda function."
}
]
}
},
"stopReason": "end_turn",
...
}Todo este ciclo, desde la detección del incidente hasta la corrección automatizada, requirió solo una única acción de aprobación por parte del ingeniero. El sistema manejó el diagnóstico, la recuperación de la configuración, la propuesta de remediación y la ejecución de forma autónoma.
Limpieza
Limpie los recursos que creó completando los siguientes pasos:
Kiro: Si usa Kiro con el Agent Toolkit for AWS, pregunte: «Clean up all resources from the DevOps Agent remediation demo: destroy the CDK stack, delete the devops-agent-timeout test function, its IAM role, and its CloudWatch log group.» Kiro elimina los recursos en el orden correcto, confirmando cada acción destructiva antes de continuar. Para limpiar manualmente, siga estos pasos.
- Elimine los recursos de AWS CDK:
$ cdk destroy - Elimine manualmente la función
devops-agent-timeoutque simula el incidente:$ aws lambda delete-function --function-name devops-agent-timeout - Elimine manualmente el rol de IAM y el grupo de logs de CloudWatch de la función
devops-agent-timeout:$ aws iam detach-role-policy \ --role-name devops-agent-timeout-role \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole $ aws iam delete-role --role-name devops-agent-timeout-role $ aws logs delete-log-group --log-group-name /aws/lambda/devops-agent-timeout
Conclusión
Esta publicación demostró cómo puede automatizar la remediación de problemas usando Lambda Durable Functions, Amazon EventBridge y Bedrock junto con el DevOps Agent. La solución continúa donde AWS DevOps Agent se detiene, transformando los resúmenes de investigación en pasos de remediación accionables que se ejecutan con aprobación humana en el proceso. Este enfoque reduce el tiempo medio de resolución porque, para cuando el ingeniero de guardia interviene, el sistema ya ha diagnosticado el problema, recopilado las configuraciones actuales y preparado una corrección lista para aprobar. La seguridad sigue siendo central en el diseño: la allowlist restringe a Amazon Bedrock para invocar solo herramientas preaprobadas, y la puerta de aprobación humana ayuda a evitar que cambios no deseados lleguen a producción sin autorización explícita. La arquitectura también es intrínsecamente extensible. Agregar nuevas capacidades de remediación requiere solo actualizaciones de configuración en el registro de herramientas, no cambios de código en el orquestador. Y debido a que AWS Lambda Durable Functions se suspende sin consumir recursos de cómputo durante la espera de aprobación, la solución sigue siendo rentable incluso cuando los ciclos de aprobación abarcan horas o días.
Para comenzar a usar esta solución, descargue la plantilla completa de AWS CDK desde el repositorio de GitHuby siga los pasos de esta publicación para implementar la solución en su entorno.
Nos encantaría saber de usted. Comparta su experiencia implementando esta solución, haga preguntas o sugiera mejoras en los comentarios. También puede unirse al AWS Community Builders programa para conectar con otros builders y compartir sus patrones de arquitectura serverless.