User's blog

Automatize a remediação após investigações do AWS DevOps Agent

Written by

Make.com Service User

in

O problema: diagnóstico sem remediação

Reduzir o tempo entre a detecção de um incidente, sua investigação e a correção é uma das prioridades mais críticas para equipes que operam cargas de trabalho em produção na AWS. Quando algo dá errado, o engenheiro de plantão precisa diagnosticar rapidamente o problema, identificar a causa raiz e aplicar a correção — muitas vezes de madrugada.

O AWS DevOps Agent já resolve a parte de diagnóstico: é um agente com inteligência artificial que faz a triagem autônoma de incidentes ao longo do dia, correlacionando métricas, logs e topologia de aplicação para entregar uma Análise de Causa Raiz (RCA) e ações recomendadas de resolução. Mas há um detalhe importante: para manter controle e evitar mudanças não intencionais, a maioria das organizações mantém seus agentes de observabilidade — incluindo o AWS DevOps Agent — no modo “observar e reportar”. Ou seja, o agente diagnostica, mas não modifica recursos em produção diretamente.

É exatamente essa lacuna que a AWS abordou em um post técnico recente, demonstrando como usar AWS Lambda Durable Functions, Amazon EventBridge e Amazon Bedrock para criar um fluxo automatizado de remediação que complementa o AWS DevOps Agent. O resultado é um pipeline que transforma os resumos de investigação em correções pré-validadas, prontas para aprovação com uma única ação do engenheiro responsável.

Visão geral da solução

Com AWS Lambda Durable Functions, é possível construir aplicações resilientes de múltiplos passos e fluxos de IA que podem rodar por até um ano sem necessidade de gerenciar infraestrutura adicional ou escrever código customizado de gerenciamento de estado e tratamento de erros. Essas funções fazem checkpoints automáticos do progresso, suspendem a execução durante tarefas de longa duração e se recuperam de falhas mantendo o progresso confiável mesmo diante de interrupções.

O fluxo da solução funciona assim:

  • O AWS DevOps Agent conclui uma investigação de incidente e emite um evento contendo sintomas, descobertas e análise de causa raiz.
  • O Amazon EventBridge recebe o evento de conclusão da investigação e aciona a função devops-agent-trigger com o conteúdo da investigação.
  • Essa função Lambda empacota o resumo da investigação e invoca a durable function devops-agent-remediation-durable.
  • A durable function envia o contexto da investigação ao Amazon Bedrock, que analisa as descobertas e busca remediações aplicáveis.
  • O Amazon Bedrock identifica e lista as ferramentas de remediação disponíveis a partir de uma lista de permissões (allowlist) de funções Lambda aprovadas: devops-agent-lambda-tool.
  • O Amazon Bedrock propõe ações específicas de remediação com base nas descobertas e nas ferramentas disponíveis.
  • Para ações de leitura, a durable function executa as ferramentas de remediação de forma autônoma. Para mudanças em infraestrutura, o fluxo suspende e aguarda aprovação humana antes de prosseguir.
  • Após a aprovação, a durable function aplica as ações de remediação à infraestrutura usando as ferramentas selecionadas.
  • A durable function opera como um loop agêntico, chamando o Amazon Bedrock iterativamente, executando ferramentas aprovadas e alimentando os resultados de volta na conversa até que a remediação esteja completa.

Segurança e controle: allowlist e aprovação humana

Para manter as ações automatizadas seguras e auditáveis, o orquestrador aplica uma allowlist de ferramentas de remediação. Cada ferramenta é uma função Lambda construída para um propósito específico e bem delimitado — como ler a configuração de uma função Lambda ou atualizar uma declaração de política do Gerenciamento de Identidade e Acesso (IAM). O Amazon Bedrock só pode selecionar e invocar ferramentas desse conjunto aprovado, mantendo o escopo das ações automatizadas sob controle.

O fluxo ainda distingue entre operações de leitura e operações mutantes. Ferramentas de leitura executam de forma autônoma, sem intervenção humana. Ações mutantes — que modificariam o estado da infraestrutura — fazem a durable function suspender a execução e aguardar aprovação humana. É aqui que o AWS Lambda Durable Functions oferece uma vantagem fundamental: a função faz checkpoints do progresso e pausa por minutos, horas ou até dias sem consumir recursos de computação, retomando exatamente de onde parou após receber o sinal de aprovação.

Quando o engenheiro de plantão finalmente entra em ação, o sistema já diagnosticou o problema, coletou as configurações relevantes e preparou um conjunto de mudanças pré-validadas prontas para aprovação com um clique.

Pré-requisitos e implantação com AWS CDK

Antes de implantar a solução, é necessário ter os seguintes pré-requisitos:

Para implantar a solução usando o AWS Cloud Development Kit (AWS CDK), execute os seguintes passos:

Clone o repositório:

$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git

Navegue até o diretório:

$ cd sample-automate-remediation-post-devops-agent-investigation

Faça o bootstrap do AWS CDK (necessário na primeira vez que você usa o AWS CDK em um ambiente específico — combinação de conta e região AWS):

$ cdk bootstrap

Implante o stack:

$ cdk deploy

O AWS CDK provisiona e configura automaticamente os seguintes recursos:

  • Três funções Lambda: devops-agent-trigger, devops-agent-remediation-durable e devops-agent-lambda-tool.
  • Uma regra do Amazon EventBridge.

As permissões de IAM são gerenciadas automaticamente pelo AWS CDK seguindo o princípio de menor privilégio. Por exemplo, o Amazon EventBridge recebe permissão lambda:InvokeFunction para a função devops-agent-trigger. O stack concede a permissão aidevops:ListJournalRecords a essa função para buscar os resumos de investigação do journal do AWS DevOps Agent. Também concede a permissão bedrock:InvokeModel à função devops-agent-remediation-durable para invocar o Amazon Bedrock.

Simulando o incidente e validando o fluxo

Para demonstrar o fluxo de ponta a ponta, o post original simula um cenário comum: uma função Lambda que ultrapassa o timeout configurado. Isso dá ao AWS DevOps Agent um incidente real para investigar e coloca o fluxo de remediação em ação. Os passos para criar e invocar essa função de teste estão no repositório, que inclui uma função devops-agent-timeout pronta para uso e instruções para implantá-la, invocá-la e confirmar o erro de timeout no Amazon CloudWatch Logs. Para o passo a passo completo, consulte a seção “Simulate the incident” do README.

Com o stack implantado e a função devops-agent-timeout falhando com erros de timeout, o fluxo se desenrola assim:

  1. Abra o console do AWS DevOps Agent, navegue até o seu espaço de agente e pergunte: “What is happening with the devops-agent-timeout function?”
  2. A investigação inicia e leva alguns minutos. O AWS DevOps Agent correlaciona métricas, logs e a configuração da função para determinar a causa raiz.
  3. Após a conclusão, o agente apresenta a análise de causa raiz, identificando que o timeout da função é insuficiente para a carga de trabalho.

A conclusão da investigação emite um evento para o Amazon EventBridge, que aciona a função devops-agent-trigger. Essa função busca o resumo da investigação do journal do AWS DevOps Agent — incluindo sintomas, causas raiz, causas contribuintes e lacunas da investigação — e o envia para a durable function.

O loop agêntico em ação

A durable function inicia seu loop agêntico enviando o contexto da investigação ao Amazon Bedrock. Na primeira chamada ao Bedrock, o modelo analisa o resumo e determina que precisa inspecionar a configuração atual da função antes de propor uma correção. Ele seleciona a ferramenta lambda_get_function_configuration da allowlist. Como é uma operação de leitura, ela executa de forma autônoma sem exigir aprovação humana. O resultado mostra a configuração atual da função devops-agent-timeout, confirmando um valor de timeout de 3 segundos.

Com a configuração confirmada, o Amazon Bedrock avança para a próxima iteração. Ele raciocina que o timeout de 3 segundos é a causa raiz das falhas e propõe aumentá-lo para 30 segundos. A resposta do Amazon Bedrock contém tanto o raciocínio quanto a chamada de ferramenta:

{
  ....
},
"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 é uma ação mutante, a durable function suspende a execução e aguarda aprovação humana.

Importante: o resumo da investigação enviado ao Amazon Bedrock e a remediação proposta são gerados por IA e devem sempre ser revisados antes da aprovação. O gate de aprovação humana é o controle de segurança: quem aprova deve inspecionar os parâmetros completos da ferramenta — por exemplo, o FunctionName e o Timeout exatos em uma chamada lambda_update_function_configuration — e confirmar que a mudança está correta.

Para aprovar via AWS CLI:

$ aws lambda send-durable-execution-callback-success \
    --callback-id <callback-id> \
    --cli-binary-format raw-in-base64-out \
    --result '{"approved": true}'

Após a aprovação, a durable function retoma a execução, invoca a ferramenta Lambda para atualizar a configuração e o Amazon Bedrock confirma que a remediação foi concluída. O output final confirma a remediação bem-sucedida:

{
  "EventType": "StepSucceeded",
  "Name": "bedrock-call-4",
  ....
},
"output": {
  "message": {
    "role": "assistant",
    "content": [
      {
        "text": "## Remediation Complete\n\n**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.\n\n**Action Taken:** Successfully updated the Lambda function configuration to increase the timeout from 3 seconds to 30 seconds.\n\n**Verification:** Confirmed the configuration change was applied successfully. The function now has:\n- **Timeout:** 30 seconds (increased from 3 seconds)\n- **Status:** Successful update completion\n- **LastModified:** 2026-05-22T11:11:28.000+0000\n\nThis 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 esse ciclo — da detecção do incidente à correção automatizada — exigiu apenas uma única ação de aprovação do engenheiro. O sistema cuidou do diagnóstico, da coleta de configurações, da proposta de remediação e da execução de forma autônoma.

Limpeza dos recursos

Para remover os recursos criados, execute:

$ cdk destroy

Delete manualmente a função de simulação de incidente:

$ aws lambda delete-function --function-name devops-agent-timeout

Delete manualmente a role IAM e o grupo de logs do CloudWatch da função:

$ 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

Conclusão

A solução demonstrada pela AWS mostra como é possível fechar o ciclo entre investigação e remediação de incidentes usando Lambda Durable Functions, Amazon EventBridge e Amazon Bedrock em conjunto com o DevOps Agent. O fluxo transforma resumos de investigação em passos de remediação acionáveis que rodam com aprovação humana no loop.

A abordagem reduz o Tempo Médio de Resolução (MTTR) porque, quando o engenheiro de plantão entra em ação, o sistema já diagnosticou o problema, coletou as configurações atuais e preparou uma correção pronta para aprovação. A segurança permanece central no design: a allowlist restringe o Amazon Bedrock a invocar apenas ferramentas pré-aprovadas, e o gate de aprovação humana evita que mudanças não intencionais cheguem à produção sem autorização explícita.

A arquitetura também é extensível por natureza. Adicionar novas capacidades de remediação requer apenas atualizações de configuração no registro de ferramentas, sem mudanças de código no orquestrador. E como as AWS Lambda Durable Functions suspendem sem consumir recursos de computação durante a espera por aprovação, a solução permanece eficiente em custo mesmo quando os ciclos de aprovação se estendem por horas ou dias.

Para começar, baixe o template completo do AWS CDK no repositório no GitHub e siga os passos descritos para implantar a solução no seu ambiente.

Fonte

Automate remediation post AWS DevOps Agent investigation (https://aws.amazon.com/blogs/machine-learning/automate-remediation-post-aws-devops-agent-investigation/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts