AWS에서 프로덕션 워크로드를 운영하는 조직에게는 사고 감지, 조사, 복구 사이의 시간을 단축하는 것이 중요한 우선순위입니다. 문제가 발생하면 온콜 엔지니어는 애플리케이션 구성 요소 전반에 걸쳐 신속하게 문제를 진단하고, 근본 원인을 파악하고, 수정 사항을 적용해야 하는데, 이는 종종 한밤중에 이루어집니다.
AWS DevOps Agent, 상관 관계가 있는 지표, 로그 및 애플리케이션 토폴로지를 기반으로 종일 자율적으로 인시던트를 분류하는 AI 기반 에이전트는 근본 원인 분석(RCA)과 해결을 위한 권장 조치를 제공하여 이 우선순위의 첫 번째 부분을 다룹니다. 그러나 제어권을 유지하고 의도하지 않은 변경을 방지하기 위해 조직은 일반적으로 AWS DevOps Agent를 포함한 observability 에이전트를 관찰 및 보고 모드로 유지하며, 이 모드에서는 에이전트가 문제를 진단하지만 프로덕션 리소스를 직접 수정하지는 않습니다. 이 게시물에서는 다음을 사용하는 방법을 보여줍니다 AWS Lambda Durable Functions, AWS Lambda의 기능인 Amazon EventBridge및 Amazon Bedrock 을 사용하여 AWS DevOps Agent를 보완해 문제 해결 단계를 완료하는 자동화된 복구 워크플로를 만듭니다. 이 워크플로는 조사 요약을 단일 승인 작업으로 실행할 수 있는 사전 검증된 수정책으로 변환하여, 평균 복구 시간(MTTR)을 줄이고 온콜 엔지니어를 반복적인 진단 작업에서 해방시키는 데 도움을 줍니다.
솔루션 개요
를 사용하면 AWS Lambda Durable Functions을 통해 추가 인프라를 관리하거나 사용자 지정 상태 관리 및 오류 처리 코드를 작성할 필요 없이 최대 1년 동안 실행될 수 있는 복원력 있는 다단계 애플리케이션과 AI 워크플로를 구축할 수 있습니다. 이러한 함수는 진행 상황을 자동으로 체크포인트하고, 장시간 실행되는 작업 중에 실행을 일시 중단하며, 중단이 발생해도 안정적인 진행 상태를 유지하면서 실패로부터 복구합니다.
다음 다이어그램은 솔루션 아키텍처를 보여줍니다.
그림 1: AWS DevOps Agent 조사에서 Amazon EventBridge, AWS Lambda, Amazon Bedrock을 거쳐 변경 사항이 인프라에 적용되기 전 선택적 인간 승인에 이르는 자동화된 복구 워크플로
워크플로는 다음 단계로 구성됩니다:
- AWS DevOps Agent가 인시던트 조사를 완료하고 증상, 발견 사항 및 근본 원인 분석이 포함된 이벤트를 발생시킵니다.
- Amazon EventBridge가 조사 완료 이벤트를 수신하고 조사 내용과 함께
devops-agent-trigger함수를 트리거합니다. - Lambda 함수는 조사 요약을 패키징하고
devops-agent-remediation-durabledurable 함수를 호출합니다. - durable 함수는 조사 컨텍스트를 Amazon Bedrock으로 전송하고, Amazon Bedrock은 발견 사항을 분석하여 적용 가능한 복구 방법을 찾습니다.
- Amazon Bedrock은 승인된 Lambda 함수의 큐레이션된 허용 목록에서 사용 가능한 복구 도구를 식별하고 나열합니다:
devops-agent-lambda-tool. - Amazon Bedrock은 조사 결과와 사용 가능한 도구를 기반으로 구체적인 복구 작업을 제안합니다.
- 읽기 전용 작업의 경우 durable 함수가 자율적으로 복구 도구를 실행합니다. 인프라 변경의 경우 워크플로는 일시 중단되고 진행하기 전에 인간 승인 을 기다립니다.
- 승인 후 durable 함수는 선택된 도구를 사용하여 복구 작업을 인프라에 적용합니다.
이 내구성 함수는 다음으로 실행됩니다: 에이전트 루프는 Amazon Bedrock을 반복적으로 호출하고, 승인된 도구를 실행하며, 결과를 대화에 다시 피드백하여 수정이 완료될 때까지 진행합니다. 자동화된 작업을 안전하고 감사 가능하게 유지하기 위해 오케스트레이터는 엄선된 수정 도구 허용 목록을 강제 적용합니다. 각 도구는 Lambda 함수 구성 읽기 또는 AWS Identity and Access Management (IAM) 정책 문 업데이트와 같이 특정하고 범위가 명확한 작업을 수행하는 목적에 맞게 구축된 Lambda 함수입니다. Amazon Bedrock은 이 승인된 집합에서만 도구를 선택하고 호출할 수 있으므로 자동화된 작업의 범위가 통제됩니다. 또한 이 워크플로는 읽기 전용 작업과 변경 작업을 구분합니다. 읽기 전용 도구는 사람의 개입 없이 자율적으로 실행됩니다. 인프라 상태를 수정하는 변경 작업은 영속성 함수가 실행을 일시 중단하고 사람의 승인을 기다리게 합니다. 바로 이 부분에서 AWS Lambda Durable Functions가 핵심적인 이점을 제공합니다. 함수 체크포인트 진행 상태를 저장하고 몇 분, 몇 시간, 심지어 며칠 동안 컴퓨팅 리소스를 소비하지 않고 일시 중지한 뒤, 승인 신호를 받으면 중단된 지점에서 정확히 재개합니다. 온콜 엔지니어가 개입할 때쯤이면 시스템은 이미 관련 구성을 수집하고, 근본 원인을 사용 가능한 복구 조치와 연관 지었으며, 원클릭 승인을 위해 사전 검증된 변경 사항 세트를 준비해 둔 상태입니다. 현재 구현은 승인 또는 거부 신호를 사용합니다. 콜백이 임의의 JSON 페이로드를 수락하기 때문에, 승인에 파라미터 재정의나 검토자 의견을 포함하도록 확장할 수 있습니다. 이러한 내용은 실행 전에 제안된 복구 방안을 개선하기 위해 Bedrock 대화에 다시 입력될 수 있습니다.
다음 섹션에서는 Amazon EventBridge 규칙 구성과 내구성 있는 함수 오케스트레이션 로직을 포함한 구현 세부 사항을 살펴봅니다. 그런 다음 다음을 사용하여 솔루션을 배포합니다. AWS Cloud Development Kit (AWS CDK).
필수 조건
이 솔루션을 배포하기 전에 다음 사전 요구 사항을 충족하는지 확인하십시오:
- 이 AWS Command Line Interface (AWS CLI)가 설치 및 구성되어 있어야 합니다.
- Python 3.14 이상.
- 그 AWS CDK 설치되었습니다.
- 활동적인 AWS DevOps Agent 스페이스.
- (선택 사항) Kiro ~와 함께 AWS용 에이전트 툴킷. Agent Toolkit은 Kiro가 IAM 기반 액세스 제어가 적용된 관리형 MCP Server를 통해 AWS API에 안전하게 액세스할 수 있도록 합니다. Kiro를 사용하면 이 게시물의 장애 시뮬레이션, 배포 및 정리 단계를 CLI 명령을 수동으로 실행하는 대신 자연어 프롬프트로 완료할 수 있습니다. 이를 설정하려면 AWS MCP Server를 추가하세요.
~/.kiro/settings/mcp.json(설치 지침(으)로 마무리됩니다). 이 저장소에는 Kiro 규칙 및 에이전트 파일이 포함되어 있어 Kiro에게 프로젝트 맥락, 배포 순서 및 안전 규칙을 자동으로 제공합니다.
사건 시뮬레이션하기
엔드 투 엔드 워크플로를 시연하기 위해, 우리는 흔히 발생하는 시나리오를 시뮬레이션합니다: 구성된 타임아웃을 초과하는 Lambda 함수입니다. 이를 통해 AWS DevOps Agent가 조사할 실제 인시던트를 확보하고 복구 워크플로가 시작됩니다.
취약점 해결 솔루션 자체에 초점을 맞추기 위해 이 테스트 함수를 생성하고 호출하는 단계는 다음에 저장소. 여기에는 바로 사용할 수 있는 devops-agent-timeout 기능과 이를 배포하고, 호출하고, Amazon CloudWatch Logs에서 타임아웃 오류를 확인하는 단계별 지침을 다룹니다. 전체 과정은 다음을 참조하십시오: README의 “Simulate the incident”(사고 시뮬레이션) 섹션.
함수가 배포되고 최소 한 번의 타임아웃 오류가 발생한 후에는 AWS DevOps Agent로 조사를 시작할 준비가 된 것입니다.
AWS CDK를 사용하여 솔루션 배포
다음 단계를 완료하여 나머지 솔루션 리소스를 배포합니다:
Kiro: AWS용 Agent Toolkit이 구성된 Kiro가 있다면(사전 요구 사항 참조), 복제한 리포지토리를 Kiro에서 열고 다음과 같이 요청합니다: “Python 환경을 설정하고 CDK 스택을 배포하세요. 배포하기 전에 어떤 리소스가 생성될지 보여주세요.” 그러면 Kiro는 리포지토리에서 프로젝트 규칙을 읽어 가상 환경을 설정하고, 종속성을 설치하며, 배포 전에 계획된 리소스를 보여줍니다. 실행 전에 각 인프라 변경을 확인하는데, 이는 remediation 솔루션 자체가 사용하는 것과 동일한 human-in-the-loop 패턴을 따르는 것입니다. 수동으로 배포하려면 다음 단계를 따르십시오.
- GitHub에서 호스팅되는 AWS CDK 코드를 복제합니다:
$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git - 해당 디렉터리로 이동합니다
sample-automate-remediation-post-devops-agent-investigation:$ cd sample-automate-remediation-post-devops-agent-investigation - AWS CDK를 부트스트랩합니다. 특정 AWS 환경 (AWS 계정과 AWS 리전의 조합)에서 AWS CDK를 처음 사용할 때 필요한 작업입니다.
$ cdk bootstrap - 스택을 배포합니다:
$ cdk deploy
AWS CDK는 다음 리소스를 자동으로 프로비저닝하고 구성합니다:
- 세 개의 Lambda 함수:
devops-agent-trigger.devops-agent-remediation-durable.devops-agent-lambda-tool.
- Amazon EventBridge 규칙.
AWS CDK는 최소 권한 원칙과 AWS 보안 모범 사례에 따라 IAM 권한을 자동으로 처리합니다. 예를 들어, Amazon EventBridge에는 lambda:InvokeFunction 함수에 대한 devops-agent-trigger 권한이 부여됩니다. 또한 스택은 aidevops:ListJournalRecords 함수에 devops-agent-trigger 권한을 부여하여 AWS DevOps Agent 저널에서 조사 요약을 가져올 수 있도록 합니다. 아울러 bedrock:InvokeModel 함수에 devops-agent-remediation-durable 권한을 부여하여 Amazon Bedrock을 호출할 수 있도록 합니다.
솔루션 검증
remediation 스택이 배포되고 devops-agent-timeout 함수가 타임아웃 오류로 실패하는 상태이므로, 이제 엔드투엔드 워크플로를 살펴볼 수 있습니다.
AWS DevOps Agent로 조사 시작
다음을 엽니다: AWS DevOps Agent 콘솔에서 에이전트 스페이스로 이동한 후 다음과 같이 질문합니다: “devops-agent-timeout 함수에 무슨 일이 일어나고 있나요?”
그림 2: AWS DevOps Agent 콘솔에서 조사 시작
조사가 시작되고 완료까지 몇 분 정도 걸립니다. 이 시간 동안 AWS DevOps Agent는 CloudWatch 지표, 로그 및 함수 구성을 자율적으로 상호 연관하여 근본 원인을 파악합니다.
그림 3: 조사 중 AWS DevOps Agent가 신호를 상호 연관하는 모습
조사가 완료되면 AWS DevOps Agent는 근본 원인 분석을 제시하며, 워크로드에 대해 함수 타임아웃이 불충분하다는 것을 식별합니다.
그림 4: 불충분한 함수 타임아웃을 식별하는 근본 원인 분석
트리거 Lambda 실행 검증
조사가 완료되면 Amazon EventBridge로 Investigation Completed 이벤트를 내보냅니다.
이 규칙은 다음을 트리거합니다. devops-agent-trigger AWS DevOps Agent 저널에서 조사 요약을 가져오는 Lambda 함수입니다. 이 /aws/lambda/devops-agent-trigger CloudWatch 로그 그룹에서 전송된 파싱된 요약을 볼 수 있습니다. devops-agent-remediation-durable durable function은 원인, 기여 원인, 조사 공백을 포함합니다.
그림 5: 트리거 함수 CloudWatch 로그 그룹의 파싱된 조사 요약
영구 함수 실행 모니터링
다음으로 이동합니다: Lambda 콘솔, 여세요 devops-agent-remediation-durable 기능을 선택한 후 내구성 있는 실행 탭. 새 실행을 선택하여 체크포인트가 저장된 단계를 확인하세요.
그림 6: Lambda 콘솔에서의 durable function 실행과 체크포인트된 단계들
내구성 있는 오케스트레이터는 조사 컨텍스트를 Amazon Bedrock에 전송하는 방식으로 에이전틱 루프를 시작합니다. 첫 번째 Bedrock 호출에서 모델은 조사 요약을 분석하고 수정안을 제안하기 전에 현재 함수 구성을 확인해야 한다고 판단합니다. 모델은 다음을 선택합니다. lambda_get_function_configuration allowlist의 tool. 이 작업은 읽기 전용이므로 사람의 승인 없이 자율적으로 실행됩니다. 단계 결과에는 현재의 구성이 표시됩니다. devops-agent-timeout 3초의 타임아웃 값을 확인하는 기능입니다.
Figure 7: 현재 3초 타임아웃 설정을 반환하는 읽기 전용 툴 호출
Amazon Bedrock가 수정 조치를 제안합니다
현재 구성이 확인되면 Amazon Bedrock은 다음 반복으로 진행합니다. 3초 타임아웃이 실패의 근본 원인이라고 판단하고 이를 30초로 늘리자고 제안합니다. Amazon Bedrock의 응답에는 추론과 도구 호출이 모두 포함되어 있습니다.
{
....
},
"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"
}
}
...
}왜냐하면 lambda_update_function_configuration "is a mutating action, the durable function suspends execution and waits for human approval." → 영속성 함수(durable function)는 실행을 일시 중단하고 사람의 승인을 기다립니다.
그림 8: 승인 요청을 위한 lambda durable 함수의 cloudwatch 로그 출력
중요: The investigation_summary Amazon Bedrock로 전송되는 내용과 그것이 제안하는 수정 조치는 AI가 생성한 것이므로 승인 전에 반드시 검토해야 합니다. 사람의 승인 단계가 바로 보안 통제입니다. 승인자는 전체 도구 매개변수(예: 정확한 FunctionName 그리고 Timeout 하나의 lambda_update_function_configuration 변경 사항이 올바른지 확인하세요.
AWS CLI 사용:
$ aws lambda send-durable-execution-callback-success \
--callback-id <callback-id> \
--cli-binary-format raw-in-base64-out \
--result '{"approved": true}'AWS 콘솔 사용:
내구성 있는 실행(durable execution)으로 이동하여 대기 중인 콜백을 선택한 후 선택하세요. 전송 성공 확인하려면:
그림 9: Lambda 콘솔에서 Send success를 선택하여 복구를 승인하는 모습
입력 필드에 다음을 입력하십시오. {'approved': true} 및 확인합니다.
그림 10: 콜백을 확인하기 위한 승인 페이로드 입력
수정 사항 확인
승인이 완료되면 durable function이 재개되어 도구 Lambda를 호출해 구성을 업데이트하고, Amazon Bedrock이 수정이 완료되었음을 확인합니다. 업데이트된 devops-agent-timeout 함수는 이제 새로운 타임아웃 값을 표시합니다:
그림 11: devops-agent-timeout 함수 구성이 30초 타임아웃으로 업데이트된 모습
최종 단계 출력은(bedrock-call-4")가 성공적인 조치를 확인합니다:
{
"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",
...
}이 전체 주기는 사고 감지부터 자동화된 수정까지 엔지니어의 단 한 번의 승인 조치만 필요로 했습니다. 시스템이 진단, 구성 검색, 복구 제안 및 실행을 자율적으로 처리했습니다.
정리
다음 단계를 완료하여 생성한 리소스를 정리하세요:
Kiro: Agent Toolkit for AWS와 함께 Kiro를 사용한다면 이렇게 물어보세요: “DevOps Agent 복구 데모의 모든 리소스를 정리하십시오: CDK 스택을 삭제하고, devops-agent-timeout 테스트 함수, 해당 IAM 역할, 그리고 CloudWatch 로그 그룹을 삭제하십시오.” Kiro는 리소스를 올바른 순서로 제거하며, 각 삭제 작업을 진행하기 전에 확인합니다. 수동으로 정리하려면 다음 단계를 따르십시오.
- AWS CDK 리소스를 삭제합니다:
$ cdk destroy - 수동으로 삭제합니다:
devops-agent-timeout인시던트를 시뮬레이션하는 함수:$ aws lambda delete-function --function-name devops-agent-timeout - 의 IAM 역할과 CloudWatch 로그 그룹을 수동으로 삭제합니다:
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
결론
이 게시물은 Lambda Durable Functions, Amazon EventBridge, Bedrock을 DevOps Agent와 함께 사용하여 문제 해결을 자동화하는 방법을 시연했습니다. 이 솔루션은 AWS DevOps Agent가 중단된 지점에서 이어받아 조사 요약을 승인 대기 중인 사람(human-in-the-loop)의 승인과 함께 실행되는 실행 가능한 remediation 단계로 변환합니다. 이 접근 방식은 평균 해결 시간(mean time to resolution)을 단축합니다. 온콜 엔지니어가 투입될 때쯤이면 시스템이 이미 문제를 진단하고, 최신 구성을 수집하고, 승인 준비가 완료된 수정책을 준비해두기 때문입니다. 안전성은 설계의 중심에 그대로 있습니다: allowlist는 Amazon Bedrock이 사전 승인된 도구만 호출하도록 제한하며, 사람의 승인 단계는 명시적인 승인 없이 의도하지 않은 변경 사항이 프로덕션에 적용되는 것을 방지하는 데 도움이 됩니다. 또한 이 아키텍처는 본질적으로 확장 가능합니다. 새로운 remediation 기능을 추가하려면 오케스트레이터의 코드 변경이 아닌 도구 레지스트리에 대한 구성 업데이트만 필요합니다. 그리고 AWS Lambda Durable Functions는 승인 대기 중에 컴퓨팅 리소스를 소비하지 않고 일시 중단되므로, 승인 주기가 몇 시간 또는 며칠에 걸쳐 진행되더라도 솔루션은 비용 효율성을 유지합니다.
이 솔루션을 사용하기 시작하려면 GitHub 리포지토리에서 전체 AWS CDK 템플릿을 다운로드하고, 이 게시물의 단계에 따라 여러분의 환경에 솔루션을 배포하십시오.
여러분의 의견을 기다립니다. 이 솔루션을 구현한 경험을 공유하거나, 질문을 하거나, 댓글에서 개선 사항을 제안해 주세요. 또한 AWS Community Builders 프로그램에 참여하여 다른 빌더들과 교류하고 여러분의 서버리스 아키텍처 패턴을 공유할 수 있습니다.