세 개의 고장 난 AWS 환경을 AI 온콜 엔지니어에게 맡겼더니, AWS DevOps Agent가 찾아낸 것

새벽 2시입니다. CloudWatch 알림이 울립니다. 온콜 엔지니어가 잠에서 깨어나 콘솔 탭 다섯 개를 열고, 사건의 타임라인을 처음부터 재구성하기 시작합니다.

AWS DevOps Agent는 바로 그 고통스러운 분석의 첫 시간을 처리하도록 설계되었습니다. AWS는 이를 '프론티어 에이전트(frontier agent)'라고 부르는데, 이는 단순히 사고를 해결하는 것뿐만 아니라 발생하기 전에 예방까지 한다는 의미입니다. 이 에이전트는 CloudWatch 메트릭, CloudTrail 데이터, VPC Flow Logs, RDS Performance Insights, 그리고 IaC 스택을 분석하여 근본 원인 분석(root-cause analysis)과 복구 조치 계획(action plan for remediation)을 제공합니다.

저는 이것이 실제로 어떻게 작동하는지 궁금해서, 사고 조사에 중점을 둔 AWS DevOps Agent 워크숍에 참여했습니다. 이 워크숍은 시스템 설정 관련 실습 하나와 사전에 주입된 결함이 있는 특별히 준비된 환경을 이용한 세 가지 실습으로 구성되었습니다. 저는 얼마 전에 AWS User Group 3City 커뮤니티가 AWS와 협력하여 주최한 이 흥미로운 행사에 참석했습니다.

AWS DevOps Agent console landing page

AWS DevOps Agent 콘솔: "해결(Resolve). 예방(Prevent). 개선(Improve)."

• 공간(space)을 지정하고, 선택적으로 응답 언어를 선택할 수 있습니다 (러시아어, 일본어, 포르투갈어 등 사용 가능).
• 기본 AWS 계정을 위한 **읽기 역할(read role)**을 자동 생성하도록 설정합니다.
• 선택적으로 **에이전트 액션(Agent Actions)**을 켜서 쓰기 작업용 별도의 역할을 지정할 수 있습니다. 모든 변경 사항은 명시적인 승인이 필요합니다.
• 운영팀이 사용하는 운영자 UI인 **웹 앱(web app)**을 활성화합니다.

Agent Space details and primary account role

Agent Actions, tags and web app roles

공간이 생성되면, 더 많은 **기능(capabilities)**을 추가할 수 있습니다: 보조 AWS 계정, Azure, GitHub/GitLab/Azure DevOps 파이프라인, Datadog/Dynatrace/New Relic/Splunk/Grafana 원격 측정(telemetry), Slack/ServiceNow/PagerDuty, 모든 MCP 서버, 심지어 A2A 프로토콜을 통한 원격 에이전트까지 가능합니다.

👉 전체 워크스루: Part 1: AWS DevOps Agent 설정하기

Part 2:

• CPU 크레딧 스로틀링(CPU credit throttling)은 배제했습니다. 왜냐하면 CPUCreditBalance가 t3.micro의 최대치인 288을 유지했기 때문입니다.
• 스파이크가 사용자 트래픽이 아니었음을 보여주었습니다. 애플리케이션 로드 밸런서(ALB)가 0~1 req/min에 머물렀기 때문입니다.
• CPU 사용량 급증을 일으킨 정확한 SSM Run Command ID를 찾아냈습니다.
• 자신이 할 수 없는 것까지 명확히 말했습니다. 워크숍 계정(workshop account)에서 CloudTrail이 차단되어, IAM 주체(IAM principal)를 특정할 수 없었기 때문입니다.

Completed summary: complete, Severity low

👉 Part 2: EC2 CPU spike investigation

Part 3: VPC Flow Logs를 사용한 네트워크 공격 조사

저는 노트북에서 스크립트를 실행하여 웹 서버의 포트 스캐닝을 수행하고, 관리자 페이지를 열거(enumerate)했으며, SSH 로그인을 시도하고 HTTP 요청으로 플러딩했습니다.

에이전트는 이를 **심각도: 높음(Severity: high)**으로 평가했습니다. VPC Flow Logs를 사용하여 출처 IP를 식별하고 스캔된 포트를 나열했으며, 포트 80에서 수신된 2,764개의 승인 패킷이 실제 공격이었음을 확인했습니다.

가장 눈에 띄었던 부분은 제가 요청하지 않았던 **과거 기록(historical context)**이었습니다. 동일한 경보의 이전 발생 건들을 살펴보니, 4건 중 3건이 무해한 S3 반환 트래픽이었으며, 이는 경보 자체를 조정해야 함을 의미했습니다.

Network security summary: Severity high

👉 Part 3: Network security investigation

Part 4: RDS 연결 고갈, 그리고 에이전트가 스스로 모순된 부분

배스천 호스트(bastion host)에서 실행한 스크립트는 max_connections=150 제한에 대해 약 140개의 연결을 열고 카테시안 조인(Cartesian joins)으로 CPU를 고정했습니다.

조사는 훌륭했습니다. Performance Insights를 사용하여 SLEEP() 상태에 있는 108개 세션과 CROSS JOIN 쿼리의 38개 AAS(Active Sessions)로 부하를 분산했으며, 이 모든 것을 단일 호스트와 DB 사용자에게서 추적해냈습니다.

RDS connections & CPU chart

이후 채팅에서 후속 질문을 던지며, 채팅 내용과 완화 계획(mitigation plan) 사이에 두 가지 모순점을 발견했습니다. 두 내용은 150이라는 숫자가 기본 max_connections보다 높은지 낮은지에 대해 의견이 달랐고, wait_timeout이 도움이 될지에 대해서도 이견이 있었습니다. 파트 4에서 어느 쪽이 맞았는지 다룹니다.

👉 Part 4: RDS performance investigation

좋았던 점 (What I liked)

1. 단순히 무엇이 문제인지가 아니라, 왜 문제가 발생했는지에 답합니다. 근본 원인 중 어느 것도 단순히

• 채팅 답변을 조사 결과와 비교하여 확인하세요. 구조화된 발견 사항이 대화형 답변보다 더 신중했습니다 (파트 4 참조).
• IAM 범위가 찾을 수 있는 것을 결정합니다. 에이전트는 자신의 역할과 사용자의 SCP(Service Control Policies)가 허용하는 것만 조사할 수 있습니다. 워크샵 계정에서는 CloudTrail 조회, GuardDuty 및 RDS 로그 다운로드가 차단되었고, 이러한 격차는 결과에 나타났습니다.
• 조사는 시간이 걸립니다. 8~16분을 예상하세요. 이는 새벽 2시에 시작하는 사람과 비교하면 빠르지만, 즉각적이지는 않습니다.
• **