정답 · 해설

해설

【핵심 용어】 ▸ 조직 이동 — 계정은 한 번에 하나 조직만 속함 ▸ 초대 메커니즘 — 조직 이탈 후 신규 조직에 초대 【정답 포인트】 ▸ R&D 계정이 기존 조직에서 '먼저' 떠남 ▸ 이후 새 조직에 '초대' ▸ 자동이탈 안 됨 → RemoveAccountFromOrganization API 필요 【오답 체크】 (A) 동시 양쪽 소속 — 불가능 (한 계정 = 한 조직) (C) 새로 생성 → 기존 리소스 마이그레이션 오버헤드 (D) 마스터 계정을 구성원화 — 마스터는 조직의 중심 【시험 포인트】 ▸ AWS Organizations 계정 이동 순서 — 떠남 → 초대 ▸ 계정은 동시에 여러 조직 속할 수 없음

해설

【핵심 용어】 ▸ RPO/RTO 24시간 — 느슨한 재해 복구 요구사항 ▸ 스냅샷 복사 — 저비용 비동기 백업 【정답 포인트】 ▸ 24시간 허용 → 실시간 복제 불필요 ▸ 스냅샷 자동 백업 → 추가 비용 최소 ▸ 교차 리전 복사 → 지역 장애 대비 【오답 체크】 (A) 읽기 전용 복제본 승격 — RTO 빠르지만 비용 높음 (B) DMS 복제 — 실시간 동기화로 과도한 비용 (C) S3 백업 복사 — 스냅샷 복사보다 비용 높음 【시험 포인트】 ▸ RPO/RTO 24시간 = 저비용 기반 DR 전략 ▸ SQL Server와 무관하게 스냅샷 방식이 저가

해설

【핵심 용어】 ▸ Redis — 영구 저장소 (RDB, AOF), 데이터 손실 방지 ▸ Memcached — 인메모리만, 재시작 시 데이터 소실 【정답 포인트】 ▸ 세션 데이터 손실 방지 필수 → Redis 필수 ▸ Redis 다중 AZ → 자동 페일오버 ▸ 고가용성 + 내구성 동시 충족 【오답 체크】 (A) Memcached — 재시작 시 세션 손실, 요구사항 불일치 (C) Storage Gateway — 세션 관리용 아님, 오버엔지니어링 (D) RDS — 세션처럼 빠른 접근 필요하지 않음 【시험 포인트】 ▸ Redis vs Memcached — 지속성이 핵심 차이 ▸ 세션 저장 = Redis 고정 선택

해설

【핵심 용어】 ▸ Read Replica(읽기 전용 복제본) — RDS의 읽기 트래픽 분산용 비동기 복제본 ▸ Writer(주 인스턴스) — 일일 OLTP 워크로드 처리 담당 【정답 포인트】 ▸ 읽기 워크로드 분리 → 월 1회 무거운 보고서 쿼리를 별도 인스턴스에서 실행 ▸ 주 DB 영향 없음 → 일일 업무용 성능 유지, 보고서는 독립적으로 처리 【오답 체크】 (B) 백업 복원은 초기 설정 비용 높음, 시간도 오래 걸림 + 복제본처럼 실시간 동기화 불가 (C) S3/Athena는 비용-성능 균형이 떨어짐, 한 달에 한 번이므로 복제본이 더 적절 (D) 인스턴스 업그레이드는 과도한 비용, 일일 워크로드만 있으면 충분한 용량 【시험 포인트】 ▸ 피크 vs 정상 워크로드 → 읽기 복제본으로 분리하는 것이 가장 비용 효율적 ▸ 함정 → 복제본은 읽기만 가능(쓰기는 주 인스턴스로), 이미 '읽기' 쿼리라는 점 활용

해설

【핵심 용어】 ▸ API Gateway — HTTP/REST 기반 라우팅, 서버리스 진입점 ▸ EKS 마이크로서비스 — 고객/주문 관리 등 다양한 엔드포인트 【정답 포인트】 ▸ API 기반 라우팅 → 경로별(/customers, /orders) 마이크로서비스로 자동 분배 ▸ 비용 효율성 → Ingress(ALB/NLB)보다 관리 오버헤드 적고, 서버리스 특성 【오답 체크】 (A) NLB는 극저지연·높은 처리량 필요할 때 적합, API 기반 라우팅은 약점 (B) ALB는 기능 충분하지만 Ingress 컨트롤러 별도 구성, API Gateway보다 고비용 (C) Lambda는 EKS 직접 라우팅에 부적절, 동기식 처리 제약 【시험 포인트】 ▸ 마이크로서비스 + API 기반 요청 → API Gateway 선택 트리거 ▸ 함정 → 'EKS 사용' 조건만으로 ALB 선택하는 실수, 비용 최소화 키워드 주목

해설

【핵심 용어】 ▸ Multi-AZ Replication Group — AZ 간 자동 페일오버, 데이터 복제 ▸ Shard(샤드) — Redis 클러스터 내 파티션 단위 【정답 포인트】 ▸ 노드 수준 HA → 샤드 내 여러 노드로 주/복제 구성, 자동 페일오버 ▸ 리전 수준 HA → 다중 AZ 배치로 AZ 장애 시 다른 AZ로 즉시 전환 ▸ 데이터 손실 방지 → 복제 그룹의 동기식 복제 【오답 체크】 (B) AOF는 지속성(Durability) 추가, AZ 간 고가용성 제공 안 함(단일 노드 기반) (C) 클러스터는 스케일링에 유리하지만, 문제에서는 HA 요구이고 복제 그룹으로 충분 (D) Auto Scaling은 수평 확장용, 노드/리전 수준 장애 대응 불가 【시험 포인트】 ▸ 두 계층 HA(노드+리전) → Multi-AZ Replication Group 선택 트리거 ▸ 함정 → AOF를 HA로 착각, 클러스터와 복제 그룹의 목적 구분 필요

해설

【핵심 용어】 ▸ Hibernation(최대 절전 모드) — 인스턴스 메모리 상태를 EBS에 저장, 빠른 부팅 ▸ Warm Pool(웜 풀) — 미리 초기화된 인스턴스를 대기 상태로 유지 【정답 포인트】 ▸ 부팅 시간 단축 → 최대 절전 모드로 메모리 로드 과정 생략, 즉시 재개 ▸ 테스트 효율화 → 웜 풀로 다음 실행 시 인스턴스 준비 완료 ▸ 비용-성능 → 온디맨드 인스턴스 활용, 절전 상태로 비용 절감 【오답 체크】 (A) Auto Scaling은 스케일 아웃, 부팅 시간 단축과 무관(여전히 메모리 로드 필요) (B) Spot 인스턴스는 비용이지 성능 아님, 중단 위험(테스트에 부적합) (D) 용량 예약은 가용성만 보장, 부팅 시간 단축 기능 없음 【시험 포인트】 ▸ 부팅/시작 시간 → 최대 절전 모드 (메모리 상태 복원) ▸ 함정 → 스케일링(수평 확장)으로 착각, 웜 풀과 최대 절전 모드의 조합이 핵심

해설

【핵심 용어】 ▸ Dynamic Scaling — 실시간 지표(CPU, 메모리)로 즉각 스케일 아웃 ▸ Spontaneous Traffic — 예측 불가능한 수요 변화 【정답 포인트】 ▸ 실시간 반응 → 갑작스러운 트래픽 증가를 CloudWatch 지표로 감지, 즉시 인스턴스 추가 ▸ 비용 효율성 → 과도한 사전 할당 불필요, 필요 시에만 확장 ▸ 자동화 → 수동 개입 없음, 항상 성능 유지 【오답 체크】 (A) 수동 스케일링은 반응 시간 길어짐, 갑작스러운 변화에 부적절 (B) 예측 조정은 ML 기반으로 '예측 가능한 패턴' 필요, 임의의 요일 증가는 학습 어려움 (D) 일정 조정은 고정된 시간(매일 9시 등)에만 작동, '임의의 요일' 조건 불일치 【시험 포인트】 ▸ 예측 불가능한 피크 → 동적 스케일링 (메트릭 기반) ▸ 함정 → 예측 조정의 'ML' 이름에 혹하기, 비용 효율성 키워드로 과할당 피하는 점

해설

【핵심 용어】 ▸ Aurora Serverless v2 — 자동 확장 DB, 연결 풀링 제공 ▸ Unpredictable Traffic — 예측 불가능한 변수 용량 증가 【정답 포인트】 ▸ 자동 확장 → ACU(Aurora Capacity Units)로 초 단위 자동 조정 ▸ 연결 풀링 → 데이터베이스 연결 문제 해결(RDS Proxy 기능 내장) ▸ 비용 효율성 → 사용량만큼 비용 부담, 과할당 불필요 【오답 체크】 (B) EC2 자동 크기 조정은 인스턴스 전체 업그레이드, 다운타임 발생 (C) RDS 수동 업그레이드는 예측 불가능 트래픽에 선반응 불가, 유연성 떨어짐 (D) Redshift는 OLAP(분석) 전용, OLTP 판매 이벤트 실시간 처리 부적합 【시험 포인트】 ▸ 예측 불가 + 연결 문제 → Aurora Serverless v2 (자동 확장 + 연결 풀링) ▸ 함정 → RDS 성능 개선으로 놓치기, Serverless의 ACU 기반 자동 조정이 핵심

해설

【핵심 용어】 ▸ Cold Start — Lambda 함수 초기 시작 시 발생하는 지연 ▸ Provisioned Concurrency — 미리 초기화된 Lambda 환경 유지 【정답 포인트】 ▸ Cold Start 해결 → Scheduled Action으로 근무 시작 전 미리 인스턴스 웜업 ▸ 정시성 → 매일 일정 시간(예: 8시)에 프로비저닝 동시성 증가, 직원 접근 시 즉시 대응 ▸ 비용 효율성 → 필요한 시간대만 프로비저닝, 불필요 시간은 감소 【오답 체크】 (A) 조절 한도는 요청 제한(Throttling)이지, Cold Start 지연과 무관 (C) CloudWatch 경보는 반응형(반응 후 함수 시작), 이미 지연 발생 (D) 메모리 증가는 초기화 시간 단축 조금, Cold Start 근본 해결 아님 【시험 포인트】 ▸ 매일 정시 지연 → 예약된 프로비저닝 동시성 (Scheduled Action) ▸ 함정 → 메모리/API 조절로 착각, Cold Start는 함수 환경 초기화 시간이 문제

해설

【핵심 용어】 ▸ Storage Gateway S3 File Gateway — SMB/NFS로 온프레미스 연결, S3 자동 동기화 ▸ Glue Crawler — S3의 CSV를 메타데이터 테이블로 자동 생성 ▸ Athena — Serverless SQL 쿼리 엔진, S3 데이터 직접 분석 【정답 포인트】 ▸ 온프레미스 연결 → S3 File Gateway로 SMB 공유를 S3에 동기화 ▸ 메타데이터 구성 → Glue Crawler로 CSV → 테이블 변환(자동) ▸ SQL 쿼리 → Athena로 서버리스 SQL, 비용 효율성(쿼리 데이터양 기반 결제) 【오답 체크】 (B) FSx File Gateway는 Windows/NAS 네이티브 지원, 대상(SMB)과 부합하나 E/F보다 비용 높음 (D) EMR은 클러스터 운영 오버헤드 높음, 대량 배치 처리(파일 기반 아님)에 더 적합 (E) Redshift는 DW급 성능이나, 비용 높고(항상 실행), 주기적 쿼리 요구사항 오버스펙 【시험 포인트】 ▸ SMB + S3 + SQL 쿼리 → Storage Gateway(S3 File) + Glue + Athena 조합 ▸ 함정 → EMR/Redshift 클러스터 운영 오버헤드 간과, Athena의 비용 효율성(주기 쿼리)

해설

【핵심 용어】 ▸ Outposts — AWS 서비스를 온프레미스에 배포하는 하이브리드 인프라 ▸ Customer Responsibility — 물리 인프라/보안/유지보수(운영팀) ▸ AWS Responsibility — 소프트웨어/가상화(B는 AWS 담당) 【정답 포인트】 ▸ 전력/네트워크 — 운영팀이 Outposts 랙의 안정적 전원, 네트워크 제공 (A) ▸ 물리 보안 — 온프레미스 데이터 센터이므로 출입 통제, 보안 담당 (C) ▸ 물리 유지보수 — 환경 조건 모니터링, 하드웨어 교체 등 (E) 【오답 체크】 (B) 하이퍼바이저/AWS 서비스 관리는 AWS 책임, 운영팀 아님 (D) Outposts 인프라 가용성(전원, 서버, 네트워킹)은 AWS가 제공, 운영팀은 입력 인프라만 (F) ECS 클러스터 용량은 애플리케이션 아키텍처 레벨, 운영팀 인프라 책임 외 【시험 포인트】 ▸ Outposts 책임 분담 → 물리(온프레미스)는 운영팀, 소프트웨어는 AWS ▸ 함정 → B/D/F(AWS 책임)를 운영팀으로 착각, Shared Responsibility Model 이해

해설

【핵심 용어】 ▸ NLB(Network Load Balancer) — 극저지연, 초당 백만 건 이상 요청 처리 ▸ Throughput — 초당 300만 요청(극대규모 트래픽) ▸ TCP 기반 — HTTP/HTTPS 아님, 비표준 포트 지원 【정답 포인트】 ▸ 초대규모 처리량 → NLB는 초당 300만 요청 처리 가능, ALB 대비 100배 성능 ▸ 극저지연 → NLB 100마이크로초 수준 처리, 데이터 센터 어플라이언스 성능 대응 ▸ TCP 비표준 포트 → NLB는 레이어 4(TCP/UDP), 비표준 포트 완벽 지원 【오답 체크】 (B) ALB는 HTTP/HTTPS(레이어 7), 초당 수십만 요청만 처리 가능, 성능 미달 (C) CloudFront는 콘텐츠 캐싱용, 실시간 TCP 애플리케이션 부적합, CDN 오버헤드 (D) API Gateway는 HTTP/REST, Lambda 비동기 특성상 300만 RPS 불가능 【시험 포인트】 ▸ 극저지연 + 극대규모 처리량 + TCP → NLB (Layer 4) ▸ 함정 → ALB/API Gateway는 레이어 7, 처리량 한계 간과, 비표준 포트 지원도 고려

해설

【핵심 용어】 ▸ Aurora Read Replica — RDS PostgreSQL의 비동기 읽기 복제본, Aurora 엔진 ▸ Promotion — 읽기 복제본을 독립 클러스터로 승격(최소 다운타임) 【정답 포인트】 ▸ 무다운타임 → 읽기 복제본 생성 중 원본 DB 계속 쓰기 가능 ▸ 데이터 손실 최소 → 복제본 승격 시점 직전까지 동기화 ▸ 운영 오버헤드 최소 → 자동 마이그레이션, 수동 스크립트 불필요 【오답 체크】 (A) 스냅샷 복원은 구 시점 기준, 마이그레이션 중 신규 데이터 손실 가능 (C) S3 가져오기는 초기 마이그레이션만, 진행 중 변경사항 반영 불가 (D) pg_dump는 시간 소모, 복원 과정 길어 다운타임 발생 가능 【시험 포인트】 ▸ RDS → Aurora 마이그레이션 + 무다운타임 → Aurora Read Replica + Promotion ▸ 함정 → 스냅샷으로 간단히 복원 불가(데이터 손실), 읽기 복제의 지속 동기화 가치

해설

【핵심 용어】 ▸ AWS Backup — 중앙 백업 관리, 정책 기반 자동화 ▸ 수백 개 인스턴스 — 대규모 배치 복구 요구 ▸ 최소 운영 오버헤드 — 자동화, 스케일 처리 【정답 포인트】 ▸ 중앙 집중식 관리 → 정책 1개로 모든 인스턴스 백업 ▸ 배치 복구 → API/CLI로 수백 인스턴스 동시 복구 자동화 ▸ 최소 노력 → CloudFormation 템플릿/Lambda 작성 불필요, 클릭만으로 복원 【오답 체크】 (A) CloudFormation 템플릿은 수백 인스턴스마다 작성해야 함, 유지보수 부담 큼 (B) Elastic Beanstalk는 애플리케이션 환경용, EC2 인스턴스 개별 복구에 부적합 (D) Lambda 함수 작성/유지보수는 높은 운영 오버헤드, Backup처럼 간단하지 않음 【시험 포인트】 ▸ 대규모 인스턴스 + 배치 복구 → AWS Backup (정책 기반 자동화) ▸ 함정 → EBS 스냅샷만으로 부족(인스턴스 메타데이터), Backup의 통합 복구 가치

해설

【핵심 용어】 ▸ Step Functions Distributed Map — 대규모 병렬 처리, 수천~수백만 항목 ▸ Inline Map — 소규모(<100항목), 동기식 처리 ▸ Serverless — 운영 오버헤드 제로 【정답 포인트】 ▸ 수천 개 항목 → 분산 모드의 대규모 병렬 처리(Inline은 성능 부족) ▸ 서버리스 → 인프라 관리 불필요, 스케일 자동 ▸ 운영 효율성 → 상태 머신 정의만으로 병렬화 자동 처리 【오답 체크】 (A) Inline 모드는 동기식, 몇백 항목 최대, 수천 개 처리 시 타임아웃/비효율 (C) Glue는 ETL 배치, 주문형(온디맨드) 처리보다 스케줄 기반, 서버리스 아님 (D) Lambda 다중 호출은 조율 복잡, Step Functions(상태 머신)처럼 간단하지 않음 【시험 포인트】 ▸ 대규모 병렬 + 서버리스 → Step Functions Distributed Map ▸ 함정 → Inline/Glue/Lambda 단순 병렬로 착각, Distributed Map의 대규모 처리 능력

해설

【핵심 용어】 ▸ Snowball — 물리 데이터 전송 어플라이언스, 네트워크 독립 ▸ 10PB × 6주 — 인터넷 대역폭으로 불가능(계산: 10PB ÷ 6주 ≈ 1.2Pbps 이상) ▸ 80% × 500Mbps = 400Mbps — 네트워크 용량 극히 제한적 【정답 포인트】 ▸ 물리 전송 → Snowball은 네트워크 제약 회피, 페타바이트급 빠른 이전 ▸ 6주 일정 → 인터넷 전송(수개월 소요) 불가, Snowball(배송 포함 6주 가능) ▸ 대역폭 보호 → 다른 애플리케이션 영향 제로(물리 장치 사용) 【오답 체크】 (A) DataSync는 400Mbps로도 10PB는 수개월 걸림, 6주 불가 (B) rsync 직접 전송도 동일 대역폭 제약, 6주 불가능 (C) CLI 직접 전송도 최대 400Mbps, 시간 계산상 불가능 【시험 포인트】 ▸ 페타바이트 + 제한된 대역폭 + 짧은 기간 → Snowball (물리 전송) ▸ 함정 → 네트워크 대역폭으로 계산 가능할 것처럼 보이기, 실제 시간 계산 필수

해설

【핵심 용어】 ▸ Cached Volume — 자주 사용 데이터는 로컬 캐시, 전체 데이터는 S3 저장 ▸ Stored Volume — 모든 데이터 로컬 저장(캐시 아님), 서버 크기 커짐 ▸ iSCSI 호환성 — 온프레미스 애플리케이션 변경 최소화 【정답 포인트】 ▸ 짧은 지연 시간 → 캐시된 볼륨이 자주 사용 데이터 로컬 저장 ▸ 서버 수 감축 → S3에 전체 저장하므로 온프레미스 용량 불필요 ▸ 최소 변경 → iSCSI 인터페이스 유지, 애플리케이션 코드 수정 불필요 【오답 체크】 (A) S3 File Gateway는 SMB/NFS용, iSCSI 미지원 (B) EBS는 클라우드 스토리지, iSCSI 지원 불가, 애플리케이션 변경 필요 (C) Stored Volume은 모든 데이터 로컬 저장, 온프레미스 서버 크기 여전히 커짐 【시험 포인트】 ▸ iSCSI + 로컬 캐시 + 용량 절감 → Cached Volume ▸ 함정 → Stored Volume과 Cached Volume 혼동, '자주 사용' 키워드로 캐시 필요성 파악

해설

【핵심 용어】 ▸ S3 Standard — 높은 내구성(11개 9s), 즉시 액세스 최적 ▸ S3 Standard-IA — 낮은 빈도 접근, 내구성 유지, 저장소 비용 절감 ▸ S3 Glacier — 장기 보관용, 검색 시간 길어짐 ▸ 내구성 극대화 — 단일 AZ 저장 불가 【정답 포인트】 ▸ 초기 30일 → S3 Standard(높은 내구성, 빠른 접근) ▸ 30일 후 → Standard-IA(내구성 유지, 비용 절감) ▸ 내구성 = 다중 AZ 필수 → Standard-IA는 다중 AZ, One Zone-IA는 단일 AZ 【오답 체크】 (A) Glacier는 '쉽게 사용 가능'(즉시 접근) 요구사항 미충족, 검색 시간 소모 (C) One Zone-IA는 단일 AZ 저장, 내구성 극대화 불가능(중단 위험) (D) Intelligent-Tiering은 자동 이전이지만, 추가 요금 있음, Standard-IA 단순 적용이 더 저렴 【시험 포인트】 ▸ 내구성 극대화 + 비용 효율 + 접근 패턴 → Standard → Standard-IA (다중 AZ) ▸ 함정 → Glacier의 '장기' 보관, One Zone의 단일 AZ, 내구성 극대화 조건 간과

해설

【핵심 용어】 ▸ BLOB(Binary Large Object) — 문서, 이미지 등 큰 이진 파일 ▸ 데이터베이스 팽창 → 성능 저하, 비용 증가 ▸ 분리 아키텍처 — 메타데이터(DB) ↔ 콘텐츠(S3) 【정답 포인트】 ▸ BLOB을 S3로 이동 → DB 크기 축소, 성능 향상 ▸ 메타데이터 유지 → 조회/검색은 RDS, 콘텐츠는 S3 URL로 링크 ▸ 비용 효율성 → S3는 저장소 비용 저렴, 탄력성/가용성 내장 ▸ 확장성 → 페타바이트급 콘텐츠도 S3에서 무제한 처리 【오답 체크】 (A) 마그네틱은 구형 저장소, 성능 오히려 악화, 24TB 증설 비용만 증가 (B) 인스턴스/스토리지 업그레이드는 근본 해결 아님, BLOB 크기가 계속 증가하면 반복 (D) DynamoDB는 문서 저장에 부적합(항목 크기 400KB 제한), Oracle→DynamoDB 마이그레이션 복잡 【시험 포인트】 ▸ BLOB + DB 성능 저하 → S3로 파일 분리 (메타데이터만 DB) ▸ 함정 → 인스턴스 업그레이드로 성능 개선 시도, 근본 원인(BLOB 저장)을 놓침