정답 · 해설

해설

【핵심 용어】 ▸ Amazon Athena — Serverless SQL 쿼리 ▸ AWS Glue Data Catalog — 메타데이터 관리 ▸ S3 — 저비용 스토리지 【정답 포인트】 ▸ 비용 최소화 → Serverless Athena ▸ 간헐적 쿼리 (5PM-10PM) → 온디맨드 요금 ▸ 기존 ORC 파일 호환 → Glue Catalog ▸ EMR 클러스터 종료 가능 → 고정 비용 제거 【오답 체크】 (A) Redshift Spectrum은 클러스터 유지 필요 (C) 지속적 EMR 클러스터는 비용 높음 (D) Redshift는 데이터 로드 오버헤드 【시험 포인트】 Spot usage + Low frequency → Serverless Athena pattern

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — 리소스 생성 통제 ▸ Cost allocation tags — 비용 센터 추적 ▸ Tag Editor — 기존 리소스 태깅 【정답 포인트】 ▸ 기존 리소스 태깅 필수 → Tag Editor ▸ 비용 할당 태그 정의 → 24시간 대기 ▸ 미래 리소스 강제 → SCP로 정책 적용 ▸ 조직 전체 적용 → 중앙 관리 【오답 체크】 (A) 태그 강제 메커니즘 부재 (B) 매시간 Lambda 실행 오버헤드 높음 (D) IAM 역할은 계정별 관리 필요 【시험 포인트】 Cost visibility + Compliance → Tag Editor + SCP enforcement

해설

【핵심 용어】 ▸ AWS Direct Connect — 전용 네트워크 연결 ▸ Private VIF — 비공개 인터페이스 ▸ S3 Interface Endpoint — VPC 내 S3 접근 【정답 포인트】 ▸ A: Direct Connect (Private VIF) → 온프레미스 연결 ▸ C: Interface Endpoint → 다중 계정 S3 접근 【오답 체크】 (B) Public VIF는 인터넷 거쳐감 (비공개 아님) (D) Gateway Endpoint는 직접 연결 계정에만 유효 (E) VPC Peering은 한계: 3개 계정 확장 불가 【시험 포인트】 Multi-account + Private + No internet → Direct Connect + Interface EP

해설

【핵심 용어】 ▸ DynamoDB Auto Scaling — 자동 용량 조정 ▸ Provisioned Throughput — 고정 용량 ▸ Predictable pattern — 시간대별 트래픽 【정답 포인트】 ▸ 예측 가능한 패턴 → Auto Scaling 최적 ▸ 피크 4시간만 높음 → 나머지 시간 축소 ▸ 운영 오버헤드 최소 → 자동 조정 ▸ 비용 절감 → 불필요한 용량 제거 【오답 체크】 (A) 수동 감소는 오프피크 낮은 성능 (B) On-demand는 예측 가능한 패턴에 비효율 (D) Reserved capacity는 항상 최대값, 낭비 【시험 포인트】 Predictable + Periodic spike → DynamoDB Auto Scaling

해설

【핵심 용어】 ▸ AWS AppSync — Real-time GraphQL 서비스 ▸ WebSocket — 양방향 통신 ▸ Real-time delivery — 밀리초 단위 지연 【정답 포인트】 ▸ 실시간 댓글 필요 → WebSocket 프로토콜 ▸ 사용자 경험 개선 → Push 기반 전송 ▸ 지연 최소화 → AppSync의 자동 브로드캐스트 【오답 체크】 (A) CloudFront 캐싱은 정적 데이터만, 실시간 불가 (B) Polling 10초마다 = 10초 지연 (D) Lambda 동시성은 처리량, 지연 개선 아님 【시험 포인트】 Real-time + Low-latency → AWS AppSync + WebSocket

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — Organizations 수준에서 중앙 집중식 권한 제어 ▸ s3:AccessPointNetworkOrigin — VPC 또는 인터넷 기반 접근 구분 【정답 포인트】 Multi-account 환경에서 조직 수준의 규정 강제는 SCP가 최적입니다. 모든 계정의 제품팀이 생성하는 액세스 포인트에 일관되게 VPC 제약을 적용할 수 있습니다. s3:AccessPointNetworkOrigin 조건 키는 액세스 포인트 생성 시점에 평가되므로 SCP에서 거부 정책으로 효과적으로 작동합니다. 【오답 체크】 (A) 리소스 정책은 특정 리소스 대상으로만 작동하며, 새로운 액세스 포인트마다 설정 필요 → 운영 복잡성 증가 (C) CloudFormation StackSets로 각 계정마다 IAM 정책 배포는 관리 오버헤드가 큼 (D) 버킷 정책은 S3 버킷 수준에서만 작동하며, 액세스 포인트 생성 자체는 제어 불가 【시험 포인트】 Organizations + 중앙 규제 → SCP 선택. 리소스별 정책보다 조직 정책이 scalable하고 운영 효율적입니다.

해설

【핵심 용어】 ▸ Blue/Green 배포 — 기존(Blue) 환경과 신규(Green) 환경 간 트래픽 전환 ▸ Swap Environment URLs — Elastic Beanstalk의 내장 환경 전환 기능 【정답 포인트】 Elastic Beanstalk은 두 환경의 URL을 즉시 교환하는 "Swap Environment URLs" 기능을 제공합니다. 이는 VIP(Virtual IP)를 교환하므로 DNS 변경 없이 트래픽을 신규 환경으로 즉시 전환합니다. Blue/Green 배포의 표준 방식입니다. 【오답 체크】 (A) Route 53을 사용할 수 있지만, Elastic Beanstalk 내장 기능(URL 교환)이 더 간단하고 빠름 (C) 시작 구성 교체는 Blue/Green 전환과 무관함 (D) DNS 수동 업데이트는 TTL 지연 발생, Elastic Beanstalk 기능보다 비효율적 【시험 포인트】 Elastic Beanstalk Blue/Green → Swap Environment URLs 선택. 내장 기능이 가장 신속하고 안전합니다.

해설

【핵심 용어】 ▸ S3 이벤트 알림 → SQS — 메시지 기반 작업 큐 ▸ Auto Scaling (큐 깊이 기준) — 작업량에 따른 자동 확장 【정답 포인트】 S3 업로드 이벤트 → SQS 큐 → EC2 워커 패턴은 확장성과 안정성이 우수합니다. 이미지 처리는 stateless 작업이므로 SQS 큐 깊이 기반 Auto Scaling이 효과적입니다. 처리된 이미지를 S3 버킷에 저장하면 CloudFront 원본으로 사용 가능하며, 높은 동시성(10,000명)을 효율적으로 처리할 수 있습니다. 【오답 체크】 (A) EFS는 네트워크 파일 시스템으로 높은 동시 쓰기 처리에 부적합, CloudWatch Logs 기반 폴링은 비효율적 (B) SNS는 팬아웃 메시징이며, Pull 모델이 아닌 Push 모델 → 폴링이 복잡함 (D) 공유 EBS 볼륨은 단일 가용 영역 제약, Spot 인스턴스 적합성 낮음 【시험 포인트】 비동기 이미지 처리 → S3 + SQS + EC2 조합. 메시지 큐 깊이 기반 Auto Scaling이 표준 패턴입니다.

해설

【핵심 용어】 ▸ Aurora Global Database — 다중 리전 읽기/쓰기 지원 ▸ 쓰기 포워딩 (Write Forwarding) — 보조 리전에서 주 리전으로의 쓰기 자동 라우팅 【정답 포인트】 RDS to Aurora 전환 후 Global Database 구성이 필수입니다. 유럽(보조)과 미국(주) 모두에서 쓰기 가능하려면, 쓰기 포워딩을 통해 보조 리전의 쓰기를 자동으로 주 리전으로 라우팅해야 합니다. 이를 통해 양쪽 리전의 고객이 실시간 데이터 동기화를 경험할 수 있습니다. 【오답 체크】 (B) RDS 교차 리전 복제는 단방향(일반적으로 읽기 전용), 양방향 쓰기 미지원 (C) MySQL 논리 복제는 수동 구성 필요, 실시간 동기화 보장 부족 (D) Global Database 구성은 맞으나 RDS에서 Aurora로의 변환 과정이 복잡, (A) 의 단계별 전환이 안전 【시험 포인트】 다중 리전 양방향 쓰기 + 실시간 동기화 → Aurora Global Database + Write Forwarding. RDS에서 Aurora로의 마이그레이션 경로를 인지합니다.

해설

【핵심 용어】 ▸ AWS Transfer Family — 관리형 SFTP/FTP 서비스 ▸ VPC 엔드포인트 (인터넷 기반) — 정적 IP, 높은 가용성 【정답 포인트】 Transfer Family의 VPC 엔드포인트를 사용하면 Elastic IP를 그대로 연결하고, 내부적으로 S3를 백엔드로 사용합니다. 고객은 동일한 IP로 접속하며, 서비스는 AWS 관리형(고가용성)이 됩니다. 보안 그룹을 엔드포인트에 적용하여 기존 보안 정책을 유지합니다. 【오답 체크】 (A) 공개적으로 액세스 가능한 엔드포인트는 VPC 외부 → VPC 보안 그룹 적용 불가 (C) Fargate + NLB 구성은 복잡하고 관리 오버헤드 증가, Transfer Family보다 비효율적 (D) 다중 연결 EBS는 복잡한 동기화, Spot 인스턴스 사용 제약 → 관리 부담 증가 【시험 포인트】 관리형 SFTP + 정적 IP + S3 백엔드 → Transfer Family VPC 엔드포인트. 최소 운영 오버헤드 솔루션입니다.

해설

【핵심 용어】 ▸ Kinesis Data Firehose → S3 — 스트림 데이터 저장 ▸ AWS Batch + Spot Instances — 배치 작업 최적화, 비용 절감 【정답 포인트】 Kinesis로 데이터를 S3에 저장하고, AWS Batch를 Spot 인스턴스(온디맨드의 50-90% 할인)와 함께 사용하면 비용이 극적으로 절감됩니다. 비즈니스 중요도가 낮은 야간 처리이므로 Spot 인스턴스 중단도 허용합니다. Batch는 자동 확장과 재시도를 관리합니다. 【오답 체크】 (A) S3 저장은 좋으나, 온디맨드 인스턴스는 여전히 비쌈 (C) 3년 예약은 전체 비용 증가, Spot의 이점 무시 (D) Redshift는 고비용 분석 DB, 단순 배치 처리에 부적합 【시험 포인트】 비용 최적화 + 비중요 배치 작업 → Spot Instances + AWS Batch 조합. 최대 비용 절감입니다.

해설

【핵심 용어】 ▸ Transfer Family VPC 엔드포인트 — 각 서브넷별 정적 IP ▸ EFS 멀티 AZ — 높은 가용성 및 자동 장애 조치 【정답 포인트】 Transfer Family의 VPC 엔드포인트를 구성하면 각 AZ 서브넷에 정적 Elastic IP를 할당할 수 있어, 외부 공급업체가 고정 IP를 허용 목록에 추가할 수 있습니다. EFS 멀티 AZ 배포로 높은 가용성을 제공하며, 다운스트림 애플리케이션은 Direct Connect를 통해 EFS에 NFS로 액세스합니다. 【오답 체크】 (B) 공개 액세스 엔드포인트는 정적 IP 제어 불가 → 공급업체가 특정 IP만 허용 불가 (C) Application Migration Service는 단일 EC2 구조, 단일 실패 지점 존재 (D) Application Migration Service는 VM을 Transfer Family로 직접 마이그레이션 불가 (실제 기능 아님) 【시험 포인트】 Managed SFTP + 정적 IP (다중 AZ) + EFS → Transfer Family VPC 엔드포인트. 최소 운영 오버헤드입니다.

해설

【핵심 용어】 ▸ 서브넷 CIDR 재분할 — IPv4 주소 효율적 분배 ▸ 무중단 마이그레이션 — 기존 인스턴스 중단 없음 【정답 포인트】 10.0.0.0/23은 10.0.0.0/24 + 10.0.1.0/24로 완전히 분할됩니다. 세 AZ를 위해서는 세 개의 /25 서브넷(각 64 IP)이 필요합니다. (A) 의 방식은: AZ2만 유지하며 AZ1을 절반으로 줄인 후, 다시 원본 AZ1과 AZ2 주소 공간을 각각 절반으로 분할하여 세 AZ에 할당합니다. 기존 인스턴스는 운영 유지되며 서브넷 변경은 단계적으로 진행됩니다. 【오답 체크】 (B) AZ1 인스턴스 종료 필요 → 서비스 중단 발생 (C) 새 VPC 생성 → 온프레미스 연결 재설정 필요 → 중단 가능성 (D) 서브넷 업데이트는 일부만 되며, 주소 공간 분할이 (A) 보다 명확하지 않음 【시험 포인트】 기존 서비스 보존 + CIDR 재분할 → 단계별 마이그레이션 방식. (A) 의 신중한 재구성이 유일한 무중단 솔루션입니다.

해설

【핵심 용어】 ▸ Tag Policy — Organizations 수준의 태그 강제 ▸ SCP (Service Control Policy) — API 작업 거부 【정답 포인트】 Tag Policy는 허용된 태그 값을 정의하고, SCP는 특정 조건(프로젝트 태그 존재)에서만 CloudFormation 스택 생성을 허용합니다. 이 조합으로 조직 전체의 모든 계정에서 일관되게 프로젝트 태그를 강제합니다. 관리 계정에서 정의된 태그 정책은 모든 하위 계정에 적용됩니다. 【오답 체크】 (B) 각 OU에서 태그 정책을 생성하면 관리 복잡성 증가, 중앙 집중식 관리 불가 (C) IAM 정책은 각 사용자에게 할당 필요 → 사용자 수 증가 시 관리 부담 증대 (D) Service Catalog는 템플릿 관리 도구이며, 기존 CloudFormation 스택 강제 미지원 【시험 포인트】 Multi-account 태그 강제 → Tag Policy + SCP 조합. 최소 노력으로 조직 전체 규정 준수입니다.

해설

【핵심 용어】 ▸ 속성 기반 인스턴스 선택 — CPU/메모리 요구사항 지정 ▸ Auto Scaling 유연성 — 여러 인스턴스 타입 자동 선택 【정답 포인트】 시작 템플릿에서 특정 인스턴스 타입 대신 CPU/메모리 최소/최대값을 지정하면, AWS Auto Scaling이 가격 및 가용성을 고려하여 최적의 인스턴스 타입을 자동으로 선택합니다. 향후 새로운 인스턴스 타입이 추가되어도 자동으로 비용 효율적인 선택이 가능합니다. 【오답 체크】 (A) 여러 인스턴스 타입을 수동 나열 → 유지보수 부담 증가 (B) 특정 인스턴스 타입 선택 → 향후 변경 필요시 수동 개입 (D) 스크립트 자체가 관리 오버헤드, 정책 기반 선택보다 비효율적 【시험 포인트】 비용 최적화 + 향후 유연성 → 속성 기반 인스턴스 선택. 가장 적응형 솔루션입니다.

해설

【핵심 용어】 ▸ AWS Backup — 비용 효율적 백업 및 복구 ▸ RPO 2시간, RTO 4시간 — 상대적으로 느슨한 요구사항 【정답 포인트】 RPO 2시간, RTO 4시간은 실시간 동기화가 필수적이지 않으므로 AWS Backup으로 충분합니다. 정기적 백업(2시간 간격)으로 RPO를 충족하고, DR 활성화 시 백업에서 복구하여 RTO를 달성합니다. Global Database는 높은 비용이 필요하지만, Backup으로 동일한 요구사항을 저렴하게 충족할 수 있습니다. 【오답 체크】 (A) Global Database + CloudFront는 비용이 높으며, RPO 2시간 요구사항에는 과도한 기술 (B) DMS + EventBridge + Lambda 조합은 복잡하고 고비용, 2시간 RPO 달성 어려움 (D) Global Database는 항시 복제로 비용 증가, Backup으로 충분한 요구사항에 과도한 투자 【시험 포인트】 중간 수준의 DR 요구사항(RPO 2h, RTO 4h) → AWS Backup 선택. 비용 대비 효율이 최고입니다.

해설

【핵심 용어】 ▸ Lambda@Edge — CloudFront 엣지 로케이션에서 요청 수정 ▸ Viewer Request Trigger — 클라이언트 요청 도착 시 실행 【정답 포인트】 Lambda@Edge는 viewer 요청 시점에 쿼리 문자열을 정렬하고 소문자로 정규화하므로, 동일한 리소스에 대한 URL 캐시 키를 통일시킵니다. 예: ?name=John&age=30과 ?Age=30&Name=john은 모두 동일한 캐시 키로 변환되어 캐시 히트율을 극대화합니다. 【오답 체크】 (B) 쿼리 문자열 캐싱 비활성화 → 캐시 활용도 증가하나 기능성 손상 가능 (C) 역방향 프록시는 응답 처리이며, 요청 정규화에는 부적합 (D) 대소문자 구분이 없는 처리는 CloudFront 기본 기능 미지원 【시험 포인트】 쿼리 문자열 정규화 → Lambda@Edge viewer request. 신속하고 효율적인 캐시 개선입니다.

해설

【핵심 용어】 ▸ AWS DMS CDC — 지속적 데이터 복제 ▸ S3 대상 — 비용 효율적 스토리지 【정답 포인트】 DMS CDC는 1시간 RPO 요구사항을 충족하며, S3에 저장하면 최소 비용으로 운영할 수 있습니다. DMS는 Aurora에서 S3로 변경사항을 캡처하여 복제하므로 RPO 1시간 달성 가능합니다. Global Database보다 저렴하고, 스냅샷 기반(B, D)보다 더 빠른 복제입니다. 【오답 체크】 (A) Aurora Global Database는 높은 비용 ($$$), 실시간 동기화는 1시간 RPO보다 과도한 요구 (B) 매일 스냅샷은 RPO 1시간 미충족, 최대 24시간 RPO만 가능 (D) 1시간 백업 빈도도 복잡하고 비용 효율 낮음 【시험 포인트】 중간 수준 RPO (1h) + 비용 최소화 → DMS CDC to S3. 최적의 균형입니다.

해설

【핵심 용어】 ▸ Auto Scaling Group + ALB — stateless 애플리케이션 계층의 고가용성·수평 확장, CPU 기반 스케일 ▸ Amazon Aurora MySQL — 관리형 MySQL 호환 DB, 마이그레이션 변경 최소(기존 MySQL과 호환)로 고가용성 확보 ▸ SSM Agent AMI + Launch Template — 관리형 패치로 다운타임 없는 패치 자동화 ▸ 최소 개발 노력 — 기존 스택 재작성 없이 관리형 서비스로 전환 【정답 포인트】 ▸ "CPU 100% 정지 + 수동 패치 다운타임 + 고가용성 + 최소 개발 노력" → (D) SSM Agent 포함 새 AMI로 launch template 작성, 작은 인스턴스 ASG + ALB로 확장·이중화, CPU 기반 스케일, DB는 Aurora MySQL로 마이그레이션 ▸ MySQL → Aurora MySQL은 호환성 높아 코드 변경 최소, 관리형 패치로 다운타임 제거 【오답 체크】 (A) Lambda 재작성 + DocumentDB(MongoDB 호환) 전환은 MySQL 앱을 대규모 재아키텍처, 개발 노력 과다. (B) DynamoDB(NoSQL) 마이그레이션은 관계형 MySQL 앱을 재설계해야 해 최소 노력 요구 위반. (C) 컨테이너화 + Neptune(그래프 DB) 전환은 재아키텍처 크고 DB 모델 부적합. 【시험 포인트】 "기존 MySQL 앱 최소 변경으로 HA" → ASG+ALB + Aurora MySQL(호환 마이그레이션).

해설

【핵심 용어】 ▸ AWS Migration Hub — 마이그레이션 계획 및 추적 ▸ 데이터 탐색 (Athena) — 네트워크 통신 분석 【정답 포인트】 Migration Hub의 네트워크 그래프는 서버 간 상호작용을 시각화하고, Athena를 통해 Application Discovery Agent 수집 데이터를 쿼리하여 포트 1000 통신을 식별할 수 있습니다. 이를 통해 종속성 서버를 정확히 파악하고 이동 그룹으로 구성합니다. 【오답 체크】 (B) Application Migration Service는 테스트 인스턴스 생성/테스트이며, 종속성 발견이 아님 (C) Network Access Analyzer는 네트워크 보안 정책 검증 도구, 포트 기반 통신 검색 미지원 (D) CloudWatch 에이전트 추가 설치는 불필요 (이미 Discovery Agent 데이터 수집 중) 【시험 포인트】 종속성 식별 (포트 기반) → Migration Hub + Athena 조합. 정확한 검색 방식입니다.