AWS DEA-C01 각색 문제 Day 07 — Athena 파티셔닝, S3 DSSE-KMS, EventBridge + Glue Workflow, Redshift, EMR

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

Athena 파티셔닝 성능, S3 이중 계층 암호화(DSSE-KMS), EventBridge + Glue Workflow 자동 트리거, Redshift 쿼리 편집기 예약, EMR 비용 최적화 모범 사례 — 5문제 핵심 정리.

AWS DEA-C01 Domain 1·2·4 · 쿼리 성능 · 보안 · 오케스트레이션 5문제

📋 목차

• Q31 Athena 쿼리 성능 저하 — 파티션 메타데이터 자동 등록
• Q32 S3 버킷 두 계층 서버 측 암호화 구현
• Q33 파일 전송 완료 시 Glue 워크플로 자동 시작
• Q34 Redshift 저장 프로시저 일별 자동 실행 — 가장 비용 효율적
• Q35 EMR 고성능 + 영구 스토리지 + 비용 최적화 구성

Q31Athena · Glue 크롤러 · 파티셔닝⭐ 자주 출제

Glue 크롤러(Crawler)는 S3 데이터의 스키마를 자동 탐지하고 파티션 메타데이터를 Glue 데이터 카탈로그에 등록합니다. Athena는 이 카탈로그를 기반으로 파티션 프루닝을 수행해 쿼리 속도를 크게 개선합니다.

📋 Question

웹 서버 액세스 로그를 S3에 저장하고 Amazon Athena로 트래픽 패턴을 분석하고 있습니다. 파티셔닝되지 않은 테이블로 시작했는데, 데이터가 쌓일수록 쿼리 응답 시간이 점점 길어집니다. 운영 노력을 최소화하면서 Athena 쿼리 성능을 개선하는 방법은 무엇일까요?

• A모든 로그의 스키마를 분석하고 파티션 메타데이터를 Glue 데이터 카탈로그에 기록하는 AWS Glue ETL 작업을 생성합니다.
  ❌ ETL 작업으로 파티션 메타데이터를 관리하는 것은 가능하지만, 직접 코딩이 필요하고 크롤러보다 설정이 복잡함. 최소 운영 노력 요건에 미달.
• B로그 스키마를 자동 감지하고 파티션 메타데이터를 Glue 데이터 카탈로그에 등록하는 분류자 포함 AWS Glue 크롤러를 생성합니다.
  ✅ AWS Glue 크롤러(Crawler) — S3를 자동 탐색해 스키마 추론 + 파티션 감지 + 카탈로그 등록을 한 번에 처리. 코딩 없이 설정만으로 구성 가능. Athena는 등록된 파티션 정보를 이용해 관련 파티션만 스캔 → 쿼리 속도 향상.
• CLambda 함수를 생성하여 모든 로그를 Parquet 형식으로 변환하고 파티션 메타데이터를 포함해 S3에 저장합니다.
  ❌ Lambda로 형식 변환 + 파티션 관리 로직을 직접 작성해야 해 운영 부담이 높음. Parquet 변환 효과는 있지만 최소 운영 노력 기준 미달.
• DApache Hive를 사용하여 버킷화된 테이블을 생성하고 Lambda로 로그를 변환합니다.
  ❌ Hive 버킷팅은 Athena에서 제한적으로만 지원되며 설정이 복잡. Lambda 변환 로직도 추가 개발 필요. 불필요하게 복잡한 솔루션.

🎯

정답

B — Glue 크롤러로 파티션 메타데이터 자동 등록

🔑 핵심 개념 — Athena 쿼리 성능 개선 방법

방법	효과	운영 부담
Glue 크롤러 + 파티셔닝	파티션 프루닝으로 스캔량 대폭 감소	최소
Parquet 형식 변환	컬럼 단위 스캔, 압축 효과	중간 (변환 필요)
파티셔닝 없는 Parquet	형식 효율은 있지만 전체 스캔	중간
현 상태 유지 (텍스트 무파티션)	개선 없음	낮음

💡 이것만 기억하자

"Athena 쿼리 느림 + 운영 최소화" → Glue 크롤러 + 파티션 메타데이터 등록

크롤러 = 스키마 자동 탐지 + 파티션 자동 등록 (코딩 불필요)
파티셔닝 = Athena가 관련 파티션만 스캔 → 속도↑ 비용↓

---

Q32S3 암호화 · DSSE-KMS · 이중 계층⭐ 자주 출제

DSSE-KMS(Dual-layer Server-Side Encryption with KMS)는 S3에서 두 계층의 서버 측 암호화를 단일 설정으로 적용하는 기능입니다. 규정 요건으로 이중 암호화가 필요할 때 가장 간단한 구현 방법입니다.

📋 Question

규제 요건에 따라 S3 버킷에 업로드되는 모든 파일에 두 계층의 서버 측 암호화를 적용해야 합니다. Lambda 함수를 통해 암호화를 적용하려 합니다. 이 요건을 충족하는 방법은 무엇일까요?

• ASSE-KMS(AWS KMS 키를 통한 서버 측 암호화)와 S3 암호화 클라이언트를 모두 사용합니다.
  ❌ SSE-KMS는 서버 측 1계층 암호화. S3 암호화 클라이언트는 클라이언트 측 암호화. 두 개를 조합하면 기술적으로 2계층이지만 관리가 복잡하고, 공식적인 "두 계층 서버 측 암호화"가 아님.
• BDSSE-KMS(AWS KMS 키를 통한 이중 계층 서버 측 암호화)를 사용합니다.
  ✅ DSSE-KMS(Dual-layer Server-Side Encryption with KMS) — S3가 공식 지원하는 두 계층 서버 측 암호화. 첫 번째 계층은 S3 관리 키, 두 번째 계층은 KMS 고객 관리 키를 사용. Lambda 업로드 시 헤더 설정만으로 적용 가능. 가장 간단하고 명확한 이중 암호화 방법.
• C파일이 업로드되기 전에 고객 제공 키(SSE-C)를 사용합니다.
  ❌ SSE-C(Customer-Provided Keys) — 고객이 직접 암호화 키를 관리하는 1계층 서버 측 암호화. 두 계층 암호화가 아님. 키 관리 부담도 추가.
• DSSE-KMS(AWS KMS 키를 통한 서버 측 암호화)만 사용합니다.
  ❌ SSE-KMS는 1계층 암호화. 두 계층 요건 미충족.

🎯

정답

B — DSSE-KMS로 두 계층 서버 측 암호화

🔑 핵심 개념 — S3 암호화 옵션 비교

옵션	계층 수	키 관리	이중 암호화?
SSE-S3	1	S3 관리	✗
SSE-KMS	1	KMS 관리	✗
DSSE-KMS	2	KMS 관리	✓
SSE-C	1	고객 제공	✗

💡 이것만 기억하자

"S3 두 계층 서버 측 암호화" → DSSE-KMS

D = Dual (이중) + SSE-KMS
SSE-KMS 혼자 쓰면 1계층 → 이중 요건 미충족

---

Q33EventBridge · Glue Workflow · 이벤트 트리거⭐ 자주 출제

Amazon EventBridge는 AWS 서비스 이벤트를 감지해 자동으로 대응하는 이벤트 버스입니다. Storage Gateway 파일 전송 완료 이벤트를 감지해 Glue Workflow를 자동 시작할 수 있어 추가 인프라 없이 이벤트 기반 자동화를 구현합니다.

📋 Question

BI 플랫폼에서 AWS Storage Gateway S3 File Gateway를 통해 온프레미스 파일을 S3 버킷으로 전송하고 있습니다. 각 파일 전송이 성공적으로 완료될 때마다 자동으로 일련의 Glue 작업(Glue Workflow)을 시작하는 프로세스가 필요합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?

• A과거 전송 이력을 분석하여 파일 전송이 주로 완료되는 시간대를 파악하고, 해당 시간에 Glue 작업을 시작하도록 EventBridge 예약 이벤트를 설정합니다.
  ❌ 예약 기반 트리거는 전송 완료와 무관하게 실행됨. 전송이 늦어지거나 빨라지면 타이밍이 맞지 않아 데이터 처리 누락 또는 오류 발생 가능. 이벤트 기반이 아님.
• BStorage Gateway 파일 전송 완료 이벤트를 감지하여 Glue 워크플로를 시작하는 Amazon EventBridge 이벤트 규칙을 설정합니다.
  ✅ Amazon EventBridge — 자동 반응 알람 시스템. Storage Gateway는 파일 전송 완료 이벤트를 EventBridge로 전송하며, EventBridge 규칙이 이를 감지해 Glue Workflow를 자동 시작. 코딩 없이 콘솔에서 규칙 설정만으로 구현 가능. 추가 인프라 불필요.
• C온디맨드 Glue 워크플로를 설정하여 엔지니어가 파일 전송 완료를 확인한 후 수동으로 시작합니다.
  ❌ 수동 시작은 운영 오버헤드가 가장 큼. 사람이 개입해야 하므로 24/7 자동화 불가.
• DS3 객체 생성 이벤트를 트리거로 사용하는 Lambda 함수를 만들어 Glue 워크플로를 호출합니다.
  ❌ 기술적으로 작동하지만 Lambda 함수 코드 작성·배포·유지보수가 추가됨. EventBridge 규칙 직접 연결(B)보다 운영 오버헤드가 더 높음. 불필요한 중간 레이어.

🎯

정답

B — EventBridge로 Storage Gateway 완료 이벤트 → Glue Workflow 자동 시작

🔑 핵심 개념 — 이벤트 기반 트리거 방법 비교

방법	실제 완료 시점 감지	코딩 필요	운영 부담
EventBridge 이벤트 규칙	✓ 정확	없음	최소
EventBridge 예약	✗ 시간 기반	없음	낮음
Lambda + S3 이벤트	✓ (파일 단위)	필요	중간
수동 시작	수동 확인	없음	최대

💡 이것만 기억하자

"AWS 서비스 이벤트 완료 시 자동 트리거" → EventBridge 이벤트 규칙

예약(Cron) ≠ 이벤트 기반 → 타이밍 불일치 위험
Lambda 중간 레이어 = 불필요한 오버헤드

---

Q34Redshift 쿼리 편집기 v2 · 저장 프로시저 예약⭐ 자주 출제

Redshift 쿼리 편집기 v2(Query Editor v2)는 Redshift에 내장된 SQL 편집 도구로, 추가 비용 없이 SQL 명령문 예약 실행 기능을 제공합니다. 별도 서비스(Lambda, EventBridge, Glue) 없이 Redshift 자체 기능으로 저장 프로시저를 자동 실행할 수 있습니다.

📋 Question

Amazon Redshift에서 일별 집계 처리를 수행하는 저장 프로시저(Stored Procedure)가 있습니다. 이 프로시저를 매일 자동으로 실행하고 싶습니다. 가장 비용 효율적인 방법은 무엇일까요?

• ALambda 함수를 생성하여 저장 프로시저를 실행하도록 cron 작업을 예약합니다.
  ❌ Lambda 함수에서는 cron 예약이 불가. EventBridge를 추가해야 예약이 가능하며, Lambda 호출마다 비용이 발생. 추가 서비스 구성과 비용이 필요.
• BEC2 스팟 인스턴스에서 Redshift Data API를 사용하여 저장 프로시저를 예약하고 실행합니다.
  ❌ EC2 인스턴스는 스팟이어도 인스턴스 시간당 비용이 발생. 단순 SQL 예약 실행에 EC2를 띄우는 것은 비용 과다. Redshift 내장 기능으로 충분.
• CRedshift 쿼리 편집기 v2를 사용하여 저장 프로시저 실행을 원하는 일정으로 예약합니다.
  ✅ Redshift 쿼리 편집기 v2 — Redshift에 내장된 SQL 편집 도구. 추가 비용 없이 SQL 명령문 예약 실행 기능 제공. EventBridge가 백엔드에서 예약을 관리하고 Redshift Data API로 호출. 외부 서비스 설정 없이 Redshift 콘솔만으로 구성 가능. 가장 비용 효율적.
• DAWS Glue Python Shell 작업으로 저장 프로시저 실행을 예약합니다.
  ❌ AWS Glue 작업은 실행마다 DPU(Data Processing Unit) 비용이 발생. 단순 SQL 호출에 Glue를 사용하는 것은 불필요한 비용 낭비.

🎯

정답

C — Redshift 쿼리 편집기 v2로 추가 비용 없이 예약 실행

🔑 핵심 개념 — Redshift SQL 예약 실행 방법 비교

방법	추가 비용	설정 복잡도	적합성
쿼리 편집기 v2 예약	없음	최소	✓ 최적
Lambda + EventBridge	Lambda 호출 비용	중간	과도한 구성
EC2 + Data API	인스턴스 비용	높음	비용 과다
Glue Python Shell	DPU 비용	중간	비용 과다

💡 이것만 기억하자

"Redshift SQL/프로시저 정기 실행 + 비용 최소"
→ Redshift 쿼리 편집기 v2 예약 (추가 비용 없음)

Lambda/Glue/EC2 = 모두 추가 비용 발생
Redshift 내장 기능 = 이미 포함된 기능, 무료

---

Q35EMR · Graviton · 영구 스토리지 · 비용 최적화⭐ 자주 출제

EMR 비용 최적화 모범 사례는 Graviton 기반 EC2 인스턴스 + 온디맨드·스팟 혼합 사용 + S3 영구 스토리지입니다. 스팟 인스턴스만 사용하면 중단 위험이 있고, HDFS는 클러스터 종료 시 데이터가 사라집니다.

📋 Question

대규모 데이터 분석을 위해 Amazon EMR을 도입하려 합니다. 컴퓨팅 리소스와 분리된 영구 스토리지가 필요하며, 고성능을 유지하면서도 비용을 최적화해야 합니다. 모범 사례에 부합하는 구성은 무엇일까요?

• AGraviton 기반 EC2 인스턴스를 사용합니다. 코어 노드에 온디맨드 인스턴스를, 태스크 노드에 스팟 인스턴스를 혼합하여 사용합니다. Amazon S3를 영구 데이터 스토어로 사용합니다.
  ✅ Graviton 기반 EC2 — ARM 아키텍처 기반으로 x86 대비 최대 40% 비용 절감. 온디맨드+스팟 혼합 — 안정적 코어 노드는 온디맨드, 탄력적 태스크 노드는 스팟으로 비용 절감. Amazon S3 — 컴퓨팅과 분리된 영구 객체 스토리지. EMR 클러스터 종료 후에도 데이터 유지. EMR 모범 사례의 핵심 3요소 모두 충족.
• BGraviton 기반 EC2 인스턴스를 사용합니다. 모든 노드에 스팟 인스턴스만 사용합니다. Amazon S3를 영구 데이터 스토어로 사용합니다.
  ❌ 스팟 인스턴스는 2분 사전 알림 후 중단될 수 있음. 모든 노드를 스팟으로만 구성하면 클러스터 전체가 중단 위험에 노출됨. 고성능 유지 요건 미충족.
• CGraviton 기반 EC2 인스턴스를 사용합니다. 온디맨드·스팟 혼합 사용합니다. HDFS를 영구 데이터 스토어로 사용합니다.
  ❌ HDFS(Hadoop Distributed File System) — EMR 클러스터의 로컬 스토리지. 클러스터 종료 시 모든 데이터 삭제됨. 영구 스토리지 요건 미충족.
• D컴퓨팅 최적화 EC2 인스턴스를 프라이머리 노드에 사용합니다. 온디맨드·스팟 혼합 사용합니다. HDFS를 영구 데이터 스토어로 사용합니다.
  ❌ 프라이머리 노드는 컴퓨팅 집약적이지 않아 컴퓨팅 최적화 인스턴스 불필요. HDFS도 영구 스토리지 요건 미충족. 두 가지 모두 모범 사례와 맞지 않음.

🎯

정답

A — Graviton + 온디맨드·스팟 혼합 + S3 영구 스토리지

🔑 핵심 개념 — EMR 스토리지 비교

스토리지	영구성	클러스터 종료 후	영구 스토리지 적합?
Amazon S3	영구	데이터 유지	✓ 권장
HDFS	일시적	데이터 삭제	✗
EBS	영구 가능	수동 관리 필요	조건부

💡 이것만 기억하자

EMR 모범 사례 3요소:
1. Graviton 기반 EC2 (비용 절감)
2. 온디맨드 + 스팟 혼합 (안정성 + 비용 균형)
3. Amazon S3 (컴퓨팅 분리 영구 스토리지)

HDFS = 클러스터 종료 시 데이터 사라짐 → 영구 스토리지 아님!

AWS DEA-C01 Glue 크롤러 Athena 파티셔닝 DSSE-KMS EventBridge Redshift 쿼리 편집기 v2 EMR 모범 사례 AWS 자격증