Reducir el tiempo que transcurre entre la detección, la investigación y la solución de los incidentes es una prioridad fundamental para las organizaciones que ejecutan cargas de trabajo de producción en AWS. Cuando surge un problema, los ingenieros de guardia suelen necesitar diagnosticar rápidamente el problema en todos los componentes de la aplicación, identificar la causa raíz y aplicar la solución, a menudo en mitad de la noche
.
AWS DevOps Agent, un agente con tecnología de inteligencia artificial que clasifica los incidentes de forma autónoma durante todo el día en función de métricas, registros y topología de aplicaciones correlacionados, aborda la primera parte de esta prioridad proporcionando un análisis de la causa raíz (RCA) y las acciones recomendadas para su resolución. Sin embargo, para mantener el control y ayudar a evitar cambios no deseados, las organizaciones suelen mantener sus agentes de observabilidad, incluido AWS DevOps Agent, en un modo de observación e informe, en el que el agente diagnostica los problemas pero no modifica los recursos de producción directamente. En esta publicación, mostramos cómo usar AWS Lambda Durable Functions, una capacidad de AWS Lambda, Amazon EventBridge y Amazon Bedrock para crear un flujo de trabajo de corrección automatizado que complemente a AWS DevOps Agent para completar el paso de resolución de problemas. Este flujo de trabajo transforma los resúmenes de las investigaciones en correcciones validadas previamente listas para una única acción de aprobación, lo que le ayuda a reducir el tiempo medio de resolución (MTTR) y a liberar a
sus ingenieros de guardia de tareas de diagnóstico repetitivas.
Descripción general de la solución
Con AWS Lambda Durable Functions, puede crear aplicaciones de varios pasos y flujos de trabajo de IA resilientes que puedan ejecutarse durante un máximo de un año sin necesidad de administrar infraestructura adicional o escribir un código personalizado de gestión de errores y administración de estados. Estas funciones comprueban automáticamente el progreso, suspenden la ejecución durante las tareas de larga duración y se recuperan de los errores, a la vez que mantienen un progreso fiable a pesar de
las interrupciones.
El siguiente diagrama ilustra la arquitectura de la solución.
Figura 1: Flujo de trabajo de remediación automatizado a partir de 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:
- El agente DevOps de AWS completa la investigación de un incidente y emite un evento que contiene los síntomas, los hallazgos y el análisis de la causa raíz.
- Amazon EventBridge recibe el evento de finalización de la investigación y activa la función
devops-agent-trigger con el contenido de la investigación.
La función Lambda empaqueta el resumen de la investigación e invoca la función duradera devops-agent-remediation-durable.- La función durable envía el contexto de la investigación a Amazon Bedrock, que analiza los hallazgos y busca las soluciones aplicables.
Amazon Bedrock identifica y enumera las herramientas de corrección disponibles a partir de una lista seleccionada de funciones de Lambda aprobadas: devops-agent-lambda-tool.- Amazon Bedrock propone acciones correctivas específicas en función de los resultados de la investigación y de las herramientas disponibles.
En - el caso de las acciones de solo lectura, la función duradera ejecuta las herramientas de corrección de forma autónoma.
En el caso de los cambios en la infraestructura, el flujo de trabajo se suspende y espera la aprobación humana antes de continuar.
- Tras la aprobación, la función duradera aplica las acciones correctivas a la infraestructura mediante las herramientas seleccionadas.
La función duradera se ejecuta como un bucle de agencia, que llama de forma iterativa a Amazon Bedrock, ejecuta las herramientas aprobadas y devuelve los resultados a la conversación hasta que se complete la corrección. Para que las acciones automatizadas sean seguras y auditables, el orquestador aplica una lista seleccionada de herramientas de remediación permitidas. Cada herramienta es una función de Lambda diseñada específicamente que lleva a cabo una acción específica y bien definida, como leer la configuración de una función de 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 controlado el alcance de las acciones automatizadas. El flujo de trabajo distingue además entre las operaciones de solo lectura y las operaciones de mutación. Las herramientas de solo lectura se ejecutan de forma autónoma sin intervención humana. Las acciones mutantes que modificarían el estado de la infraestructura hacen que la función duradera suspenda la ejecución y espere la aprobación humana. Aquí es donde las funciones duraderas de AWS Lambda ofrecen una ventaja clave. La función comprueba su progreso y se detiene durante minutos, horas o incluso días sin consumir recursos informáticos. Después, se reanuda exactamente donde se quedó después de recibir la señal de aprobación. Cuando el ingeniero de guardia se pone en marcha, el sistema ya ha recopilado las configuraciones pertinentes, ha correlacionado la causa principal con las medidas correctivas disponibles y ha preparado un conjunto de cambios validados previamente para su aprobación con un solo clic. La implementación actual utiliza una señal de aprobación o rechazo. Como la devolución de llamada acepta una carga JSON arbitraria, puedes extender la aprobación para incluir las anulaciones de parámetros o las observaciones de los revisores. Estas se pueden incorporar a la conversación de Bedrock para refinar la solución propuesta antes de la ejecución
.
En las siguientes secciones, analizamos los detalles de la implementación, incluida la configuración de las reglas de Amazon EventBridge y la lógica duradera de orquestación de funciones. A continuación, implementamos la solución mediante el kit de desarrollo en la nube de AWS (AWS CDK)
.
Prerrequisitos
Antes de implementar esta solución, compruebe que tiene los siguientes requisitos previos:
Simule el incidente
Para demostrar el flujo de trabajo de principio a fin, simulamos un escenario común: una función de Lambda que supera el tiempo de espera configurado. Esto permite al agente DevOps de AWS investigar un incidente real y pone en marcha el flujo de trabajo de remediación
.
Para centrarse en la solución de corrección propiamente dicha, los pasos para crear e invocar esta función de prueba se guardan en el repositorio. Incluye una función devops-agent-timeout lista para usar e instrucciones paso a paso para implementarla, invocarla y confirmar el error de tiempo de espera en Amazon CloudWatch Logs.
Para ver el tutorial completo, consulte la sección «Simular el incidente» del archivo README.
Una vez que la función esté implementada y se haya producido al menos un error de tiempo de espera, estará listo para iniciar una investigación con AWS DevOps Agent.
Implemente la solución con el AWS CDK
Complete los siguientes pasos para implementar los recursos restantes de la solución:
Kiro: Si tiene Kiro con el kit de herramientas de agentes para AWS configurado (consulte los requisitos previos), abra el repositorio clonado en Kiro y pregunte: «Configure el entorno de Python e implemente la pila de CDK. Muéstrame qué recursos se crearán antes de la implementación. » Kiro lee las reglas del proyecto desde el repositorio, configura el entorno virtual, instala las dependencias y muestra los recursos planificados antes de la implementación. Confirma cada cambio de infraestructura antes de ejecutarlo, siguiendo el mismo patrón continuo que utiliza la propia solución de corrección. Para realizar la implementación de forma manual, siga estos pasos
.
- Clone el código del AWS CDK alojado en GitHub:
$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git
- Navegue hasta el directorio
sample-automate-remediation-post-devops-agent-investigation:
$ cd sample-automatizar-remediar-pos-investigación-agente de DevOps
- Arranque el AWS CDK. Esto es obligatorio la primera vez que utilice el AWS CDK en un entorno de AWS específico (una combinación de una cuenta de AWS y una región de AWS).
- Despliegue la pila:
El AWS CDK aprovisiona y configura automáticamente los siguientes recursos:
- Tres funciones de Lambda:
- activador de agente de
DevOps.
devops-agent-remediation-durable.herramienta devops-agent-lambda.
- Regla de Amazon EventBridge.
El AWS CDK gestiona automáticamente los permisos de IAM utilizando los principios de privilegios mínimos y las prácticas recomendadas de seguridad de AWS. Por ejemplo, Amazon EventBridge recibe los permisos lambda:invokeFunction para la función devops-agent-trigger. La pila otorga el permiso aidevops:listjournalRecords a la función devops-agent-trigger para que pueda obtener los resúmenes de las investigaciones del diario del agente DevOps de AWS.
También concede el permiso Bedrock:invokeModel a la función devops-agent-remediation-durable para que pueda invocar Amazon Bedrock.Valide la solución
Con la pila de soluciones implementada y la función devops-agent-timeout que produce errores de tiempo de espera, ahora podemos analizar el flujo de trabajo de principio a fin.
Inicie una investigación con AWS DevOps Agent
Abra la consola de AWS DevOps Agent, navegue hasta su espacio de agente y pregunte: «¿Qué ocurre con la función devops-agent-timeout? »
Figura 2: Inicio de una investigación desde la consola de AWS DevOps Agent
La investigación comienza y tarda unos minutos en completarse. Durante este tiempo, AWS DevOps Agent correlaciona de forma autónoma las métricas, los registros y la configuración de la función de CloudWatch para determinar
la causa principal.
Figura 3: Correlación de las señales del agente DevOps de AWS durante la investigación
Una vez finalizada la investigación, el agente de DevOps de AWS presenta el análisis de la causa raíz e identifica que el tiempo de espera de la función no es suficiente para la carga de trabajo.
Figura 4: El análisis de la causa raíz que identifica el tiempo de espera insuficiente de la función
Verifique la ejecución del disparador de Lambda
Al finalizar la investigación, se emite un evento de investigación completada a Amazon EventBridge.
La regla activa la función Lambda devops-agent-trigger, que obtiene el resumen de la investigación del diario del agente DevOps de AWS.
En el grupo de registros de CloudWatch /aws/lambda/devops-agent-trigger, puede ver el resumen analizado que se envía a la función duradera devops-agent-remediation-durable, que incluye los síntomas, las causas principales, las causas contribuyentes y las brechas en la investigación.
Figura 5: El resumen de la investigación analizada en el grupo de registros de CloudWatch con la función activadora
Supervise la ejecución duradera de la función
Navegue hasta la consola de Lambda, abra la función devops-agent-remediation-durable y seleccione la pestaña Ejecuciones duraderas. Elija la nueva ejecución para inspeccionar sus pasos puntuales
.
Figura 6: La ejecución duradera de la función y sus pasos puntuales en la consola Lambda
El orquestador duradero comienza su ciclo de agencia enviando el contexto de la investigación a Amazon Bedrock. En la primera llamada de Bedrock, el modelo analiza el resumen de la investigación y determina que necesita inspeccionar la configuración actual de la función antes de proponer una solució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 necesidad de aprobación humana. El resultado del paso muestra la configuración actual de la función devops-agent-timeout
y confirma un valor de tiempo de espera de 3 segundos.
Figura 7: La llamada a la herramienta de solo lectura que devuelve la configuración actual de tiempo de espera de 3 segundos
Una vez confirmada la configuración actual, Amazon Bedrock pasa a la siguiente iteración. Considera que el tiempo de espera de 3 segundos es la causa principal de los errores y propone aumentarlo a 30 segundos. La respuesta de Amazon Bedrock contiene tanto el razonamiento como la llamada a la herramienta
:
{
...
},
«salida»: {
«mensaje»: {
«rol»: «asistente»,
«contenido»: [
{
«text»: «Ahora puedo ver que la configuración actual confirma el problema: la función tiene un tiempo de espera de 3 segundos. Dado que parece ser una función de prueba para situaciones en las que se agota el tiempo de espera (según el nombre\ "devops-agent-timeout\» y su asociación con\ "DevOps Agent Test Infrastructure\»), aumentaré el tiempo de espera a un valor razonable que permita que la función se complete correctamente. Lo estableceré en 30 segundos, que es un tiempo de espera habitual en las funciones de Lambda que necesitan más tiempo de ejecución».
},
{
«Uso de herramientas»: {
«toolUseID»: «toolUse_lcghbwdxng5HiLpMhwagds»,
«nombre»: «lambda_update_function_configuration»,
«entrada»: {
«functionName»: «tiempo de espera de devops-agent-timeout»,
«Tiempo de espera»: 30
},
«type»: «tool_use»
}
}
...
}
Como lambda_update_function_configuration es una acción mutante, la función duradera suspende la ejecución y espera la aprobación humana.
Figura 8: cloudwatch registra la salida de la función duradera de lambda para la solicitud de aprobación
Importante: El resumen de la investigación enviado a Amazon Bedrock y la solución que propone se generan mediante inteligencia artificial y siempre deben revisarse antes de su 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 nombre de la función y el tiempo de espera exactos en una llamada lambda_update_function_configuration) y confirmar que el cambio es correcto.
Uso de la CLI de AWS:
$ aws lambda send-durable-execution-callback-success\
--id de devolución de llamada\
--cli-formato binario raw-in-base64-out\
--result '{"aprobado»: verdadero}'
Uso de la consola de AWS:
Navegue hasta la ejecución permanente, seleccione la devolución de llamada pendiente y elija Enviar correctamente para confirmar:
Figura 9: Aprobación de la corrección seleccionando Enviar correctamente en la consola de Lambda
En el campo de entrada, introduzca {'approved': true} y confirme.
Figura 10: Ingresar la carga útil de aprobación para confirmar la devolución de llamada
Verifique la corrección
Tras la aprobación, la función duradera se reanuda, invoca la herramienta Lambda para actualizar la configuración y Amazon Bedrock confirma que se ha completado la corrección. La función devops-agent-timeout actualizada ahora muestra
el nuevo valor de tiempo de espera:
Figura 11: La configuración de la función devops-agent-timeout se actualizó a un tiempo de espera de 30 segundos
El resultado del último paso (bedrock-call-4) confirma que la corrección se ha realizado correctamente:
{
«EventType»: «Paso realizado correctamente»,
«Nombre»: «bedrock-call-4",
...
},
«salida»: {
«mensaje»: {
«rol»: «asistente»,
«contenido»: [
{
«text»: «## Remediación completada
**Problema identificado: ** La función Lambda `devops-agent-timeout` de eu-west-1 se configuró con un tiempo de espera de 3 segundos que no era suficiente para su tiempo de ejecución, lo que provocaba errores de tiempo de espera de exactamente 3000 ms.
**Acción tomada: ** Se actualizó correctamente la configuración de la función Lambda para aumentar el tiempo de espera de 3 a 30 segundos.
**Verificación: ** Se confirmó que el cambio de configuración se aplicó correctamente. La función ahora tiene:
- **Tiempo de espera: ** 30 segundos (en vez de 3 segundos)
- **Estado: ** La actualización se ha completado correctamente
- **Última modificación: ** 2026-05-22T 11:11:28.000 +0000
Esta corrección debería resolver los errores de tiempo de espera proporcionando a la función el tiempo suficiente para completar su ejecución. El tiempo de espera de 30 segundos multiplica por 10 el límite original de 3 segundos, lo que debería ser suficiente para la mayoría de las operaciones y, al mismo tiempo, mantener unos límites de ejecución razonables para una función de Lambda».
}
]
}
},
«StopReason»: «end_turn»,
...
}
Todo este ciclo, desde la detección de incidentes hasta la reparación automática, solo requirió una única acción de aprobación por parte del ingeniero. El sistema gestionó el diagnóstico, la recuperación de la configuración, la propuesta de corrección y la ejecución
de forma autónoma.
Limpiar
Limpia los recursos que creaste realizando los siguientes pasos:
Kiro: Si usa Kiro con el kit de herramientas de agentes para AWS, pregúntese: «Elimine todos los recursos de la demostración de corrección de DevOps Agent: destruya la pila de CDK, elimine la función de prueba devops-agent-timeout, su función de IAM y su grupo de registros de CloudWatch». Kiro elimina los recursos en el orden correcto y confirma cada acción destructiva antes de continuar. Para limpiar manualmente, sigue estos pasos
.
- Elimine los recursos de AWS CDK:
- Elimine manualmente la función
devops-agent-timeout que simula el incidente:
$ aws lambda delete-function --function-name devops-agent-timeout
Elimine manualmente la función de IAM y el grupo de registros de CloudWatch de la función devops-agent-timeout:
Política de
separación de roles de $ aws iam\
--nombre del rol devops-agent-timeout-role\
--policy-arn arn:aws:iam: :aws:policy/service-role/awslambda rol de ejecución básico
$ aws iam delete-role --role-name devops-agent-timeout-role
$ aws registra delete-log-group --log-group-name /aws/lambda/devops-agent-timeout
Conclusión
En esta publicación se demostró cómo puede automatizar la solución de problemas mediante el uso de Lambda Durable Functions, Amazon EventBridge y Bedrock junto con el agente de DevOps. La solución continúa donde termina AWS DevOps Agent, transformando los resúmenes de las investigaciones en pasos de solución prácticos que se ejecutan con la aprobación de una persona. Este enfoque reduce el tiempo medio de resolución porque, cuando el ingeniero de guardia se pone en contacto con él, el sistema ya ha diagnosticado el problema, recopilado las configuraciones actuales y preparado una solución lista para su aprobación. La seguridad sigue siendo un aspecto fundamental del diseño: la lista de permisos restringe a Amazon Bedrock a invocar únicamente las herramientas previamente aprobadas, y el sistema de aprobación humana ayuda a evitar que los cambios no deseados lleguen a la producción sin autorización expresa. La arquitectura también es intrínsecamente ampliable. La adición de nuevas capacidades de corrección solo requiere actualizaciones de configuración en el registro de herramientas, no cambios de código en el orquestador. Además, dado que AWS Lambda Durable Functions se suspende sin consumir recursos informáticos durante la espera de aprobación, la solución sigue siendo rentable incluso cuando los ciclos de aprobación duran horas o días.
Para empezar a usar esta solución, descargue la plantilla completa del CDK de AWS del repositorio de GitHub y siga los pasos de esta publicación para implementar la solución en su entorno.
Nos encantaría escuchar su opinión. Comparta su experiencia en la implementación de esta solución, haga preguntas o sugiera mejoras en los comentarios. También puede unirse al programa AWS Community Builders para conectarse con otros desarrolladores y compartir sus patrones de arquitectura sin servidor
.
Acerca del autor
Reducing the time between incident detection, investigation, and remediation is a critical priority for organizations running production workloads on AWS. When an issue arises, on-call engineers often need to quickly diagnose the problem across application components, identify the root cause, and apply the fix, often in the middle of the night.
AWS DevOps Agent, an AI powered agent that autonomously triages incidents all day based on correlated metrics, logs, and application topology, addresses the first part of this priority by providing root cause analysis (RCA) and recommended actions for resolution. However, to retain control and help prevent unintended changes, organizations typically keep their observability agents, including AWS DevOps Agent, in an observe-and-report mode, where the agent diagnoses issues but doesn’t modify production resources directly. In this post, we demonstrate how to use AWS Lambda Durable Functions, a capability of AWS Lambda, Amazon EventBridge, and Amazon Bedrock to create an automated remediation workflow that complements AWS DevOps Agent to complete the issue resolution step. This workflow transforms investigation summaries into pre-validated fixes ready for single approval action, helping you reduce mean time to resolution (MTTR) and free your on-call engineers from repetitive diagnostic work.
Solution overview
With AWS Lambda Durable Functions, you can build resilient multi-step applications and AI workflows that can run for up to one year without requiring you to manage additional infrastructure or write custom state management and error handling code. These functions automatically checkpoint progress, suspend execution during long-running tasks, and recover from failures while maintaining reliable progress despite interruptions.
The following diagram illustrates the solution architecture.
Figure 1: Automated remediation workflow from an AWS DevOps Agent investigation through Amazon EventBridge, AWS Lambda, and Amazon Bedrock, with optional human approval before changes reach the infrastructure
The workflow consists of the following steps:
- AWS DevOps Agent completes an incident investigation and emits an event containing symptoms, findings, and root cause analysis.
- Amazon EventBridge receives the investigation completion event and triggers the
devops-agent-trigger function with the investigation content.
- The Lambda function packages the investigation summary and invokes the
devops-agent-remediation-durable durable function.
- The durable function sends the investigation context to Amazon Bedrock, which analyzes the findings and looks for applicable remediations.
- Amazon Bedrock identifies and lists the available remediation tools from a curated allowlist of approved Lambda functions:
devops-agent-lambda-tool.
- Amazon Bedrock proposes specific remediation actions based on the investigation findings and the available tools.
- For read-only actions, the durable function runs the remediation tools autonomously. For infrastructure changes, the workflow suspends and waits for human approval before proceeding.
- After approval, the durable function applies the remediation actions to the infrastructure using the selected tools.
The durable function runs as an agentic loop, iteratively calling Amazon Bedrock, executing approved tools, and feeding results back into the conversation until the remediation is complete. To keep automated actions safe and auditable, the orchestrator enforces a curated allowlist of remediation tools. Each tool is a purpose-built Lambda function that performs a specific, well-scoped action, such as reading a Lambda function configuration or updating an AWS Identity and Access Management (IAM) policy statement. Amazon Bedrock can only select and invoke tools from this approved set, which keeps the scope of automated actions controlled. The workflow further distinguishes between read-only operations and mutating operations. Read-only tools run autonomously without human intervention. Mutating actions that would modify infrastructure state cause the durable function to suspend execution and wait for human approval. This is where AWS Lambda Durable Functions provide a key advantage. The function checkpoints its progress and pauses for minutes, hours, or even days without consuming compute resources, then resumes exactly where it left off after it receives the approval signal. By the time the on-call engineer engages, the system has already gathered relevant configurations, correlated the root cause with available remediation actions, and prepared a set of pre-validated changes ready for one-click approval. The current implementation uses an approve or reject signal. Because the callback accepts an arbitrary JSON payload, you can extend the approval to carry parameter overrides or reviewer observations. These can be fed back into the Bedrock conversation to refine the proposed remediation before execution.
In the following sections, we walk through the implementation details, including the Amazon EventBridge rule configuration and the durable function orchestration logic. We then deploy the solution using the AWS Cloud Development Kit (AWS CDK).
Prerequisites
Before deploying this solution, verify that you have the following prerequisites:
- The AWS Command Line Interface (AWS CLI) installed and configured.
- Python 3.14 or later.
- The AWS CDK installed.
- An active AWS DevOps Agent space.
- (Optional) Kiro with the Agent Toolkit for AWS. The Agent Toolkit gives Kiro secure access to AWS APIs through a managed MCP Server with IAM-based access controls. If you use Kiro, the incident simulation, deployment, and cleanup steps in this post can be completed with natural language prompts instead of running CLI commands manually. To set it up, add the AWS MCP Server to
~/.kiro/settings/mcp.json (setup instructions). The repository includes a Kiro rules and agents file that gives Kiro the project context, deployment sequence, and safety conventions automatically.
Simulate the incident
To demonstrate the end-to-end workflow, we simulate a common scenario: a Lambda function that exceeds its configured timeout. This gives AWS DevOps Agent a real incident to investigate and sets the remediation workflow in motion.
To keep the focus on the remediation solution itself, the steps to create and invoke this test function are kept in the repository. It includes a ready-to-use devops-agent-timeout function and step-by-step instructions to deploy it, invoke it, and confirm the timeout error in Amazon CloudWatch Logs. For the full walkthrough, see the “Simulate the incident” section of the README.
After the function is deployed and has produced at least one timeout error, you’re ready to start an investigation with AWS DevOps Agent.
Deploy the solution using the AWS CDK
Complete the following steps to deploy the remaining solution resources:
Kiro: If you have Kiro with the Agent Toolkit for AWS configured (see Prerequisites), open the cloned repository in Kiro and ask: “Set up the Python environment and deploy the CDK stack. Show me what resources will be created before deploying.” Kiro reads the project rules from the repository, sets up the virtual environment, installs dependencies, and shows you the planned resources before deploying. It confirms each infrastructure change before executing, following the same human-in-the-loop pattern that the remediation solution itself uses. To deploy manually, follow these steps.
- Clone the AWS CDK code hosted on GitHub:
$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git
- Navigate to the directory
sample-automate-remediation-post-devops-agent-investigation:
$ cd sample-automate-remediation-post-devops-agent-investigation
- Bootstrap the AWS CDK. This is required the first time you use the AWS CDK in a specific AWS environment (a combination of an AWS account and AWS Region).
- Deploy the stack:
The AWS CDK automatically provisions and configures the following resources:
- Three Lambda functions:
devops-agent-trigger.devops-agent-remediation-durable.devops-agent-lambda-tool.
- Amazon EventBridge rule.
The AWS CDK automatically handles the IAM permissions using least-privilege principles and AWS security best practices. For example, Amazon EventBridge is granted lambda:InvokeFunction permissions for the devops-agent-trigger function. The stack grants the aidevops:ListJournalRecords permission to the devops-agent-trigger function so it can fetch investigation summaries from the AWS DevOps Agent journal. It also grants the bedrock:InvokeModel permission to the devops-agent-remediation-durable function so it can invoke Amazon Bedrock.
Validate the solution
With the remediation stack deployed and the devops-agent-timeout function failing with timeout errors, we can now walk through the end-to-end workflow.
Start an investigation with AWS DevOps Agent
Open the AWS DevOps Agent console, navigate to your agent space, and ask: “What is happening with the devops-agent-timeout function?”
Figure 2: Starting an investigation from the AWS DevOps Agent console
The investigation starts and takes a few minutes to complete. During this time, AWS DevOps Agent autonomously correlates CloudWatch metrics, logs, and the function’s configuration to determine the root cause.
Figure 3: AWS DevOps Agent correlating signals during the investigation
After the investigation completes, AWS DevOps Agent presents the root cause analysis, identifying that the function timeout is insufficient for the workload.
Figure 4: The root cause analysis identifying the insufficient function timeout
Verify the trigger Lambda execution
The investigation completion emits an Investigation Completed event to Amazon EventBridge.
The rule triggers the devops-agent-trigger Lambda function, which fetches the investigation summary from the AWS DevOps Agent journal. In the /aws/lambda/devops-agent-trigger CloudWatch log group, you can see the parsed summary that is sent to the devops-agent-remediation-durable durable function, including symptoms, root causes, contributing causes, and investigation gaps.
Figure 5: The parsed investigation summary in the trigger function CloudWatch log group
Monitor the durable function execution
Navigate to the Lambda console, open the devops-agent-remediation-durable function, and choose the Durable executions tab. Choose the new execution to inspect its checkpointed steps.
Figure 6: The durable function execution and its checkpointed steps in the Lambda console
The durable orchestrator begins its agentic loop by sending the investigation context to Amazon Bedrock. In the first Bedrock call, the model analyzes the investigation summary and determines that it needs to inspect the current function configuration before proposing a fix. It selects the lambda_get_function_configuration tool from the allowlist. Because this is a read-only operation, it runs autonomously without requiring human approval. The step result shows the current configuration of the devops-agent-timeout function, confirming a timeout value of 3 seconds.
Figure 7: The read-only tool call returning the current 3-second timeout configuration
With the current configuration confirmed, Amazon Bedrock proceeds to the next iteration. It reasons that the 3-second timeout is the root cause of the failures and proposes increasing it to 30 seconds. The Amazon Bedrock response contains both the reasoning and the tool call:
{
....
},
"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"
}
}
...
}
Because lambda_update_function_configuration is a mutating action, the durable function suspends execution and waits for human approval.
Figure 8: cloudwatch logs output of lambda durable function for approval request
Important: The investigation_summary sent to Amazon Bedrock, and the remediation it proposes, are AI-generated and should always be reviewed before approval. The human approval gate is the security control: the approver must inspect the full tool parameters (for example, the exact FunctionName and Timeout in a lambda_update_function_configuration call) and confirm the change is correct.
Using the AWS CLI:
$ aws lambda send-durable-execution-callback-success \
--callback-id <callback-id> \
--cli-binary-format raw-in-base64-out \
--result '{"approved": true}'
Using the AWS Console:
Navigate to the durable execution, select the pending callback, and choose Send success to confirm:
Figure 9: Approving the remediation by choosing Send success in the Lambda console
In the input field, enter {'approved': true} and confirm.
Figure 10: Entering the approval payload to confirm the callback
Verify the fix
After approval, the durable function resumes, invokes the tool Lambda to update the configuration, and Amazon Bedrock confirms the remediation is complete. The updated devops-agent-timeout function now shows the new timeout value:
Figure 11: The devops-agent-timeout function configuration updated to a 30-second timeout
The final step output (bedrock-call-4) confirms the successful remediation:
{
"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",
...
}
This entire cycle, from incident detection to automated fix, required only a single approval action from the engineer. The system handled diagnosis, configuration retrieval, remediation proposal, and execution autonomously.
Clean up
Clean up the resources you created by completing the following steps:
Kiro: If you use Kiro with the Agent Toolkit for AWS, ask: “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 removes resources in the correct order, confirming each destructive action before proceeding. To clean up manually, follow these steps.
- Delete the AWS CDK resources:
- Manually delete the
devops-agent-timeout function that simulates the incident:
$ aws lambda delete-function --function-name devops-agent-timeout
- Manually delete the IAM role and the CloudWatch log group of the
devops-agent-timeout function:
$ 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
Conclusion
This post demonstrated how you can automate issue remediation by using Lambda Durable Functions, Amazon EventBridge, and Bedrock in conjunction with the DevOps Agent. The solution picks up where AWS DevOps Agent leaves off, transforming investigation summaries into actionable remediation steps that run with human-in-the-loop approval. This approach reduces mean time to resolution because, by the time the on-call engineer engages, the system has already diagnosed the issue, gathered current configurations, and prepared a ready-to-approve fix. Safety remains central to the design: the allowlist restricts Amazon Bedrock to only invoke pre-approved tools, and the human approval gate helps prevent unintended changes from reaching production without explicit authorization. The architecture is also inherently extensible. Adding new remediation capabilities requires only configuration updates to the tool registry, not code changes to the orchestrator. And because AWS Lambda Durable Functions suspend without consuming compute resources during the approval wait, the solution remains cost-efficient even when approval cycles span hours or days.
To get started using this solution, download the complete AWS CDK template from the GitHub repository, and follow the steps in this post to deploy the solution in your environment.
We would love to hear from you. Share your experience implementing this solution, ask questions, or suggest improvements in the comments. You can also join the AWS Community Builders program to connect with other builders and share your serverless architecture patterns.
About the author
