SOA-C03 03/16 — 이벤트 라우팅과 자동 복구
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 관측 조건을 실행 가능한 복구로 연결한다
02에서 alarm은 시간 조건을 평가하고 SNS는 결과를 전달했다. 이제 필요한 것은 어떤 변화가 어떤 대상의 어떤 절차를 시작해야 하는지를 정하는 일이다.
지표·상태 변화·API 활동
→ EventBridge event bus
→ event pattern을 만족하는 rule
→ 필요한 입력으로 변환
→ 실행 주체의 권한으로 target 호출
→ runbook의 단계 실행
→ 리소스 상태와 사용자 영향 재확인자동 복구는 모든 경보에 재시작을 붙이는 방식으로 설계하지 않는다. 같은 CPU 상승이라도 정상 수요 증가, 무한 반복, 데이터베이스 대기 때문에 대응이 달라진다. 감지는 조건을 알리고, 진단은 개입을 선택할 근거를 만든다.
2. Bus·rule·target을 서로 다른 경계로 본다
| 구성 | 역할 | 실패를 좁힐 때 보는 것 |
|---|---|---|
| Event bus | 이벤트를 받아 규칙 평가의 범위를 만든다 | 송신 account·Region·bus가 맞는가 |
| Event pattern | 관심 있는 이벤트의 필드와 값을 명시한다 | 실제 event의 source·detail-type·detail 구조와 일치하는가 |
| Rule | 일치한 이벤트를 지정한 target들에 전달한다 | 활성화 상태, target ARN, 규칙별 지표 |
| Input transformer | 이벤트 필드를 뽑아 target 입력 형태로 구성한다 | JSONPath와 문자열·객체 형태가 맞는가 |
| Target | 알림·코드·자동화 작업을 수행한다 | 호출 수신, 실행 기록, 업무 결과 |
하나의 rule에 여러 target을 붙여도 그 target 사이에 실행 순서가 생기지는 않는다. 앞 단계 결과가 뒤 단계 입력이어야 한다면 순서를 표현하는 runbook이 필요하다. EventBridge rules
CloudTrail로 전달된 API 활동을 처리할 때는 실제 event의 eventSource·eventName·requestParameters를 대조한다. 서비스가 직접 내보낸 상태 이벤트와 API 호출 기록은 payload와 의미가 다르다. 존재하지 않는 필드에 pattern을 만들면 이벤트가 있어도 규칙은 일치하지 않는다.
Input transformer는 이미 받은 필드를 선택·재구성한다. 리소스 owner나 최신 설정처럼 원래 event에 없는 정보는 별도 조회 단계에서 보강한다. 경로가 없는 변수를 쓰거나 객체를 문자열로 잘못 감싸면 원하는 입력을 만들지 못한다. 이벤트 샘플과 변환 결과를 함께 확인한다. 입력 변환
3. 호출 권한과 작업 권한을 따로 추적한다
EventBridge가 target을 부를 수 있어야 하고, target은 실제 리소스를 바꿀 수 있어야 한다.
- Lambda target은 함수의 resource-based policy에서 EventBridge 호출을 허용하는지 확인한다. 함수 실행 역할의 EC2 수정 권한만 추가해도 EventBridge 호출 허용을 대신하지 못한다.
- Automation을 시작하는 주체에는 필요한 시작 권한과, 실행 역할을 전달한다면 해당 역할의 PassRole 허용이 필요하다.
- Automation이 맡는 역할은 trust policy와 실제 단계별 API 권한을 모두 충족해야 한다.
- 계정 간 bus 전달에서는 송신 측 권한과 수신 bus 정책을 함께 본다. Region과 대상 ARN도 확인한다.
누가 누구를 호출하는가를 화살표마다 적으면 광범위한 AdministratorAccess를 붙이지 않고도 실패 위치를 찾기 쉽다. CloudTrail은 실패한 API와 호출 identity를 확인하는 근거이며, runbook 출력은 그 API를 시도한 실행 단계를 보여 준다. EventBridge 문제 해결
4. 재시도는 전달 신뢰성을 높이고, 멱등성은 중복 효과를 막는다
EventBridge는 재시도 가능한 target 전달 오류에 기본적으로 최대 24시간·185회 재시도한다. 재시도를 소진하면 이벤트를 잃을 수 있으므로 DLQ로 실패 이벤트를 보존할 수 있다. 이 정책의 대상은 target으로 전달하는 단계다. Lambda가 요청을 받은 뒤 코드가 실패하는 문제까지 하나의 성공 값으로 합치지 않는다. 재시도와 DLQ
운영 절차에는 다음 판단을 넣는다.
- 이벤트가 오래됐으면 현재 상태를 다시 읽는다.
- 리소스가 이미 원하는 상태라면 불필요한 변경 없이 종료한다.
- 같은 사건을 반복 처리해도 같은 최종 상태가 되게 만든다.
- 자기 조치가 다시 동일 이벤트를 만들어 무한히 실행되지 않도록 필터와 상태 조건을 둔다.
- DLQ를 복구할 때도 원래 조치가 일부 성공했는지 확인한 뒤 재처리한다.
예를 들어 볼륨 크기를 매번 일정량 늘리는 절차는 중복 처리 시 계속 증가한다. 원하는 최소 크기를 입력하고 현재 크기와 비교하는 절차가 재시도에 더 안정적이다. 이는 설명을 위한 운영 설계 예시이며 실제 자원에서 실행한 결과는 아니다.
5. Automation runbook은 실행의 근거와 결과를 남긴다
Systems Manager Automation은 AWS 제공 runbook과 사용자 작성 runbook으로 유지보수·배포·복구 절차를 구성한다. YAML/JSON의 입력 parameters와 mainSteps로 절차를 표현하고 각 단계의 결과를 확인한다. 동시 실행 수와 오류 임계값으로 일괄 조치의 영향을 제한할 수 있다. Automation 개요
| action | 절차에서 맡는 역할 |
|---|---|
| aws:executeAwsApi | AWS API를 호출하고 응답을 다음 판단에 사용 |
| aws:assertAwsResourceProperty | 리소스 속성이 기대 조건인지 확인 |
| aws:waitForAwsResourceProperty | 비동기 변경이 목표 상태에 도달할 때까지 대기 |
| aws:branch | 관찰한 값에 따라 경로 선택 |
| aws:executeScript | 기본 action으로 표현하기 어려운 로직 수행 |
| aws:approve | 절차에 정의된 승인 단계 |
| aws:runCommand | 관리 대상 노드에서 명령 실행 |
API 요청 수락, 리소스 상태 전환, 애플리케이션 정상 응답은 서로 다른 완료 조건이다. runbook에서 변경 API만 호출하고 끝내면 실행은 끝났어도 서비스 회복은 확인되지 않는다. timeout·onFailure·출력과 후속 검증 단계를 읽어야 한다. Automation actions
6. DevOps Agent와 Kiro의 위치
AWS DevOps Agent는 연결된 관측·코드·배포 자료를 연관 지어 조사와 완화안을 지원한다. Kiro는 코드 변경 구현과 개발 흐름에 연결할 수 있다. 여기서 익힐 관계는 증거 조사 → 완화안 → 구현·검증이다. Agent Space가 접근할 수 있는 자료·권한이 조사 범위를 정한다. DevOps Agent 개요
AWS의 Kiro 연계 예시는 조사 결과를 이벤트로 전달해 코드 변경과 PR 검토·배포로 잇는다. 이것은 구성해야 하는 통합 예시다. 제품을 연결했다는 이유로 모든 조치가 자동으로 승인되거나 안전해지는 것은 아니다. 생성된 원인 설명은 실제 로그·변경 내역에 대조하고, 적용 후에는 원래 장애 신호로 회복을 확인한다. 공식 연계 예시
7. 완성된 운영 적용 — 예상하지 않은 인스턴스 중지
- EC2 상태 변화 이벤트를 받아 대상 환경과 상태를 제한한다.
- tag·유지보수 일정·현재 상태를 조회해 의도된 중지인지 판단한다.
- CloudTrail에서 중지 API 주체와 변경 맥락을 확인한다.
- 정책상 자동 복구 대상이면 runbook을 시작하고 실행 ID를 남긴다.
- 시작 API 수락 후 running 상태와 상태 검사를 기다린다.
- 애플리케이션 health와 요청 성공률을 확인한다. 인스턴스 running만으로 종료하지 않는다.
- 반복 중지가 발생하면 무한 재시작 대신 추가 변경을 멈추고 원인 조사에 넘긴다.
규칙이 실행되지 않으면 bus·pattern을, 실행이 시작되지 않으면 호출 권한을, 실행 중 실패하면 단계 권한·입력을, 실행은 끝났는데 장애가 남으면 복구 가설과 완료 조건을 본다.
8. 연결 요약
- event pattern은 입력 선택, transformer는 입력 재구성, runbook은 순서와 조건을 담당한다.
- CloudTrail은 호출 주체·활동의 근거이며 원인 확정은 다른 증거와 연결한다.
- 재시도·DLQ·멱등성을 함께 설계한다.
- 자동화의 종료 조건에는 리소스 상태와 서비스 영향을 모두 포함한다.
- 시험 범위는 Task 1.2의 도구 선택·연결·문제 해결이다. 실제 운영에서는 중복·동시 변경·실패 후 재개까지 고려한다.
범위 확인: SOA-C03 Domain 1. 공식 평가 문제는 사용하지 않았다.
계획과 연결
-
ID:
03-event-routing-and-automated-remediation -
의존:
01-operational-signals-and-evidence,02-collection-alarms-dashboards-notifications -
결정 축: 탐지된 조건을 이벤트 패턴·라우팅·실행 권한·runbook·결과 검증으로 연결한다.
-
범위: CloudWatch, EventBridge rules·event buses, Lambda, Systems Manager Automation, CloudTrail, Kiro, AWS DevOps Agent.
-
시험 매핑: Domain 1, Skills 1.2.1–1.2.3.