정답 · 해설

해설

【핵심 용어】 ▸ DynamoDB 자동 스케일링 — RCU/WCU를 트래픽 패턴에 자동으로 조정하는 기능 ▸ Lambda Throttles 1% — Lambda는 문제가 아님 ▸ DynamoDB 연관 Errors 10% — 데이터베이스 용량 부족이 실제 원인 【정답 포인트】 ▸ 메트릭 분석: Throttles(1%) + Errors(10%) + DynamoDB 호출 연관성 → DynamoDB 용량 부족 ▸ 20% 오류 요청 중 애플리케이션 로그가 "DynamoDB 호출 시 발생" 명시 → DynamoDB가 병목 ▸ 자동 스케일링으로 피크 트래픽 자동 대응 → 응답 시간 개선 【오답 체크】 (A) Lambda Throttles는 1%로 매우 낮음 → Lambda는 문제가 아님 (C) API Gateway 스로틀 제한 증가 → 문제 원인 해결 안 됨 (DynamoDB가 병목) (D) 파티션 기본 인덱스 재생성 → 용량 부족 문제 해결 안 되고 운영 오버헤드 높음 【시험 포인트】 "errors are occurring on 20% + DynamoDB call" → DynamoDB 용량 문제 "Lambda Throttles = 1%, Errors = 10%" → Lambda가 아닌 DynamoDB 스케일링 필요 오류 메트릭과 실제 병목의 연관성 파악이 핵심

해설

【핵심 용어】 ▸ Amazon EFS — POSIX 호환 공유 파일시스템, 여러 EC2 인스턴스에 동시 마운트 가능 ▸ 최소한의 아키텍처 변경 — Linux VM → EC2 인스턴스는 거의 동일한 구조 ▸ HTTP 기반 라우팅 → ALB (Application Load Balancer 사용) 【정답 포인트】 ▸ "FEWEST changes" → VM과 가장 유사한 아키텍처 = EC2 기반 ▸ 3개 VM + 공유 파일시스템 → EC2 3개 + EFS (동일한 패턴) ▸ EFS는 POSIX 호환으로 기존 애플리케이션 코드 수정 불필요 ▸ HTTP 기반 라우팅 → ALB 선택 (NLB는 L4 레이어) 【오답 체크】 (A) ECS Fargate + S3 → 객체 스토리지이므로 파일 마운트 불가능, 애플리케이션 코드 변경 필요 (C) EKS + FSx for Lustre → 고성능 컴퓨팅용(HPC), 일반 애플리케이션에 과도한 복잡성 (D) 3개 리전 배포 → 마이그레이션 복잡도 극대화, 최소 변경 원칙 위배 【시험 포인트】 "FEWEST changes" + "quickly" → 기존 구조와 가장 유사한 솔루션 Linux VM → EC2는 자연스러운 대응, EFS는 기존 파일시스템 호환 HTTP 요청 기반 라우팅 → ALB (L7) vs NLB (L4) 구분 필수

해설

【핵심 용어】 ▸ AWS Application Discovery Service — 온프레미스 서버 및 응용 프로그램 종속성을 자동으로 검색 ▸ AWS Migration Hub — 마이그레이션 추적 및 네트워크 다이어그램 생성 ▸ Application Discovery Agent — 상세한 서버/네트워크 정보 수집 【정답 포인트】 ▸ "network dependencies diagram" → Application Discovery Service 목적 ▸ "host IP addresses, hostnames, network connection information" → Agent 기반 상세 수집 필요 ▸ Migration Hub 네트워크 다이어그램 → Application Discovery Service의 표준 산출물 ▸ 권한 설정으로 다이어그램 생성 자동화 【오답 체크】 (B) Agentless Collector는 기본 서버 정보만 수집, 네트워크 종속성 상세 분석 미흡 (C) Application Migration Service는 실제 마이그레이션용으로, 검색(Discovery) 목적과 다름 (D) CSV 형식 내보내기 → 수동으로 CloudWatch 다이어그램을 만들어야 하며 비효율적 【시험 포인트】 "network dependencies diagram with details" → Application Discovery Service 선택 "collect information about network dependencies" → Agent 기반 수집이 표준 Migration Hub의 네트워크 다이어그램 기능이 핵심 → (A) 가 정확한 조합

해설

【핵심 용어】 ▸ RDS Proxy — Lambda에서 생성되는 단기 연결 폭증을 연결 풀로 해결 ▸ Aurora — MySQL 대비 높은 처리량 및 다중 복제본 지원 ▸ 연결 폭증 (Connection Spikes) — Lambda 특성상 동시 많은 연결 시도 【정답 포인트】 ▸ "many database connections during peak" → 연결 관리 문제 ▸ Lambda 함수 + RDS 조합 → 단기 연결 폭증 흔한 문제 ▸ RDS Proxy는 연결 풀링으로 백엔드 DB 연결 재사용 → 연결 부하 감소 ▸ Aurora Replica + RDS Proxy 조합 → 읽기 확장 + 연결 관리 동시 해결 【오답 체크】 (A) 자동 복제본 추가는 연결 풀 문제 해결 안 됨 (B) 핸들러 외부 연결 풀 → Lambda 특성상 컨테이너 재사용 불보장 (C) Route 53 가중치 레코드 → DNS 기반 라우팅이 연결 풀 문제 해결 안 함 【시험 포인트】 "many database connections + Lambda + peak periods" → RDS Proxy 선택 Lambda는 호출마다 새 연결을 시도하므로 Proxy를 통한 풀 관리 필수 Aurora + RDS Proxy 조합이 스케일 및 가용성 모두 해결

해설

【핵심 용어】 ▸ AWS Storage Gateway File Gateway — SMB/NFS 프로토콜을 S3에 매핑하는 게이트웨이 ▸ SMB 호환성 유지 — 기존 애플리케이션 코드 변경 불필요 ▸ S3 백엔드 — 최종 저장소가 S3이므로 API 마이그레이션 시 용이 【정답 포인트】 ▸ "continue to have access through SMB" → Storage Gateway File Gateway 선택 ▸ "migrate to S3 but maintain SMB access" → File Gateway가 유일한 솔루션 ▸ File Gateway는 온프레미스에서 SMB 파일 공유 인터페이스 제공 → S3 백엔드 ▸ 단계적 마이그레이션 가능 → 코드 재작성 시간 확보 【오답 체크】 (A) FSx for Windows → S3가 아닌 FSx에 저장되므로 요구사항 미충족 (B) S3 버킷만 생성 → SMB 접근 불가능, 애플리케이션 코드 변경 필수 (C) SMS 마이그레이션 → 온프레미스 서버 기반이므로 클라우드 마이그레이션 목표 미달 【시험 포인트】 "SMB access while migrating to S3" → Storage Gateway File Gateway 필수 "until code is rewritten to use S3 APIs" → 단계적 마이그레이션 전략 File Gateway = SMB 인터페이스 + S3 백엔드의 변환기 역할

해설

【핵심 용어】 ▸ DynamoDB 글로벌 테이블 — 다중 리전 지원, 낮은 지연 시간 읽기, 조건 쓰기 ▸ Lambda@Edge — CloudFront 에지 로케이션에서 실행되는 경량 컴퓨팅 ▸ CloudFront — 글로벌 콘텐츠 전송, 에지 기반 처리 【정답 포인트】 ▸ "최저 지연시간" → 에지 로케이션에서의 처리가 최적 ▸ DynamoDB 글로벌 테이블 + Lambda@Edge → 가장 가까운 에지에서 검증 로직 실행 ▸ CloudFront에지의 Lambda@Edge 함수가 바코드 검증 처리 → API 호출 회피 ▸ 에지 캐싱 + 글로벌 DB → 초저지연 【오답 체크】 (A) ECS 클러스터는 특정 리전에만 존재 → 원거리 사용자는 높은 지연 (B) EKS도 특정 리전 고정 → 에지 기반 처리 미흡 (C) CloudFront 함수는 읽기 전용, 쓰기 불가 → 사용된 바코드 표시 불가능 【시험 포인트】 "lowest latency" + "global users" + "write to database" → Lambda@Edge + DynamoDB 글로벌 테이블 CloudFront 함수 vs Lambda@Edge: 함수는 읽기, Lambda@Edge는 쓰기 지원 에지 로케이션 기반 처리가 결정적 요소

해설

【핵심 용어】 ▸ Origin Access (OA) 패턴 — CloudFront만 ALB에 접근 가능하도록 제한 ▸ 커스텀 헤더 검증 — 비밀 헤더로 정당한 요청 식별 ▸ WAF — ALB 레이어에서의 접근 제어 【정답 포인트】 ▸ "enhance the origin security" → CloudFront와 ALB 간 통신만 허용 ▸ Secrets Manager + Lambda 자동 로테이션 → 비밀 헤더 주기적 갱신 ▸ CloudFront 커스텀 헤더 삽입 → WAF 규칙으로 검증 ▸ WAF를 ALB에 연결 → 허가된 트래픽만 통과 【오답 체크】 (B) IP 필터만으로는 CloudFront IP 범위 고정 불가능, 보안 미흡 (C) Parameter Store는 자동 로테이션 지원하지 않거나 불완전 (D) Shield Advanced는 DDoS 방어이며, 원본 접근 제어와 무관 【시험 포인트】 "CloudFront origin security" → 정당한 CloudFront 요청만 허용 "custom header + WAF" 조합이 표준 패턴 Secrets Manager 자동 로테이션으로 보안 강화

해설

【핵심 용어】 ▸ Direct Connect Gateway — 여러 AWS 리전에 대한 단일 DX 연결 접근 ▸ 비용 효율성 — 단일 본사에서 다중 리전 연결 ▸ 인터넷 회피 — 모든 트래픽이 DX를 통해 이동 【정답 포인트】 ▸ "multiple public AWS Regions" + "no internet traffic" → Direct Connect Gateway 필수 ▸ "cost-effective" → 본사의 단일 DX 연결로 모든 리전 접근 ▸ Direct Connect Gateway는 여러 리전의 VPC와 연결 가능 ▸ 2개 DX 연결 = 고가용성 (이중화) 【오답 체크】 (A) "all AWS Regions in use" 각각에 DX 연결 → 비용 매우 높음 (B) VPC 피어링은 리전 간 스케일 불가, 중복 설정 필요 (C) 트랜짓 VPC는 복잡한 라우팅, Direct Connect Gateway가 더 간단 【시험 포인트】 "multiple regions + single headquarters" → Direct Connect Gateway Direct Connect Gateway = 리전 간 연결의 중앙 허브 2개 DX 연결 + 1개 Gateway = 높은 가용성 + 낮은 비용

해설

【핵심 용어】 ▸ AWS Elastic Disaster Recovery — VMware/Hyper-V에서 EC2로의 자동화된 재해복구 ▸ RPO 5분 — 데이터 손실 허용도 5분 ▸ 최소 운영 오버헤드 — 자동화된 장애 조치 【정답 포인트】 ▸ "Windows Server on VMware" → Elastic Disaster Recovery의 표준 사용 사례 ▸ "RPO 5분" → Elastic Disaster Recovery는 지속적 복제로 5분 충족 가능 ▸ "least operational overhead" → 자동화된 장애 조치 및 복구 ▸ "return to on-premises" → 재해 해결 후 원위치 복귀 지원 【오답 체크】 (A) DataSync + CloudFormation → 수동 인스턴스 생성, 자동화 부족 (C) Storage Gateway + Backup → 파일 시스템 기반이므로 독점 형식 데이터 접근 불가 (D) FSx + CloudFormation → 파일 게이트웨이로 FSx 마운트가 복잡하고 자동화 미흡 【시험 포인트】 "VMware + Windows + proprietary format" → Elastic Disaster Recovery 최적 "5분 RPO + 최소 오버헤드" → 완전 자동화된 솔루션 필요 DR 도구 선택: DataSync(마이그레이션) vs Elastic DR(지속 복제)

해설

【핵심 용어】 ▸ 지역 간 지연 (Cross-Region Latency) — 먼 거리의 네트워크 지연 ▸ S3 Cross-Region Replication (CRR) — 자동 비동기 복제 ▸ 로컬 S3 버킷 — 지역 내 업로드로 낮은 지연시간 【정답 포인트】 ▸ "significant lag on data arrival" → 장거리 업로드 지연이 주요 원인 ▸ 원격 리전 → 로컬 S3 업로드 → CRR로 중앙화 → 지연 최소화 ▸ sa-east-1, ap-northeast-1 각각에 로컬 S3 생성 → 최단 경로 업로드 ▸ CRR은 자동 비동기 복제 → 추가 애플리케이션 변경 불필요 【오답 체크】 (A) VPC 엔드포인트 → eu-north-1은 여전히 원격, 지연 개선 미흡 (B) Transfer Acceleration → 기존 단일 버킷의 최적화일 뿐, 장거리 기본 지연 해결 안 함 (D) Lambda 메모리 + 멀티파트 → 대역폭 개선이지 지리적 지연 해결 안 함 【시험 포인트】 "significant lag + multiple regions" → 로컬 버킷 우선 전략 CRR 사용으로 중앙 분석 데이터 유지 + 로컬 업로드 성능 향상 지역 간 지연은 물리적 거리 극복 불가, 로컬 우선 아키텍처 필수

해설

【핵심 용어】 ▸ VPC Endpoint Service — NLB를 통한 VPC 간 프라이빗 연결 ▸ 엔드포인트 수락 (Endpoint Acceptance) — 명시적 승인 메커니즘 ▸ CIDR 겹침 (CIDR Overlap) — 피어링 불가능, 엔드포인트 서비스 가능 【정답 포인트】 ▸ "CIDR blocks overlap" → 피어링 불가능, VPC 엔드포인트 서비스 필수 ▸ "authorized business unit VPCs only" → 엔드포인트 수락 메커니즘으로 제어 ▸ NLB 기반 → VPC 엔드포인트 서비스가 표준 ▸ 10개 VPC까지 확장 가능 【오답 체크】 (A) Transit Gateway는 CIDR 겹침 처리 불가능, 라우팅 복잡성 증가 (C) VPC 피어링 → CIDR 겹침 불허 (Cannot have overlapping CIDR blocks) (D) Site-to-Site VPN → 온프레미스 환경용으로 VPC 간 연결 부자연스러움 【시험 포인트】 "overlapping CIDR blocks" → VPC Endpoint Service 선택 "authorized only" → 엔드포인트 수락 승인 메커니즘 VPC 엔드포인트 서비스 = NLB + Private Link로 CIDR 겹침 해결

해설

【핵심 용어】 ▸ Amazon EKS — Kubernetes 호환 관리형 서비스 ▸ 매니페스트 호환성 — YAML 매니페스트를 그대로 적용 가능 ▸ 최소 노력 마이그레이션 → Kubernetes 구조 유지 【정답 포인트】 ▸ "manifests from on premises" → Kubernetes 양식 그대로 사용 가능한 솔루션 ▸ EKS는 표준 Kubernetes API 호환 → 매니페스트 수정 최소 ▸ ECR에 컨테이너 이미지만 복사 → 최소한의 변환 ▸ Aurora PostgreSQL → 관리형 데이터베이스로 운영 부담 감소 【오답 체크】 (A) App Runner은 YAML 매니페스트 미지원 → 코드 재작성 필요 (C) ECS는 Task Definition 필요 → 모든 매니페스트 변환 필요 (D) EC2에 자체 K8s 호스팅 → 관리 부담 극대화, 클라우드 이점 상실 【시험 포인트】 "manifests from source control" → EKS가 직접 적용 가능 Kubernetes 매니페스트 호환성이 결정적 요소 최소 노력 = 기존 배포 정의 그대로 사용

해설

【핵심 용어】 ▸ DynamoDB TTL — 자동 데이터 만료로 스토리지 비용 절감 ▸ Lambda — 서버리스 컴퓨팅, 사용 시에만 비용 발생 ▸ "no need to retain data" → 자동 삭제 메커니즘 필수 【정답 포인트】 ▸ "reduce cost of running contests" → 최소 운영 비용 구조 ▸ DynamoDB + TTL → 경쟁 종료 시 자동 데이터 삭제 → 비용 최소 ▸ Lambda 함수 → 전체 경쟁 기간 동안만 컴퓨팅 비용 발생 ▸ EC2 + ALB 운영 비용 완전 제거 【오답 체크】 (A) DAX 클러스터 운영 비용 지속 발생, ECS도 최적화 아님 (B) Redshift는 최소 비용 높음, 단시간 경쟁에 부적합 (C) ElastiCache 클러스터는 지속 운영 비용, RDS도 유지 비용 높음 【시험 포인트】 "variable length contests + no data retention" → 단기 임시 저장 DynamoDB TTL + Lambda = 최저 비용 조합 Lambda의 종량제 가격 모델이 핵심 효율성

해설

【핵심 용어】 ▸ Source/Destination Check — EC2의 기본 보안 기능으로, 자신의 IP가 아닌 트래픽 차단 ▸ 투명 프록시 — 자신의 IP가 아닌 트래픽을 중개하는 역할 ▸ EC2 기본 동작 — Source/Destination Check가 활성화되면 프록시 역할 불가 【정답 포인트】 ▸ "traffic is not being properly forwarded" → EC2가 중개 트래픽을 차단 중 ▸ 투명 프록시는 타 인스턴스의 IP 소스 트래픽을 처리 → Check 비활성화 필수 ▸ Source/Destination Check 비활성화 → 프록시가 다른 출발지 트래픽 전달 가능 ▸ AWS의 표준 프록시 배포 요구사항 【오답 체크】 (B) 보안 그룹 규칙만으로는 패킷 기반 라우팅 불가능 (C) DHCP DNS 설정 → 트래픽 포워딩과 무관 (D) 다중 ENI → 더 복잡하고 근본 해결 아님, 기본 메커니즘 무시 【시험 포인트】 "transparent proxy" + "traffic not forwarding" → Source/Destination Check EC2 투명 프록시 배포의 필수 첫 단계 라우팅 정책만으로 부족, 인스턴스 수준 설정 필요

해설

【핵심 용어】 ▸ CloudFormation Import — 기존 리소스를 CloudFormation으로 관리하도록 전환 ▸ Existing Resources — 이미 생성된 수동 VPC를 IaC 관리로 전환 ▸ 최소 노력 — 기존 구조 유지하며 관리 도구만 변경 【정답 포인트】 ▸ "manually created VPC" → 기존 VPC 그대로 유지 ▸ "manage all infrastructure in an automatic way" → CloudFormation IaC 관리 ▸ CloudFormation 콘솔의 "Import resources" 기능 사용 ▸ 기존 VPC 스냅샷 → 새로운 CloudFormation 스택으로 전환 【오답 체크】 (A) CDK는 새로운 코드 작성 필요, AWS CDK 학습곡선 높음 (B) Stack Set은 여러 계정/리전 배포용, 단일 VPC 관리에 과도함 (D) SAM CLI는 서버리스 애플리케이션용, VPC 관리와 무관 【시험 포인트】 "already created manually" → Import Existing Resources 기능 최소 노력 = 기존 VPC 유지 + CloudFormation 제어권만 획득 CloudFormation 콘솔의 직관적 import 기능이 핵심

해설

【핵심 용어】 ▸ Amazon CloudFront — 글로벌 엣지 로케이션 기반 콘텐츠 전송 ▸ S3 + CloudFront — 대용량 파일 배포의 표준 아키텍처 ▸ "improved download performance + low transfer costs" → CDN 필수 【정답 포인트】 ▸ "worldwide users" → 지역별 최적의 에지 로케이션에서 제공 ▸ "large file (5GB)" → CloudFront 캐싱으로 오리진 부하 감소 ▸ CloudFront 데이터 전송 비용 < EC2/ALB 구성 ▸ S3 + CloudFront는 글로벌 파일 배포 표준 【오답 체크】 (A) (B) EC2 + FTP → 오리진 서버 비용 지속, 글로벌 성능 낮음 (D) Requester Pays → 다운로드 사용자가 전송료 부담하므로 수용성 낮음 【시험 포인트】 "improved performance + low costs + global" → CloudFront + S3 CDN은 글로벌 대용량 파일 배포의 표준 패턴 CloudFront 캐싱으로 중복 다운로드 비용 절감

해설

【핵심 용어】 ▸ 고가용성 (HA) — 다중 가용 영역(AZ) + 중복성 ▸ Auto Scaling — 트래픽 급증에 자동 대응 ▸ Aurora Replica — 데이터베이스 가용성 향상 【정답 포인트】 ▸ (A) Auto Scaling + ALB — 높은 트래픽 처리, 가용성 향상 ▸ (C) Aurora + Replica — 단일 MySQL 가용성 문제 해결, 자동 페일오버 ▸ (F) 다른 AZ의 공용 서브넷 — 가용 영역 분산으로 AZ 장애 대응 ▸ 3가지 모두 가용성 향상의 필수 요소 【오답 체크】 (B) 추가 VPC 피어링 → 연결 성능 개선이지 애플리케이션 가용성 아님 (D) NAT 게이트웨이 → 아웃바운드 연결용, 인바운드 트래픽 성능 미흡 (E) Tomcat을 DB VPC로 이동 → 네트워크 지연 증가, 가용성 저하 【시험 포인트】 "high traffic outages" → Auto Scaling + ALB로 수평 확장 MySQL 단일 인스턴스 → Aurora로 자동 페일오버 지원 단일 가용 영역 → 다중 AZ 분산으로 가용성 극대화 3가지 선택지가 HA의 3대 요소

해설

【핵심 용어】 ▸ CloudFront 커스텀 오류 페이지 — 502 오류 발생 시 CDN에서 처리 ▸ S3 정적 호스팅 — 오류 페이지 저장 ▸ 최소 운영 오버헤드 → 자동화된 정적 솔루션 【정답 포인트】 ▸ (A) S3 정적 호스팅 + 커스텀 페이지 → 오류 페이지 저장소 ▸ (E) CloudFront 커스텀 오류 응답 → 502 오류 발생 시 자동으로 S3 페이지 표시 ▸ 2가지 조합으로 CDN 레벨에서 오류 처리 → 운영 자동화 【오답 체크】 (B) (D) Lambda 함수로 ALB 규칙 동적 수정 → 운영 복잡성 높음, 근본 원인 해결 아님 (C) Route 53 health check + DNS failover → DNS 레벨이므로 브라우저 갱신 필요, 사용자 경험 저하 【시험 포인트】 "502 Bad Gateway" + "custom error page" → CloudFront 오류 응답 설정 S3 + CloudFront 조합이 표준 패턴 최소 오버헤드 = 정적 구성, 동적 Lambda 제어 회피

해설

【핵심 용어】 ▸ 스냅샷 공유 — 크로스 계정 빠른 마이그레이션 ▸ AWS DMS — 원본 지속 운영 중 마이그레이션 【정답 포인트】 ▸ (A) 스냅샷: 계정 간 빠른 복사, 다운타임 최소화. Organizations 구성원이므로 스냅샷 공유 가능 ▸ (B) DMS: 원본 실행 중 데이터 동기화, 전환 전 검증 가능, 최소 다운타임 【오답 체크】 (C) AWS Backup: Organizations 공유 미지원, 스냅샷 공유 불가능 (D) Application Migration Service: 물리 서버용, DB에 최적화 아님 【시험 포인트】 크로스 계정 Aurora 마이그레이션 시 스냅샷(빠름) + DMS(검증)의 조합이 최소 다운타임을 보장합니다.

해설

【핵심 용어】 ▸ Transit Gateway — 중앙 허브 기반 다중 VPC 연결(망 증가에 유연) ▸ PrivateLink — 관리 VPC 서비스 노출(단방향 보안) 【정답 포인트】 ▸ (A) Transit Gateway: 50개+의 VPC를 단일 허브로 연결, VPC 증가 시 선형 확장 ▸ (C) PrivateLink + NLB: 관리 VPC의 라이선스 서비스를 고객들에게 노출, 단방향 통신 보장 【오답 체크】 (B) VPC 피어링: 50개 VPC는 1,225개 피어링 필요(O(n²)) (D) (E) VPN/피어링: 단방향 액세스 구조 미흡, 확장성 낮음 【시험 포인트】 VPC가 동적으로 증가하는 환경에서 Transit Gateway(중앙 허브) + PrivateLink(서비스 노출)가 최적 구조입니다.