[AWS DEA] 문제로 공부하기 13 - Macie + EventBridge

AWS DEA-C01 Amazon Macie Amazon EventBridge PII 감지 데이터 마스킹 최소 운영 오버헤드

S3 PII 자동 감지 → 즉시 마스킹 호출 — Amazon Macie + EventBridge가 정답인 이유

AWS DEA-C01 시험에 자주 나오는 데이터 보안 자동화 문제입니다. S3에 저장된 신규·기존 데이터의 PII(개인 식별 정보)를 자동 감지하고 마스킹 애플리케이션을 즉시 호출하는 솔루션으로 Amazon Macie + EventBridge 이벤트 규칙이 정답인 이유를 Lambda 수동 구현, S3 알림 방식과 비교하여 도식으로 정리합니다.

📋 문제

회사가 Amazon S3 데이터 레이크를 사용하며, 수집·저장되는 일부 데이터에는 PII(개인 식별 정보)가 포함된다.

데이터 엔지니어는 신규 및 기존 데이터의 PII를 자동으로 식별하고 식별된 데이터의 개요를 제공해야 한다. 데이터를 마스킹하는 작업은 이미 생성된 애플리케이션에서 처리하며, 데이터 엔지니어는 PII가 발견되는 즉시 이 애플리케이션을 호출해야 한다.

다음 중 최소한의 운영 오버헤드로 요구 사항을 충족하는 솔루션은 무엇인가?

✅ 핵심 요구사항 분석

• 🔍
  PII 자동 식별 — 신규 + 기존 데이터 모두
  단순히 새 파일 업로드 감지가 아니라, 이미 저장된 기존 데이터도 스캔해야 함
• 📊
  식별된 데이터 개요(Overview) 제공
  어떤 파일에 어떤 PII가 있는지 리포트·대시보드 형태로 요약 제공
• ⚡
  PII 발견 즉시 마스킹 애플리케이션 호출
  폴링(주기적 확인)이 아닌 이벤트 기반(Event-Driven) 즉시 트리거
• ⚙️
  최소 운영 오버헤드
  PII 감지 로직을 직접 구현하지 않고 AWS 완전관리형 서비스 활용

🔐 Amazon Macie — PII 자동 감지 완전관리형 서비스

💡 Amazon Macie는 S3 데이터에서 PII(이름·이메일·신용카드·주민번호 등)를 머신러닝으로 자동 감지하는 AWS 완전관리형 데이터 보안 서비스입니다.

🔍 PII 자동 감지

100+ PII 유형 기본 지원
이름, 이메일, 전화, 신용카드, 여권번호, 주민번호 등
커스텀 식별자 추가 가능

📊 결과 개요 제공

Macie 결과(Findings)로 어떤 S3 버킷·파일에 PII가 있는지 상세 보고서 제공
AWS Console + API 조회 가능

🗂️ 신규 + 기존 데이터 모두 스캔

예약 작업(Scheduled Job)으로 기존 S3 데이터 스캔
새 업로드 감지 + 증분 스캔 지원

📡 EventBridge 자동 통합

Macie 결과 생성 시 EventBridge 기본 이벤트 버스에 자동 이벤트 발행
별도 구성 없이 즉시 연동

🏗️ 정답 아키텍처 — Macie + EventBridge 자동화 흐름

S3 데이터 레이크
(신규 + 기존)

→

Amazon Macie
PII 자동 스캔

→

Macie 결과
(Finding) 생성

↓

자동으로 EventBridge 이벤트 버스에 발행

EventBridge
기본 이벤트 버스

→

Macie Finding
규칙 매칭

→

마스킹 애플리케이션
즉시 호출 ✅

✅ 핵심: Macie는 활성화만 하면 자동으로 EventBridge에 결과를 발행합니다. 별도 Lambda·폴링 로직 없이 EventBridge 규칙 하나로 마스킹 앱을 즉시 트리거할 수 있어 운영 오버헤드가 최소입니다.

🔍 솔루션 비교 — 정답 vs 오답 이유

🏆

D. Macie + EventBridge ⭐

PII 감지 ✅ Macie 전용

기존 데이터 ✅ 스캔 지원

결과 개요 ✅ Finding 제공

즉시 호출 ✅ 이벤트 기반

오버헤드 ✅ 최소

✅ 모든 요건 충족 — 정답

⚠️

C. Macie + Lambda 폴링

PII 감지 ✅ Macie 사용

기존 데이터 ✅ 스캔 지원

즉시 호출 ❌ 폴링 지연

Lambda 유지 ❌ 추가 운영

오버헤드 ❌ 높음

❌ 폴링 방식 — 즉시 호출 요건 미충족

⚠️

A. Lambda 직접 PII 분석

PII 감지 ❌ 직접 구현

기존 데이터 ❌ S3 알림만

결과 개요 ❌ 별도 구현

ML 모델 ❌ 없음

오버헤드 ❌ 매우 높음

❌ PII 감지 로직 직접 구현 필요

⚠️

B. S3 알림 + EventBridge

PII 감지 ❌ 없음

기존 데이터 ❌ 신규만

결과 개요 ❌ 없음

업로드 감지 ✅ S3 알림

PII 여부 판단 ❌ 불가

❌ PII 감지 기능 자체가 없음

⚠️ 핵심 함정 — C vs D: C는 Macie를 사용하지만 Lambda가 주기적으로 Macie 결과를 폴링합니다. 문제 조건 "PII 발견 즉시 호출"을 충족하지 못하며 Lambda 스케줄 관리 오버헤드가 추가됩니다. D는 Macie 결과가 EventBridge에 자동 발행되어 즉시 트리거되므로 완전 이벤트 기반입니다.

📝 선택지 해설

각 항목을 클릭하면 해설이 펼쳐집니다.

A

❌ Lambda 함수로 PII 직접 분석 + S3 신규 업로드 알림으로 Lambda 호출

PII 감지 로직 직접 구현 + 기존 데이터 스캔 불가 + 결과 개요 없음

💡 세 가지 문제가 있습니다. 첫째, Lambda로 PII를 직접 분석하려면 머신러닝 모델·정규표현식 등 복잡한 로직을 직접 구현해야 합니다. 이는 운영 오버헤드가 매우 크고 Amazon Macie처럼 100+ PII 유형을 정확하게 감지하기 어렵습니다. 둘째, S3 버킷 알림은 신규 업로드 이벤트에만 동작하므로 기존에 저장된 데이터는 스캔할 수 없습니다. 셋째, 식별된 데이터의 개요(결과 리포트)를 제공하는 기능도 별도로 구현해야 합니다.

B

❌ S3 알림 + EventBridge 규칙 → 마스킹 애플리케이션 호출

PII 감지 기능 자체가 없음 — 업로드 이벤트만 감지, PII 여부 판단 불가

💡 S3 알림과 EventBridge 규칙을 조합하면 새 객체 업로드 시 마스킹 애플리케이션을 호출하는 것은 가능합니다. 그러나 이 구성에는 PII를 감지하는 기능이 전혀 없습니다. 모든 업로드 파일을 무조건 마스킹 애플리케이션에 전달하게 되어 PII가 없는 파일도 처리하게 됩니다. 또한 기존 데이터 스캔과 식별 결과 개요 제공도 불가능합니다. "PII 발견 즉시"가 아니라 "파일 업로드 즉시" 트리거되는 구조입니다.

C

❌ Macie 활성화 + Lambda 예약 실행으로 Macie 결과 폴링 → 마스킹 애플리케이션 호출

Macie 사용은 올바르나 폴링 방식 — "즉시 호출" 요건 미충족 + Lambda 스케줄 관리 오버헤드

💡 Macie를 사용하여 PII를 감지하는 방향은 올바릅니다. 그러나 Lambda가 예약(Schedule)에 따라 주기적으로 Macie 결과를 폴링하는 구조는 문제 조건인 "PII가 발견되는 즉시 호출"을 충족하지 못합니다. 폴링 주기(예: 5분, 1시간)만큼의 지연이 발생합니다. 또한 Lambda 함수 생성·스케줄 관리·오류 처리 등 불필요한 운영 오버헤드가 추가됩니다. Macie는 결과 생성 즉시 EventBridge에 자동으로 이벤트를 발행하므로, Lambda 폴링 없이 EventBridge 규칙만으로 더 간단하게 처리할 수 있습니다.

D

✅ Macie 활성화 + Macie 결과 기반 EventBridge 규칙 → 마스킹 애플리케이션을 대상으로 설정

PII 자동 감지(Macie) + 즉시 이벤트 트리거(EventBridge) + 결과 개요(Finding) + 최소 오버헤드

💡 정답. 4가지 요건을 모두 최소 오버헤드로 충족합니다. ① PII 자동 식별 (신규 + 기존): Amazon Macie는 S3 버킷의 신규 업로드와 기존 객체 모두를 스캔하여 100+ PII 유형을 머신러닝으로 자동 감지합니다. ② 결과 개요 제공: Macie Finding(결과)이 어떤 파일에 어떤 PII가 있는지 상세 보고서를 제공합니다. ③ 즉시 호출: Macie는 결과 생성 즉시 EventBridge 기본 이벤트 버스에 자동으로 이벤트를 발행합니다. EventBridge 규칙이 이 이벤트를 감지하고 마스킹 애플리케이션을 즉시 호출합니다. ④ 최소 운영 오버헤드: Lambda·스케줄·폴링 로직이 필요 없습니다.

정답 및 핵심 정리 (클릭)

정답: D — Amazon Macie + EventBridge 이벤트 규칙

이 문제의 핵심 구분 포인트는 두 가지입니다. ① PII 감지 전용 서비스(Macie) vs 직접 구현: Lambda로 PII를 직접 분석하는 것은 복잡하고 오버헤드가 크며, S3 알림에는 PII 감지 기능이 없습니다. ② 폴링(C) vs 이벤트 기반(D): "즉시 호출" 조건은 EventBridge 이벤트 규칙으로만 충족됩니다.

# 정답 D — Macie + EventBridge 자동화 파이프라인 S3 데이터 레이크 (신규 + 기존 객체) ↓ (스캔) Amazon Macie ├─ PII 자동 감지 (100+ 유형, ML 기반) ├─ 신규·기존 데이터 모두 스캔 지원 └─ Macie Finding(결과) 생성 → 개요 제공 ↓ (자동 이벤트 발행) EventBridge 기본 이벤트 버스 ↓ (Macie Finding 타입 규칙 매칭) 마스킹 애플리케이션 즉시 호출 ✅ # 오답 C vs 정답 D 핵심 차이 C: Macie + Lambda(폴링) → IteratorAge 지연, Lambda 관리 필요 D: Macie + EventBridge(Push) → 즉시 트리거, 서버리스 완전 자동화 # Macie가 충족하는 요건 ✅ PII 자동 감지 (직접 구현 불필요) ✅ 신규 + 기존 데이터 스캔 ✅ Finding으로 결과 개요 제공 ✅ EventBridge 자동 통합 (폴링 불필요)

📊 선택지 비교 요약

선택지	PII 감지	기존 데이터	결과 개요	즉시 호출	오버헤드	결론
A	직접 구현	❌ 신규만	❌ 없음	이벤트 기반	매우 높음	탈락
B	❌ 없음	❌ 신규만	❌ 없음	업로드만	낮음	탈락
C	✅ Macie	✅ 지원	✅ Finding	❌ 폴링 지연	중간	탈락
D ⭐	✅ Macie	✅ 지원	✅ Finding	✅ 즉시	최소	정답

#AWS_DEA-C01 #AmazonMacie #AmazonEventBridge #PII감지 #개인식별정보 #데이터마스킹 #S3데이터레이크 #MacieFinding #이벤트기반아키텍처 #최소운영오버헤드 #데이터보안자동화 #AWS자격증 #AWS데이터엔지니어