정답 · 해설

해설

【핵심 용어】 ▸ Lambda—서버리스, 초 단위 과금, 최대 15분 실행 ▸ Glue—ETL 배치, 최소 DPU 비용 (요금 높음) ▸ EMR—클러스터 기반, 복잡한 처리 【정답 포인트】 ▸ "2MB 데이터" + "30초 내 완료" → Lambda 최적 (1GB 메모리 충분) ▸ "가능한 한 빨리" → 서버리스 즉시 실행 ▸ "비용 효율적" → Lambda (초 단위) > Glue (최소 DPU) ▸ 간단한 처리 (수요 요약) → Spark/Glue 불필요 【오답 체크】 (A) Glue Scala Job은 최소 1 DPU 비용 (시간 단위), 매일 반복 시 비용 높음 (B) EMR은 클러스터 오버헤드, 소규모 작업에 부적합 (D) Glue PySpark도 마찬가지로 최소 DPU 비용 발생 【시험 포인트】 ▸ 작은 데이터 + 짧은 처리 시간 → Lambda ▸ Glue vs Lambda 비용: 배치 빈도가 높으면 Lambda 우위

해설

【핵심 용어】 ▸ AWS DataSync — 대규모 데이터 전송, 증분 동기화(Sync 모드), 자동 검증, 관리형 서비스 ▸ 증분 전송(Delta Sync) — 변경된 데이터만 전송하여 네트워크 효율화 ▸ 다중 위치(Multi-Target) — 동일 데이터를 여러 대상으로 동시 전송 ▸ 운영 오버헤드 — Lambda 시간 제한, EC2 관리 비용 회피 【정답 포인트】 ▸ "계속해서 복사" → DataSync 스케줄 기반 자동 동기화 (관리형) ▸ "변경된 경우만" → DataSync Sync 모드(변경 감지 필터링) ▸ "2개 대상" (S3 + EFS) → DataSync가 동일 소스에서 다중 위치 지원 ▸ "운영 오버헤드 최소" → 관리형 서비스(자동 스케줄, 모니터링, 재시도) 【오답 체크】 (B) Lambda는 EFS 마운트 준비 시간(수 초) + 함수 실행 15분 제한, 대용량 파일 전송 부적합, VPC 네트워킹 오버헤드 (C) DataSync "모든 데이터 전송" 모드는 증분 미지원, 매번 전체 데이터 전송으로 비용 낭비, 요구사항 불충족 (D) EC2 + 스크립트는 인스턴스 관리, 네트워킹 설정, 스크립트 유지보수로 운영 오버헤드 높음, 자동 실패 재시도 불가 【시험 포인트】 ▸ S3 ↔ EFS 동시 동기화 → DataSync 전용 기능 ▸ "변경만" 필터 = DataSync Sync 모드 반드시 설정 필수 ▸ "지속적" 단서 → 관리형 자동 스케줄 필수 (수동 트리거 배제)

해설

【핵심 용어】 ▸ Amazon EBS Snapshot — 증분 백업이나 정책 없이 방치 시 계속 누적되어 비용 증가 ▸ Amazon Data Lifecycle Manager (DLM) — 스냅샷 생성·보존·삭제를 정책으로 자동화 (관리형) ▸ EBS Elastic Volumes — 볼륨 크기 변경 기능이나 스냅샷 누적 비용 문제와는 무관 【정답 포인트】 ▸ "스토리지 추가 구매 없음 + 매월 비용 증가" → 원인은 스냅샷 누적 ▸ "최소 운영 오버헤드" → 불필요 스냅샷 삭제 + DLM으로 정책 기반 자동 생성·보존·만료 관리 【오답 체크】 (A) CloudWatch Logs 모니터링 + Elastic Volumes 축소는 볼륨 용량 접근으로 스냅샷 누적 원인을 못 잡음. (B) 커스텀 스크립트는 직접 개발·운영 부담이 커 최소 오버헤드에 반함. (C) 만료 스냅샷 삭제는 일회성 조치일 뿐, 재발 방지 자동화가 없어 매월 재누적됨. 【시험 포인트】 스냅샷 비용 지속 증가 + 최소 운영 → 정리 후 Data Lifecycle Manager로 라이프사이클 자동화.

해설

【핵심 용어】 ▸ DynamoDB Accelerator(DAX) — DynamoDB 전용 인메모리 캐시, 마이크로초 응답, 관리형 ▸ ElastiCache(Redis) — 범용 캐시, 별도 프로비저닝 및 관리 필요 ▸ Redshift — 분석 데이터 웨어하우스, OLTP 미설계, 마이그레이션 필수 ▸ RDS — 관계형 데이터베이스, DynamoDB 비NoSQL 특성 미제공 【정답 포인트】 ▸ "DynamoDB 응답 시간 개선" → DAX가 DynamoDB 전용 최적화 제공 ▸ "밀리초 → 마이크로초" → DAX의 인메모리 캐시 유일한 달성 방법 ▸ "최소 운영 오버헤드" → DAX는 DynamoDB 통합 관리형(별도 관리 미필요) ▸ "캐싱 자동 관리" → DAX는 TTL, 무효화 자동 처리 【오답 체크】 (B) Redshift는 분석 데이터베이스, OLTP 트랜잭션 처리 미설계, 데이터 구조 전환 필요, 마이그레이션 복잡 (C) RDS는 RDBMS, DynamoDB의 NoSQL 특성(유연한 스키마, 무제한 확장) 미제공, 쿼리 방식 완전 변경 필수 (D) ElastiCache는 DAX 대비 복잡한 운영(별도 클러스터 관리, 패치, 백업), DAX보다 높은 관리 오버헤드 【시험 포인트】 ▸ DynamoDB 최적화 → DAX 전용(ElastiCache는 일반 솔루션) ▸ 마이크로초 응답 → DAX만 가능(ElastiCache는 밀리초대) ▸ 최소 관리 → DAX > ElastiCache (DynamoDB와 통합)

해설

【핵심 용어】 ▸ DynamoDB Accelerator(DAX) — DynamoDB 전용 인메모리 캐시, 마이크로초 응답, 관리형 ▸ ElastiCache(Redis) — 범용 캐시, 별도 프로비저닝 및 관리 필요 ▸ Redshift — 분석 데이터 웨어하우스, OLTP 미설계, 마이그레이션 필수 ▸ RDS — 관계형 데이터베이스, DynamoDB 비NoSQL 특성 미제공 【정답 포인트】 ▸ "DynamoDB 응답 시간 개선" → DAX가 DynamoDB 전용 최적화 제공 ▸ "밀리초 → 마이크로초" → DAX의 인메모리 캐시 유일한 달성 방법 ▸ "최소 운영 오버헤드" → DAX는 DynamoDB 통합 관리형(별도 관리 미필요) ▸ "캐싱 자동 관리" → DAX는 TTL, 무효화 자동 처리 【오답 체크】 (B) Redshift는 분석 데이터베이스, OLTP 트랜잭션 처리 미설계, 데이터 구조 전환 필요, 마이그레이션 복잡 (C) RDS는 RDBMS, DynamoDB의 NoSQL 특성(유연한 스키마, 무제한 확장) 미제공, 쿼리 방식 완전 변경 필수 (D) ElastiCache는 DAX 대비 복잡한 운영(별도 클러스터 관리, 패치, 백업), DAX보다 높은 관리 오버헤드 【시험 포인트】 ▸ DynamoDB 최적화 → DAX 전용(ElastiCache는 일반 솔루션) ▸ 마이크로초 응답 → DAX만 가능(ElastiCache는 밀리초대) ▸ 최소 관리 → DAX > ElastiCache (DynamoDB와 통합)

해설

【핵심 용어】 ▸ 클러스터 배치 그룹(Cluster Placement Group) — 극저지연(서브 밀리초) 네트워킹, HPC 최적화, 같은 AZ 배치 ▸ 파티션 배치 그룹(Partition Placement Group) — 확장성 중심, 지연 시간 미최적화, 다중 AZ 가능 ▸ Amazon FSx for NetApp ONTAP — 다중 프로토콜(NFS+SMB), HPC 워크로드 지원, HA 통합 ▸ Amazon FSx for Lustre — HPC 성능 최적화, NFS만 지원, SMB 미지원 ▸ Amazon FSx for OpenZFS — 범용 파일 시스템, HPC 미최적화, 높은 지연 【정답 포인트】 ▸ "가장 짧은 대기 시간" → (A) 클러스터 배치 그룹 필수(극저지연 네트워킹) ▸ "HPC 워크로드" → 클러스터 배치가 HPC 전용 아키텍처 제공 ▸ "NFS+SMB 다중 프로토콜" → (E) NetApp ONTAP 유일한 지원(Lustre는 NFS만) ▸ "파일 시스템 지원" → NetApp ONTAP이 HPC + 다중 프로토콜 조합 충족 【오답 체크】 (B) 파티션 배치는 지연 시간 최적화 아님, 리소스 격리 목적(확장성 중심), HPC 요구 미충족 (C) FSx for Lustre는 NFS만 지원, SMB 프로토콜 완전 미지원(온프레미스 호환성 깨짐) (D) OpenZFS는 범용 파일 시스템, HPC 최적화 미부재, 지연 시간 성능 낮음 【시험 포인트】 ▸ HPC + 저지연 조합 → 클러스터 배치 반드시 필요 ▸ 다중 프로토콜 요구 → NetApp ONTAP만 완전 지원 ▸ "2개 선택" 함정 → 배치 + FSx 종류 조합 신중히 선택

해설

【핵심 용어】 ▸ AWS CloudTrail — 모든 AWS API 호출 감시, 리소스 생성 이벤트 캡처, 사용자 정보 포함 ▸ Amazon EventBridge — CloudTrail 이벤트 실시간 감지, 규칙 기반 자동 트리거 ▸ AWS Lambda — 서버리스 함수, RDS 데이터베이스 조회, 동적 태그 적용 기능 ▸ Service Control Policy(SCP) — 사전 방지 정책, 리소스 생성 전 차단(사후 태그 불가) ▸ 휴지통(Recycle Bin) — 삭제 후 복원 기능, 즉각적 보호 미제공 【정답 포인트】 ▸ "실시간 자동 태그" → CloudTrail 이벤트 감지 + EventBridge 즉시 트리거 필수 ▸ "동적 비용 센터 조회" → Lambda가 RDS 데이터베이스에서 생성자의 비용 센터 ID 실시간 검색 ▸ "모든 리소스 대상" → CloudTrail이 모든 AWS API 호출 캡처(광범위 커버) ▸ "최소 관리 오버헤드" → Lambda + EventBridge는 서버리스 자동화(추가 인프라 미필요) 【오답 체크】 (A) SCP는 리소스 생성을 사전 방지만 가능(거부), 기존 리소스 태그 지정 미지원, 정책 기반 차단이 아닌 동적 태그 필요 (C) 예약 규칙(Scheduled Rule)은 정기적 주기 실행만 가능(예: 1시간마다), 리소스 생성 직후 즉시 처리 불가능, 태그 지연 발생 (D) 기본값 태그는 고정 값만 적용 가능, RDS에서 조회한 "사용자별 비용 센터" 동적 매핑 불가능 【시험 포인트】 ▸ "사용자 정보 매핑" → CloudTrail의 사용자 정보 + RDS 조회 결합 필수 ▸ "실시간 처리" → EventBridge 규칙(예약 아님), 이벤트 기반 트리거 ▸ "동적 조회" → Lambda 함수에서 RDS 데이터베이스 접근 필수

해설

【핵심 용어】 ▸ EBS 스냅샷 락(Snapshot Lock) — 스냅샷 삭제 영구 차단, Root 권한도 무시하는 강제 보호 ▸ IAM 정책 거부(Deny Policy) — 사용자 권한 제한으로 삭제 차단(근본적 방지 미약) ▸ 휴지통(Recycle Bin) — 삭제 후 일정 기간 보관, 삭제 가능 시간 존재(완벽한 보호 미제공) ▸ 최소 권한 원칙 — 기존 관리 권한 유지하면서 보호 구현 【정답 포인트】 ▸ "스냅샷 삭제 방지" → EBS 스냅샷 락이 유일한 강제 메커니즘 ▸ "관리 권한을 변경해서는 안 됨" → 스냅샷 락은 IAM 변경 미필요(사용자 권한 유지) ▸ "우발적 삭제 방지" → 지정된 IAM 권한도 무시(관리자 실수 방지) ▸ "최소 관리 노력" → 네이티브 기능으로 별도 프로세스 불필요 【오답 체크】 (A) 새 EC2 인스턴스와 IAM 역할 추가로 운영 복잡성 증가, 권한 관리 이원화, 스냅샷 생성 후 별도 보호 절차 필요 (B) IAM 거부 정책으로 사용자 권한 명시적 제한 → "관리 권한을 변경해서는 안 됨" 직접 위반 (C) 휴지통은 삭제 후 설정된 일수(예: 7일) 후 영구 삭제, 최종적으로 삭제 가능(규정 요구사항 미충족) 【시험 포인트】 ▸ "우발적 삭제 방지" → EBS 스냅샷 락이 표준 솔루션 ▸ "권한 유지" 요구사항 → IAM 정책 변경 배제(스냅샷 락으로만 해결) ▸ "규정 준수" → 매일 스냅샷 생성 → 락으로 보존 강제

해설

【핵심 용어】 ▸ AWS Lambda Edge — CloudFront 엣지 로케이션에서 실행, 콘텐츠 요청/응답 수정 ▸ CloudFront — 전역 CDN, 캐싱, DDoS 보호, 낮은 지연시간 ▸ Origin Shield — 오리진 서버 앞의 추가 캐시 계층, 캐시 미스 시 부하 감소 ▸ Web Application Firewall(WAF) — Layer 7 공격 차단, DDoS 방어 【정답 포인트】 ▸ "전역 사용자" → CloudFront의 엣지 로케이션으로 지연 시간 단축 ▸ "콘텐츠 개인화" → Lambda@Edge가 엣지에서 동적 헤더/쿠키 처리 ▸ "높은 가용성" → CloudFront의 글로벌 분산으로 부분 장애 격리 ▸ "DDoS 보호" → CloudFront는 기본적으로 DDoS 완화 제공 【오답 체크】 (A) Application Load Balancer(ALB)는 지역 기반 부하분산, 전역 지연 시간 개선 미제공 (B) API Gateway는 싱글 리전, CloudFront 없이 전역 분산 불가 (C) Global Accelerator는 TCP/UDP 최적화, HTTP 캐싱 미지원, 비용 높음 【시험 포인트】 ▸ "전역 사용자" + "지연 시간" → CloudFront 필수 ▸ "동적 콘텐츠" → Lambda@Edge로 엣지 처리 ▸ "가용성" → CloudFront의 다중 엣지 로케이션 활용

해설

【핵심 용어】 ▸ Amazon VPC(Virtual Private Cloud) — 격리된 네트워크, 보안 경계 설정 ▸ 보안 그룹(Security Group) — Stateful 방화벽, 아웃바운드 규칙도 필요 ▸ 네트워크 ACL(NACL) — Stateless 방화벽, 인/아웃바운드 명시 필수 ▸ NAT 게이트웨이 — Private 서브넷 → 인터넷 아웃바운드 트래픽 변환 【정답 포인트】 ▸ "Private 서브넷" → 인터넷 인바운드 접근 차단(자동) ▸ "아웃바운드 인터넷" → NAT 게이트웨이 필수(IP 변환) ▸ "데이터베이스 보안" → 보안 그룹으로 애플리케이션 서버만 접근 허용 ▸ "경제성" → NAT 인스턴스 대비 NAT 게이트웨이 관리형 우위 【오답 체크】 (A) VPC Endpoint는 특정 서비스(S3, DynamoDB) 액세스용, 일반 인터넷 아웃바운드 불가 (B) 보안 그룹만으로는 네트워크 격리 미완성, 라우팅 경로 미정의 (C) VPN은 온프레미스 연결용, 인터넷 아웃바운드 최적화 미제공 【시험 포인트】 ▸ "Private + 인터넷" → NAT 게이트웨이 필수 ▸ "데이터베이스 보안" → 보안 그룹의 제한적 규칙 설정 ▸ "비용 절감" → NAT 게이트웨이 사용량 모니터링

해설

【핵심 용어】 ▸ AWS DataSync — 온프레미스와 AWS 간의 대규모 데이터 전송, 검증, 압축 지원 ▸ AWS Storage Gateway — 온프레미스 애플리케이션이 AWS 스토리지를 마운트 ▸ AWS Snowball — 오프라인 물리 데이터 전송, 매우 큰 데이터용 ▸ 네트워크 최적화 — 대역폭 제한 환경에서의 효율적 전송 【정답 포인트】 ▸ "대규모 데이터" → DataSync의 병렬 전송 및 최적화 ▸ "지속적 동기화" → DataSync의 증분 전송 기능 ▸ "검증" → DataSync의 자동 체크섬 검증 ▸ "온프레미스 통합" → DataSync는 기존 인프라와 호환 【오답 체크】 (A) Storage Gateway는 마운트용, 일회성 마이그레이션에 미적합 (B) Snowball은 오프라인 전송, 지속적 동기화 불가능 (C) 직접 S3 업로드는 네트워크 최적화 미제공, 검증 기능 부족 【시험 포인트】 ▸ "온프레미스 → AWS" 대규모 → DataSync ▸ "지속적" + "동기화" → DataSync의 Sync 모드 ▸ "검증" → DataSync의 자동 무결성 확인

해설

【핵심 용어】 ▸ Amazon CloudFront — 글로벌 CDN, 캐싱, 엣지 로케이션, 낮은 지연 ▸ Origin Shield — CloudFront 뒤의 추가 캐시 계층, 오리진 부하 감소 ▸ Lambda@Edge — 엣지 로케이션 코드 실행, 콘텐츠 커스터마이제이션 ▸ 캐시 무효화(Cache Invalidation) — 특정 객체 강제 갱신 【정답 포인트】 ▸ "글로벌 사용자" → CloudFront의 엣지 로케이션으로 지연 단축 ▸ "높은 트래픽" → CloudFront 캐싱으로 오리진 부하 분산 ▸ "향상된 성능" → 지리적으로 사용자 근처 엣지에서 콘텐츠 제공 ▸ "DDoS 보호" → CloudFront의 기본 DDoS 방어 【오답 체크】 (A) API Gateway는 HTTP API 관리용, CDN 기능 미제공 (B) Application Load Balancer는 리전 기반, 글로벌 분산 불가 (C) Route 53은 DNS 라우팅, CDN 캐싱 미제공 【시험 포인트】 ▸ "글로벌" + "성능" → CloudFront 필수 ▸ "정적 콘텐츠" → CloudFront 캐싱 최적 ▸ "동적 콘텐츠" → Lambda@Edge 활용

해설

【핵심 용어】 ▸ AWS Lambda — 서버리스, 이벤트 기반 함수 실행, 자동 확장 ▸ AWS Step Functions — 복잡한 워크플로우 오케스트레이션, 상태 기반 실행 ▸ AWS SQS — 비동기 메시지 큐, 지연 처리 가능 ▸ 부분 장애 처리 — 재시도, 데드레터 큐, 로깅 【정답 포인트】 ▸ "다양한 작업" → Step Functions으로 워크플로우 정의 ▸ "조건부 분기" → Step Functions의 상태 머신으로 로직 표현 ▸ "오류 처리" → Step Functions의 Catch, Retry 지원 ▸ "장기 실행 작업" → Lambda(15분) 제한 초과 시 Step Functions 필수 【오답 체크】 (A) Lambda만으로는 장기 실행 및 복잡 로직 표현 어려움(15분 제한) (B) SQS는 메시지 큐만, 워크플로우 오케스트레이션 미제공 (C) EventBridge는 이벤트 트리거, 복잡한 조건부 실행 미지원 【시험 포인트】 ▸ "여러 AWS 서비스" + "조건" → Step Functions ▸ "장기 실행" → Step Functions (Lambda 제한 초과) ▸ "오류 처리" → Step Functions의 Catch/Retry

해설

【핵심 용어】 ▸ AWS WAF(Web Application Firewall) — Layer 7 공격 차단, 규칙 기반 필터링 ▸ AWS Shield — DDoS 보호, Standard(기본, 무료) / Advanced(유료, 24/7 지원) ▸ CloudFront + WAF — 엣지에서 공격 차단, 오리진 보호 ▸ 규칙 그룹 — AWS 관리형 규칙, 커스텀 규칙 【정답 포인트】 ▸ "웹 애플리케이션 공격" → WAF의 HTTP/HTTPS 분석 ▸ "SQL Injection, XSS" → WAF의 패턴 매칭 차단 ▸ "DDoS" → Shield Standard + WAF 조합 ▸ "CloudFront 통합" → 엣지에서 공격 조기 차단 【오답 체크】 (A) Security Groups는 네트워크 레벨(Layer 4), 애플리케이션 공격 미차단 (B) NACLs는 IP/포트 레벨, HTTP 페이로드 검사 미제공 (C) AWS Shield Standard는 기본 DDoS만, 애플리케이션 공격 미차단 【시험 포인트】 ▸ "웹" 공격 → WAF (Layer 7) ▸ "SQL Injection 등" → WAF의 관리형 규칙 ▸ "CloudFront + WAF" → 글로벌 보호

해설

【핵심 용어】 ▸ Amazon Route 53 — DNS 서비스, 가용성 높음, 정책 기반 라우팅 ▸ Health Check — 엔드포인트 상태 감시, 자동 장애조치 ▸ 가중 라우팅(Weighted Routing) — 트래픽 분배 비율 제어 ▸ 지연시간 기반 라우팅(Latency-based Routing) — 사용자 근처 리전으로 라우팅 【정답 포인트】 ▸ "고가용성 DNS" → Route 53의 다중 네임서버 ▸ "자동 장애조치" → Health Check + Failover Routing ▸ "글로벌 분산" → 지연시간 기반 라우팅으로 성능 최적화 ▸ "트래픽 제어" → 가중 라우팅으로 세밀한 분배 【오답 체크】 (A) Application Load Balancer는 리전 내 부하분산, 글로벌 DNS 미제공 (B) CloudFront는 CDN, DNS 서비스 아님 (C) VPC는 네트워킹, DNS 관리 미제공 【시험 포인트】 ▸ "글로벌 애플리케이션" → Route 53 필수 ▸ "자동 장애조치" → Health Check + Failover ▸ "성능 최적화" → 지연시간 기반 라우팅

해설

【핵심 용어】 ▸ AWS CloudFormation — Infrastructure as Code(IaC), 템플릿 기반 자동화 ▸ 스택(Stack) — CloudFormation의 리소스 모음, 생명주기 관리 ▸ 변경 집합(Change Set) — 스택 변경 사전 검토, 안전한 업데이트 ▸ 매개변수(Parameters) — 템플릿 재사용성, 환경별 커스터마이제이션 【정답 포인트】 ▸ "인프라 코드화" → CloudFormation 템플릿으로 정의 ▸ "버전 관리" → 템플릿을 Git에 저장, 변경 추적 ▸ "재현성" → 동일 템플릿으로 환경 동일성 보장 ▸ "자동화" → 스택 생성/업데이트/삭제 자동화 【오답 체크】 (A) AWS Systems Manager는 운영 관리용, IaC 기능 미제공 (B) AWS AppConfig는 설정 관리, 인프라 자동화 미제공 (C) 수동 리소스 생성은 오류 위험, 버전 관리 불가 【시험 포인트】 ▸ "인프라 자동화" → CloudFormation ▸ "환경 일관성" → 템플릿 재사용 ▸ "변경 관리" → Change Set으로 안전한 업데이트

해설

【핵심 용어】 ▸ AWS Lambda — 서버리스, 완전 관리형, 이벤트 기반 ▸ AWS Fargate — 컨테이너 오케스트레이션, 완전 관리형 ▸ AWS AppRunner — 컨테이너 간단 배포, 최소 설정 ▸ Auto Scaling — 부하 기반 자동 확장 【정답 포인트】 ▸ "간단한 애플리케이션" → AppRunner 또는 Lambda ▸ "컨테이너 이미지" → Fargate 또는 AppRunner ▸ "최소 운영 오버헤드" → AppRunner > Fargate (설정 최소) ▸ "자동 확장" → 모든 솔루션 지원 【오답 체크】 (A) EC2는 자체 관리(패치, 보안), 운영 오버헤드 높음 (B) ECS(Elastic Container Service)는 Fargate보다 복잡한 설정 필요 (C) On-Premises는 클라우드 이점 상실 【시험 포인트】 ▸ "간단" + "관리형" → AppRunner 또는 Lambda ▸ "컨테이너" + "최소 설정" → AppRunner ▸ "서버리스 함수" → Lambda

해설

【핵심 용어】 ▸ NLB (Network Load Balancer) — 4계층 로드 밸런서, UDP 지원, 극저지연(마이크로초 단위), 초당 수백만 패킷 처리 ▸ ALB (Application Load Balancer) — 7계층, HTTP/HTTPS 최적화, UDP 미지원 ▸ GLB (Gateway Load Balancer) — 3계층 가상 어플라이언스 배포 용 【정답 포인트】 ▸ UDP 프로토콜 → NLB만 지원 (ALB는 TCP/HTTP 기반) ▸ "초당 수백만 건" → NLB의 극저지연·초고성능 특화 기능 ▸ 비용 효율 → 멀티 리전 불필요, 단일 리전 스케일링으로 충분 【오답 체크】 (A) ALB는 HTTP/HTTPS 애플리케이션 계층 로드 밸런싱만 가능 — UDP 미지원 (B) GLB는 타사 보안 어플라이언스(방화벽, IDS) 배포용 — 게임 서버 로드밸런싱 부적합 (D) 멀티 리전 복제는 비용 증가, 지연시간 개선 효과 없음 【시험 포인트】 ▸ UDP + 극저지연 조합 → NLB 선택 ▸ 로드 밸런서 3종 구분: ALB(L7), NLB(L4), GLB(L3 가상 어플라이언스) ▸ 함정: "가장 비용 효율적" — 멀티 리전으로 오도 가능

해설

【핵심 용어】 ▸ 최종적 일관성 (Eventual Consistency) — DynamoDB 기본값, 약간의 지연 후 모든 복제본 동기화 ▸ 강력한 일관성 (Strong Consistency) — 읽기 직후 최신 쓰기 데이터 보장, 약간의 성능 비용 ▸ 읽기 전용 복제본 — RDS/Aurora 기능, DynamoDB에는 해당 없음 【정답 포인트】 ▸ "최신 데이터를 반환하지 않음" → 일관성 문제, 성능 문제 아님 ▸ 성능(지연시간) 양호 + 데이터 신선도 필요 → 강력한 일관성 전환 ▸ 비용: 강력한 일관성은 최종 일관성의 2배 처리량 사용 【오답 체크】 (A) DynamoDB에 읽기 전용 복제본 개념 없음 (RDS 기능) (B) GSI는 대체 쿼리 패턴용, 일관성 문제 해결 불가 (D) 최종 일관성으로 더 약화 → 문제 악화 【시험 포인트】 ▸ DynamoDB 일관성 모드: ConsistentRead 플래그 활용 ▸ "데이터 신선도 문제" 핵심: 성능 vs 일관성 트레이드오프 ▸ 함정: 읽기 전용 복제본, GSI는 다른 목적의 선택지

해설

【핵심 용어】 ▸ Resolver 아웃바운드 엔드포인트 — VPC → 온프레미스 DNS 쿼리 전달 ▸ Resolver 인바운드 엔드포인트 — 온프레미스 → VPC DNS 쿼리 수신 ▸ 프라이빗 호스팅 영역 — Route 53 내부 DNS, VPC 내 리소스용 【정답 포인트】 ▸ "VPC에서 온프레미스 서비스와 통신" → VPC가 쿼리 발신 ▸ 아웃바운드 = VPC에서 나가는 쿼리 라우팅 ▸ 해석기 규칙 = 특정 도메인을 온프레미스 DNS로 리다이렉트 【오답 체크】 (B) 인바운드 엔드포인트는 반대 방향 (온프레미스 → VPC) 해석 (C) 프라이빗 호스팅 영역은 Route 53 내부 전용, 온프레미스 통신 불가 (D) 퍼블릭 호스팅 영역은 인터넷 공개 (보안 위반, VPN 취지 무화) 【시험 포인트】 ▸ "VPC에서" 발신 → 아웃바운드 엔드포인트 ▸ Resolver 트래픽 흐름: VPC (아웃바운드) → 온프레미스 DNS ▸ 함정: 인바운드/아웃바운드 방향 혼동, 프라이빗 호스팅 영역 과선택