정답 · 해설

해설

【핵심 용어】 ▸ DynamoDB Point-in-Time Recovery(PITR) — 최근 35일 내 임의 시점으로 테이블 복원(초 단위), 설정만으로 자동 ▸ AWS Backup / 온디맨드 백업 — 백업 스케줄·관리 필요, 임의 시점 복원엔 PITR이 최적 ▸ DynamoDB Streams — 변경 로그 캡처용이나 복원 파이프라인은 직접 구축 필요 【정답 포인트】 ▸ "지난 24시간 내 임의 시점으로 되돌리기 + 최소 운영" → PITR 활성화 ▸ PITR은 설정 한 번으로 임의 시점 복원을 자동 제공 → 24시간 요구를 최소 운영으로 충족 【오답 체크】 (B) AWS Backup은 백업 계획·관리가 필요하고 임의 시점(초 단위) 복원엔 PITR이 더 적합. (C) 매시간 Lambda 온디맨드 백업은 개발·운영 부담 + "임의 시점" 복원 불가(시간 단위 스냅샷). (D) Streams + S3 저장은 복원 로직을 직접 구현해야 해 오버헤드가 큼. 【시험 포인트】 DynamoDB 임의 시점 복원 + 최소 운영 → PITR(Point-in-Time Recovery).

해설

【핵심 용어】 ▸ S3 이벤트 알림(s3:ObjectCreated) + Lambda — 업로드 즉시 이벤트 기반으로 함수 트리거(서버리스, 자동 확장) ▸ AWS Lambda — 5초 미만 처리 + 수백 동시 업로드에 자동 확장·초당 과금으로 비용 효율 ▸ Kinesis / SNS / CloudTrail — 스트리밍·팬아웃·감사용으로 이 시나리오엔 과도하거나 부적합 【정답 포인트】 ▸ "업로드마다 5초 미만 메타데이터 추출 + 변동 폭 큰 부하 + 비용 효율" → S3 이벤트 알림 → Lambda ▸ 이벤트 기반 서버리스로 동시 업로드에 자동 확장, 유휴 시 비용 없음 → 요구 충족 【오답 체크】 (A) CloudTrail은 API 감사용이고 AppSync는 GraphQL API로 파일 처리 트리거에 부적합. (C) Kinesis Data Streams는 지속 스트리밍용으로 산발적 파일 업로드엔 과도·비효율. (D) SNS는 팬아웃 메시징이며 S3 업로드 처리 트리거로는 Lambda 직접 트리거가 더 단순·효율적. 【시험 포인트】 S3 업로드 이벤트 처리 → S3 event notification + Lambda(서버리스, 자동 확장).

해설

【핵심 용어】 ▸ Compute Savings Plans — 상시 실행 워크로드에 최대 할인 + 인스턴스 유형·리전 유연성 ▸ On-Demand Instances — 간헐적/예측 불가 사용(비상시·비프로덕션)에 적합 ▸ 비프로덕션 종료(shut down) — 미사용 시간(주말/야간) 인스턴스 중지로 비용 절감 【정답 포인트】 ▸ "프로덕션 상시 사용" → Compute Savings Plans로 최대 절감 ▸ "비프로덕션은 평일 업무시간만" → On-Demand + 미사용 시 종료 → 프로덕션·비프로덕션 각각 최적 비용 【오답 체크】 (A) Dedicated Hosts는 라이선스/격리 요구용으로 비용 효율이 낮고 시나리오에 과도. (B) 비프로덕션까지 Reserved Instances는 상시 약정이라 간헐 사용 시 낭비(종료해도 약정 비용 발생). (D) Dedicated Hosts(프로덕션)는 비용 비효율이고 요구와 무관. 【시험 포인트】 상시 워크로드 → Savings Plans, 간헐 워크로드 → On-Demand + 미사용 종료.

해설

【핵심 용어】 ▸ AWS DMS(Database Migration Service) — 기존 데이터 마이그레이션 + CDC(변경 데이터 캡처)로 진행 중 변경 지속 복제 ▸ AWS SCT(Schema Conversion Tool) — 이기종(Oracle→PostgreSQL) 스키마 변환 ▸ 마이그레이션 중 변경 캡처 — full-load만으로는 부족, CDC 복제 필요 【정답 포인트】 ▸ "Oracle → Aurora PostgreSQL(이기종) + 마이그레이션 중 소스 변경 캡처" → SCT로 스키마 변환 + DMS로 기존 데이터 + 진행 변경(CDC) 복제 ▸ DMS의 ongoing replication(CDC)이 마이그레이션 동안 발생하는 변경을 지속 반영 → 요구 충족 【오답 체크】 (A) DMS full-load만으로는 진행 중 변경(CDC)을 캡처하지 못함. (B) DataSync는 파일 전송용이며 이기종 DB 스키마 변환·CDC 복제를 못함. (D) Snowball은 오프라인 대량 전송으로 실시간 변경 캡처가 불가. 【시험 포인트】 이기종 DB 마이그레이션 + 진행 중 변경 반영 → SCT + DMS(full-load + CDC).

해설

【핵심 용어】 ▸ AWS Fargate — 서버리스 컨테이너 실행(노드/인프라 관리 불필요), ECS·EKS 양쪽에서 사용 가능 ▸ Amazon ECS on Fargate / Amazon EKS on Fargate — 관리형 오케스트레이션 + 서버리스로 수요에 따라 스케일 ▸ EC2 워커 노드 / Lambda 컨테이너 — 노드 자체 관리 필요 or 컨테이너 서비스 호스팅 방식 부적합 【정답 포인트】 ▸ "Docker 앱을 관리형 서비스로 호스팅 + 컨테이너별 수요에 따라 스케일 + 인프라 관리 없음" → Fargate 기반 ▸ ECS on Fargate(A)와 EKS on Fargate(B) 모두 서버리스로 노드 관리 없이 스케일 → 두 조합이 정답 【오답 체크】 (C) API Gateway + Lambda로 "컨테이너 실행"은 컨테이너 호스팅 방식과 결이 다르고 요구에 부합하지 않음. (D) ECS + EC2 워커 노드는 EC2 인스턴스(인프라)를 직접 관리해야 함. (E) EKS + EC2 워커 노드 역시 노드 관리 부담이 있어 "관리 부담 없음" 요구에 위배. 【시험 포인트】 컨테이너 + 인프라 관리 없음 → Fargate(ECS 또는 EKS). EC2 워커 노드는 관리 필요.

해설

【핵심 용어】 ▸ EC2 Auto Scaling(동적 확장) — 트래픽 증가에 따라 인스턴스를 자동 추가/제거해 수요 대응·비용 효율 ▸ Launch Template + AMI — 사전 구성 AMI로 신규 인스턴스를 빠르게 기동 ▸ 과대 프로비저닝/상시 대형 ASG — 유휴 자원 비용 낭비로 비용 효율 위배 【정답 포인트】 ▸ "시즌 세일 급증 트래픽 + 가장 비용 효율" → 트래픽 증가 시 스케일 아웃하는 Auto Scaling + 사전 구성 AMI 시작 템플릿 ▸ 수요에 맞춰 필요한 만큼만 확장하고 감소 시 축소 → 급증 대응 + 비용 효율 【오답 체크】 (A) 대형 ASG를 만들고 절반을 중지해 확장에 쓰는 방식은 비표준·비효율(중지 인스턴스 기반 스케일 아웃 부적절). (B) 최소 크기를 피크에 맞추면 평상시 유휴 자원으로 비용 낭비. (C) CloudFront + ElastiCache로 "동적 콘텐츠"를 캐싱하는 구성은 과도·부적합(동적 캐싱 제약, 복잡). 【시험 포인트】 급증 트래픽 + 비용 효율 → 수요 기반 Auto Scaling(scale out) + Launch Template/AMI.

해설

【핵심 용어】 ▸ AWS Config managed rule (restricted-ssh) — 보안 그룹이 0.0.0.0/0에서 SSH(22)를 허용하는지 자동 평가하는 관리형 규칙 ▸ Amazon SNS — Config 규칙 위반(NON_COMPLIANT) 이벤트를 관리자에게 알림 전송 ▸ AWS Lambda / SCP — 커스텀 감시 코드, 계정 단위 정책 (관리형 대비 운영 부담·목적 불일치) 【정답 포인트】 ▸ "SSH 0.0.0.0/0 금지" 규정 자동 감시 → 이미 존재하는 restricted-ssh 관리형 규칙이 정확히 이 조건을 평가 ▸ "위반 시 알림" + "운영 부담 최소" + "최대한 빨리" → Config 규칙 + SNS 조합으로 코드 없이 즉시 구성 【오답 체크】 (A) Lambda 스크립트를 직접 작성·유지하는 것은 관리형 규칙 대비 개발·운영 부담이 큼. (C) 역할 사용(assume) 알림은 실제 보안 그룹 규칙 위반 자체를 탐지하지 못함. (D) SCP는 생성 자체를 막는 예방책이나 위반 탐지·알림 요건과 어긋나고 티켓 연동은 부담 큼. 【시험 포인트】 "규정 준수 자동 감시 + 최소 운영" → AWS Config 관리형 규칙 + SNS. 이미 존재하는 규칙명이 보기에 나오면 우선 후보.

해설

【핵심 용어】 ▸ Amazon VPC Lattice — 계정·VPC 경계를 넘어 서비스 간 연결·인증·서비스 디스커버리를 제공하는 애플리케이션 네트워킹 서비스 ▸ Service Network — 여러 마이크로서비스(Lambda, EKS 등)를 등록하고 VPC를 연결해 HTTPS 통신 구성 ▸ Network Firewall / PrivateLink / VPC Peering — 트래픽 검사·엔드포인트·직접 연결 (서비스 디스커버리 미제공, 관리 부담 큼) 【정답 포인트】 ▸ "서비스 간 HTTPS(443) 통신" + "서비스 레지스트리(디스커버리)" → VPC Lattice가 리스너·타깃·서비스 네트워크로 기본 제공 ▸ "멀티 계정, 최소 관리 부담" → Lattice 서비스 네트워크에 VPC 연결만으로 계정 간 연결 완성 【오답 체크】 (A) Network Firewall + Transit Gateway는 트래픽 검사용으로 서비스 디스커버리 기능이 없고 구성 복잡. (C) NLB + PrivateLink는 서비스마다 엔드포인트를 수동 생성해야 해 관리 부담이 큼. (D) VPC 피어링 + 프리픽스 리스트는 서비스 수 증가 시 연결·라우팅 관리가 기하급수적으로 복잡. 【시험 포인트】 "서비스 간 통신 + 서비스 디스커버리 + 멀티 계정 최소 관리" → VPC Lattice.

해설

【핵심 용어】 ▸ Amazon ElastiCache for Redis — 인메모리 캐시, 서브밀리초 응답 + 스냅샷·복제(read replica)·자동 장애 조치 지원 ▸ ElastiCache for Memcached — 단순 캐시, 스냅샷·복제 미지원 (수평 확장만) ▸ Aurora / DynamoDB — DB 계층 확장 자체는 이미 효과 없다고 명시됨 【정답 포인트】 ▸ "스냅샷 + 복제 + 서브밀리초 응답" 세 조건을 모두 만족 → Redis만 해당 ▸ "DB 스케일링으로 해결 안 됨" + "메타데이터 읽기 지연" → DB 앞단 캐시 계층 추가가 정석 【오답 체크】 (A) Aurora 이관은 "DB 확장은 도움 안 됨" 전제와 어긋나며 서브밀리초 캐시 요건 미충족. (B) DynamoDB 글로벌 테이블 마이그레이션은 캐시 계층 추가 대비 애플리케이션 재작성 부담이 크고 요구는 캐싱. (D) Memcached는 스냅샷·복제 미지원이라 세 요건을 못 채움. 【시험 포인트】 캐시 선택 시 "스냅샷/복제/영속성/고가용성" 요구 → Redis, 단순·순수 캐시 → Memcached.

해설

【핵심 용어】 ▸ AMI Launch Permission — AMI를 공유할 대상(계정/OU ARN)을 지정하는 권한 목록 ▸ AWS KMS Key Policy — 암호화 스냅샷 복호화를 위해 대상 OU에 KMS 키 사용 권한 부여 필요 ▸ AWS Organizations OU — 조직 단위 단위로 AMI 공유 대상 지정 가능 【정답 포인트】 ▸ (A) AMI를 개발 OU와 공유 → launch permission 목록에 개발 OU의 ARN 추가 ▸ (C) AMI가 KMS 암호화 스냅샷 기반이므로 개발 OU가 KMS 키를 사용(복호화)할 수 있도록 키 정책 업데이트 → 두 가지 모두 있어야 실제 인스턴스 시작 가능 【오답 체크】 (B) Organizations 루트 ARN을 launch 목록에 넣으면 조직 전체에 과도 공유되어 보안 OU→개발 OU 요건과 불일치. (D) 개발 팀 "계정" ARN도 가능하나 문제는 OU 단위 공유를 요구, OU ARN(A)이 적합. (E) KMS 키 재생성은 불필요하고 루트 ARN 허용은 과도 공유. 【시험 포인트】 암호화 AMI 공유 = "launch permission(공유 대상) + KMS key policy(복호화 권한)" 두 축을 항상 함께 설정.

해설

【핵심 용어】 ▸ AWS Snowball Edge — 페타바이트급 오프라인 대량 전송용 물리 디바이스, 여러 대 병렬 사용 가능 ▸ AWS Snowmobile — 엑사바이트급 단일 장소 전송용 트럭 (분산 다수 사이트에 부적합) ▸ Direct Connect / Storage Gateway — 전용선·온라인 게이트웨이 (대역폭·비용·기간 부적합) 【정답 포인트】 ▸ "80개 오피스 × 1PB(총 80PB)" + "1~2Gbps 대역폭" + "4주 내 일회성 마이그레이션" → 인터넷 전송은 물리적으로 불가능(1PB에 수개월) ▸ 각 오피스에 Snowball Edge 여러 대를 병렬 투입해 오프라인 전송이 기간·비용 모두 최적 【오답 체크】 (A) 오피스마다 10Gbps Direct Connect 신설은 프로비저닝에 수주~수개월, 비용도 과도. (C) Snowmobile은 단일 대용량 사이트용이라 80개 분산 오피스에 부적합·과잉. (D) Volume Gateway는 인터넷 대역폭에 의존해 80PB를 4주에 전송 불가. 【시험 포인트】 "대량 데이터 + 낮은 대역폭 + 마감 기한" → Snowball(Edge). 단일 초대용량(엑사바이트) → Snowmobile.

해설

【핵심 용어】 ▸ EFS Resource Policy (파일 시스템 정책) — 파일 시스템에 부착하는 리소스 기반 정책, 특정 IAM 주체의 액션 허용/거부 ▸ elasticfilesystem:ClientWrite — EFS 쓰기(수정/삭제) 권한 액션, 이를 Deny하면 읽기 전용 강제 ▸ EFS Access Point / read-only mount — POSIX·마운트 옵션 (IAM 접근 제어 요건과 불일치) 【정답 포인트】 ▸ "IAM 접근 제어로 수정/삭제 방지" → EFS 파일 시스템 리소스 정책에서 EC2 IAM 역할에 대해 ClientWrite를 Deny ▸ 마운트 옵션이 아닌 IAM 권한 레벨로 강제해야 한다는 조건에 정확히 부합 【오답 체크】 (A) read-only 마운트는 IAM 제어가 아니라 클라이언트 측 설정이라 우회 가능, 요건 불일치. (C) EFS에는 "identity policy를 파일 시스템에 생성"하는 개념이 없음(정책 유형 혼동), 리소스 정책이 맞음. (D) 액세스 포인트 + POSIX 권한도 IAM 접근 제어가 아니라 POSIX 기반, 요건과 다름. 【시험 포인트】 "IAM으로 EFS 읽기 전용 강제" → 파일 시스템 리소스 정책에서 ClientWrite Deny.

해설

【핵심 용어】 ▸ IAM Role 교차 계정 위임 (cross-account role / AssumeRole) — 외부 계정이 자기 자격증명으로 우리 계정 역할을 맡아 임시 자격증명 사용 ▸ IAM User / long-term credentials — 장기 자격증명 공유는 보안 취약 ▸ Permission Boundary — 권한 상한 설정 (계정 간 접근 위임 메커니즘 아님) 【정답 포인트】 ▸ "외부 벤더의 자동화 도구(벤더 계정)가 우리 계정 접근" + "가장 안전" → 우리 계정에 IAM 역할 생성 후 벤더 IAM 역할에 위임(신뢰 정책) ▸ 역할 위임은 장기 자격증명 없이 임시 토큰을 사용하므로 교차 계정 접근의 보안 모범 사례 【오답 체크】 (B) IAM 사용자 + 비밀번호는 장기 자격증명 공유로 유출 위험이 크고 프로그래밍 접근에 부적합. (C) 다른 계정의 IAM 사용자를 우리 계정 IAM 그룹에 추가할 수 없음(개념 오류). (D) permission boundary는 계정 간 신뢰를 부여하는 메커니즘이 아니며 사용자 자격증명 문제 잔존. 【시험 포인트】 교차 계정 접근은 "IAM Role + AssumeRole(역할 위임)"이 정답, IAM User/키 공유는 오답.

해설

【핵심 용어】 ▸ Cost Allocation Tags — 리소스에 소유자/부서 태그를 붙여 비용을 부서별로 분류·집계 ▸ AWS Budgets — 예산 및 임계값 알림, 지출이 예산의 특정 % 도달 시 통지 ▸ Cost Explorer / Cost Anomaly Detection — 예측·이상 탐지 (임계값 % 기준 예산 알림 목적과 다름) 【정답 포인트】 ▸ "부서별 비용 책임" → 비용 할당 태그로 소유자 라벨링 ▸ "예산의 60% 도달 시 알림" → AWS Budgets의 사용량 예산 + 알림 임계값 60% 설정 【오답 체크】 (B) Cost Explorer 예측으로 소유자를 파악한다는 것은 부적절하고, Anomaly Detection은 이상치 탐지지 예산 % 알림이 아님. (C) Trusted Advisor/Support API는 예산 임계 알림 기능이 아님. (D) 소유자 파악은 태그가 맞음(Cost Explorer 예측 아님), 예산 부분은 맞으나 소유자 방법이 틀림. 【시험 포인트】 "부서/소유자별 비용 추적" = 비용 할당 태그, "예산 % 도달 알림" = AWS Budgets 임계값.

해설

【핵심 용어】 ▸ Internal ALB — VPC 내부 전용 로드밸런서, 사무실(Site-to-Site VPN) 트래픽만 수신 ▸ NAT Gateway + Internet Gateway — 프라이빗 서브넷의 아웃바운드(패치 다운로드)만 허용, 인바운드 인터넷 차단 ▸ Security Group 소스 CIDR — ALB 인바운드 소스를 사무실 네트워크 CIDR로 제한 【정답 포인트】 ▸ "사무실에서만 접근" → 프라이빗 서브넷 + 내부 ALB, SG 인바운드 소스를 사무실 CIDR로 한정 ▸ "인터넷에서 보안 패치 다운로드" → 퍼블릭 서브넷의 NAT 게이트웨이로 아웃바운드만 허용 【오답 체크】 (A) 퍼블릭 ALB + 0.0.0.0/0 인바운드는 인터넷에 노출되어 "사무실만 접근" 요건 위반. (C) NAT 게이트웨이는 프라이빗이 아닌 퍼블릭 서브넷에 있어야 하고 SG "아웃바운드" 소스 제한은 접근 통제 방식이 잘못됨. (D) 퍼블릭 ALB는 내부 전용 요건과 상충, 아웃바운드 0.0.0.0/0 설정도 접근 제한 목적과 무관. 【시험 포인트】 "내부 전용 접근 + 인터넷 아웃바운드 패치" → 프라이빗 서브넷 + Internal ALB(SG 소스=사무실 CIDR) + 퍼블릭 서브넷 NAT.

해설

【핵심 용어】 ▸ Amazon QLDB (Quantum Ledger Database) — 변경 불가(immutable)·암호학적으로 검증 가능한 변경 이력을 제공하는 완전관리형 원장 DB ▸ Redshift / Neptune / Timestream — 데이터 웨어하우스 / 그래프 / 시계열 DB (불변 검증 원장 기능 없음) 【정답 포인트】 ▸ "불변·암호학적으로 검증 가능한 데이터 변경 로그" → QLDB의 저널이 정확히 이 특성 제공(회계 감사 이력) ▸ "관리형 + 최소 운영 + 비용 효율" → 완전관리형 QLDB 【오답 체크】 (A) Redshift는 분석용 웨어하우스로 불변 검증 로그 기능이 없음. (B) Neptune은 그래프 DB로 관계 데이터용, 원장 요건과 무관. (C) Timestream은 시계열 DB로 변경 불가 원장·암호 검증 요건 미충족. 【시험 포인트】 "immutable + cryptographically verifiable ledger(감사 이력)" 키워드 → Amazon QLDB.

해설

【핵심 용어】 ▸ AWS Glue DataBrew — 코드 없이 데이터 정제/집계 준비 작업 수행 ▸ AWS Step Functions — 병렬 실행·순서 제어·에러 처리·재시도·상태 관리를 내장한 워크플로 오케스트레이션 ▸ Lambda / Athena / Data Pipeline — 개별 작업 실행 수단 (오케스트레이션·상태 관리 부담 큼/부적합) 【정답 포인트】 ▸ "병렬 실행 + 일부는 특정 순서" + "에러 처리·재시도·상태 관리 부담 제거" → Step Functions가 이를 관리형으로 제공 ▸ 데이터 준비 작업 자체는 DataBrew로 수행, 오케스트레이션은 Step Functions 【오답 체크】 (A) Lambda 단독은 순서·재시도·상태 관리를 직접 구현해야 해 운영 부담이 큼. (B) Athena는 SQL 쿼리 엔진으로 병렬/순서 있는 준비 작업 오케스트레이션에 부적합. (D) Data Pipeline은 자정 1회 실행으로 병렬·순서·에러 처리 요건을 충족 못하고 사실상 레거시. 【시험 포인트】 "작업 오케스트레이션 + 에러/재시도/상태 관리 부담 제거" → AWS Step Functions.

해설

【핵심 용어】 ▸ Amazon SQS FIFO Queue — 순서 보장 + 정확히 한 번 처리(exactly-once)·중복 제거(deduplication) 지원 ▸ SQS Standard Queue — 최소 한 번 전달로 중복 가능 (중복 결제 방지에 부적합) ▸ S3 이벤트 / DynamoDB Streams — 이벤트 기반 트리거이나 중복 방지 보장 없음 【정답 포인트】 ▸ "중복 결제 처리 방지" → SQS FIFO 큐의 중복 제거·정확히 한 번 처리 특성이 핵심 ▸ 여러 Lambda가 처리하더라도 FIFO 큐가 메시지 중복 소비를 방지 【오답 체크】 (A) S3 버킷 이벤트 통지는 중복 방지 보장이 없고 결제 처리 파이프라인으로 부적절. (B) SQS Standard는 최소 한 번 전달이라 중복 메시지가 발생할 수 있어 중복 결제 위험. (D) DynamoDB Streams는 변경 이벤트 트리거지 결제 중복 방지 메커니즘이 아님. 【시험 포인트】 "중복 없이 정확히 한 번 처리(결제/트랜잭션)" → SQS FIFO(중복 제거).

해설

【핵심 용어】 ▸ AWS Control Tower — 관리 계정에 배포하는 멀티 계정 거버넌스 랜딩 존, CloudTrail 감사·가드레일 자동 적용 ▸ AWS Security Hub — FSBP 등 보안 표준 준수 여부를 계정 전반에서 점검 ▸ Account Factory — 신규 계정을 표준 거버넌스로 자동 프로비저닝 【정답 포인트】 ▸ "기존·신규 모든 계정의 API 호출·로그인 감사" + "FSBP 미준수 감지" → Control Tower(CloudTrail) + Security Hub 조합 ▸ "관리형·최소 운영·비용 최소" → Control Tower는 조직 관리 계정에 배포, Account Factory로 신규 계정 자동 적용 【오답 체크】 (B) Control Tower는 전용 멤버 계정이 아니라 Organizations 관리(management) 계정에 배포됨. (C) AMS Accelerate + GuardDuty는 위협 탐지지 FSBP 준수 점검이 아니고 운영 부담(RFC) 큼. (D) FSBP 점검은 Security Hub가 맞으나 AMS Accelerate MALZ + RFC 방식은 운영 부담이 커 최소 오버헤드에 반함. 【시험 포인트】 "전 계정 감사 + 보안 표준(FSBP) 준수 + 최소 운영" → Control Tower(관리 계정) + Security Hub.

해설

【핵심 용어】 ▸ Amazon Athena — S3 데이터를 직접 SQL 조회하는 서버리스 쿼리 서비스, 스캔량 기반 과금(간헐적 사용에 저렴) ▸ AWS Glue Crawler / Data Catalog — S3의 Parquet 스키마를 자동 크롤링해 테이블 메타데이터 등록 ▸ Redshift / Aurora / EMR — 상시 클러스터 비용 발생 (간헐 조회에 비효율) 【정답 포인트】 ▸ "10TB Parquet를 가끔 SQL 분석" + "가장 비용 효율" → 상시 클러스터 없이 스캔량만 과금하는 Athena ▸ Glue 크롤러로 스키마 자동 등록 후 Athena로 S3에 직접 쿼리 【오답 체크】 (A) Aurora로 DMS 마이그레이션은 상시 DB 비용 + 이관 오버헤드로 간헐 분석에 과함. (B) Redshift 클러스터는 상시 프로비저닝 비용이 커 가끔 쓰는 용도에 비효율. (D) EMR 클러스터도 상시/기동 비용과 운영 부담이 커 비용 효율이 낮음. 【시험 포인트】 "S3 데이터 + 가끔(ad-hoc) SQL + 최소 비용" → Athena(+ Glue Data Catalog), 서버리스·스캔 과금.