AWS DEA-C01 각색 문제 Day 16 — Redshift, MSK OpenSearch, Kinesis 핫샤드, DynamoDB SSE-KMS, S3 Glacier Vault Lock

AWS DEA-C01 문제로 공부하기 — Day 16

클릭스트림 → Redshift 최소 오버헤드, MSK OpenSearch 최소 지연 시각화, Kinesis 핫샤드 WriteThroughputExceeded 해결, DynamoDB SSE-KMS·클라이언트 암호화(복수), S3 Glacier Vault Lock 삭제 방지 — 5문제 핵심 정리.

AWS DEA-C01 Domain 1·2·4 · 스트리밍·보안·시각화 5문제

📋 목차

• Q76 클릭스트림 → 변환 → Redshift 적재 파이프라인 (최소 오버헤드)
• Q77 MSK 시계열 → 최소 지연 대시보드 시각화
• Q78 Kinesis 핫샤드 문제 — WriteThroughputExceeded 해결
• Q79 DynamoDB 저장 데이터 암호화 안전한 방법 (복수)
• Q80 10년 보관 + 직원 삭제 방지 + 48시간 내 검색

Q76Firehose · Lambda 변환 · Redshift · 스트리밍 파이프라인⭐ 자주 출제

Amazon Data Firehose는 Lambda를 통해 스트리밍 데이터를 변환하고 Redshift에 직접 적재하는 완전관리형 파이프라인을 제공합니다. 별도 MSK·Flink·추가 Lambda 없이 단일 Firehose 구성으로 최소 오버헤드로 구현 가능합니다.

📋 Question

전자상거래 앱의 대량 클릭스트림 이벤트를 수집·변환하고 분석을 위해 Amazon Redshift에 적재하는 파이프라인이 필요합니다. 운영 오버헤드를 최소화하는 솔루션은 무엇일까요?

• AAmazon MSK Serverless로 데이터를 수집하고, Glue 스트리밍 ETL로 변환해 S3에 저장합니다. 객체 생성 시 Lambda 함수로 Redshift에 적재합니다.
  ❌ MSK Serverless + Glue 스트리밍 + S3 + Lambda 4개 서비스를 연결. 각 서비스 구성·모니터링·유지보수가 필요해 오버헤드가 높음.
• BCloudWatch Logs로 데이터를 전송하고, 구독 필터로 Lambda에 전달합니다. Lambda로 변환 후 S3에 저장하고, 두 번째 Lambda로 Redshift에 적재합니다.
  ❌ CloudWatch Logs는 애플리케이션 로그 저장 서비스. 대량 클릭스트림 이벤트 수집에 부적합. Lambda 2개 + 여러 서비스 연결로 오버헤드가 큼.
• CKinesis Data Streams로 수집하고, Apache Flink 애플리케이션으로 변환해 S3에 저장합니다. 객체 생성 시 Lambda로 Redshift에 적재합니다.
  ❌ Kinesis Data Streams + Flink + S3 + Lambda 4개 서비스 연결. Flink 애플리케이션 개발·배포·관리가 추가 오버헤드.
• DAmazon Data Firehose로 스트리밍 데이터를 직접 수신합니다. 들어오는 데이터를 변환하는 Lambda 함수를 호출하도록 Firehose 데이터 변환을 구성합니다. 변환된 데이터를 Amazon Redshift로 직접 적재합니다.
  ✅ Amazon Data Firehose — 수집 + Lambda 변환 + Redshift 직접 적재까지 단일 서비스에서 구성. 중간 S3 단계 없이 Redshift로 바로 전달 가능. 가장 적은 서비스 수 = 최소 운영 오버헤드.

🎯

정답

D — Firehose(수집·변환·적재 통합) 단일 구성

🔑 핵심 개념 — 스트리밍 → Redshift 파이프라인 비교

방법	서비스 수	오버헤드
Firehose + Lambda 변환	1-2개	최소
KDS + Flink + Lambda	4개	높음
MSK + Glue + Lambda	4개	높음
CW Logs + Lambda×2	3개+	부적합

💡 이것만 기억하자

"스트리밍 수집 + 변환 + Redshift 적재 + 최소 오버헤드"
→ Firehose + Lambda 데이터 변환 + Redshift 직접 적재

Firehose = 수집·변환·적재 한 번에 처리 가능

---

Q77OpenSearch · 실시간 대시보드 · 최소 지연⭐ 자주 출제

Amazon OpenSearch Service + OpenSearch Dashboards는 데이터 인덱스에 직접 연결되어 실시간에 가까운 데이터 시각화를 제공합니다. Athena(S3 쿼리)나 Grafana보다 스트리밍 데이터의 지연이 낮습니다.

📋 Question

시계열 데이터 실시간 대시보드를 구축합니다. Amazon MSK로 데이터를 수집하고, 커스텀 파이프라인이 Amazon Keyspaces, Amazon OpenSearch Service, S3(Apache Avro 형식)에 동시에 씁니다. 가장 짧은 지연으로 시각화하는 솔루션은 무엇일까요?

• AOpenSearch Service에 저장된 데이터로 OpenSearch Dashboards를 생성합니다.
  ✅ OpenSearch Dashboards — OpenSearch Service에 이미 저장된 데이터를 실시간으로 직접 시각화. 파이프라인이 OpenSearch에 이미 쓰고 있으므로 추가 처리 없이 즉시 시각화 가능. S3 Avro나 Keyspaces를 경유하는 경로보다 지연이 낮음.
• BHive 메타스토어와 Athena로 S3 Avro 객체를 쿼리하고, Amazon Managed Grafana로 대시보드를 생성합니다.
  ❌ S3 Avro → Athena 쿼리 → Grafana 경로는 S3에 데이터가 쌓인 뒤에야 쿼리 가능. OpenSearch 직접 연결보다 지연이 높음. Hive 메타스토어 설정도 추가 오버헤드.
• CAthena로 S3 Avro를 쿼리하고 Keyspaces를 카탈로그로 사용합니다. QuickSight를 Athena에 연결해 대시보드를 생성합니다.
  ❌ Amazon Keyspaces는 데이터 카탈로그가 아닌 NoSQL DB. Avro → Athena → QuickSight는 S3 배치 처리 기반으로 실시간 지연이 높음.
• DGlue로 데이터를 카탈로그화하고, EMR 기반 Presto로 S3 Avro를 쿼리합니다. QuickSight를 S3에 연결해 대시보드를 생성합니다.
  ❌ Glue + EMR Presto + QuickSight S3 연결은 여러 서비스 연결 + S3 배치 쿼리 기반. 실시간 대시보드보다는 배치 분석에 적합. 지연이 가장 높음.

🎯

정답

A — OpenSearch Service + OpenSearch Dashboards 직접 연결

🔑 핵심 개념 — 실시간 스트리밍 시각화 지연 비교

방법	데이터 소스	지연
OpenSearch Dashboards	OpenSearch(실시간 인덱스)	최소
Athena + QuickSight	S3 (배치 쿼리)	중간~높음
Athena + Grafana	S3 (배치 쿼리)	중간~높음
EMR Presto + QuickSight	S3	높음

💡 이것만 기억하자

"스트리밍 데이터 최소 지연 시각화"
→ 데이터가 이미 들어가 있는 저장소에서 직접 시각화
→ OpenSearch + OpenSearch Dashboards

S3 경유 = 배치 처리 → 지연 큼

---

Q78Kinesis 핫샤드 · 파티션 키 · WriteThroughputExceeded⭐ 자주 출제

Kinesis 핫샤드(Hot Shard)는 파티션 키가 편중되어 특정 샤드에 트래픽이 집중될 때 발생합니다. 시설 ID처럼 분포가 고르지 않은 키 대신 무작위 키를 사용하면 샤드 간 부하가 균등하게 분산됩니다.

📋 Question

전세계 시설의 IoT 디바이스 데이터를 Amazon Kinesis Data Streams로 수집합니다. 데이터에는 디바이스 ID, 날짜, 측정 유형, 측정값, 시설 ID가 있으며 파티션 키로 시설 ID를 사용합니다. 최근 WriteThroughputExceeded 예외가 많이 발생하고 일부 샤드는 과부하, 나머지는 유휴 상태입니다. 어떻게 해결해야 할까요?

• A파티션 키를 시설 ID에서 무작위로 생성된 키로 변경합니다.
  ✅ 무작위 파티션 키 — 시설 ID는 규모가 큰 시설에 편중(일부 시설에 IoT 디바이스가 훨씬 많음). 무작위 키를 사용하면 레코드가 모든 샤드에 균등하게 분산되어 핫샤드 제거. WriteThroughputExceeded 해결.
• B샤드 수를 늘립니다.
  ❌ 샤드 수를 늘려도 파티션 키(시설 ID)가 그대로면 같은 시설 ID의 모든 트래픽이 특정 샤드에 몰림. 핫샤드 문제 근본 해결 불가. 비용만 증가.
• C생산자 측에 데이터를 아카이브합니다.
  ❌ 아카이브는 스트리밍 처리 중 WriteThroughputExceeded와 무관. 데이터를 생산자에 쌓아두는 방식으로는 Kinesis 스로틀링 해결 불가.
• D파티션 키를 시설 ID에서 캡처 날짜로 변경합니다.
  ❌ 캡처 날짜를 파티션 키로 쓰면 같은 시간대에 모든 디바이스가 동일 날짜 키를 가짐 → 다시 핫샤드 발생. 균등 분산 효과 없음.

🎯

정답

A — 파티션 키를 무작위 키로 변경해 균등 분산

🔑 핵심 개념 — Kinesis 핫샤드 원인과 해결

파티션 키	샤드 분산	핫샤드?
시설 ID (편중 분포)	불균등	✓ 발생
캡처 날짜 (동일 시간대 동일값)	불균등	✓ 발생
무작위 키	균등	✗ 해결

💡 이것만 기억하자

"Kinesis 핫샤드 (일부 과부하, 나머지 유휴)"
→ 파티션 키 편중이 원인
→ 해결: 무작위 파티션 키로 변경

샤드 수 증가만으로는 해결 불가 (키 편중 유지)

---

Q79DynamoDB · SSE-KMS · 클라이언트 암호화✌️ 복수 정답

DynamoDB 저장 데이터 암호화는 서버 측(SSE-KMS)과 클라이언트 측(클라이언트 암호화 후 업로드) 두 가지 방식이 있습니다. 암호화 키를 Git에 저장하거나 Lambda로 자동 복호화하는 방식은 보안 위험이 있습니다.

📋 Question — 두 가지를 선택하세요

의료 회사의 데이터 엔지니어가 환자 기록을 Amazon DynamoDB에 저장합니다. 규정 준수를 위해 저장 중인 데이터를 암호화해야 합니다. 안전하게 암호화하는 방법 두 가지는 무엇일까요?

• ADynamoDB 테이블에서 AWS KMS 키를 통한 서버 측 암호화(SSE-KMS)를 활성화합니다.
  ✅ DynamoDB SSE-KMS — KMS 고객 관리 키를 사용한 DynamoDB 기본 서버 측 암호화. 저장된 데이터를 자동으로 암호화·복호화. 키 관리·감사·교체가 KMS에서 통합 관리. 규정 준수 암호화의 표준 방법.
• BDynamoDB에 항목을 업로드하기 전에 클라이언트 측 암호화를 적용합니다.
  ✅ 클라이언트 측 암호화 — 애플리케이션에서 데이터를 암호화한 후 DynamoDB에 저장. 데이터가 AWS 인프라에 도달하기 전부터 암호화됨. DynamoDB Encryption Client 라이브러리 활용. 엔드투엔드 암호화로 규정 준수 충족.
• C암호화 키를 프라이빗 Git 리포지토리에 저장하여 팀원에게 접근 권한을 제공합니다.
  ❌ Git 리포지토리는 암호화 키 저장소로 안전하지 않음. 소스 코드 유출·내부자 위협 시 키가 노출될 수 있음. AWS KMS나 Secrets Manager가 키 관리 표준.
• DAWS Lambda를 사용하여 DynamoDB에서 데이터에 접근할 때마다 자동으로 복호화합니다.
  ❌ Lambda 복호화 함수를 추가 계층으로 구성하는 방식. A(SSE-KMS)를 쓰면 DynamoDB가 투명하게 복호화해줘 불필요한 복잡도. 복호화 키 관리도 별도로 필요.
• ELambda를 사용하여 DynamoDB와 함께 쓰는 AWS KMS 키를 주 단위로 교체합니다.
  ❌ KMS 키 교체(Rotation)는 KMS 자체 기능으로 설정 가능. Lambda로 직접 구현할 필요가 없음. 또한 키 교체는 저장 데이터 암호화 요건(데이터 보호)과 다른 주제.

🎯

정답

A + B — SSE-KMS 서버 측 + 클라이언트 측 암호화

🔑 핵심 개념 — DynamoDB 암호화 방법 비교

방법	암호화 시점	키 관리	안전성
SSE-KMS	저장 시 (서버)	KMS 통합	✓ 안전
클라이언트 측 암호화	전송 전 (클라이언트)	앱 레벨	✓ 안전
Git 리포지토리에 키 저장	-	Git	✗ 위험

💡 이것만 기억하자

DynamoDB 저장 데이터 암호화:
SSE-KMS (서버 측, KMS 관리)
클라이언트 암호화 (전송 전 암호화)

Git에 키 저장 = 보안 금지 (항상 오답)

---

Q80S3 Glacier · Vault Lock · 삭제 방지 · 48시간 검색⭐ 자주 출제

S3 Glacier Vault Lock은 저장소 수준에서 데이터 삭제를 영구적으로 방지하는 WORM 정책입니다. S3 Glacier Flexible Retrieval은 신속 검색(수 분) ~ 표준 검색(수 시간)을 지원해 48시간 내 검색 요건을 충족합니다.

📋 Question

금융 서비스 회사가 ML 모델 입력 데이터를 10년 동안 보관해야 합니다. 직원이 데이터를 삭제할 수 없어야 하고, 48시간 이내에 데이터를 검색할 수 있어야 합니다. 이 요건을 충족하는 솔루션은 무엇일까요?

• AS3 Glacier Deep Archive에 데이터를 저장합니다.
  ❌ S3 Glacier Deep Archive — 검색 시간이 12~48시간으로 48시간 내 검색은 가능하지만 삭제 방지 정책(Vault Lock)이 없음. 직원 삭제 방지 요건 미충족.
• BAmazon S3 Glacier Flexible Retrieval에 데이터를 저장하고, S3 Glacier 저장소 잠금(Vault Lock) 정책을 적용합니다.
  ✅ S3 Glacier Flexible Retrieval — 신속 검색 1~5분, 표준 검색 3~5시간으로 48시간 내 검색 충족. Vault Lock 정책 — 저장소 수준의 불변 WORM 정책. 루트 사용자 포함 누구도 잠금 기간 내 삭제 불가. 두 요건 모두 충족.
• CAmazon S3 Glacier Flexible Retrieval에 데이터를 저장합니다.
  ❌ Glacier Flexible Retrieval만으로는 검색 요건은 충족하지만 삭제 방지 정책(Vault Lock)이 없음. 직원이 여전히 데이터를 삭제할 수 있어 삭제 방지 요건 미충족.
• DAmazon S3 Glacier Flexible Retrieval에 데이터를 저장하고, S3 Glacier 저장소 액세스 정책을 적용합니다.
  ❌ 저장소 액세스 정책(Vault Access Policy)은 리소스 기반 접근 제어 정책. 권한이 있는 관리자가 정책을 수정하여 삭제를 허용할 수 있음. Vault Lock처럼 불변성을 보장하지 않음.

🎯

정답

B — Glacier Flexible Retrieval + Vault Lock 정책

🔑 핵심 개념 — Glacier 삭제 방지 정책 비교

정책 유형	불변성	삭제 방지?
Vault Lock 정책	잠금 후 수정 불가	✓ 영구
Vault Access Policy	수정 가능	✗ 우회 가능
없음	-	✗

💡 이것만 기억하자

"장기 보관 + 삭제 불가 + 48시간 내 검색"
→ S3 Glacier Flexible Retrieval + Vault Lock 정책

Vault Lock = 잠금 후 수정 불가 (루트도 삭제 못함)
Vault Access Policy ≠ Vault Lock (우회 가능)

AWS DEA-C01Firehose RedshiftOpenSearch DashboardsKinesis 핫샤드DynamoDB SSE-KMSGlacier Vault LockAWS 자격증