정답 · 해설

해설

【핵심 용어】 ▸ S3 복제: 원본 버킷의 객체를 다른 버킷으로 자동 복제 ▸ 교차 계정 복제: 서로 다른 AWS 계정 간의 데이터 복제 ▸ 운영 효율성: 최소한의 관리와 자동화 【정답 포인트】 ▸ S3 복제 규칙은 원본 버킷에 설정되며, 규칙 생성 후 모든 새 객체가 자동으로 대상 버킷으로 복제됩니다. 교차 계정 시나리오에서는 대상 버킷 소유자가 원본 계정의 S3 서비스가 복제할 수 있도록 버킷 정책을 설정해야 합니다. 기존 데이터는 수동으로 복사하고(이미 완료됨), 이후의 모든 새 데이터는 자동으로 복제됩니다. 이는 가장 운영 효율적이며 관리 부담이 적습니다. 【오답 체크】 ▸ (B) EventBridge와 Batch 조합은 복제 규칙보다 복잡하고 관리 부담이 큽니다. ▸ (C) S3 이벤트 알림과 Lambda는 커스텀 로직이 필요하며, 실패 처리와 재시도가 복잡합니다. ▸ (D) EC2 인스턴스 스크립트는 인스턴스 운영, 유지보수, 중단 시 처리가 필요합니다. 【시험 포인트】 ▸ S3 복제는 데이터 보호 전략의 핵심입니다. SOA 시험에서는 S3 복제 규칙의 설정, 교차 계정 권한 구성, 기존 데이터 vs 새 데이터 처리를 구분하는 것이 중요합니다. AWS 관리형 서비스를 우선적으로 선택하는 아키텍처 원칙을 이해해야 합니다.

해설

【핵심 용어】 ▸ 클러스터 배치 그룹: 저 레이턴시 고 대역폭 클러스터링을 위해 인스턴스를 밀접하게 배치 ▸ 파티션 배치 그룹: 분산 애플리케이션을 위해 파티션 간 격리 ▸ 레이턴시: 네트워크 지연 시간 【정답 포인트】 ▸ HPC 애플리케이션의 최소 레이턴시와 최대 처리량 요구사항을 충족하려면 클러스터 배치 그룹이 필수입니다. 클러스터 배치 그룹은 인스턴스들을 같은 가용 영역의 같은 물리적 하드웨어에 가깝게 배치하여 노드 간 네트워크 지연을 최소화합니다. 여러 가용 영역에 걸쳐 배치하면 가용 영역 간의 네트워크 레이턴시가 증가하므로 성능 저하가 발생합니다. 【오답 체크】 ▸ (B) 클러스터 배치 그룹을 여러 AZ에 걸쳐 배치하면 AZ 간 레이턴시로 성능이 저하됩니다. ▸ (C) 파티션 배치 그룹은 대규모 분산 워크로드(Hadoop, Cassandra)를 위한 것이며, HPC의 최대 성능 요구사항을 충족하지 못합니다. ▸ (D) 파티션 배치 그룹을 여러 AZ에 배치하는 것은 HPC 시나리오에 부적합합니다. 【시험 포인트】 ▸ EC2 배치 그룹은 SOA 시험의 성능 최적화 주제입니다. 클러스터, 파티션, 스프레드 배치 그룹의 차이와 사용 사례를 이해해야 합니다. HPC, 분산 애플리케이션, 고가용성 요구사항에 따른 선택이 중요합니다.

해설

【핵심 용어】 ▸ Spot Fleet: Spot 인스턴스와 온디맨드 인스턴스를 함께 사용하는 플릿 ▸ 온디맨드 용량: Spot Fleet에서 온디맨드 인스턴스의 최소 보장 수 ▸ 비용 효율성: 비용 대비 최고의 성능 【정답 포인트】 ▸ Spot Fleet에서 온디맨드 용량을 6개로 설정하면, 최소한 6개의 온디맨드 인스턴스가 항상 실행되어 서비스 요구사항을 충족합니다. 추가 용량은 저가의 Spot 인스턴스로 채워져 비용을 절감합니다. Spot 인스턴스가 중단되면 온디맨드 인스턴스가 기본 용량을 보장합니다. 이는 안정성과 비용 효율성의 균형을 제공합니다. 【오답 체크】 ▸ (B) 최소 6개, 최대 10개의 온디맨드 인스턴스는 모두 온디맨드 가격으로 비용이 높습니다. ▸ (C) 최소 1개만 보장하면 트래픽 증가 시 부족할 수 있으며, 서비스 요구사항을 충족하지 못합니다. ▸ (D) 목표 용량 6개의 Spot Fleet은 Spot 인스턴스 중단 시 6개 미만으로 떨어질 수 있으며, 최소 6개 보장이 없습니다. 【시험 포인트】 ▸ EC2 인스턴스 유형(온디맨드, Spot, 예약, Saving Plans) 선택과 비용 최적화는 SOA 시험의 중요 주제입니다. Spot Fleet의 온디맨드 용량 설정을 통한 안정성과 비용의 균형 맞추기를 이해해야 합니다.

해설

【핵심 용어】 ▸ CloudWatch Agent: EC2 내 애플리케이션 모니터링 에이전트 ▸ AWS Systems Manager State Manager: 인스턴스의 상태를 지속적으로 관리 ▸ 자동 복구: 장애 감지 시 자동 치료 【정답 포인트】 ▸ (A) CloudWatch Agent는 EC2 내 서비스의 상태를 모니터링할 수 있습니다. 상태 확인이 실패하면 CloudWatch Alarm을 통해 EC2 작업(예: 재시작)을 자동으로 수행합니다. 에이전트는 커스텀 메트릭을 수집하고 이에 따라 자동 조치를 취할 수 있습니다. ▸ (C) Systems Manager State Manager는 인스턴스에 대한 관리형 연결을 정의하여 정기적으로 실행합니다. AWS-RunShellScript 문서를 사용하여 서비스 상태 확인 및 자동 재시작 스크립트를 5분마다 실행할 수 있으며, 태그 기반 대상 지정이 가능합니다. 【오답 체크】 ▸ (B) Session Manager를 통한 로그인은 상호작용적이며 자동화에 적합하지 않습니다. 권한 및 접근성 문제도 있습니다. ▸ (D) 사용자 데이터의 cron 스크립트는 모든 인스턴스를 재배포해야 하며, 기존 인스턴스에는 적용되지 않습니다. ▸ (E) 시작 중 서비스만 시작하면 런타임 실패 시 복구되지 않습니다. 【시험 포인트】 ▸ 자동 복구 메커니즘은 SOA 시험의 고가용성 주제입니다. CloudWatch와 Systems Manager의 모니터링 및 관리 역할, 상태 기반 자동화의 중요성을 이해해야 합니다. 멀티 선택에서는 실제 작동하는 두 솔루션을 구분하는 것이 중요합니다.

해설

【핵심 용어】 ▸ 고가용성: 가용 영역 장애에도 서비스 지속 ▸ 성능 저하 없음: 최소 12개 인스턴스 필요 ▸ 인스턴스 최소화: 비용 절감 【정답 포인트】 ▸ 한 개 AZ 장애 시에도 최소 12개 인스턴스를 유지해야 합니다. 3개 AZ에 각 6개씩 배치(총 18개)하면, 한 AZ 장애 시 12개가 남아 요구사항을 충족합니다. 2개 AZ에서 각 12개는 총 24개 필요하므로 인스턴스가 더 많습니다. 4개씩 배치는 한 AZ 장애 시 8개만 남으므로 부족합니다. 【오답 체크】 ▸ (A) 2AZ에 각 6개(총 12개): 한 AZ 장애 시 6개만 남아 부족합니다. ▸ (B) 2AZ에 각 12개(총 24개): 요구사항을 충족하지만 인스턴스 수가 가장 많습니다. ▸ (C) 3AZ에 각 4개(총 12개): 한 AZ 장애 시 8개만 남아 최소 12개 요구사항을 충족하지 못합니다. 【시험 포인트】 ▸ 고가용성 아키텍처에서 AZ 분산과 인스턴스 계획은 SOA 시험의 중요 주제입니다. 최악의 경우(한 AZ 전체 장애)를 고려한 용량 계획이 필수입니다. 비용 효율성과 안정성의 균형을 맞추는 것이 핵심입니다.

해설

【핵심 용어】 ▸ CloudWatch Agent(CloudWatch 에이전트): EC2 인스턴스 내부의 메트릭을 수집하는 소프트웨어. IAM Role(IAM 역할): 에이전트가 CloudWatch에 데이터를 전송할 권한 제공. disk_used_percent: 디스크 사용 백분율 메트릭. 【정답 포인트】 ▸ A: CloudWatchAgentServerPolicy를 포함한 IAM 역할 필수 → 에이전트에 CloudWatch 접근 권한 부여. C: CloudWatch 에이전트 설치 및 시작 필수 → 실제 메트릭 수집 수행. E: disk_used_percent > 80% 알람 구성 필수 → EBS 볼륨 디스크 사용률 모니터링. 이 세 가지가 모두 필요하여 완전한 솔루션 구성. 【오답 체크】 ▸ (B) CloudWatchApplicationInsightsReadOnlyAccess는 읽기 전용이므로 메트릭 전송 불가. (D) 불필요한 중복 설명 - IAM 역할은 이미 A에서 처리. (F) disk_free와 80%/20% 조합은 EBS 볼륨 내부 디스크 모니터링에 부적절. 【시험 포인트】 ▸ CloudWatch Agent 배포 시 세 가지 필수 구성: ① IAM 권한, ② 에이전트 설치, ③ 알람 정의. EBS 디스크 메트릭은 OS 내부에서만 수집 가능하므로 에이전트 필수. 정책 선택 시 쓰기 권한 확인 중요.

해설

【핵심 용어】 ▸ ElastiCache Eviction Policy(제거 정책): 메모리가 부족할 때 제거할 키 선택 방식. Cache Hit Ratio(캐시 히트 비율): 캐시에서 찾은 요청 비율. Least Frequently Used(LFU): 사용 빈도가 낮은 데이터 우선 제거. 【정답 포인트】 ▸ D: allkeys-lfu 정책으로 변경하면 자주 사용되지 않는 키를 제거하여 자주 접근하는 데이터 보존. 이는 캐시 히트 비율을 증가시키면서 새로운 비용 없이 솔루션 제공. 현재 정책은 TTL 관계없이 무작위 제거하므로 유용한 데이터까지 손실 초래. 【오답 체크】 ▸ (A) 노드 추가는 비용 증가 → 요구사항 위반. (B) TTL 증가만으로는 제거 정책 문제 해결 불가 → 메모리 부족 시에도 무작위 제거. (C) TTL 기반 제거도 불완전 → 자주 사용되는 데이터가 TTL 없으면 제거될 수 있음. 【시험 포인트】 ▸ ElastiCache 제거 정책 종류: random, lru(Least Recently Used), lfu(Least Frequently Used). 사용 빈도가 캐시 효율성의 핵심. 캐시 히트 비율 최대화는 최적의 제거 정책 선택으로 달성.

해설

【핵심 용어】 ▸ Session Affinity(세션 어피니티/고정 세션): 동일 클라이언트 요청을 항상 같은 서버로 라우팅. Stateful Application(상태 유지 애플리케이션): 클라이언트 세션 상태를 서버에 저장하는 애플리케이션. 【정답 포인트】 ▸ B: 웹 애플리케이션이 상태 유지식(stateful)이므로 로그인 세션 정보가 특정 EC2 인스턴스에 저장. ALB의 기본 라운드 로빈 방식은 각 요청을 다른 인스턴스로 보내 세션 손실 야기. Sticky Session 활성화하면 동일 클라이언트는 항상 같은 인스턴스 접속 → 세션 유지. 【오답 체크】 ▸ (A) CloudFront는 정적 콘텐츠 캐싱 용 → 로그인 상태 문제 미해결. (C) Placement Group은 물리적 배치 최적화 → 세션 문제와 무관. (D) NLB는 단순 레이어4 로드밸런싱 → CloudFront처럼 근본 원인 미해결. 【시험 포인트】 ▸ 로드 밸런서 뒤의 상태 유지식 애플리케이션 운영 시 Sticky Session 필수. ALB는 기본 쿠키 기반 고정 지원. 멀티 AZ 배포 시에도 세션 유지 가능. 주의: 단일 인스턴스 장애 시 클라이언트 세션 손실.

해설

【핵심 용어】 ▸ S3 Storage Lens: S3 전체 사용 현황 및 메트릭 분석 도구. S3 Lifecycle Policy: 객체 생명주기에 따른 자동 관리 규칙. AbortIncompleteMultipartUpload: 미완성 업로드 자동 삭제 액션. 【정답 포인트】 ▸ A: S3 Storage Lens는 Incomplete Multipart Upload Bytes 메트릭 제공 → 불완전 업로드 모니터링. S3 Lifecycle 정책의 AbortIncompleteMultipartUpload 규칙으로 7일 경과 후 자동 삭제 설정 → 스토리지 비용 절감. AWS 기본 기능으로 간단하고 비용 효율적. 【오답 체크】 ▸ (B) S3 Storage Lens 정책이 아닌 Lifecycle 정책으로 삭제 수행. Intelligent-Tiering은 완성된 객체 티어링용. (C) Lambda 함수는 추가 복잡성과 비용 발생. (D) S3 Bucket Policy는 접근 제어 용 → 자동 삭제 기능 없음. Analytics도구도 삭제 기능 미제공. 【시험 포인트】 ▸ S3 Lifecycle Policy는 자동 삭제/이동 관리의 필수 도구. AbortIncompleteMultipartUpload는 미완성 업로드 정리 시 활용. Storage Lens의 메트릭 기반 의사결정 중요. 불완전 업로드는 별도 요금 발생 가능하므로 정기 정리 권장.

해설

【핵심 용어】 ▸ AWS Direct Connect: AWS와 기업 네트워크를 전용 연결로 연결. Public Virtual Interface: S3 등 AWS 공용 서비스 접근용. Private Virtual Interface: VPC 프라이빗 리소스 접근용. 【정답 포인트】 ▸ D: S3는 AWS 공용 서비스이므로 Public Virtual Interface 사용. 3개 리전 모두에 Direct Connect 구성할 필요 없이(비용 낭비) 하나의 리전만 구성해도 충분. S3는 Cross-Region Replication 지원하므로 한 리전 연결로도 모든 S3 데이터 접근 가능. VPN 대신 Direct Connect 사용으로 ISP 혼잡 우회 → 일관된 전송 속도 보장. 【오답 체크】 ▸ (A) 3개 리전 모두 구성은 과도한 비용. (B) 역시 3개 리전 구성 비용 증가. (C) Private VIF는 VPC 접근용 → S3 공용 서비스에 부적절. 【시험 포인트】 ▸ Direct Connect 사용 시 VIF 유형 선택 중요: 공용 서비스(S3, DynamoDB 등)는 Public VIF, VPC 리소스는 Private VIF. Multi-Region 구성 시 모든 리전에 연결 불필요 → 비용 최적화. ISP 혼잡 해결의 핵심은 공용 인터넷 우회.

해설

【핵심 용어】 ▸ EBS Elastic Volume: EBS 볼륨 크기를 온라인 상태에서 변경. File System Extension(파일 시스템 확장): 볼륨 크기 증가 후 OS 수준에서 파일 시스템 재설정. 【정답 포인트】 ▸ A: EBS는 인스턴스 재부팅 없이 온라인 상태에서 크기 변경 가능(Elastic Volumes). 볼륨 확장 후 EC2에 접속하여 파일 시스템 확장 명령(resize2fs 등) 실행 → 몇 분 내 완료. 가동 중지 시간 최소화로 가장 빠른 솔루션. 【오답 체크】 ▸ (B) 스냅샷 생성 시간 소요(대용량 데이터 시 길 수 있음) → 느림. (C) 새 볼륨 생성 후 데이터 복사 필요 → 시간 소모 + 인스턴스 다운타임. (D) 인스턴스 중지-재시작 필요 → 가동 중지 시간 발생. EC2 인스턴스 크기 변경도 인스턴스 유형에 따라 제약 있을 수 있음. 【시험 포인트】 ▸ EBS Elastic Volumes(gp2, gp3, io1, io2)는 인스턴스 실행 중 크기 변경 가능. 인스턴스 타입 변경은 호환성 및 다운타임 고려 필요. 즉각적 용량 확장은 EBS 볼륨 확대가 최선. 온라인 파일 시스템 확장 명령은 Linux 배포판별로 상이(resize2fs, xfs_growfs 등).

해설

【핵심 용어】 ▸ Service Control Policy(SCP): AWS Organizations에서 모든 계정에 적용되는 조직 수준 정책. Identity-Based IAM Policy: 특정 계정 내 IAM 사용자/역할 기반 정책. AWS Organizations: 다중 AWS 계정 관리 서비스. 【정답 포인트】 ▸ B: AWS Organizations의 관리 계정에서 SCP 생성 → 모든 구성원 계정에 자동 적용. SCP는 정책 평가 프로세스의 상한선(permission boundary) 역할 → 루트 사용자 포함 모든 보안주체(principal) 영향. 중앙 집중식 관리로 각 계정별 정책 설정 필요 없음. 【오답 체크】 ▸ (A) IAM 정책은 루트 사용자에게 효과 없음(루트 사용자는 모든 정책 제약 무시 가능). (C) AWS Config는 리소스 규정 준수 모니터링 용 → 접근 제어 기능 없음. (D) Amazon Inspector는 취약점 스캔 용 → 접근 제어 미제공. 【시험 포인트】 ▸ 루트 사용자 제어는 SCP만 가능(IAM 정책 불가). Organizations 구조에서 SCP는 가장 강력한 정책 메커니즘. SCP는 '허용하지 않음' 중심이므로 명시적 거부(Deny) 문장 사용. 루트 사용자 MFA 활성화 및 SCP 조합이 모범 사례.

해설

【핵심 용어】 ▸ AWS Config Managed Rule: AWS 제공 사전 정의 규칙. Automatic Remediation: 비준수 리소스 자동 수정. AWS Systems Manager Automation: 루북 기반 자동화 실행. 【정답 포인트】 ▸ A: eip-attached 규칙은 미연결 Elastic IP 감지 전문 → 운영 오버헤드 최소화. AWS Config가 자동으로 비준수 상태 감지 후, Systems Manager Runbook(AWS-ReleaseElasticIP) 통해 자동 해제. 관리 복잡도 최소 + 구성만으로 완전 자동화 달성. 【오답 체크】 ▸ (B) Trusted Advisor는 주간 1회 실행 → 즉각 대응 불가. All Events는 너무 광범위. (C) CloudFormation은 배포 도구 → 상태 감지 및 자동 해제에 부적절. 복잡도 높음. (D) D는 구조상 좋으나, 커스텀 Lambda 개발/관리 필요 → 운영 오버헤드 증가. Config Managed Rule이 이미 최적 솔루션 제공. 【시험 포인트】 ▸ AWS Config는 규정 준수 및 자동 수정의 핵심. 관리 규칙 활용으로 커스텀 코드 최소화. Runbook 기반 자동화는 일관성과 추적성 제공. eip-attached 같은 구체적 규칙이 존재하면 우선 활용.

해설

【핵심 용어】 ▸ CloudFront Invalidation(무효화): 특정 객체를 캐시에서 즉시 제거하는 기능. TTL(Time To Live): 객체 캐시 유지 기간. Cached Content Refresh: 캐시된 콘텐츠 업데이트. 【정답 포인트】 ▸ C: CloudFront Invalidation은 TTL 만료 대기 없이 특정 객체를 즉시 만료 → 가장 빠른 캐시 새로고침. /images/* 또는 특정 이미지 경로 무효화로 마케팅 팀의 150개 이미지 즉시 반영. 최소 비용(Invalidation 요청 비용)으로 최대 효율. 【오답 체크】 ▸ (A) 새 배포 생성 + DNS 전환 → 시간 소모 + Route 53 TTL 등 추가 지연. (B) 이미지 위치 변경은 워크플로우 복잡화 → 비효율적. (D) TTL 변경만으로는 기존 캐시 객체 미처리 → 이미 캐시된 이미지는 여전히 오래된 버전. 【시험 포인트】 ▸ CloudFront Invalidation은 즉시 새로고침의 표준 방법. 경로 와일드카드(*) 사용 가능 → 여러 객체 한 번에 처리. 모든 엣지 로케이션에 즉시 적용. 월별 무료 Invalidation 요청 포함(대량 무효화 시만 추가 비용).

해설

【핵심 용어】 ▸ S3 Cross-Account Replication: 다른 AWS 계정의 S3 버킷 간 복제. Object Ownership: 복제된 객체의 소유권 설정. Owner Override(소유자 재설정): 대상 계정 소유권으로 변경. 【정답 포인트】 ▸ A: Cross-Account 복제 시 기본 설정에서 복제된 객체는 소스 계정 소유 → 대상 계정이 접근 불가. Replication Configuration의 'Destination Owner'를 대상 계정 소유자로 설정하면 객체 소유권 자동 이전 → 대상 계정이 접근 가능. 이것이 Cross-Account 복제의 핵심 설정. 【오답 체크】 ▸ (B) 복제 규칙 범위는 어떤 객체를 복제할지 결정 → 접근 권한과 무관. (C) S3 RTC는 복제 완료 시간 SLA → 접근 권한 미제공. (D) 스토리지 클래스는 객체 접근성 미영향 → 소유권 문제 미해결. 【시험 포인트】 ▸ S3 Cross-Account 복제의 필수 설정: ① 소스 계정 버킷 정책(복제 권한), ② IAM 역할(복제 수행), ③ 대상 계정 버킷 정책(객체 수신), ④ 객체 소유권 설정. 기본값은 소유권 유지 → 명시적으로 'Destination Owner' 옵션 활성화 필요.

해설

【핵심 용어】 ▸ Storage Auto Scaling: RDS 스토리지 자동 확장 기능. CloudFormation Template Modification: IaC 템플릿 수정으로 향후 인스턴스 자동 설정. VACUUM: PostgreSQL 데이터베이스 최적화 명령(공간 회수 미제공). 【정답 포인트】 ▸ C: RDS Storage Auto Scaling을 CloudFormation 템플릿의 AWS::RDS::DBInstance 속성에 추가 → 향후 생성되는 모든 DB 인스턴스에 자동 적용. 디스크 가득 시 자동 확장으로 사전 대응 가능. 애플리케이션 변경 최소화(CloudFormation 설정만 수정). 【오답 체크】 ▸ (A) Aurora로 전환은 아키텍처 변경 → 큰 애플리케이션 수정 필요. (B) DynamoDB는 NoSQL → PostgreSQL 마이그레이션 필수(상당한 변경). (D) VACUUM은 죽은 행 공간 회수 기능 미제공 → 스토리지 확장 문제 미해결. 【시험 포인트】 ▸ RDS Auto Scaling은 특정 임계값 도달 시(예: 90% 사용) 자동 확장. CloudFormation에서 StorageType과 함께 MaxAllocatedStorage 속성 설정 필수. 매주 생성하는 인스턴스 모두에 적용 가능 → 운영 단순화.

해설

【핵심 용어】 ▸ RDS Snapshot Sharing(스냅샷 공유): 암호화된 스냅샷을 다른 계정과 공유. KMS Key Policy: KMS 키 접근 권한 제어. Cross-Account KMS: 다른 계정의 KMS 키 사용 권한 부여. 【정답 포인트】 ▸ A: 스냅샷 공유 후 마이그레이션 계정이 복호화하려면 KMS 키 접근 필요 → production-rds-key 정책에 마이그레이션 계정 루트 사용자 추가. 이것이 최소 변경으로 최대 효과(기존 스냅샷 메커니즘 활용). 관리 오버헤드 최소 → 정책 수정만으로 완료. 【오답 체크】 ▸ (B) 읽기 복제본은 같은 리전/계정 내 생성 → Cross-Account 복제 미지원. KMS 키 복제도 불가능. (C) 마이그레이션 계정의 새 KMS 키로는 프로덕션 스냅샷 복호화 불가 → 접근 권한 미해결. (D) 데이터베이스 내보내기/가져오기는 복잡한 프로세스 → RDS 스냅샷이 훨씬 간단. 【시험 포인트】 ▸ RDS 암호화 스냅샷 공유 시 두 가지 조건 필수: ① 스냅샷 공유 권한, ② KMS 키 복호화 권한. KMS 키 정책의 Principal 항목에 대상 계정 추가 필수. 읽기 복제본은 계정 간 미지원 → 스냅샷이 유일한 선택.

해설

【핵심 용어】 ▸ gp2(범용 SSD): 버스트 기반 성능(3 IOPS/GB). gp3(범용 SSD): 독립적 처리량 설정 가능. BurstBalance: gp2 버스트 크레딧 누적도(0 = 크레딧 고갈). 【정답 포인트】 ▸ B: gp2는 500GB 기준 기본 1,500 IOPS, 버스트로 3,000 IOPS 달성 → BurstBalance 0 = 지속 성능 불가. gp3는 크기와 무관하게 IOPS 독립 설정 가능(기본 3,000 IOPS) → 야간 빌드 3,000 IOPS 지속 가능. 비용 대비 성능 최적. io2는 불필요한 고비용. 【오답 체크】 ▸ (A) 500GB → 1,000GB 확대해도 기본 IOPS는 3,000 → 여전히 버스트 기반 → 지속 성능 미해결. (C) st1은 HDD 기반 → gp2보다 낮은 IOPS(최대 500 IOPS) → 문제 악화. (D) io2는 IOPS당 높은 비용 → 3,000 IOPS gp3로 충분한 상황에서 과잉 설정. 【시험 포인트】 ▸ gp2는 버스트 기반(크리딧 고갈 시 기본 성능으로 하락) → 지속적 고성능 불가. gp3는 IOPS/처리량 독립 설정 → 예측 가능한 일관된 성능. BurstBalance 0 = 지속 성능 필요 신호 → gp3 전환이 해결책. 비용 고려 시 gp3 > gp2(대용량일 경우 io2 필요 아님).

해설

【핵심 용어】 ▸ AWS Global Accelerator: 지역 기반 로드 밸런싱 제공 고정 IP 주소(2개). Static IP: 고객이 접근에 사용 가능한 변하지 않는 IP. ALB IP: 리전별 여러 개 보유 → 정적 아님. 【정답 포인트】 ▸ A: Global Accelerator는 2개의 고정 Anycast IP 제공(AWS 글로벌 네트워크로 분산) → 고객이 두 개의 정적 IP만 사용하면 됨. 뒤에 ALB 구성하면 3개 AZ 모두 적용 가능 → 고가용성 유지. 유일한 정적 IP 제공 메커니즘. 【오답 체크】 ▸ (B) NLB 추가는 IP 주소 개수 증가 → 요구사항 미달성. (C) 2개 AZ로 제한 = 1개 AZ 가용성 손실 → 가용성 저하. (D) ALB는 Elastic IP 할당 불가(NLB만 가능) → 기술적으로 불가능. 【시험 포인트】 ▸ Global Accelerator의 핵심: 2개 고정 Anycast IP로 단순함. NLB는 가능하지만 ALB는 EIP 미지원. Multi-AZ ALB는 기본 3개+ 가용 IP(지역별 변동) → 정적 불가. Global Accelerator가 정적 IP 요구 충족 유일한 AWS 네이티브 솔루션.

해설

【핵심 용어】 ▸ AWS Config: 리소스 구성 변경 추적 및 변경 이력 기록. Change Timeline: 리소스 설정 변경 시간순 기록. Configuration History: 누가, 언제, 무엇을 변경했는지 추적. 【정답 포인트】 ▸ A: AWS Config는 리소스 구성 변경을 자동 감지 및 기록 → Auto Scaling 그룹의 MinSize 변경 추적 가능. AWS CloudTrail과 통합하여 변경자(IAM 사용자/역할) 식별 → '변경을 한 사람' 파악. Configuration Timeline에서 변경 전후 설정값, 타임스탐프, 사용자 정보 모두 확인. 【오답 체크】 ▸ (B) Amazon Inspector: 취약점 스캔 도구 → 변경 추적 기능 미제공. (C) Amazon Macie: 데이터 분류 및 보안 서비스 → 리소스 구성 변경 미추적. (D) CloudWatch Logs: 애플리케이션 로그 저장 → 리소스 설정 변경 감지 불가(명시적 로깅 필요). 【시험 포인트】 ▸ AWS Config는 규정 준수 및 변경 추적의 필수 서비스. CloudTrail과 함께 사용 시 변경 주체/시간/내용 완벽 기록. Auto Scaling, EC2, 보안 그룹 등 주요 리소스 변경 감지 → 거버넌스/감사 목적 필수.