DOP-C02에서 인시던트 및 이벤트 대응 도메인은 시험 전체의 14%를 차지합니다. 단순히 도구를 아는 수준을 넘어 "어떤 이벤트 소스가 무엇을 트리거하는가", "자동화된 대응 체인을 어떻게 설계하는가"를 묻는 문제가 집중됩니다.
이벤트 소스 관리와 처리 패턴
DevOps 엔지니어에게 이벤트 소스를 정확히 이해하는 것은 매우 중요합니다. AWS는 다양한 이벤트 생성 서비스를 제공하며 각각 용도가 다릅니다.
AWS Health + EventBridge 패턴
AWS Health는 AWS 계정에 영향을 미치는 서비스 장애, 예정된 유지보수, 인스턴스 폐기(retirement) 이벤트를 실시간으로 발행합니다. EventBridge의 이벤트 소스로 를 사용하면 Health 이벤트를 즉시 캡처할 수 있습니다.
실무 시나리오를 보겠습니다. 수천 대의 EC2 인스턴스를 운영하는 기업에서 AWS가 특정 인스턴스들에 대한 retirement 일정을 통보했을 때, 수동으로 콘솔을 확인하다가 늦게 대응하는 문제가 발생했습니다. 해결책은 EventBridge 규칙으로 이벤트를 감지하고 SSM Automation 런북을 트리거해 자동으로 인스턴스를 중지·재시작하는 것입니다.
| 이벤트 소스 | source 값 | 대표 이벤트 유형 | |------------|----------|----------------| | AWS Health | aws.health | EC2 retirement, 서비스 장애, 유지보수 | | CloudTrail | aws.cloudtrail (이미 통합됨) | 모든 AWS API 호출 | | EC2 Auto Scaling | aws.autoscaling | 인스턴스 시작·종료 lifecycle 이벤트 | | CodePipeline | aws.codepipeline | 파이프라인 상태 변화 |
Health vs CloudTrail을 혼동하지 마세요. AWS 인프라 자체의 상태 변화는 Health, 사용자가 수행한 API 호출은 CloudTrail입니다.
CloudTrail + EventBridge — 실시간 API 이벤트 감시
IAM 사용자 생성, 보안 그룹 규칙 변경 같은 민감한 API 호출을 실시간에 가깝게 탐지해야 할 때 CloudTrail과 EventBridge의 기본 통합을 활용합니다.
금융 기관 시나리오: IAM 정책상 IAM 사용자 직접 생성이 금지되어 있으나 일부 개발자가 우회하는 사례가 발생했습니다. 대응 아키텍처는 다음과 같습니다.
EventBridge 규칙에 이벤트 패턴 설정: Lambda 함수를 타겟으로 등록 Lambda가 + 호출로 즉시 비활성화 SNS를 통해 보안팀에 알림 전송
이 아키텍처는 API 호출 후 수 초 내에 감지→비활성화→알림이 완료됩니다. Athena 쿼리로 CloudTrail 로그를 주기적으로 분석하는 방식은 수십 분의 지연이 발생하므로 실시간 대응에 부적합합니다.
보안 그룹에 SSH 0.0.0.0/0 규칙이 추가되면 어떻게 하겠습니까? 동일한 패턴으로 이벤트를 감지하고 EventBridge 이벤트 패턴에 조건을 추가해 Lambda로 를 자동 실행합니다.
SQS Dead Letter Queue — 독성 메시지 격리
대규모 이벤트 처리 시스템에서 특정 메시지가 반복적으로 처리 실패해 정상 메시지 흐름을 방해하는 현상을 "독성 메시지(Poison Pill)"라고 부릅니다.
SQS Dead Letter Queue(DLQ)는 를 초과한 메시지를 원본 큐에서 자동으로 별도 DLQ로 이동시킵니다. 핵심은 독성 메시지를 격리해 정상 흐름을 보호하면서, DLQ에 격리된 메시지는 원본 그대로 보존되어 나중에 원인 분석 및 재처리가 가능하다는 점입니다.
Lambda가 SQS 이벤트 소스 매핑을 통해 메시지를 처리할 때, 배치 내 모든 메시지가 성공해야 ACK가 전송됩니다. 실패 시 배치 전체가 재시도됩니다. 에 도달하면 DLQ로 이동합니다. SQS 콘솔의 DLQ Redrive 기능으로 분석 완료 후 원본 큐로 재전송할 수 있습니다.
Kinesis Data Streams Enhanced Fan-Out — 소비자 확장
DynamoDB Streams에서 여러 Lambda 소비자가 동시에 동일 샤드를 읽으려 할 때 오류가 발생합니다. DynamoDB Streams는 샤드당 최대 2개의 동시 소비자만 허용합니다.
Kinesis Data Streams로 전환하면 Enhanced Fan-Out 기능으로 각 소비자가 샤드당 전용 2MB/s 처리량을 독립적으로 확보합니다. DynamoDB에서 Kinesis로의 직접 통합도 지원되어 코드 변경 없이 전환 가능합니다. SNS + SQS 팬아웃 패턴과의 차이: SNS+SQS는 메시지 브로커 계층을 추가하는 방식이고, Kinesis Enhanced Fan-Out은 스트림 소비자를 직접 확장하는 방식입니다.
이벤트 기반 구성 변경과 자동 복구
CloudWatch Alarm + SSM Run Command — 프로세스 자동 복구
인스턴스 자체는 정상이지만 그 위에서 실행 중인 게임 서버 프로세스가 간헐적으로 종료되는 상황을 생각해 보겠습니다. Auto Scaling 헬스 체크는 인스턴스 레벨 장애만 감지하므로 프로세스 장애는 탐지하지 못합니다.
해결책은 CloudWatch Agent의 플러그인으로 특정 프로세스의 실행 여부를 커스텀 메트릭으로 수집하는 것입니다. 프로세스 수가 0이 되면 CloudWatch Alarm이 발생하고, 알람 액션으로 SSM Run Command를 트리거해 해당 인스턴스에서만 프로세스를 재시작합니다.
이 방식의 장점: 인스턴스를 교체하지 않으므로 플레이어 세션이 끊기지 않습니다. Auto Scaling DesiredCapacity도 변경되지 않습니다. SSH 없이 SSM Agent를 통해 원격으로 명령을 실행합니다.
ASG Lifecycle Hook — 종료 전 로그 수집과 인스턴스 보존
Auto Scaling 그룹에서 인스턴스가 종료되면 그 위의 로그도 함께 사라집니다. 장애 원인 분석을 위해 로그를 보존해야 할 때 ASG Lifecycle Hook이 핵심 도구입니다.
Lifecycle Hook은 인스턴스가 → 상태로 전환될 때 단계를 삽입합니다. 이 대기 기간(기본 3600초, 최대 48시간) 동안 인스턴스는 실제로 종료되지 않고 접근 가능한 상태를 유지합니다.
두 가지 핵심 활용 패턴이 시험에 출제됩니다.
첫째, 로그 수집 패턴: EventBridge가 이벤트를 감지 → Lambda가 트리거되어 로그를 S3에 전송 → 호출 → 인스턴스 최종 종료. 로그 전송이 완료된 후에만 종료가 진행됩니다.
둘째, 서비스 디스커버리 동기화: 인스턴스가 추가될 때()와 종료될 때() 모두 Lambda를 트리거해 외부 레지스트리를 자동으로 동기화합니다.
주의할 함정: EventBridge + Run Command 조합은 개념적으로 유사해 보이지만, 이미 종료 중인 인스턴스에는 SSM 명령이 도달하지 않습니다. Lifecycle Hook으로 종료를 잠시 멈춰야만 명령 실행이 가능합니다.
CI/CD 파이프라인 장애 해결
CodeCommit → CodePipeline 자동 트리거가 동작하지 않을 때
개발자가 main 브랜치에 코드를 푸시해도 파이프라인이 자동으로 시작되지 않는다고 합니다. 수동 실행은 정상입니다. 어디를 먼저 확인해야 할까요?
정답은 EventBridge 규칙 상태 확인입니다. CodePipeline이 CodeCommit 소스를 구성할 때 이벤트를 감지하는 EventBridge 규칙을 자동으로 생성합니다. 이 규칙이 비활성화(DISABLED)되거나 잘못된 파이프라인 ARN을 가리키면 자동 트리거가 실패합니다. 수동 실행은 IAM 권한 문제가 아님을 증명하므로 트리거 메커니즘인 EventBridge 규칙이 원인입니다.
CodeDeploy 배포 이벤트가 모두 Skipped 상태로 표시될 때
배포가 실패하는 것이 아니라 아예 시작되지 않고 Skipped 상태가 표시됩니다. CodeDeploy Agent는 풀(pull) 방식으로 작동합니다. 에이전트가 CodeDeploy 서비스 엔드포인트를 주기적으로 폴링해 배포 명령을 확인합니다.
프라이빗 서브넷에서 NAT Gateway도 없고 VPC 엔드포인트도 없다면, 에이전트는 에 도달할 수 없고 폴링이 실패합니다. 모든 이벤트가 Skipped로 표시되는 것은 에이전트가 명령 자체를 받지 못했다는 의미입니다. Failed와 Skipped의 차이를 구별하세요. Failed는 에이전트가 받아서 실행했으나 실패한 것이고, Skipped는 에이전트가 아예 명령을 받지 못한 것입니다.
해결책: com.amazonaws.{region}.codedeploy VPC 인터페이스 엔드포인트를 생성하거나 NAT Gateway를 통한 인터넷 아웃바운드 경로를 확보합니다.
X-Ray와 Step Functions으로 복잡한 워크플로 추적
다단계 보안 인시던트 자동화 워크플로(노출된 액세스 키 비활성화 → CloudTrail 활동 요약 → 팀 알림)를 Lambda 체이닝으로 구현하면 각 단계의 실패를 추적하기가 매우 어렵습니다. AWS Step Functions Standard Workflow를 사용하면 각 상태의 입출력과 전환 이력을 90일간 보존합니다. Retry/Catch로 각 단계별 재시도 로직을 선언적으로 정의할 수 있습니다. EventBridge가 AWS Health 이벤트를 감지 → Step Functions 워크플로를 시작하는 패턴이 AWS 보안 인시던트 자동화의 표준입니다.
시험 핵심 정리
"EC2 retirement 이벤트 자동 감지 + 재시작" -- EventBridge(source: aws.health, AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED) + SSM Automation
"IAM 사용자 생성 즉시 감지 + 자동 비활성화" -- CloudTrail + EventBridge(source: aws.iam, CreateUser) + Lambda
"반복 처리 실패 메시지 격리 + 정상 흐름 보호" -- SQS Dead Letter Queue(maxReceiveCount)
"DynamoDB Streams 소비자 확장 + 스로틀링 없음" -- Kinesis Data Streams Enhanced Fan-Out
"프로세스 비정상 종료 탐지 + 인스턴스 교체 없이 복구" -- CloudWatch Agent procstat + CloudWatch Alarm + SSM Run Command
"종료 전 로그 수집 시간 확보" -- ASG Lifecycle Hook(Terminating:Wait) + Lambda + complete-lifecycle-action
"CodeCommit push 후 파이프라인 미시작" -- EventBridge 규칙 ENABLED/DISABLED 상태 확인
"CodeDeploy 모든 이벤트 Skipped" -- 프라이빗 서브넷 + VPC 엔드포인트 또는 NAT 없음 (Agent가 폴링 불가)