SOA-C03 10/16 — 관리 자동화와 이벤트 기반 운영

정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.

1. 반복 실행이 가능한 운영 절차를 만든다

03은 탐지된 사건을 복구 절차에 연결했다. 10은 이미 존재하는 자원에 패치·설정 유지·정기 작업·데이터 처리 같은 반복 동작을 적용한다.

일정 또는 event
→ 대상과 현재 상태 확인
→ 작업을 시작할 권한 확인
→ 제한된 동시성으로 실행
→ 대상별 결과 보존
→ 실패·부분 성공을 대조하고 재개

한 번 수동 실행에 성공한 명령을 주기적으로 반복하는 것만으로 안정적인 자동화가 되지는 않는다. 중복·오래된 입력·대상 변경·부분 실패를 처리해야 한다.

2. Systems Manager 도구를 작업의 성격으로 고른다

도구	중심 역할	예시
Run Command	관리 대상 노드에 명령·문서 실행	설정 파일 확인·agent 갱신
State Manager	정의한 상태를 association으로 유지	필수 software·설정 상태 유지
Patch Manager	baseline 기준 패치 scan·install	승인 패치 적용·결과 확인
Maintenance Windows	영향 있는 작업을 지정 시간에 수행	업무 외 시간의 patch·정비
Automation	AWS API와 단계·조건을 묶은 절차	snapshot 후 변경·검증

Run Command는 관리 대상으로 구성된 EC2·비EC2 노드에서 작업을 수행한다. 명령 접수 뒤 결과가 즉시 모든 조회에 반영되지 않을 수 있으므로 invocation 상태·출력으로 완료를 확인한다. Run Command

State Manager association은 대상·document·입력·일정을 연결한다. 생성 시 즉시 실행되는 기본 동작과 다음 schedule부터 실행하도록 한 설정을 구분한다. 일회성 실행 성공과 주기적인 상태 유지 결과는 다르다. State Manager

3. 노드가 관리 경로에 연결돼 있어야 한다

SSM Agent 설치·실행, instance 또는 관리 노드의 IAM 권한, service endpoint로의 통신이 필요하다. SSH 포트를 열었다고 SSM 연결이 만들어지지 않는다.

관리 대상이 보이지 않거나 명령을 받지 못하면 순서대로 확인한다.

올바른 account·Region·node ID인가?
SSM Agent가 정상 실행되고 로그를 남기는가?
관리용 role·instance profile 또는 등록이 유효한가?
DNS와 필요한 HTTPS endpoint 접근이 가능한가?
PrivateLink endpoint를 사용한다면 endpoint·security group·정책이 맞는가?

SSM Agent 문제 해결

SSM Agent가 연결을 시작하므로 instance 쪽에는 해당 HTTPS 송신 경로가 필요하고, 응답을 위해 SSM 전용 인바운드 포트를 열 필요는 없다. 그러나 interface endpoint에 연결한 SG에는 노드에서 들어오는 TCP 443 허용이 필요하다. 인바운드 불필요라는 설명을 endpoint SG까지 확대하지 않는다. 필요한 endpoint는 Region·agent 버전·사용 기능에 따라 확인한다. SSM VPC endpoints

Automation의 AWS API 단계는 guest에 들어가지 않고 동작할 수 있다. 반대로 aws:runCommand로 노드 내부를 건드리는 단계는 노드 관리 경로가 필요하다. 모든 Automation 실패를 SSM Agent 문제로 분류하지 않는다.

4. 패치 선택·적용·재부팅·정상 기능을 나눈다

Patch baseline은 어떤 패치를 승인 대상으로 볼지 정한다. Scan은 상태 확인이고 install은 변경이다. Patch compliance는 그 baseline을 만족한다는 뜻이며 모든 취약점이 사라졌다는 보장은 아니다. 지원 OS·package 범위와 scan capture time을 확인한다. Patch Manager

Maintenance Window는 schedule·duration·target·task를 연결한다. 시간대와 작업 시작 경계, task별 timeout·중단 동작을 확인한다. Window가 끝났다는 사실만으로 이미 시작한 모든 작업이 안전하게 종료됐다고 가정하지 않는다. Maintenance Windows

운영 절차 예시는 대상 확인 → backup 필요성 확인 → 작은 묶음 적용 → reboot 상태 확인 → 서비스 health 확인 → 다음 묶음 진행이다. 패키지 설치 exit code가 0이어도 프로세스가 기동하지 않거나 LB health가 실패하면 후속 검증은 실패다.

5. S3 event는 객체 처리의 시작 신호다

S3 Event Notifications는 객체 생성·삭제 등의 사건을 SNS·SQS·Lambda·EventBridge 등과 연결한다. 직접 notification 대상의 지원 조건과 Region을 확인한다. 알림은 적어도 한 번 전달하도록 설계되며 순서가 보장되지 않으므로 중복과 순서 역전을 고려한다. S3 notifications

예를 들어 입력 prefix의 업로드를 Lambda로 처리하고 같은 입력 prefix에 결과를 쓰면 자기 자신을 다시 실행할 수 있다. 입력·출력 bucket 또는 prefix를 분리하고 event filter와 처리 조건을 맞춘다.

Event의 bucket·object key·version ID를 읽고 key의 encoding을 올바르게 처리한다. sequencer는 같은 object key의 이벤트 순서를 비교하는 데 쓸 수 있지만 서로 다른 key 사이의 전역 순서를 제공하지 않는다. S3 event 구조

6. Lambda 호출 성공과 업무 처리 성공

비동기 호출에서 Lambda가 event를 수신한 뒤 함수 실행이 실패하면 별도 재시도가 개입한다. Function error·throttling·system error의 처리 방식은 같지 않다. 함수 error에 대한 기본 추가 시도와 event age·retry 설정을 확인하며, 중복 수신 가능성을 고려한다. Lambda 비동기 오류 처리

Idempotent handler는 이미 처리한 object version·업무 ID를 대조하고 같은 입력이 반복돼도 중복 효과를 만들지 않게 한다. 외부 API를 호출한 뒤 완료 기록 쓰기에 실패하는 경우처럼 “효과는 생겼지만 완료 표시는 없는” 상태도 설계에 포함한다. Lambda best practices

실패 위치	확인할 근거
Event가 없음	원천 event·filter·destination 설정
함수가 시작하지 않음	invoke 허용·throttle·concurrency
함수 중간 실패	log·timeout·memory·실행 역할
함수 성공 뒤 결과 누락	실제 저장 대상·version·후속 처리
중복 결과	업무 ID·조건부 갱신·재시도 경계

동시성을 무한히 늘리면 downstream DB·외부 API를 압도할 수 있다. Handler 성능뿐 아니라 후속 자원의 처리 능력에 맞춰 동시 실행을 제한한다.

7. DevOps Agent와 기존 자동화를 연결하는 기준

DevOps Agent는 관측·코드·배포 정보를 이용해 조사와 완화안을 지원한다. 이미 정해진 반복 작업은 명시적 runbook으로 표현하고, 원인 탐색이 필요한 사건은 조사 결과와 증거를 남겨 검토한다. DevOps Agent

자동화가 수정하는 속성을 CloudFormation·State Manager·다른 복구 함수도 바꾸면 서로 반복해서 덮어쓸 수 있다. 자원별 원하는 상태의 관리 주체와 이벤트 처리의 재진입 조건을 정한다. 03의 권한·재시도·결과 검증 원칙을 그대로 재사용한다.

8. 완성된 운영 적용 — 파일 도착 후 변환 작업

input prefix의 object-created event를 받는다.
Bucket·key·version과 처리 가능 형식·크기를 확인한다.
같은 version 처리 여부를 확인하고 중복 효과를 막는다.
제한된 권한으로 원본을 읽어 output prefix에 결과를 쓴다.
저장 결과의 식별자와 처리 상태를 연결한다.
실패 event는 재시도 또는 별도 실패 경로로 보존한다.
재처리할 때 이전 출력이 있는지 확인하고 원본 version과 대조한다.
원천 event 수·실행 수·성공 결과 수·실패 보존 수를 비교한다.

여기서 실습 자원은 만들지 않았다. 시험에서는 운영 요구에 맞는 SSM·Lambda·S3·EventBridge의 연결을 고르고, 실제 운영에서는 중복 효과·부분 성공·동시성을 함께 검증한다. 범위: Domain 3 Task 3.2.

계획과 연결

ID: 10-management-and-event-driven-automation
의존: 03-event-routing-and-automated-remediation, 08-images-and-infrastructure-as-code
결정 축: 기존 리소스의 반복 작업과 상태 변화 기반 실행을 실행 주체·권한·멱등성·실패 처리에 맞게 자동화한다.
범위: Systems Manager, Lambda, S3 Event Notifications, EventBridge, AWS DevOps Agent.
시험 매핑: Domain 3, Tasks 3.2.1–3.2.2.
학습 안내
전체 계획

DanzzaN

탐색기