Automate remediation post AWS DevOps Agent investigation

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS DevOps Agent의 조사 결과를 Amazon EventBridge, AWS Lambda Durable Functions, Amazon Bedrock과 연결해, 읽기 전용 작업은 자동 실행하고 인프라 변경은 사람의 승인을 거쳐 수행하는 복구 워크플로를 소개한다.

📌 핵심 요약

• AWS DevOps Agent는 지표·로그·애플리케이션 토폴로지를 연계해 근본 원인 분석(RCA)과 해결 권고를 제공한다. 조직은 통제권을 유지하고 의도하지 않은 변경을 방지하기 위해 대체로 관찰·보고 모드로 운영하며, 글은 이를 보완하는 자동 복구 워크플로를 통해 평균 해결 시간(MTTR)을 줄이는 것을 목표로 한다.
• 조사 완료 이벤트를 Amazon EventBridge가 받아 devops-agent-trigger를 실행하면, 이 함수가 조사 요약을 devops-agent-remediation-durable로 전달한다. Amazon Bedrock은 조사 내용과 승인된 Lambda 도구 허용 목록을 바탕으로 복구 작업을 제안하고, 오케스트레이터는 도구 실행 결과를 다시 전달하는 에이전트 루프를 수행한다.
• 읽기 전용 작업은 자동 실행하지만 인프라 상태를 변경하는 작업은 사람의 승인이 필요하다. AWS Lambda Durable Functions는 진행 상태를 체크포인트로 저장하고 승인 대기 중 컴퓨팅 자원을 소비하지 않으며, 최대 1년 동안 실행되는 워크플로를 지원한다. 현재 승인 방식은 승인 또는 거부 신호를 사용한다.
• 배포에는 구성된 AWS CLI, Python 3.14 이상, AWS CDK, 활성 AWS DevOps Agent space가 필요하다. AWS CDK는 Lambda 함수 3개와 Amazon EventBridge 규칙을 생성하고 최소 권한 원칙에 따라 권한을 구성한다. 선택적으로 Kiro와 Agent Toolkit for AWS를 사용해 자연어로 배포 과정을 진행할 수 있다.
• 검증 사례에서는 devops-agent-timeout의 타임아웃 오류를 조사하고, 읽기 전용 도구로 현재 설정이 3초임을 확인한 뒤 Amazon Bedrock이 30초로 늘리는 변경을 제안한다. 제공된 원문은 제안 응답 중간에서 끝나므로 실제 승인, 변경 적용, 장애 해소 여부는 확인할 수 없다.

🧩 주요 포인트

1. 조사 완료 이벤트를 복구 실행으로 연결 → AWS DevOps Agent의 진단 결과를 후속 조치에 활용해 MTTR 단축을 지향한다.
2. 승인된 Lambda 도구 허용 목록과 사람의 승인으로 실행 범위를 제한 → 읽기 전용 작업의 자동화와 인프라 변경 통제를 함께 구현한다.
3. 초 설정 확인과 30초 변경 제안까지 제시 → 복구 판단 과정은 드러나지만 실제 적용과 장애 해소의 검증은 제공된 원문만으로 불가능하다.

🧠 상세 정리

1. 진단에서 복구까지의 간극

AWS에서 운영 워크로드를 실행하는 조직은 장애 탐지, 조사, 복구 사이의 시간을 줄이는 것을 중요한 과제로 삼는다. 장애가 발생하면 당직 엔지니어는 밤중에도 여러 애플리케이션 구성 요소를 살펴보고 근본 원인을 찾아 수정해야 한다. AWS DevOps Agent는 지표, 로그, 애플리케이션 토폴로지를 연계해 상시 자율적으로 장애를 분류하고 근본 원인 분석과 해결 권고를 제공한다. 다만 조직은 통제권 유지와 의도하지 않은 변경 방지를 위해 이 같은 관측 에이전트를 대체로 관찰·보고 모드로 운영한다. 글은 Amazon EventBridge, AWS Lambda Durable Functions, Amazon Bedrock을 연결해 조사 요약을 사전 검증된 수정안으로 전환하고 단일 승인으로 실행할 수 있도록 하는 방식을 제시한다. MTTR 단축과 반복적인 진단 업무 감소는 이 설계가 지향하는 효과이며, 제공된 내용에는 이를 정량적으로 입증하는 결과가 없다.

2. 이벤트 기반 연결과 내구성 있는 실행

AWS DevOps Agent가 조사를 완료하면 증상, 조사 결과, 근본 원인 분석을 담은 이벤트를 내보내고 Amazon EventBridge가 이를 수신한다. EventBridge는 devops-agent-trigger를 실행하며, 이 함수는 조사 요약을 준비해 devops-agent-remediation-durable을 호출한다. 내구성 함수는 조사 맥락을 Amazon Bedrock에 보내 적용 가능한 복구 조치와 도구를 검토하게 한다. Amazon Bedrock은 승인된 Lambda 함수 허용 목록에서 도구를 선택하고, 오케스트레이터는 실행 결과를 대화에 다시 전달하면서 복구가 완료될 때까지 반복하도록 설계되어 있다. AWS Lambda Durable Functions는 최대 1년 동안 실행되는 다단계 애플리케이션과 AI 워크플로를 지원하며, 진행 상태 저장과 장기 작업 중 실행 중단 및 장애 후 복구를 처리한다. 따라서 이 방식은 조사 결과를 실행으로 연결하는 동시에 중단과 재개가 필요한 복구 절차의 상태를 유지한다.

3. 허용 목록과 작업 유형별 통제

자동 실행의 범위를 통제하고 감사 가능성을 확보하기 위해 오케스트레이터는 선별된 복구 도구 허용 목록을 적용한다. 각 도구는 특정한 범위의 작업을 수행하도록 만든 Lambda 함수이며, 원문은 Lambda 함수 설정 조회와 AWS Identity and Access Management(IAM) 정책 문장 변경을 예로 든다. Amazon Bedrock은 이 승인된 도구 집합에서만 도구를 선택하고 호출할 수 있으므로, 조사 결과를 받았다고 해서 임의의 인프라 작업을 수행할 수 있는 구조는 아니다. 읽기 전용 도구는 사람의 개입 없이 실행되지만, 인프라 상태를 바꾸는 작업은 내구성 함수의 실행을 중단시키고 사람의 승인을 기다리게 한다. 이 구분은 필요한 설정 정보를 자동으로 수집하면서 실제 변경에 대한 통제권을 유지하는 핵심 장치다. 승인 후에는 선택한 도구를 통해 복구 조치를 인프라에 적용하도록 워크플로가 구성된다.

4. 승인 대기와 피드백 확장

인프라 변경에 대한 승인을 기다릴 때 AWS Lambda Durable Functions는 진행 상태를 체크포인트로 저장하고 실행을 일시 중단한다. 대기 시간은 몇 분에서 몇 시간 또는 며칠까지 이어질 수 있으며, 이 기간에는 컴퓨팅 자원을 소비하지 않고 승인 신호를 받으면 중단한 지점에서 재개한다. 글이 제시하는 목표는 당직 엔지니어가 개입할 때 관련 설정 수집과 근본 원인에 맞는 조치 검토가 이미 끝나 있어, 준비된 변경을 한 번의 승인으로 실행할 수 있게 하는 것이다. 현재 구현은 승인 또는 거부 신호를 사용하지만, 콜백 자체는 임의의 JSON 페이로드를 받을 수 있다. 이를 활용하면 매개변수 재정의나 검토자의 관찰 내용을 승인 응답에 담아 Amazon Bedrock 대화로 되돌리는 확장이 가능하다. 다만 이런 피드백을 통해 실행 전에 제안을 수정하는 방식은 확장 가능성으로 설명되며, 현재 구현의 기본 승인 동작과 구별된다.

5. 사전 준비와 타임아웃 장애 재현

배포의 사전 조건은 설치와 구성이 완료된 AWS CLI, Python 3.14 이상, 설치된 AWS CDK, 활성 AWS DevOps Agent space다. 선택 사항인 Kiro와 Agent Toolkit for AWS를 사용하면 IAM 기반 접근 제어가 적용된 관리형 MCP Server를 통해 AWS API에 접근하고, 장애 재현과 배포 및 정리 단계를 자연어 요청으로 진행할 수 있다. 이 경우 AWS MCP Server를 ~/.kiro/settings/mcp.json에 추가하며, 저장소의 규칙과 에이전트 파일이 프로젝트 맥락과 배포 순서 및 안전 관례를 제공한다. 전체 흐름을 검증하기 위한 사례는 Lambda 함수가 설정된 타임아웃을 초과하는 장애다. 저장소에는 devops-agent-timeout 함수와 이를 배포하고 호출해 Amazon CloudWatch Logs에서 타임아웃 오류를 확인하는 절차가 포함되어 있다. 해당 함수에서 최소 한 번의 타임아웃 오류가 발생하면 AWS DevOps Agent의 조사를 시작할 수 있다.

6. AWS CDK 배포와 최소 권한 구성

수동 배포는 GitHub의 sample-automate-remediation-post-devops-agent-investigation 저장소를 복제하고 해당 디렉터리로 이동하는 과정으로 시작한다. 특정 AWS 계정과 AWS 리전의 조합에서 AWS CDK를 처음 사용하는 경우 cdk bootstrap을 수행한 뒤 cdk deploy로 스택을 배포한다. 스택은 devops-agent-trigger, devops-agent-remediation-durable, devops-agent-lambda-tool의 Lambda 함수 3개와 Amazon EventBridge 규칙을 생성하고 구성한다. 권한은 최소 권한 원칙에 따라 부여되며, EventBridge에는 트리거 함수의 lambda:InvokeFunction 권한, 트리거 함수에는 조사 저널 조회를 위한 aidevops:ListJournalRecords 권한이 포함된다. 내구성 함수에는 Amazon Bedrock 호출을 위한 bedrock:InvokeModel 권한이 부여된다. Kiro를 사용하는 대안에서는 Python 환경과 의존성을 준비하고 생성할 리소스를 먼저 보여주며, 저장소 규칙에 따라 각 인프라 변경을 실행하기 전에 확인을 받는 흐름을 설명한다.

7. 조사 완료부터 실행 기록 확인까지

복구 스택을 배포하고 devops-agent-timeout에서 타임아웃 오류가 발생한 상태에서 AWS DevOps Agent 콘솔의 에이전트 공간을 열어 해당 함수에 무슨 일이 일어나는지 질문한다. 조사는 몇 분 동안 진행되며, 에이전트는 CloudWatch 지표와 로그 및 함수 설정을 연계해 근본 원인을 판단한다. 조사 완료 결과는 워크로드에 비해 함수 타임아웃이 부족하다는 분석을 제시하고, Investigation Completed 이벤트가 Amazon EventBridge로 전달된다. 규칙에 의해 실행된 devops-agent-trigger는 AWS DevOps Agent 저널에서 조사 요약을 가져오며, /aws/lambda/devops-agent-trigger 로그 그룹에는 증상과 근본 원인, 기여 원인, 조사 공백을 포함한 파싱 결과가 표시된다. 이 요약이 devops-agent-remediation-durable로 전달된 뒤에는 Lambda 콘솔의 Durable executions 탭에서 새 실행과 체크포인트가 저장된 단계를 확인할 수 있다. 이 절차는 진단 결과가 복구 오케스트레이터에 전달되는 연결을 관찰하는 검증 흐름이다.

8. 3초 설정 확인과 30초 변경 제안

내구성 오케스트레이터는 첫 번째 Amazon Bedrock 호출에서 조사 맥락을 전달하고, 모델은 수정안을 제시하기 전에 현재 함수 설정을 확인할 필요가 있다고 판단한다. 이에 허용 목록의 lambda_get_function_configuration 도구를 선택하며, 읽기 전용 작업이므로 사람의 승인 없이 실행된다. 도구 결과는 devops-agent-timeout의 현재 타임아웃이 3초임을 확인하고, Amazon Bedrock은 다음 반복에서 이 설정을 장애의 근본 원인으로 판단해 30초로 늘리는 조치를 제안한다. 원문은 Bedrock 응답에 판단 근거와 도구 호출이 함께 포함된다고 설명하고 응답 JSON 일부를 제시한다. 그러나 제공된 자료는 해당 응답의 문장 중간에서 끝나므로, 이 제안에 대한 승인 여부나 실제 설정 변경 및 후속 검증 결과는 나타나지 않는다. 따라서 이 사례에서 확인되는 범위는 현재 설정 조회와 구체적인 변경 제안까지이며, 장애 해소가 완료되었다고 결론 내릴 수는 없다.

🧾 핵심 주장 / 시사점

• 이 설계의 핵심 전환점은 AWS DevOps Agent가 만든 조사 결과를 후속 복구의 입력으로 사용한다는 데 있다. 진단과 실행을 연결하면서도 인프라 변경의 승인 권한은 사람에게 유지한다.
• AWS Lambda Durable Functions의 체크포인트와 실행 중단·재개 기능은 승인 대기 시간을 워크플로 안에서 처리하게 한다. 승인된 도구 허용 목록은 모델이 선택할 수 있는 실행 범위를 제한하는 별도의 통제 장치다.
• devops-agent-timeout 사례는 조사 결과를 현재 설정과 대조한 뒤 변경을 제안하는 과정을 보여준다. 다만 3초에서 30초로의 변경 제안은 실제 적용이나 복구 성공을 입증하는 결과와 구분해야 한다.

✅ 액션 아이템

• AWS DevOps Agent의 조사 완료 이벤트가 Amazon EventBridge와 devops-agent-trigger를 거쳐 devops-agent-remediation-durable에 전달되는 연결 확인.
• 승인된 Lambda 도구 허용 목록에서 읽기 전용 작업과 인프라 변경 작업의 구분 및 사람의 승인 적용 여부 점검.
• devops-agent-timeout의 3초 설정을 30초로 늘리는 제안에 대해 실제 승인, 변경 적용, 장애 해소 여부 추가 확인.

❓ 열린 질문

• AWS DevOps Agent와 복구 워크플로를 연결했을 때 MTTR은 실제로 얼마나 줄어드는가?
• 승인된 Lambda 도구 허용 목록에서 읽기 전용 작업과 인프라 변경 작업의 구분은 어떻게 적용되는가?
• devops-agent-timeout의 타임아웃을 3초에서 30초로 늘리는 제안은 실제로 승인·적용되었으며 장애가 해소되었는가?