Réduire le temps entre la détection d'un incident, son investigation et sa remédiation est une priorité essentielle pour les organisations qui exécutent des charges de travail de production sur AWS. Lorsqu'un problème survient, les ingénieurs d'astreinte doivent souvent diagnostiquer rapidement le problème à travers les composants applicatifs, identifier la cause racine et appliquer le correctif, souvent au milieu de la nuit.
Agent AWS DevOps, un agent alimenté par l'IA qui trie de manière autonome les incidents toute la journée en se basant sur des métriques corrélées, des journaux et la topologie des applications, répond à la première partie de cette priorité en fournissant une analyse des causes profondes (RCA) et des actions recommandées pour la résolution. Cependant, pour conserver le contrôle et aider à prévenir les modifications non intentionnées, les organisations maintiennent généralement leurs agents d'observabilité, y compris AWS DevOps Agent, en mode observation et rapport, où l'agent diagnostique les problèmes mais ne modifie pas directement les ressources de production. Dans cet article, nous montrons comment utiliser AWS Lambda Durable Functions, une capacité d'AWS Lambda, Amazon EventBridge, et Amazon Bedrock pour créer un flux de remédiation automatisé qui complète AWS DevOps Agent afin de terminer l'étape de résolution des incidents. Ce flux transforme les résumés d'investigation en correctifs prévalidés, prêts pour une action d'approbation unique, vous aidant à réduire le délai moyen de résolution (MTTR) et à libérer vos ingénieurs d'astreinte des travaux de diagnostic répétitifs.
Présentation de la solution
Avec AWS Lambda Durable Functions, vous pouvez créer des applications multi-étapes résilientes et des flux de travail d'IA pouvant s'exécuter pendant un an maximum, sans avoir à gérer d'infrastructure supplémentaire ni à écrire du code personnalisé de gestion d'état et de gestion des erreurs. Ces fonctions créent automatiquement des points de contrôle de progression, suspendent l'exécution pendant les tâches de longue durée et se rétablissent après des échecs tout en maintenant une progression fiable malgré les interruptions.
Le schéma suivant illustre l'architecture de la solution.
Figure 1 : flux de remédiation automatisé depuis une investigation d'AWS DevOps Agent via Amazon EventBridge, AWS Lambda et Amazon Bedrock, avec approbation humaine facultative avant que les modifications n'atteignent l'infrastructure
Le flux se compose des étapes suivantes :
- AWS DevOps Agent termine une investigation d'incident et émet un événement contenant les symptômes, les constatations et l'analyse de la cause racine.
- Amazon EventBridge reçoit l'événement d'achèvement de l'investigation et déclenche la fonction
devops-agent-triggeravec le contenu de l'investigation. - La fonction Lambda empaquette le résumé de l'investigation et invoque la fonction durable
devops-agent-remediation-durable. - La fonction durable envoie le contexte de l'investigation à Amazon Bedrock, qui analyse les constatations et recherche les remédiations applicables.
- Amazon Bedrock identifie et répertorie les outils de remédiation disponibles à partir d'une liste d'autorisation organisée de fonctions Lambda approuvées :
devops-agent-lambda-tool. - Amazon Bedrock propose des actions de remédiation spécifiques en fonction des constatations de l'investigation et des outils disponibles.
- Pour les actions en lecture seule, la fonction durable exécute les outils de remédiation de manière autonome. Pour les modifications d'infrastructure, le flux se suspend et attend une approbation humaine avant de continuer.
- Après approbation, la fonction durable applique les actions de remédiation à l'infrastructure à l'aide des outils sélectionnés.
La fonction durable s'exécute comme une boucle agentique, appelant itérativement Amazon Bedrock, exécutant les outils approuvés et réinjectant les résultats dans la conversation jusqu'à ce que la remédiation soit terminée. Pour garantir que les actions automatisées restent sûres et auditables, l'orchestrateur applique une liste blanche organisée d'outils de remédiation. Chaque outil est une fonction Lambda conçue à des fins spécifiques qui exécute une action précise et bien délimitée, comme la lecture de la configuration d'une fonction Lambda ou la mise à jour d'une déclaration de politique AWS Identity and Access Management (IAM). Amazon Bedrock ne peut sélectionner et invoquer que des outils de cet ensemble approuvé, ce qui maintient le périmètre des actions automatisées sous contrôle. Le flux de travail distingue en outre les opérations en lecture seule des opérations de modification. Les outils en lecture seule s'exécutent de manière autonome, sans intervention humaine. Les actions de modification qui altéreraient l'état de l'infrastructure entraînent la suspension de l'exécution de la fonction durable et l'attente d'une approbation humaine. C'est là que les AWS Lambda Durable Functions offrent un avantage clé. La fonction enregistre des points de contrôle de sa progression et se met en pause pendant des minutes, des heures, voire des jours, sans consommer de ressources de calcul, puis reprend exactement là où elle s'était arrêtée après réception du signal d'approbation. Au moment où l'ingénieur d'astreinte intervient, le système a déjà recueilli les configurations pertinentes, mis en corrélation la cause racine avec les actions de remédiation disponibles et préparé un ensemble de modifications prévalidées prêtes pour une approbation en un clic. L'implémentation actuelle utilise un signal d'approbation ou de rejet. Comme le rappel accepte une charge utile JSON arbitraire, vous pouvez étendre l'approbation pour transporter des substitutions de paramètres ou des observations du réviseur. Celles-ci peuvent être réinjectées dans la conversation Bedrock afin d'affiner la remédiation proposée avant son exécution.
Dans les sections suivantes, nous parcourons les détails de l'implémentation, y compris la configuration de la règle Amazon EventBridge et la logique d'orchestration de la fonction durable. Nous déployons ensuite la solution à l'aide du AWS Cloud Development Kit (AWS CDK).
Prérequis
Avant de déployer cette solution, vérifiez que vous disposez des prérequis suivants :
- L' AWS Command Line Interface (AWS CLI) installée et configurée.
- Python 3.14 ou version ultérieure.
- Le AWS CDK installé.
- Un espace AWS DevOps Agent.
- actif (Facultatif) Kiro avec l'. L'Agent Toolkit donne à Kiro un accès sécurisé aux API AWS via un serveur MCP géré avec des contrôles d'accès basés sur IAM. Si vous utilisez Kiro, les étapes de simulation d'incident, de déploiement et de nettoyage décrites dans cet article peuvent être effectuées avec des requêtes en langage naturel au lieu d'exécuter manuellement des commandes CLI. Pour le configurer, ajoutez le serveur MCP AWS à
~/.kiro/settings/mcp.json(. L'Agent Toolkit donne à Kiro un accès sécurisé aux API AWS via un serveur MCP géré avec des contrôles d'accès basés sur IAM. Si vous utilisez Kiro, les étapes de simulation d'incident, de déploiement et de nettoyage de cet article peuvent être réalisées avec des invites en langage naturel au lieu d'exécuter manuellement des commandes CLI. Pour le configurer, ajoutez le serveur AWS MCP auxinstructions de configuration
). Le dépôt inclut un fichier de règles et d'agents Kiro qui fournit automatiquement à Kiro le contexte du projet, la séquence de déploiement et les conventions de sécurité.
Pour démontrer le flux de travail de bout en bout, nous simulons un scénario courant : une fonction Lambda qui dépasse son délai d'expiration configuré. Cela donne à AWS DevOps Agent un véritable incident à examiner et déclenche le flux de travail de remédiation.
Pour démontrer le flux de travail de bout en bout, nous simulons un scénario courant : une fonction Lambda qui dépasse son délai d'attente configuré. Cela donne à AWS DevOps Agent un véritable incident à examiner et déclenche le flux de travail de remédiation. Pour rester concentré sur la solution de remédiation elle-même, les étapes de création et d'invocation de cette fonction de test sont conservées dans ledépôt devops-agent-timeout . Il inclut une fonction prête à l'emploi et des instructions pas à pas pour la déployer, l'invoquer et confirmer l'erreur de délai d'attente dans Amazon CloudWatch Logs. Pour le guide complet, consultez le Section « Simulate the incident » du README.
Une fois la fonction déployée et après avoir produit au moins une erreur de timeout, vous êtes prêt à démarrer une investigation avec AWS DevOps Agent.
Déployer la solution à l'aide de l'AWS CDK
Suivez les étapes ci-dessous pour déployer les ressources restantes de la solution :
Kiro : Si vous disposez de Kiro avec l'Agent Toolkit for AWS configuré (voir Prérequis), ouvrez le dépôt cloné dans Kiro et demandez : «Configurez l'environnement Python et déployez la pile CDK. Montrez-moi les ressources qui seront créées avant le déploiement.» Kiro lit les règles du projet depuis le dépôt, configure l'environnement virtuel, installe les dépendances et vous montre les ressources prévues avant le déploiement. Il confirme chaque modification d'infrastructure avant de l'exécuter, en suivant le même modèle de supervision humaine (human-in-the-loop) que celui utilisé par la solution de remédiation elle-même. Pour déployer manuellement, suivez ces étapes.
- Clonez le code AWS CDK hébergé sur GitHub :
$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git - Accédez au répertoire
sample-automate-remediation-post-devops-agent-investigation:$ cd sample-automate-remediation-post-devops-agent-investigation - Amorcez (bootstrap) l'AWS CDK. Cette opération est requise la première fois que vous utilisez l'AWS CDK dans un environnement AWS spécifique (une combinaison d'un compte AWS et d'une Région AWS).
$ cdk bootstrap - Déployez la pile :
$ cdk deploy
L'AWS CDK provisionne et configure automatiquement les ressources suivantes :
- Trois fonctions Lambda :
devops-agent-trigger.devops-agent-remediation-durable.devops-agent-lambda-tool.
- Une règle Amazon EventBridge.
L'AWS CDK gère automatiquement les autorisations IAM en appliquant les principes du moindre privilège et les meilleures pratiques de sécurité AWS. Par exemple, Amazon EventBridge se voit accorder les lambda:InvokeFunction autorisations pour la devops-agent-trigger fonction. La pile accorde l'autorisation aidevops:ListJournalRecords à la fonction devops-agent-trigger afin qu'elle puisse récupérer les résumés d'investigation depuis le journal de l'AWS DevOps Agent. Elle accorde également l'autorisation bedrock:InvokeModel à la fonction devops-agent-remediation-durable afin qu'elle puisse invoquer Amazon Bedrock.
Validez la solution
La pile de remédiation étant déployée et la fonction devops-agent-timeout échouant avec des erreurs de délai d'attente, nous pouvons maintenant parcourir le flux de travail de bout en bout.
Démarrer une investigation avec l'AWS DevOps Agent
Ouvrez la console AWS DevOps Agent, accédez à votre espace d'agent et demandez : «Que se passe-t-il avec la fonction devops-agent-timeout ?”
Figure 2 : Démarrage d'une investigation depuis la console AWS DevOps Agent
L'investigation démarre et prend quelques minutes pour se terminer. Pendant ce temps, l'AWS DevOps Agent met en corrélation de manière autonome les métriques CloudWatch, les journaux et la configuration de la fonction afin de déterminer la cause racine.
Figure 3 : L'AWS DevOps Agent mettant en corrélation les signaux pendant l'investigation
Une fois l'investigation terminée, l'AWS DevOps Agent présente l'analyse de la cause racine, identifiant que le délai d'attente de la fonction est insuffisant pour la charge de travail.
Figure 4 : L'analyse de la cause racine identifiant le délai d'attente insuffisant de la fonction
Vérifier l'exécution du Lambda de déclenchement
L'achèvement de l'investigation émet un événement Investigation Completed vers Amazon EventBridge.
La règle déclenche la devops-agent-trigger fonction Lambda, qui récupère le résumé de l'investigation à partir du journal de l'AWS DevOps Agent. Dans le /aws/lambda/devops-agent-trigger groupe de journaux CloudWatch, vous pouvez voir le résumé analysé qui est envoyé à la devops-agent-remediation-durable fonction durable, y compris les symptômes, les causes racines, les causes contributives et les lacunes de l'investigation.
Figure 5 : le résumé d'investigation analysé dans le groupe de journaux CloudWatch de la fonction de déclenchement
Surveiller l'exécution de la fonction durable
Accédez à la console Lambda, ouvrez la devops-agent-remediation-durable fonction, puis choisissez l'onglet Durable executions . Choisissez la nouvelle exécution pour examiner ses étapes checkpointées.
Figure 6 : l'exécution de la fonction durable et ses étapes checkpointées dans la console Lambda
L'orchestrateur durable commence sa boucle agentique en envoyant le contexte de l'investigation à Amazon Bedrock. Dans le premier appel à Bedrock, le modèle analyse le résumé de l'investigation et détermine qu'il doit inspecter la configuration actuelle de la fonction avant de proposer une correction. Il sélectionne l'outil lambda_get_function_configuration dans la liste autorisée. Comme il s'agit d'une opération en lecture seule, elle s'exécute de manière autonome sans nécessiter d'approbation humaine. Le résultat de l'étape montre la configuration actuelle de la fonction devops-agent-timeout , confirmant une valeur de timeout de 3 secondes.
Figure 7 : l'appel d'outil en lecture seule renvoyant la configuration actuelle du timeout de 3 secondes
Amazon Bedrock propose la remédiation
La configuration actuelle étant confirmée, Amazon Bedrock passe à l'itération suivante. Il raisonne que le timeout de 3 secondes est la cause racine des échecs et propose de l'augmenter à 30 secondes. La réponse d'Amazon Bedrock contient à la fois le raisonnement et l'appel d'outil :
{
....
},
"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"
}
}
...
}Parce que lambda_update_function_configuration est une action de modification, la fonction durable suspend son exécution et attend une approbation humaine.
Figure 8 : sortie des journaux cloudwatch de la fonction durable Lambda pour la demande d'approbation
Important : Le investigation_summary envoyé à Amazon Bedrock, ainsi que la remédiation qu'il propose, sont générés par IA et doivent toujours être examinés avant approbation. Le seuil d'approbation humaine est le contrôle de sécurité : l'approbateur doit inspecter l'intégralité des paramètres de l'outil (par exemple, les valeurs exactes FunctionName et Timeout dans un appel lambda_update_function_configuration ) et confirmer que la modification est correcte.
À l'aide de l'AWS CLI :
$ aws lambda send-durable-execution-callback-success \
--callback-id <callback-id> \
--cli-binary-format raw-in-base64-out \
--result '{"approved": true}'À l'aide de la console AWS :
Accédez à l'exécution durable, sélectionnez le callback en attente et choisissez Send success pour confirmer :
Figure 9 : Approbation de la remédiation en choisissant Send success dans la console Lambda
Dans le champ de saisie, entrez {'approved': true} et confirmez.
Figure 10 : Saisie de la charge utile d'approbation pour confirmer le callback
Vérifiez la correction
Après l'approbation, la fonction durable reprend, invoque la Lambda de l'outil pour mettre à jour la configuration, et Amazon Bedrock confirme que la remédiation est terminée. La fonction devops-agent-timeout mise à jour affiche désormais la nouvelle valeur de timeout :
Figure 11 : La configuration de la fonction devops-agent-timeout mise à jour avec un timeout de 30 secondes
La sortie de la dernière étape (bedrock-call-4) confirme la réussite de la remédiation :
{
"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",
...
}Ce cycle complet, de la détection de l'incident à la correction automatisée, n'a nécessité qu'une seule action d'approbation de l'ingénieur. Le système a géré de manière autonome le diagnostic, la récupération de la configuration, la proposition de remédiation et l'exécution.
Nettoyage
Nettoyez les ressources que vous avez créées en suivant les étapes ci-dessous :
Kiro : Si vous utilisez Kiro avec l'Agent Toolkit for AWS, demandez : « Nettoie toutes les ressources de la démo de remédiation du DevOps Agent : détruis la pile CDK, supprime la fonction de test devops-agent-timeout, son rôle IAM et son groupe de logs CloudWatch. » Kiro supprime les ressources dans le bon ordre, en confirmant chaque action destructive avant de continuer. Pour effectuer le nettoyage manuellement, suivez ces étapes.
- Supprimez les ressources AWS CDK :
$ cdk destroy - Supprimez manuellement la fonction
devops-agent-timeoutqui simule l'incident :$ aws lambda delete-function --function-name devops-agent-timeout - Supprimez manuellement le rôle IAM et le groupe de logs CloudWatch de la fonction
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
Conclusion
Cet article a montré comment vous pouvez automatiser la remédiation des problèmes en utilisant les Lambda Durable Functions, Amazon EventBridge et Bedrock en combinaison avec le DevOps Agent. La solution prend le relais là où AWS DevOps Agent s'arrête, en transformant les synthèses d'enquête en étapes de remédiation actionnables qui s'exécutent avec une approbation humaine dans la boucle. Cette approche réduit le délai moyen de résolution, car au moment où l'ingénieur d'astreinte intervient, le système a déjà diagnostiqué le problème, collecté les configurations actuelles et préparé une correction prête à être approuvée. La sécurité demeure au cœur de la conception : la liste d'autorisation restreint Amazon Bedrock à n'invoquer que des outils pré-approuvés, et la porte d'approbation humaine aide à empêcher que des modifications involontaires n'atteignent la production sans autorisation explicite. L'architecture est aussi intrinsèquement extensible. L'ajout de nouvelles capacités de remédiation ne nécessite que des mises à jour de configuration du registre d'outils, et non des modifications de code de l'orchestrateur. Et comme les AWS Lambda Durable Functions se suspendent sans consommer de ressources de calcul pendant l'attente de l'approbation, la solution reste rentable même lorsque les cycles d'approbation s'étendent sur des heures ou des jours.
Pour commencer à utiliser cette solution, téléchargez le modèle AWS CDK complet depuis le dépôt GitHub, puis suivez les étapes de cet article pour déployer la solution dans votre environnement.
Nous serions ravis de vous lire. Partagez votre expérience de la mise en œuvre de cette solution, posez des questions ou suggérez des améliorations dans les commentaires. Vous pouvez également rejoindre le AWS Community Builders programme pour échanger avec d'autres builders et partager vos modèles d'architecture serverless.