정답 · 해설

해설

【핵심 용어】 ▸ VPC 엔드포인트 — AWS 서비스에 대한 프라이빗 연결 (인터넷 게이트웨이 불필요) ▸ VPC 피어링 — 두 VPC 간 직접 프라이빗 네트워크 연결 ▸ NAT 게이트웨이 삭제 — 인터넷 액세스 차단 【정답 포인트】 ▸ S3 + Systems Manager 접근 → VPC 엔드포인트로 프라이빗 경로 구성 ▸ 인터넷 액세스 방지 → NAT 게이트웨이 제거 ▸ 코어 계정 패치 저장소 접근 → VPC 피어링 (계정 간 프라이빗 연결) ▸ 비용 효율성 → 모든 트래픽이 AWS 프라이빗 네트워크 내부 【오답 체크】 (A) 사용자 지정 VPN 서버 — 불필요한 복잡성, VPC 엔드포인트로 충분 (B) 프라이빗 VIF — Direct Connect 전용 (문제에 언급 없음), Transit Gateway는 여러 VPC 연결이 아닌 2개만 필요 (D) 인바운드 차단 — 패치 소스로부터 수신할 수 없음, 아웃바운드 차단이 맞음 【시험 포인트】 "인터넷 차단 + AWS 서비스 + 계정 간" → VPC 엔드포인트 + VPC 피어링 조합 NAT 게이트웨이 제거 = 인터넷 접근 완전 차단 의도

해설

【핵심 용어】 ▸ VPC 피어링 — 두 VPC 간 직접 프라이빗 연결 ▸ Transit Gateway — 중앙 허브를 통한 다중 VPC 연결 (관리 오버헤드) ▸ 지역 간 VPC 피어링 — 리전 간 피어링 가능 【정답 포인트】 ▸ "5개 VPC in us-east-2 → 1개 VPC in eu-west-1" 요구사항 → 일대다 연결 ▸ Transit Gateway는 5개 VPC 모두를 연결 → 불필요한 상호 연결 생성 ▸ 각 us-east-2 VPC → eu-west-1 VPC 피어링 → 5개의 정점 피어링 연결만 필요 ▸ us-east-2 VPC 간 통신 불필요 → 피어링 연결 수 최소화 ▸ 지역 간 피어링 요금 < Transit Gateway 요금 → 비용 효율성 【오답 체크】 (A) 단일 TGW (eu-west-1) → us-east-2 VPC 간 상호 연결 가능 (불필요) (B) 각 리전 TGW + 피어링 → Transit Gateway 비용 + 피어링 요금 (비효율) (C) 전체 메시 → 5×5=25개 피어링 관계 (과도함) 【시험 포인트】 VPC 연결 시나리오 = 연결 요구사항을 정확히 분석하여 필요 최소 경로만 구성 N:1 연결 = 각각의 포인트 피어링이 비용 효율적

해설

【핵심 용어】 ▸ Amazon SES 구성 세트 — 이메일 이벤트(전송, 바운스 등)의 로깅 설정 ▸ Kinesis Data Firehose — 스트리밍 데이터를 S3로 배치 로드 ▸ Amazon Athena — S3 데이터에 대한 SQL 쿼리 실행 【정답 포인트】 ▸ A) SES 구성 세트 + Firehose → S3에 이메일 이벤트 로깅 ▸ C) Athena → S3의 SES 로그를 SQL로 조회 (수신자, 제목, 시간 등) ▸ 데이터 흐름: SES 이벤트 → Firehose 버퍼링 → S3 저장 → Athena 쿼리 【오답 체크】 (B) CloudTrail — SES API 호출(SendEmail 등)만 기록, 실제 이메일 이벤트(전송 성공/실패)는 미포함 (D) CloudWatch Logs → 이메일 검색 최적화 아님, Athena 쿼리 불가능 (E) CloudWatch Logs에서 Athena 조회 → CloudWatch는 S3가 아니며 Athena는 S3만 지원 【시험 포인트】 SES 이벤트 로깅 + SQL 검색 → 구성 세트 + Firehose + Athena 패턴 데이터 흐름 이해 = 각 서비스의 역할 구분

해설

【핵심 용어】 ▸ AWS Trusted Advisor — 리소스 사용률 및 최적화 권고사항 제공 ▸ Trusted Advisor 저활용 인스턴스 검사 — 자동 탐지 ▸ Amazon EventBridge — Trusted Advisor 이벤트 트리거 ▸ 운영 오버헤드 최소 = 자동화된 기본 제공 솔루션 활용 【정답 포인트】 ▸ AWS Trusted Advisor는 이미 저활용 인스턴스 탐지 기능 제공 ▸ EventBridge → Trusted Advisor 이벤트 자동 캡처 ▸ Lambda → 태그 필터링 + 자동 중지 ▸ 운영 오버헤드 최소 = Trusted Advisor 내장 기능 활용 (수동 모니터링 불필요) ▸ AWS Business Support 포함 기능 【오답 체크】 (A) CloudWatch 대시보드 — 수동 모니터링, 자동 탐지 없음, 정기적 검토 필요 (B) Systems Manager 추적 → Trusted Advisor보다 복잡한 커스텀 구성 필요 (D) Lambda 일일 폴링 → 완전 커스텀 개발, 운영 오버헤드 최대 【시험 포인트】 "최소 운영 오버헤드" → AWS 내장 도구 활용 (Trusted Advisor) EventBridge + Trusted Advisor = 자동화 표준 패턴 Business Support 레벨 확인 중요

해설

【핵심 용어】 ▸ Auto Scaling 그룹 — 동적 인스턴스 크기 조정 ▸ Reserved Instances — 기본 사용량에 대한 비용 절감 ▸ Spot Instances — 간헐적 버스트에 적합 ▸ 3년 장기 워크로드 → Reserved Instances 최적 【정답 포인트】 ▸ 기본 부하 20개 인스턴스 → 최소 용량 4 (기본부하의 상당 부분은 Reserved Instances로 커버) ▸ 바쁜 시간 버스트 → Auto Scaling으로 최대 28까지 확장 ▸ Reserved Instances 4개 → 장기(3년) 기본 기금 비용 절감 ▸ Auto Scaling 8개 추가 용량 → 온디맨드 또는 Spot으로 동적 확장 ▸ NLB 유지 → 상태 비저장이므로 ALB로 변경 불필요 【오답 체크】 (A) 최소/원하는 용량 20/28 → Auto Scaling의 이점 없음, 항상 20개 이상 운영 (비효율) (B) Spot Fleet request 유형 → 유지 보장 없음, 중단 가능 (C) NLB → ALB 교체 → 불필요한 변경, 성능 향상 미미 【시험 포인트】 3년 장기 + 변동 부하 → Reserved (기본) + Auto Scaling (버스트) 비용 최적화 = 기본 부하에만 Reserved, 추가는 온디맨드 Auto Scaling 최소 용량 = Reserved 커버 범위 고려

해설

【핵심 용어】 ▸ AWS IoT Core Basic Ingest — 경량 MQTT 메시지 (비용 낮음) ▸ Kinesis Data Firehose — 자동 배치 처리 및 전달 ▸ 버퍼링 간격 900초 (15분) — 30분 내 도착 목표 충족 ▸ Lambda 변환 — Firehose 통합 데이터 보강 【정답 포인트】 ▸ Basic Ingest → 표준 MQTT 주제보다 저비용 ▸ Firehose 자동 배치 처리 → 개별 S3 PUT 호출 비용 절감 ▸ 900초 버퍼링 → 30분 내 도착 SLA 충족 ▸ Firehose → Lambda 변환 → S3 파이프라인 자동화 ▸ 관리형 서비스로 운영 오버헤드 최소 【오답 체크】 (A) 각 메시지마다 Lambda 호출 → 비용 높음 (메시지당 호출 비용) (C) Timestream → 시계열 데이터베이스 (불필요), Lambda 폴링 필요 (D) Kinesis Data Streams → 메시지 당 PUT 호출 필요 (비용 높음), 지연 발생 가능 【시험 포인트】 "5초마다 전송" + "비용 효율" → Firehose 배치 자동화 버퍼링 간격 설정 = SLA와 비용 균형 Basic Ingest + Firehose = IoT 파이프라인 표준 패턴

해설

【핵심 용어】 ▸ Gateway VPC 엔드포인트 — S3로의 프라이빗 연결 (인터넷 게이트웨이 불필요) ▸ S3 액세스 포인트 — S3 정책 제어의 중간 계층 ▸ 조건 키 (s3:DataAccessPointArn) — 액세스 포인트를 통한 요청만 허용 【정답 포인트】 ▸ A) Gateway VPC 엔드포인트 → S3 접근을 프라이빗 경로로 제한 (승인된 네트워크) ▸ E) S3 버킷 정책 + DataAccessPointArn 조건 → 액세스 포인트를 통한 요청만 허용 ▸ 조합: VPC 엔드포인트(네트워크) + 버킷 정책(권한) = 이중 제어 【오답 체크】 (B) 액세스 포인트 생성 자체 — 제어 메커니즘 아님, 정책과 함께 사용되어야 함 (C) EC2 역할 정책 — IAM 권한만 제어, "네트워크" 제한 불가능 (D) VPC 라우트 테이블 → 정책상 경로 지정 불가능, VPC 엔드포인트만으로 충분 【시험 포인트】 "승인된 네트워크 전용" → Gateway VPC 엔드포인트 + 액세스 포인트 정책 S3 액세스 제어 계층 = 액세스 포인트 + 버킷 정책 + IAM 역할 VPC 엔드포인트 = 네트워크 경로 제한, 정책 = 권한 제한

해설

【핵심 용어】 ▸ AWS Migration Evaluator — 온프레미스 인프라 분석 및 TCO 추정 전문 도구 ▸ Migration Evaluator Collector — agentless 수집 어플라이언스 ▸ Quick Insights 보고서 — TCO 및 비용 절감 분석 ▸ TCO (총 소유 비용) — 현재 vs 클라우드 비용 비교 【정답 포인트】 ▸ Migration Evaluator 전용 TCO 추정 도구 ▸ Collector로 현재 인프라 스캔 (VM 호스트, 리소스, 성능) ▸ 시나리오 구성 (마이그레이션 대상 정의) ▸ Quick Insights 보고서 → 상세 TCO 분석 ▸ 복수 워크로드(EKS + RDS) 동시 분석 가능 【오답 체크】 (B) AWS DMS — 데이터베이스 마이그레이션 도구 (TCO 추정 미흡), Pricing Calculator는 수동 입력 필요 (C) Application Migration Service — VM 마이그레이션 도구 (컨테이너/데이터베이스 미지원), TCO 보고서 없음 (D) Cloud Economics Center — 일반 프레임워크만 제공, 개인화된 TCO 추정 불가 【시험 포인트】 TCO 추정 → Migration Evaluator 유일한 정답 Collector + Quick Insights = 엔터프라이즈 TCO 분석 표준 마이그레이션 전 비용 계획 패턴

해설

【핵심 용어】 ▸ Gateway VPC 엔드포인트 — NAT 게이트웨이 비용 제거 (프라이빗 경로) ▸ 예약된 스케일링 — 사전 정의된 시간에 자동 스케일링 ▸ 예측 스케일링 — ML 기반 예측 (이벤트 예약 정보 활용 안함) 【정답 포인트】 ▸ A) Gateway VPC 엔드포인트→ NAT 게이트웨이 비용 제거 (S3 프라이빗 접근) ▸ E) 예약된 스케일링 → 이벤트 시간을 사전 알고있으므로 정확한 스케일링 (예측 스케일링보다 효율) ▸ NAT 게이트웨이 요금 절감 + 정확한 시간 기반 스케일링 = 비용 최적화 【오답 체크】 (B) Spot 인스턴스 추가 → 비용 절감 효과 있으나, 주요 비용은 NAT 게이트웨이 (C) Capacity Reservations → 예약 시간에 할당량 예약 (비용 증가), 이미 On-Demand 구매 중 (D) Transfer Acceleration → 성능 향상이지 비용 절감 아님 【시험 포인트】 NAT 게이트웨이 비용 = 처리된 GB당 요금 (높음) Gateway VPC 엔드포인트 = 무료 또는 저비용 (같은 리전) "알려진 이벤트 일정" → 예약된 스케일링 최적화 두 가지 비용 절감 원천 구분