정답 · 해설

해설

【핵심 용어】 ▸ 교차 리전 자동 백업: RDS의 자동 백업을 다른 리전에 자동 복제하는 기능 ▸ RDS 읽기 복제본: 비동기 복제로 만든 읽기 전용 인스턴스, 추가 리소스 비용 발생 ▸ AWS DMS: 데이터 마이그레이션 도구로 백업 목적에는 비효율적 【정답 포인트】 ▸ RDS 교차 리전 자동 백업은 가장 간단하고 자동화된 솔루션입니다. DB 인스턴스의 자동 백업이 자동으로 지정된 리전에 복제되므로, 운영 오버헤드가 최소화되고 일관된 백업을 보장합니다. 암호화도 유지됩니다. 【오답 체크】 (B) 읽기 복제본은 백업이 아닌 읽기 전용 DB로, 계속 실행되어 비용이 발생합니다. 백업 목적으로는 비효율적입니다. (C) DMS는 마이그레이션 도구이며 정기적인 백업 전략으로는 부적절하고 비용이 높습니다. (D) 암호화를 비활성화하면 보안을 훼손하며, 수동 프로세스로 자동화되지 않아 운영 부담이 증가합니다. 【시험 포인트】 ▸ RDS 자동 백업의 교차 리전 기능은 재해 복구 및 규정 준수 요구사항 충족의 기본 도구입니다. 최소 운영 개입으로 점진적 백업 및 지정 시간 복구(PITR)를 지원합니다. 암호화 상태는 원본과 동일하게 유지됩니다.

해설

【핵심 용어】 ▸ 가중치 기반 라우팅: 레코드의 가중치 비율에 따라 트래픽 분배(예: 80:20) ▸ 장애 조치 라우팅: 주 리소스 장애 시만 보조 리소스로 전환, 비율 제어 불가 ▸ 지연 시간 기반 라우팅: 클라이언트 위치 기반으로 가장 빠른 리소스 선택 【정답 포인트】 ▸ 가중치 기반 라우팅은 정확한 비율(80% vs 20%)로 트래픽을 분산하는 유일한 방법입니다. 새 버전의 점진적 배포(카나리 배포)에 최적화되어 있으며, 실시간으로 가중치 변경이 가능하여 빠른 롤백도 지원합니다. 【오답 체크】 (A) 장애 조치 정책은 주 리소스가 정상이면 항상 주 리소스로만 라우팅하므로, 비율 제어가 불가능합니다. (B) 다중값은 최대 8개 레코드를 무작위 반환하는 방식으로, 정확한 80:20 비율 보장이 어렵습니다. (C) 지연 시간 정책은 지역 기반 라우팅이므로 의도한 비율 분배를 보장하지 못합니다. 【시험 포인트】 ▸ Route 53의 가중치 기반 라우팅은 카나리 배포, A/B 테스팅, 트래픽 마이그레이션의 표준 방식입니다. 새 리소스 10% → 50% → 100%처럼 단계적 업그레이드 시나리오에서 필수 기술입니다. 가중치 합계의 상대값으로 계산됩니다.

해설

【핵심 용어】 ▸ CloudFormation 롤백: 실패한 리소스 생성으로 인한 스택 생성 중단 시 모든 생성된 리소스 자동 삭제 ▸ 스택 상태: CREATE_FAILED, ROLLBACK_IN_PROGRESS, ROLLBACK_COMPLETE 등 ▸ DisableRollback: 롤백 비활성화 옵션으로, 기본값은 롤백 활성화 【정답 포인트】 ▸ CloudFormation의 기본 동작은 일부 리소스 생성 실패 시 스택을 롤백합니다. 이미 생성된 EC2 인스턴스와 ELB는 삭제되지만, 스택 자체는 ROLLBACK_COMPLETE 상태로 유지되어 문제 원인 파악 및 템플릿 수정이 가능합니다. 【오답 체크】 (A) 스택을 롤백한 후에도 스택 삭제는 별도 명령어(delete-stack)로만 가능합니다. 자동 삭제되지 않습니다. (C) CloudFormation은 자동으로 롤백을 진행하며, 사용자 상호작용 대기하지 않습니다. (D) 기본 동작은 자동 롤백이며, 부분 성공 상태로 유지되지 않습니다. 【시험 포인트】 ▸ CloudFormation 스택 실패 시 자동 롤백은 데이터 손상과 부분 배포 상태 방지의 핵심입니다. DisableRollback=false가 기본값으로, 환경을 프로덕션 준 상태로 유지합니다. 문제 진단 후 템플릿 수정으로 재시도하면 됩니다.

해설

【핵심 용어】 ▸ EventBridge 규칙: AWS 서비스 리소스의 상태 변화를 감지하는 이벤트 기반 규칙 ▸ Cron 표현식: 시간 기반 스케줄을 정의하는 표현식(예: "cron(0 23 * * ? *)") ▸ S3 이벤트 알림: 객체 업로드/삭제 같은 S3 작업 시 트리거 【정답 포인트】 ▸ 매일 정해진 시간에 함수를 실행하는 정기 작업은 EventBridge의 스케줄 기반 규칙이 최적입니다. EC2 인스턴스 유지보수 없이 서버리스 방식으로 자동 실행되며, 초 단위의 정확한 시간 제어가 가능합니다. 추가 비용도 최소화됩니다. 【오답 체크】 (A) S3 이벤트 패턴은 버킷 데이터 변경(객체 생성/삭제)을 감지하는 방식이므로, 일정한 시간에 고정 실행되지 않습니다. (C) S3 이벤트 알림은 데이터 변경 시에만 트리거되어 "매일 말"이라는 고정 일정을 보장하지 못합니다. (D) EC2 인스턴스는 유지보수(패치, 모니터링)가 필요하고 비용이 높아 경제성이 떨어집니다. 【시험 포인트】 ▸ EventBridge 스케줄은 Lambda 정기 작업의 표준 패턴입니다. Cron/Rate 표현식으로 UTC 기준 정확한 시간 설정이 가능하며, 관리형 서비스로 가용성 99.99%를 보장합니다. 또한 실패 재시도, DLQ 설정 등 엔터프라이즈 기능을 제공합니다.

해설

【핵심 용어】 ▸ 버킷 정책: S3 버킷 전체 수준의 접근 제어(s3:GetBucket* 등) ▸ 객체 정책: 개별 객체의 접근 제어(s3:GetObject) ▸ 정적 웹사이트 호스팅: HTML, CSS, JS 같은 정적 콘텐츠 제공 기능 【정답 포인트】 ▸ S3 정적 웹사이트 호스팅에서 403 오류는 객체 읽기 권한 부족을 의미합니다. 버킷 정책에서 "s3:GetObject" 액션과 "Resource": "arn:aws:s3:::bucket-name/*" (객체 수준)을 지정하여 모든 사용자("Principal": "*")에게 객체 읽기 권한을 부여해야 합니다. 【오답 체크】 (A) 버킷 레벨 권한만으로는 실제 객체 읽기가 불가능합니다. 웹사이트 호스팅에는 객체 수준의 GetObject 권한이 필수입니다. (C) 기본 버킷 정책은 실제로 "명시적 거부"를 포함하지 않으며, 정책 추가가 우선입니다. (D) CORS는 브라우저의 Cross-Origin 요청 처리용으로 403 오류의 주요 원인이 아닙니다. 【시험 포인트】 ▸ S3 정적 호스팅은 객체 수준 퍼블릭 읽기 권한이 필수입니다. 정책 문서는 Effect: Allow + s3:GetObject + "*" Principal + arn:aws:s3:::bucket-name/* 패턴을 따릅니다. 보안상 필요시 AWS CloudFront 병합으로 IAM 기반 제한도 가능합니다.

해설

【핵심 용어】 ▸ AWS Organizations "모든 기능" 모드: 정책 제어(SCP, 태그 정책, 백업 정책 등) 활성화 필수 ▸ "통합 청구" 모드: 기본 모드로 정책 기능 미지원 ▸ 신뢰할 수 있는 액세스: 위임된 관리자가 멤버 계정 관리 권한을 가지는 메커니즘 【정답 포인트】 ▸ AWS Organizations의 태그 정책, SCP, 백업 정책 등 고급 정책 제어는 "모든 기능" 모드에서만 활성화됩니다. "통합 청구" 모드(기본)에서는 이러한 정책을 사용할 수 없습니다. Organizations 콘솔의 정책 섹션에 접근 불가 상태가 된 것입니다. 【오답 체크】 (B) 통합 청구는 기본 활성화 상태이며, 태그 정책과 무관합니다. 모든 기능 모드 활성화 후 태그 정책이 가능합니다. (C) 멤버 계정의 비용 할당 태그 설정은 Organizations 정책 활성화와 별개의 문제입니다. (D) Compute Optimizer의 신뢰할 수 있는 액세스는 부가 기능이며, Organizations 정책 활성화의 선행 조건이 아닙니다. 【시험 포인트】 ▸ AWS Organizations는 두 가지 운영 모드를 제공합니다: (1)통합 청구(기본, 정책 없음) → (2)모든 기능(SCP, 태그 정책, 백업 정책 지원). 모든 기능 활성화 후에는 역으로 되돌릴 수 없으므로 신중한 결정이 필요합니다. 거버넌스를 위해서는 필수입니다.

해설

【핵심 용어】 ▸ CloudFront 지역 제한(Geo Restriction): 국가/지역 기반 배포 차단 ▸ 원본 액세스 식별자(OAI): CloudFront → S3 간 비공개 통신 ▸ 서명된 URL: 시간 제한, IP 제한 등 조건부 액세스 제어 【정답 포인트】 ▸ CloudFront의 지역 제한(Geo Blocking) 기능은 클라이언트의 지역(CloudFront 엣지 로케이션 기반)을 감지하여 특정 국가의 접근을 즉시 차단합니다. CDN 레벨에서 처리되어 S3, 애플리케이션 로직 수정 없이 가장 효율적이며, 일괄 적용 가능합니다. 【오답 체크】 (A) S3 LocationConstraint는 버킷 생성 리전 지정용이며 클라이언트 국가 감지가 불가능합니다. (B) OAI는 CloudFront와 S3 간 접근 제어용이지, 지리적 제한과는 무관합니다. (D) 애플리케이션 레벨의 서명된 URL은 관리 부담이 크고, 응용 프로그램 로직 변경 필요로 비효율적입니다. 【시험 포인트】 ▸ CloudFront Geo Restriction은 화이트리스트(특정국만 허용) 및 블랙리스트(특정국 차단) 두 모드 지원합니다. GEOIP 데이터베이스 기반으로 엣지에서 판단되어 즉시 403 응답합니다. 라이선스 규정 준수(GDPR, CCPA 등)를 위한 필수 기능입니다.

해설

【핵심 용어】 ▸ Egress 전용 인터넷 게이트웨이(EIGW): IPv6 아웃바운드만 지원하며 인바운드 차단 ▸ ::/0: IPv6 모든 주소(0.0.0.0/0은 IPv4) ▸ NAT 게이트웨이: IPv4 전용으로 IPv6 미지원 【정답 포인트】 ▸ "인터넷에 액세스할 수 있지만 인터넷에서의 액세스는 차단"이라는 요구는 Egress 전용 인터넷 게이트웨이(EIGW)의 정확한 용도입니다. IPv6에 대해 ::/0 대상의 아웃바운드 트래픽만 허용하고 인바운드는 차단합니다. 라우팅 테이블에 "::/0 → Egress-only IGW" 규칙을 추가하면 됩니다. 【오답 체크】 (A) NAT 게이트웨이는 IPv4 전용이므로 IPv6 트래픽을 처리할 수 없습니다. (B) 표준 인터넷 게이트웨이는 양방향(인바운드+아웃바운드) 트래픽을 허용하므로 인바운드 금지 요구를 충족하지 않습니다. (C) EIGW는 IPv6 전용이므로 IPv4 대상(0.0.0.0/0)은 적절하지 않습니다. 【시험 포인트】 ▸ AWS는 IPv6 지원 확대와 함께 Egress 전용 인터넷 게이트웨이를 도입했습니다. NAT는 IPv6에 불필요(stateless 특성)하므로, "아웃바운드만 허용" 요구사항은 EIGW로만 구현됩니다. 보안 강화(역방향 스캔 방지) 및 규정 준수 목적에 활용됩니다.

해설

【핵심 용어】 ▸ Aurora 다중 마스터: 여러 마스터 노드가 동시에 쓰기 가능(짧은 지연) ▸ Aurora 단일 마스터: 1개 마스터(쓰기) + 다수 복제본(읽기) ▸ 멀티테넌트: 여러 테넌트가 동시에 데이터 쓰기 및 읽기 【정답 포인트】 ▸ "쓰기 집약적" + "멀티테넌트 워크로드"는 Aurora 다중 마스터의 최적 사용 사례입니다. 여러 노드에서 동시에 쓰기가 가능하므로 높은 쓰기 처리량을 제공하며, 각 테넌트가 독립적으로 데이터를 쓸 수 있습니다. 고가용성(99.99%)도 보장합니다. 【오답 체크】 (A) EC2 기반 읽기 복제본은 고가용성을 제공하지만, 쓰기는 여전히 마스터 1개에만 가능합니다. (B) Aurora 단일 마스터는 1개 마스터만 쓰기 가능하므로 쓰기 부하 분산이 불가능합니다. (D) RDS for MySQL은 읽기 복제본 지원이지만 동시 쓰기 확장성이 제한적입니다. 【시험 포인트】 ▸ Aurora 다중 마스터는 2021년 일부 리전에서 지원되었으나, 현재는 권장되지 않는 추세입니다. 대안으로 Aurora Global Database(비동기 다중 리전)가 권장됩니다. 시험에서는 "멀티테넌트 + 쓰기 집약적" 키워드로 다중 마스터 개념을 묻는 경향이 있습니다.

해설

【핵심 용어】 ▸ ActiveConnectionCount: ELB에서 제공하는 활성 연결 수 메트릭 ▸ mem_used: 기본 제공되지 않는 메트릭(EC2 인스턴스 메모리 사용량은 CloudWatch Agent 필요) ▸ Target Tracking Scaling Policy: 메트릭 기반 자동 스케일링 【정답 포인트】 ▸ "사용자 수 기반 스케일링"을 위한 가장 직접적인 지표는 ActiveConnectionCount입니다. ELB는 연결 상태를 실시간 추적하며 자동으로 CloudWatch 메트릭으로 제공합니다. Auto Scaling 정책에서 이 메트릭을 대상으로 설정하면 사용자 증가에 맞춰 인스턴스가 자동 추가됩니다. 【오답 체크】 (B) mem_used는 ELB에서 제공되지 않습니다. EC2 인스턴스의 메모리 사용량은 CloudWatch Agent를 별도 설치해야만 수집됩니다. (C) 예약된 스케일링은 시간 기반이므로, 실제 사용자 연결 증가에 동적으로 대응하지 못합니다. (D) 사용자 정의 메트릭은 가능하지만, 기존 ActiveConnectionCount를 사용하는 것이 더 간단하고 효율적입니다. 【시험 포인트】 ▸ ELB의 기본 메트릭(ActiveConnectionCount, RequestCount, TargetResponseTime 등)은 별도 설정 없이 CloudWatch에서 자동 수집됩니다. 이를 활용한 Target Tracking Scaling Policy는 가장 일반적인 스케일링 패턴입니다. 사용자 부하에 정비례하는 연결 수 메트릭이 스케일링 결정의 가장 신뢰할 수 있는 지표입니다.

해설

【핵심 용어】 ▸ 서브넷 CIDR: IP 주소 범위 정의(예: /28은 16개, /27은 32개) ▸ AWS 예약 IP: 각 서브넷마다 5개(네트워크, 게이트웨이, DNS, 미래용, 브로드캐스트) ▸ Elastic IP: 퍼블릭 IP 주소로 서브넷 용량과 무관 【정답 포인트】 ▸ VPC의 서브넷은 생성 후 CIDR 블록을 변경할 수 없습니다(AWS 제약). 새로운 서브넷을 생성하는 것이 유일한 방법입니다. 기존 11개 인스턴스는 유지하고, 새 인스턴스는 새 서브넷에 배포하면 됩니다. 【오답 체크】 (A) AWS에서는 생성된 서브넷의 CIDR 블록 변경을 허용하지 않습니다. VPC 재생성이 필요합니다. (B) 서브넷을 "확장"하는 기능은 없습니다. 다른 가용 영역의 새 서브넷 생성만 가능합니다. (C) Elastic IP는 서브넷 주소 공간과 무관하며, 서브넷 IP 부족 문제를 해결하지 못합니다. 【시험 포인트】 ▸ VPC 설계 단계에서 충분한 서브넷 크기를 선택하는 것이 중요합니다. 후속 CIDR 변경은 불가능하므로, 예상 인스턴스 수 이상의 크기(예: /25 → 128개 주소, 실제 120개 사용 가능)를 할당해야 합니다. 멀티 AZ 구성 시 각 AZ마다 별도 서브넷이 필요합니다.

해설

【핵심 용어】 ▸ Amazon GuardDuty: 위협 탐지 서비스로 비정상 로그인, API 사용 패턴 분석 ▸ UnauthorizedAccess 결과: 비정상 액세스 시도(여러 지역 로그인, 실패한 인증 등) ▸ Cognito: 사용자 인증/권한 관리 서비스로 감지 목적과 다름 【정답 포인트】 ▸ GuardDuty는 AWS 계정 전역에서 CloudTrail, VPC Flow Logs, DNS 로그를 분석하여 위협을 자동으로 감지합니다. "UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B" 결과는 여러 지역에서의 로그인 성공 시도(지리적 이상 감지)를 의미합니다. AWS Management Console 무단 액세스 감시에 가장 적합합니다. 【오답 체크】 (A) Cognito는 사용자 인증 관리 서비스로 손상된 자격증명 탐지는 부분적이며, CloudTrail 로그인 분석은 아닙니다. (B) Inspector는 EC2, 컨테이너 이미지의 취약점 스캔용으로, 로그인 패턴 분석 기능이 없습니다. (C) AWS Config는 리소스 구성 정렬 확인용(iam-policy-blacklisted-check)이지, 비정상 로그인 감지는 아닙니다. 【시험 포인트】 ▸ GuardDuty는 SysOps 시험의 보안/모니터링 영역 핵심 서비스입니다. 지역 기반 이상 탐지(Geolocation anomaly), IP 평판 데이터베이스 활용, 머신러닝 기반 위협 분류를 제공합니다. EventBridge와 연계하면 의심 활동 시 자동 대응(Lambda, SNS 등) 가능합니다.

해설

【핵심 용어】 ▸ ElastiCache for Redis: 고가용성(클러스터 모드, 자동 장애 조치 지원) ▸ ElastiCache for Memcached: 분산 캐싱(자동 장애 조치 미지원) ▸ RDS Multi-AZ: 데이터베이스 동기 복제로 고가용성 제공 ▸ Auto Discovery: 클라이언트가 캐시 노드 자동 감지(Memcached) 【정답 포인트】 ▸ "캐싱 + 고가용성" 요구는 (C)Redis 또는 (D)RDS Multi-AZ 조합이 답입니다. - (C) ElastiCache for Redis: Cluster Mode 활성화 시 자동 장애 조치, 다중 샤드 지원 - (D) RDS Multi-AZ: 데이터베이스 가용성 99.95% 보장 두 조합으로 캐싱 레이어와 DB 레이어 모두 고가용성 구성이 완성됩니다. 【오답 체크】 (A) Auto Discovery는 ElastiCache 캐싱 기능이지만, 고가용성과는 직접 무관합니다. (B) Memcached는 단순 캐싱 저장소로 자동 장애 조치나 영속성을 지원하지 않습니다. (E) Multi-threading은 데이터 저장소의 동시 처리 능력이지, 고가용성 기능이 아닙니다. 【시험 포인트】 ▸ ElastiCache for Redis의 고가용성 아키텍처는 (1)Cluster Mode Enabled (여러 샤드) + (2)Multi-AZ(각 샤드마다 복제본)로 구성됩니다. RDS Multi-AZ와 함께 사용하면 전체 스택(캐시+DB)의 99.99% 가용성을 달성할 수 있습니다. 두 구성은 상호 보완적입니다.

해설

【핵심 용어】 ▸ CloudTrail 로그 파일 무결성 검증: SHA-256 해시 기반 무결성 확인 ▸ 다이제스트 파일: 이전 로그 파일의 해시값 및 현재 로그 파일 체인 정보 포함 ▸ 암호화: 기밀성 보호(무결성 검증 아님) ▸ CloudWatch Logs 스트리밍: 이중 저장(무결성 보증 아님) 【정답 포인트】 ▸ CloudTrail의 로그 파일 무결성 검증(Log File Integrity Validation)은 암호화 해시 체인으로 파일 변조를 탐지합니다. 설정 후 CloudTrail이 다이제스트 파일(digest files)을 생성하며, 이 파일들은 다이제스트 공개키로 서명됩니다. 관리자는 다이제스트 파일로 로그 파일의 SHA-256 해시값을 검증하여 변조 여부를 즉시 확인할 수 있습니다. 【오답 체크】 (A) CloudWatch Logs 스트리밍은 이중 저장 방식이지만, 원본 파일 무결성을 보장하지 못합니다. (C) 지역 복제와 암호화는 가용성과 기밀성을 높이지만, 파일 변조 탐지와는 무관합니다. (D) S3 서버 액세스 로깅은 S3에 대한 요청 기록이므로, CloudTrail 로그 파일 변조 감지와는 다릅니다. 【시험 포인트】 ▸ CloudTrail 로그 파일 무결성 검증은 규정 준수(HIPAA, PCI-DSS, SOC 2) 요구사항의 필수 기능입니다. 다이제스트 파일의 해시 체인 구조로 "한 파일 변조 = 모든 후속 다이제스트 해시 변경"을 보장합니다. CLI(aws cloudtrail validate-logs)로 자동 검증도 가능합니다.

해설

【핵심 용어】 ▸ 원본 액세스 식별자(OAI): CloudFront 전용 AWS 계정으로 S3 원본에만 액세스 ▸ 서버 측 암호화: 데이터 기밀성 보호(액세스 제어 아님) ▸ CloudFront 배포에 IAM 역할/사용자 할당: 지원되지 않는 기능 【정답 포인트】 ▸ CloudFront의 원본 액세스 식별자(OAI)는 CloudFront 전용 특수 AWS 계정입니다. S3 버킷 정책에서 OAI만 GetObject 권한을 허용하고 다른 모든 주체를 거부하면, CloudFront를 통한 요청만 S3에 도달하고 직접 요청은 403으로 차단됩니다. 【오답 체크】 (A) SSE-S3 암호화는 데이터 저장 기밀성만 보호하며, 퍼블릭 S3 액세스를 제한하지 못합니다. (C) CloudFront 배포에 IAM 사용자를 할당하는 것은 지원되지 않는 구성입니다. (D) CloudFront 배포에 IAM 역할을 할당하는 것도 일반적이지 않으며, OAI 방식이 표준입니다. 【시험 포인트】 ▸ OAI는 "CloudFront 배포만 S3 원본에 액세스" 패턴의 표준 구현입니다. (1)OAI 생성 → (2)CloudFront 배포 연결 → (3)S3 버킷 정책에서 OAI:GetObject 허용 → (4)모든 Principal:Deny 적용 순서로 진행합니다. 최신 대체 기능인 "CloudFront Origin Access Control(OAC)"은 서명 기반으로 더 보안성 있습니다.

해설

【핵심 용어】 ▸ 라이트사이징: 실제 사용량 기반 더 작은 인스턴스 유형으로 변경(예: m5.large → t3.medium) ▸ "Low Utilization": CPU/메모리 사용량이 낮은 인스턴스(비용 낭비) ▸ 가용성 요구: 3개 AZ 구성 유지 필수 【정답 포인트】 ▸ Trusted Advisor의 "Low Utilization" 경고는 현재 인스턴스 크기가 실제 워크로드보다 과다하다는 의미입니다. AWS Cost Explorer의 라이트사이징 권장사항은 CloudWatch 메트릭(CPU, 네트워크) 분석으로 필요한 인스턴스 타입을 제안합니다. 더 작은(저렴한) 인스턴스로 변경하면 비용은 절감하면서 3개 AZ 구성과 가용성은 그대로 유지됩니다. 【오답 체크】 (A) 서버 수를 줄이면 각 AZ당 1개씩만 남아 가용성 저하(단일 장애점 발생)의 위험이 있습니다. (C) Application Load Balancer는 트래픽 분산 도구로, 낮은 사용률 문제 해결과 무관합니다. (D) 인스턴스 확대는 비용을 증가시키는 역방향이며, Trusted Advisor 경고 목적과 상충합니다. 【시험 포인트】 ▸ AWS Cost Explorer와 Trusted Advisor는 비용 최적화의 두 주요 도구입니다. 라이트사이징은 "오른쪽 크기(Right Sizing)"라고도 하며, 인스턴스 성능 저하 없이 호스팅 비용을 최대 70%까지 절감할 수 있습니다. 정기적 라이트사이징은 FinOps 모범 사례입니다.

해설

【핵심 용어】 ▸ 지리적 위치 라우팅(Geolocation): 클라이언트의 지역 위치 기반 라우팅(유럽 → eu-central, 기타 → us-east) ▸ 지리적 근접 라우팅(Geoproximity): 리소스와의 물리적 거리 및 편향값 기반 ▸ 지연 시간 라우팅: 클라이언트에서 각 리소스까지의 응답 시간 비교 【정답 포인트】 ▸ "유럽 지역의 사용자만 eu-central 사용"이라는 요구는 지리적 위치 라우팅(Geolocation)의 정확한 용례입니다. 국가/대륙 단위로 명확하게 트래픽을 분기하므로, "유럽 → eu-central", "기타 → us-east" 규칙을 정확히 구현할 수 있습니다. 【오답 체크】 (B) Geoproximity는 편향값(bias) 사용으로 유연한 분기가 가능하지만, "유럽만" 정확한 제어에는 geolocation이 더 직관적입니다. (C) Latency 기반은 지역이 아닌 응답 시간으로 판단하므로, 지리적 제약(라이선스 등)을 보장하지 못합니다. (D) Multivalue는 최대 8개 리소스를 무작위 반환하는 방식으로, 특정 지역 전용 라우팅에 부적절합니다. 【시험 포인트】 ▸ Route 53 지리적 위치 라우팅은 규제 준수(GDPR, 라이선스), 지역별 서비스 제약 등을 위한 핵심 도구입니다. CloudFront 지역 제한과 함께 사용하면 웹 콘텐츠(엣지) + DNS(Route 53) 이중 제어로 지역 제한을 강화합니다. "Location"은 국가(CN, DE) 코드로 지정됩니다.

해설

【핵심 용어】 ▸ SAML(Security Assertion Markup Language): 엔터프라이즈 SSO 인증 표준 ▸ IAM Federation: 외부 자격증명 공급자와의 통합 ▸ LDAP: Lightweight Directory Access Protocol 기반 디렉토리 서비스 【정답 포인트】 ▸ SAML 기반 페더레이션은 기존 LDAP 자격증명을 AWS와 통합하는 표준 방식입니다. ▸ LDAP 그룹 멤버십을 기반으로 서로 다른 IAM 역할을 매핑하면 세분화된 권한 제어가 가능합니다. ▸ 이 방식은 LDAP 사용자가 AWS 자격증명 없이 기존 LDAP 암호로 AWS 리소스에 액세스할 수 있습니다. 【오답 체크】 (A) Simple AD는 온프레미스 LDAP과 동기화되지 않으며, AWS Directory Service는 페더레이션 목적에 최적화되지 않습니다. 60자 (B) Lambda 기반 자동화는 관리 오버헤드가 크고, 동적 사용자 관리보다는 일회성 마이그레이션에 적합합니다. 65자 (C) CloudFormation은 스태틱 역할만 생성하고, Direct Connect는 네트워크 연결이지 인증 메커니즘이 아닙니다. 70자 【시험 포인트】 ▸ SAML 페더레이션은 엔터프라이즈 환경에서 대규모 사용자 관리를 위한 권장 방식입니다. ▸ IAM 역할 기반 액세스 제어(RBAC)와 LDAP 그룹 멤버십 기반 매핑이 결합될 때 최고의 보안과 운영 효율성을 제공합니다. ▸ SOA 시험에서는 IAM Federation, SAML, LDAP 통합 같은 엔터프라이즈 인증 시나리오를 자주 다룹니다.

해설

【핵심 용어】 ▸ AMI(Amazon Machine Image): 특정 리전에서만 사용 가능한 지역 리소스 ▸ CloudFormation Template Portability: 템플릿을 여러 리전에서 실행하기 위한 고려사항 ▸ Region-specific Resources: 리전마다 다른 리소스 ID를 가지는 AWS 리소스 【정답 포인트】 ▸ AMI ID는 각 리전에 고유하며, 한 리전의 AMI ID를 다른 리전에서 사용할 수 없습니다. ▸ CloudFormation 템플릿이 하드코딩된 AMI ID를 참조할 경우, 다른 리전에서 해당 AMI가 존재하지 않아 배포가 실패합니다. ▸ 리전 간 템플릿 재사용을 위해서는 Mappings 섹션에서 리전별 AMI ID를 정의해야 합니다. 【오답 체크】 (A) 태그는 CloudFormation 배포에 영향을 주지 않으며, 메타데이터 목적으로만 사용됩니다. 70자 (C) cfn-init의 실행 여부는 템플릿 구문 오류가 아니라, 메타데이터 지정 문제입니다. 70자 (D) IAM 사용자는 글로벌 리소스로 모든 리전에서 사용 가능하며, 리전별로 생성될 필요가 없습니다. 72자 【시험 포인트】 ▸ CloudFormation을 여러 리전에서 사용할 때 리전별로 다른 리소스(AMI, VPC, 보안 그룹)를 고려해야 합니다. ▸ 템플릿의 Mappings 섹션을 활용하여 리전별 설정을 파라미터화하는 것이 모범 사례입니다. ▸ 템플릿 재사용성을 높이려면 하드코딩된 리전 특정 리소스 ID를 피해야 합니다.

해설

【핵심 용어】 ▸ Route 53 Geoproximity Routing: 사용자의 지리적 위치에 기반한 라우팅 ▸ Health Checks: CloudWatch 알람 기반 상태 확인으로 자동 장애 조치 구현 ▸ Weighted/Failover Routing: 여러 엔드포인트 간 트래픽 분배 및 자동 장애 조치 【정답 포인트】 ▸ (A) CloudWatch 알람을 기반으로 Route 53 상태 확인을 구성하면, ALB가 비정상일 때 자동으로 다른 리전으로 장애 조치됩니다. ▸ (D) 지리 근접성 라우팅은 사용자에게 가장 가까운 리전으로 트래픽을 자동 지도합니다. ▸ 이 두 옵션의 조합으로 지역 최적화와 자동 장애 조치 요구사항을 모두 충족합니다. 【오답 체크】 (B) EC2 인스턴스 상태 모니터링은 ALB 상태 모니터링보다 정확성이 낮습니다. 70자 (C) 프라이빗 IP 주소는 인터넷에서 접근할 수 없어 Route 53 상태 확인에 사용될 수 없습니다. 72자 (E) 단순 라우팅은 자동 장애 조치를 지원하지 않으며, 대륙/국가 지정만 가능합니다. 75자 【시험 포인트】 ▸ Route 53 라우팅 정책 선택은 비즈니스 요구사항(지역 최적화, 자동 장애 조치)에 따라 달라집니다. ▸ 다중 리전 배포에서는 ALB 또는 ELB 상태 확인이 EC2 인스턴스 개별 상태 확인보다 권장됩니다. ▸ CloudWatch 알람과 Route 53의 통합은 프로액티브 장애 조치를 가능하게 합니다.