AWS DEA-C01 각색 문제 Day 06 — AppFlow, Glue PII, EBS gp3, S3 Intelligent-Tiering, DMS 이기종 마이그레이션

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

AppFlow SaaS 연동, Glue PII 탐지 변환, EBS gp3 비용 최적화, S3 Intelligent-Tiering, DMS 이기종 DB 마이그레이션 — 5문제 핵심 정리.

AWS DEA-C01 Domain 1·2 · 수집 · 스토리지 · 보안 5문제

📋 목차

• Q26 SaaS CRM 데이터를 Redshift로 — 최소 코딩으로 연동
• Q27 ETL 파이프라인에서 PII 자동 탐지·마스킹
• Q28 EBS 볼륨 비용 절감 — gp3 마이그레이션
• Q29 접근 패턴이 혼재된 S3 데이터 레이크 비용 최적화
• Q30 SQL Server → RDS PostgreSQL 최소 다운타임 마이그레이션

Q26AppFlow · SaaS 연동 · 운영 최소화⭐ 자주 출제

Amazon AppFlow는 Salesforce·Slack 등 SaaS 서비스와 AWS 스토리지 간 데이터 이동을 코드 없이 구성하는 완전 관리형 통합 서비스입니다. 직접 Redshift를 대상으로 설정할 수 있어 파이프라인 구축 노력을 최소화합니다.

📋 Question

B2B 플랫폼 회사가 CRM 시스템에 저장된 수백만 건의 거래 레코드를 분석하려 합니다. 분석 쿼리는 Amazon Redshift에서 실행되며, CRM의 특정 거래 데이터 서브셋이 필요합니다. 회사는 CRM에서 Redshift로 데이터를 이전하되, 파이프라인 구축·유지보수에 드는 시간을 최소화하고 싶습니다. 가장 적합한 솔루션은 무엇일까요?

• AAWS Glue와 서드파티 라이브러리로 Apache Spark를 CRM에 연결하고, 데이터를 Parquet 형식으로 S3에 추출한 뒤 Redshift Spectrum으로 쿼리합니다.
  ❌ 서드파티 라이브러리 도입 + Glue Spark 잡 작성 + Redshift Spectrum 외부 테이블 설정까지 여러 단계를 직접 코딩해야 함. 구축·유지보수 부담이 가장 큰 방법.
• BAmazon AppFlow에서 흐름을 생성합니다. CRM을 소스로, Amazon Redshift 테이블을 대상으로 연결을 설정하고 트리거를 구성합니다.
  ✅ Amazon AppFlow — SaaS와 AWS 간 데이터 이동을 코드 없이 구성하는 완전 관리형 통합 서비스. 레고 블록 연결처럼 소스(CRM)와 대상(Redshift)을 콘솔에서 연결하면 끝. 코딩·인프라 관리 없이 바로 사용 가능.
• CAmazon API Gateway로 CRM 이벤트 구독을 설정하고 Lambda 함수를 연결합니다. 데이터를 Parquet 형식으로 S3에 저장한 뒤 Redshift Spectrum으로 쿼리합니다.
  ❌ API Gateway 설정 + Lambda 함수 개발 + S3 저장 로직 + Redshift Spectrum 외부 테이블 구성까지 여러 서비스를 직접 연결하는 코딩이 필요. 운영 부담이 큼.
• DCRM의 데이터 내보내기 도구로 데이터를 .csv 파일로 추출해 S3에 업로드한 뒤 Redshift Spectrum으로 쿼리합니다.
  ❌ 수동 내보내기 + S3 업로드 + Spectrum 설정은 자동화가 안 되어 있어 정기적 반복 작업이 발생. 운영 오버헤드 최소화와 정반대.

🎯

정답

B — Amazon AppFlow로 CRM → Redshift 코드 없이 연동

🔑 핵심 개념 — SaaS 데이터 연동 방법 비교

방법	코딩 필요	관리 부담	SaaS 직접 지원
Amazon AppFlow	없음	최소	✓ 네이티브
Glue + 서드파티 라이브러리	많음	높음	라이브러리 의존
API Gateway + Lambda	많음	높음	직접 구현 필요
수동 CSV 내보내기	없음	반복 수작업	미지원

💡 이것만 기억하자

"SaaS(Salesforce 등) → AWS + 최소 코딩" → Amazon AppFlow

AppFlow = 노코드 SaaS↔AWS 데이터 파이프라인
DataSync = 파일시스템↔AWS (SaaS 아님)
Data Exchange = 타사 데이터 마켓플레이스 (SaaS 아님)

---

Q27Glue PII 탐지 · 데이터 마스킹 · 운영 최소화⭐ 자주 출제

AWS Glue PII 탐지 변환(Detect PII Transform)은 전화번호·이메일·주민번호 등 개인식별정보를 자동으로 찾아내고 마스킹하는 내장 기능입니다. 직접 정규식 코드를 작성하는 것보다 훨씬 적은 노력으로 구현 가능합니다.

📋 Question

데이터 팀이 S3에 저장된 고객 테이블을 ETL 작업으로 처리하고 있습니다. 이 테이블에는 전화번호와 이메일 주소가 포함된 컬럼이 있으며, 보안 정책에 따라 해당 민감 정보를 마스킹해야 합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?

• A전화번호·이메일을 찾는 코드를 직접 작성한 Amazon EMR 작업을 생성하고, 해당 데이터를 수정합니다.
  ❌ Amazon EMR — EC2 기반 Spark/Hadoop 클러스터. PII 탐지 로직을 직접 코딩 + 클러스터 관리까지 필요. 운영 오버헤드가 가장 큼.
• B전화번호·이메일을 찾는 코드를 직접 작성한 AWS Glue 작업을 생성하고, 해당 데이터를 수정합니다.
  ❌ Glue를 쓰는 건 맞지만 PII 탐지 로직(정규식 등)을 직접 코딩해야 함. C의 내장 PII 탐지 변환과 비교하면 불필요한 코딩 부담이 있음.
• CGlue의 내장 PII 탐지 변환(Detect PII Transform)을 사용하는 AWS Glue 작업을 생성하여 전화번호·이메일을 찾아내고 마스킹합니다.
  ✅ AWS Glue PII 탐지 변환(Detect PII Transform) — 경비원이 자동으로 민감 정보를 식별하고 마스킹하는 내장 기능. 정규식 코드 없이 GUI 또는 간단한 설정만으로 전화번호·이메일·신용카드 번호 등 PII를 자동 탐지·수정. 최소 코딩으로 운영 오버헤드 최소화.
• DAmazon Comprehend API를 호출하는 Lambda 함수를 생성하여 전화번호·이메일을 찾아내고 수정합니다.
  ❌ Amazon Comprehend — 자연어 처리(NLP) 서비스. PII 탐지 기능이 있지만 Lambda 함수 개발 + Comprehend API 호출 로직 + 수정 로직까지 직접 구현해야 해 운영 오버헤드가 높음. ETL 파이프라인에 Glue 내장 변환보다 비효율적.

🎯

정답

C — Glue 내장 PII 탐지 변환으로 최소 코딩 마스킹

🔑 핵심 개념 — PII 탐지·마스킹 방법 비교

방법	코딩 필요	ETL 파이프라인 통합	운영 부담
Glue PII 탐지 변환	없음	✓ 내장	최소
Glue 직접 코딩	필요	✓ 통합	중간
Lambda + Comprehend	많음	별도 구성	높음
EMR 직접 코딩	많음	별도 구성	최대

💡 이것만 기억하자

"ETL 내 PII(전화번호·이메일) 자동 탐지·마스킹"
→ AWS Glue Detect PII Transform (내장, 코딩 불필요)

Comprehend = NLP 서비스 (PII 탐지 가능하나 별도 구현 필요)
Glue 내장 변환 = ETL 파이프라인에 직접 통합, 최소 노력

---

Q28EBS · gp2 → gp3 · 비용 최적화⭐ 자주 출제

EBS gp3는 gp2 대비 약 20% 저렴하면서 IOPS와 처리량을 독립적으로 설정 가능한 범용 SSD 볼륨입니다. 같은 성능을 더 저렴하게 유지하면서 크기까지 줄이면 추가 비용 절감이 가능합니다.

📋 Question

비용 최적화 검토 중 여러 EBS gp2 볼륨이 10TB로 프로비저닝되어 있지만 실제 사용률은 20% 수준임을 확인했습니다. 동일한 성능을 유지하면서 EBS 스토리지 비용을 줄이는 가장 효과적인 방법은 무엇일까요?

• Agp2 볼륨을 크기는 그대로(10TB) 유지하면서 gp3 볼륨으로 마이그레이션하고, gp3 기본 IOPS·처리량으로 구성합니다.
  ❌ gp3로 전환해 단가는 절감되지만 10TB 크기를 그대로 유지하므로 낭비되는 스토리지 비용이 남음. 사용률이 20%뿐이므로 크기도 줄여야 더 효과적.
• Bgp2 볼륨을 3TB 크기의 gp2 볼륨으로 마이그레이션하고, 원래와 동일한 IOPS·처리량으로 구성합니다.
  ❌ 크기는 줄였지만 gp2에 그대로 머뭄. gp2는 gp3보다 단가가 높고 IOPS가 볼륨 크기에 연동되어 있어 유연성이 낮음. gp3로 전환하는 것이 더 비용 효율적.
• Cgp2 볼륨을 3TB gp3 볼륨으로 마이그레이션하고, 원래 볼륨과 동일한 IOPS·처리량으로 구성합니다.
  ✅ EBS gp3 — gp2 대비 GB당 약 20% 저렴하고 IOPS·처리량을 독립 설정 가능. 크기를 10TB → 3TB(실사용 기준)로 줄이고, gp3로 전환하면 단가 절감 + 용량 절감 두 가지 효과 동시 달성. 성능은 IOPS·처리량 수동 지정으로 그대로 유지.
• D볼륨 크기는 그대로 유지하고 EBS 볼륨에 부분 쓰기 방지를 구현합니다.
  ❌ 부분 쓰기 방지는 데이터 무결성 기능이지 비용 절감과 무관. 크기도 그대로라 스토리지 비용 절감이 전혀 없음.

🎯

정답

C — 3TB gp3로 마이그레이션 + 동일 IOPS·처리량 유지

🔑 핵심 개념 — EBS gp2 vs gp3 비교

구분	gp2	gp3
가격	기준	약 20% 저렴
IOPS	볼륨 크기에 연동 (3 IOPS/GB)	독립 설정 가능
처리량	크기 연동	독립 설정 가능
기본 IOPS	볼륨 크기 × 3	3,000 IOPS (기본)

💡 이것만 기억하자

EBS 비용 절감 = 크기 축소 + gp2 → gp3 전환

gp3 = gp2보다 20% 저렴 + IOPS·처리량 독립 설정
크기만 줄이고 gp2 유지 = 절반의 효과

---

Q29S3 Intelligent-Tiering · 스토리지 비용 최적화⭐ 자주 출제

S3 Intelligent-Tiering은 접근 패턴을 자동으로 모니터링하여 자주 접근하는 데이터와 그렇지 않은 데이터를 각각 최적의 스토리지 계층으로 자동 이동합니다. 접근 패턴이 예측 불가하거나 혼재된 경우에 최적의 선택입니다.

📋 Question

분석 플랫폼이 S3 데이터 레이크를 운영하고 있습니다. 프로덕션 애플리케이션이 매일 데이터의 절반에 실시간으로 접근하고, 나머지 절반은 연 1회 정도만 접근합니다. 매일 새 데이터가 추가되며 S3 스토리지 비용을 최적화해야 합니다. 가장 적합한 스토리지 클래스는 무엇일까요?

• AS3 Standard
  ❌ 모든 데이터를 Standard로 유지하면 연 1회만 접근하는 절반의 데이터에도 높은 스토리지 비용을 지불하게 됨. 비용 최적화 미달.
• BS3 Glacier Flexible Retrieval
  ❌ S3 Glacier Flexible Retrieval — 검색에 분~시간이 소요되는 아카이브 스토리지. 매일 실시간으로 접근하는 데이터 절반에는 사용 불가. 검색 지연이 너무 큼.
• CS3 Intelligent-Tiering
  ✅ S3 Intelligent-Tiering — AWS가 접근 패턴을 자동 모니터링해 자주 접근하는 데이터는 Standard 계층에, 잘 접근하지 않는 데이터는 IA 계층에 자동 배치. 매일 새 데이터가 추가되고 접근 패턴이 혼재된 이 시나리오에 가장 적합. 수명주기 규칙 관리 불필요.
• DS3 One Zone-Infrequent Access (S3 One Zone-IA)
  ❌ S3 One Zone-IA — 단일 AZ 저장으로 고가용성 미보장. 매일 실시간 접근하는 데이터가 있어 IA 계층의 검색 비용이 높고, 하나의 스토리지 클래스로 두 가지 접근 패턴을 모두 커버하기 어려움.

🎯

정답

C — S3 Intelligent-Tiering으로 접근 패턴 자동 최적화

🔑 핵심 개념 — S3 Intelligent-Tiering이 맞는 상황

상황	Intelligent-Tiering 적합?	이유
접근 패턴이 예측 불가	✓ 최적	자동 모니터링·이동
자주 + 드물게 혼재	✓ 최적	계층 자동 분리
매일 새 데이터 추가	✓ 최적	수명주기 규칙 불필요
연 1~2회만 접근	Glacier 고려	Deep Archive가 더 저렴

💡 이것만 기억하자

"접근 패턴 예측 불가 or 자주+드물게 혼재" → S3 Intelligent-Tiering

자동으로 적절한 계층으로 이동 → 수명주기 규칙 관리 불필요
접근 패턴이 명확하면 → 수명주기 정책으로 Standard-IA → Glacier

---

Q30DMS · 이기종 DB 마이그레이션 · 스키마 변환⭐ 자주 출제

AWS DMS(Database Migration Service)는 최소 다운타임으로 이기종 DB를 마이그레이션하는 서비스입니다. 스키마 변환은 DMS Schema Conversion(현재 DMS에 통합)이 담당하며, 별도 SCT 설치 없이 사용 가능합니다.

📋 Question

온프레미스의 Microsoft SQL Server 2019 데이터베이스(8TB)를 AWS의 Amazon RDS for PostgreSQL로 마이그레이션해야 합니다. 서비스 중단 시간을 최소화하는 방법은 무엇일까요?

• AAWS DataSync로 DB를 마이그레이션하고, DMS Schema Conversion으로 스키마를 RDS for PostgreSQL에 맞게 변환합니다.
  ❌ AWS DataSync — 파일시스템(NFS, SMB) 데이터 동기화 서비스. DB 마이그레이션 도구가 아님. DataSync 스트림을 DMS로 읽는 기능도 없음.
• BAWS DMS로 데이터를 마이그레이션하고, DMS Schema Conversion을 사용하여 SQL Server 스키마를 RDS for PostgreSQL 형식으로 변환합니다.
  ✅ AWS DMS(Database Migration Service) — 이기종 DB 최소 다운타임 마이그레이션 전문 서비스. CDC(Change Data Capture)로 마이그레이션 중에도 원본 DB 계속 운영 가능. DMS Schema Conversion — DMS에 통합된 스키마 변환 기능으로 별도 도구 설치 불필요. 가장 간단하고 완전한 솔루션.
• CAWS DMS로 마이그레이션하고, 대상 RDS 인스턴스에 AWS SCT(Schema Conversion Tool)를 직접 설치하여 스키마를 변환합니다.
  ❌ AWS SCT(Schema Conversion Tool) — 온프레미스 또는 별도 서버에 설치해야 하는 도구. 대상 RDS 인스턴스에 직접 설치는 불가. 또한 현재 DMS Schema Conversion이 SCT 기능을 통합했으므로 B가 더 간단.
• DAWS DMS로 마이그레이션하되 Amazon RDS Custom을 대상으로 사용하고, 대상 인스턴스에 AWS SCT를 설치해 스키마를 변환합니다.
  ❌ Amazon RDS Custom — OS 및 DB 엔진 수준의 커스터마이징이 필요한 특수 케이스용. 일반 PostgreSQL 마이그레이션에는 표준 RDS for PostgreSQL로 충분. 불필요한 복잡성 추가.

🎯

정답

B — AWS DMS + DMS Schema Conversion으로 최소 다운타임 마이그레이션

🔑 핵심 개념 — DMS 스키마 변환 옵션 비교

도구	설치 방법	이기종 변환	현재 권장?
DMS Schema Conversion	DMS 콘솔에 내장	✓	✓ 권장
AWS SCT	별도 서버에 설치	✓	레거시 방식
DataSync	-	✗ DB 아님	파일 동기화 전용
RDS Custom	-	-	고급 커스텀 필요 시만

💡 이것만 기억하자

"이기종 DB 마이그레이션 + 최소 다운타임"
→ AWS DMS + DMS Schema Conversion

DataSync = 파일시스템 동기화 (DB 마이그레이션 아님)
SCT = 구형 방식, DMS에 통합됨

AWS DEA-C01 Amazon AppFlow Glue PII 탐지 EBS gp3 S3 Intelligent-Tiering AWS DMS 데이터 엔지니어 자격증 AWS 자격증