정답 · 해설

해설

【핵심 용어】 ▸ 패치 그룹: 태그로 식별된 인스턴스의 논리적 그룹 ▸ 패치 기준선: 승인 규칙 및 자동 승인 지연 정의 ▸ 유지보수 창: 패치 적용 시간 범위 【정답 포인트】 ▸ 패치 기준선에서 자동 승인 지연을 설정하므로 서로 다른 2일과 5일 지연을 구현하려면 두 개의 패치 기준선 필요 ▸ 패치 그룹은 각 기준선과 연결되어 자동 승인 지연 정책 적용 ▸ 유지보수 창은 모든 그룹에 적용되므로 단일 창만 필요 【오답 체크】 (A) 하나의 패치 기준선으로는 서로 다른 승인 지연 설정 불가능 (C) 두 개의 유지보수 창은 불필요하며 비용 증가 (D) 그룹이나 기준선이 불완전 【시험 포인트】 ▸ 서로 다른 자동 승인 지연이 필요하면 여러 패치 기준선 사용 ▸ 각 기준선은 하나의 자동 승인 지연값만 설정 가능 ▸ 유지보수 창은 패치 적용 시간을 제어하므로 공통으로 사용 가능

해설

【핵심 용어】 ▸ AWS Glue: ETL 및 데이터 카탈로그 서비스 ▸ Amazon Athena: S3 데이터에 대한 SQL 쿼리 ▸ 구조화되지 않은 로그: 필드 위치가 불일치하는 JSON 【정답 포인트】 ▸ Glue는 로그를 처리하여 구조화된 형식으로 변환할 수 있으므로 필드 위치 불일치 문제 해결 ▸ Athena는 S3 기반 로그에 강력한 SQL 쿼리 지원 ▸ 복잡한 문자열 매칭 (공통 접두사)은 Glue ETL로 전처리하면 효율적 【오답 체크】 (A) S3 Select는 기본적인 쿼리만 지원하며 복잡한 필드 매칭에 제한 있음 (C) CloudWatch Logs Insights는 S3 저장 로그 직접 쿼리 불가능 (D) Contributor Insights는 특정 필드 분석용이므로 부적절 【시험 포인트】 ▸ S3 저장 JSON 로그의 복잡한 검색은 Glue + Athena 조합이 최적 ▸ 필드 위치 불일치는 Glue로 정규화 후 처리 ▸ CloudWatch Logs Insights는 CloudWatch에 저장된 로그만 처리

해설

【핵심 용어】 ▸ CloudWatch 에이전트: 로그 전송을 위한 IAM 권한 필요 ▸ IAM 역할: EC2 인스턴스의 권한 관리 ▸ CloudWatch Logs 권한: CreateLogGroup, CreateLogStream, PutLogEvents, DescribeLogStreams 【정답 포인트】 ▸ CloudWatch 에이전트가 실행 중이고 구성이 올바르다면 문제는 권한에 있을 가능성 높음 ▸ IAM 역할이 필요한 모든 CloudWatch Logs 권한을 가지지 못하면 로그 발행 실패 ▸ 에이전트 실행과 구성이 정상이면 AWS API 호출 권한 확인 필요 【오답 체크】 (A) 수동 cron은 에이전트 구성이 올바르면 불필요하며 비효율적 (B) 보존 기간은 로그 발행 여부와 무관 (C) Kinesis는 CloudWatch Logs 전송의 일반적인 구성이 아님 【시험 포인트】 ▸ CloudWatch 에이전트 구성이 올바르지만 로그 미발행 -> IAM 권한 확인 우선 ▸ EC2 인스턴스는 역할을 통해 AWS 서비스 권한 획득 ▸ 에이전트 실행 + 구성 정상 = 권한 문제 가능성 높음

해설

【핵심 용어】 ▸ EC2 인스턴스 스토어: 인스턴스에 물리적으로 연결된 고속 스토리지 ▸ 임시 데이터: 인스턴스 재시작 시 손실되어도 괜찮음 ▸ 최고 성능: 지연 시간 최소화 【정답 포인트】 ▸ EC2 인스턴스 스토어는 물리적으로 호스트에 직접 연결되어 있어 EBS보다 훨씬 높은 IOPS와 낮은 지연 시간 제공 ▸ 데이터 지속성이 필요 없는 임시 캐시에 최적 ▸ 인스턴스 재시작 시 데이터 손실이 문제 없으므로 최고 성능 선택 가능 【오답 체크】 (A) gp3는 밸런스 있는 성능이지만 인스턴스 스토어보다 느림 (B) io2는 높은 IOPS이지만 비용 높고 여전히 인스턴스 스토어보다 느림 (C) st1은 처리량 최적화이며 IOPS 성능 부족 【시험 포인트】 ▸ 임시 캐시 + 최고 성능 = EC2 인스턴스 스토어 ▸ EBS는 영속성이 필요할 때 사용 ▸ 인스턴스 재시작 시 손실 가능은 인스턴스 스토어의 특징

해설

【핵심 용어】 ▸ AWS Cost and Usage Report: 상세한 비용 데이터 (시간 단위 지원) ▸ Amazon Athena: S3 기반 SQL 쿼리 ▸ Amazon QuickSight: 비용 데이터 시각화 ▸ 시간 단위 세분화: 매시간 추세 분석 【정답 포인트】 ▸ AWS Cost and Usage Report는 시간 단위 세분화를 지원하여 매시간 데이터 확보 가능 ▸ S3 저장 후 Athena로 쿼리하면 비용 효율적 ▸ QuickSight로 대시보드화하면 멀티 계정 비용 통합 조회 가능 【오답 체크】 (A) CloudWatch Insights는 실시간 로그 분석용이며 비용 데이터 전문성 부족 (C) Lambda로 매일 조회는 시간 단위 데이터 확보 불가능하고 비효율적 (D) 관리 계정만으로는 멀티 계정 통합 비용 분석 제한 【시험 포인트】 ▸ 시간 단위 비용 분석은 AWS Cost and Usage Report 필수 ▸ 멀티 계정 비용 통합은 조직 수준 보고서로 자동 처리 ▸ Cost Explorer는 시간 단위 세분화 제한 있음

해설

【핵심 용어】 ▸ Compute Savings Plan: EC2, Fargate, Lambda에 공통 적용 가능 ▸ 유연성: 리전, 인스턴스 유형, OS 변경 가능 ▸ 비용 절감: Reserved Instance보다 유연성 좋음 【정답 포인트】 ▸ Compute Savings Plan은 세 가지 컴퓨팅 서비스(EC2, Fargate, Lambda) 모두에 적용되므로 최대 활용도 제공 ▸ 리전, 인스턴스 유형, OS 변경에 유연하므로 비즈니스 변화에 대응 ▸ Reserved Instance보다 유연하면서도 온디맨드보다 저렴 【오답 체크】 (B) EC2 Instance Savings Plan은 Fargate와 Lambda에는 직접 적용 불가능 (C) Reserved Instance는 리전, OS 유연성 제한 (D) Spot Instances는 중단 가능하므로 24/7 운영에 부적절 【시험 포인트】 ▸ 여러 서비스 통합 사용 + 유연성 필요 = Compute Savings Plan ▸ Reserved Instance는 특정 구성 고정할 때만 최적 ▸ Savings Plan은 권장사항 기반 구매로 최대 절감

해설

【핵심 용어】 ▸ Amazon EventBridge: AWS 이벤트 실시간 감지 및 라우팅 ▸ Amazon SNS: 푸시 기반 메시지 전송 (이메일 포함) ▸ EC2 인스턴스 시작 이벤트: EventBridge에서 감지 가능 【정답 포인트】 ▸ EventBridge는 EC2 인스턴스 시작 이벤트를 자동으로 감지하여 SNS에 전달 ▸ SNS는 이메일 구독을 지원하므로 추가 개발 불필요 ▸ 즉시 알림 = 푸시 기반 아키텍처 필요 (SNS, EventBridge) 【오답 체크】 (A) 사용자 데이터 스크립트는 각 인스턴스마다 실행되며 이메일 발송 기능이 복잡 (C) SQS는 폴링 기반이므로 "즉시" 알림 불가능 (D) Lambda로 폴링하는 것은 비효율적이며 실시간성 부족 【시험 포인트】 ▸ 실시간 이벤트 처리 = EventBridge + SNS 조합 ▸ 즉시 알림 = 푸시 기반 (SNS, EventBridge) ▸ 폴링 기반 (SQS, Lambda)은 지연 발생

해설

【핵심 용어】 ▸ AWS Trusted Advisor: 저사용 리소스 감지 ▸ Amazon EventBridge: Trusted Advisor 검출 결과 자동 라우팅 ▸ EC2 TerminateInstances: 인스턴스 자동 종료 【정답 포인트】 ▸ EventBridge는 Trusted Advisor의 저사용 검출 결과를 직접 처리 가능 ▸ API 대상으로 직접 설정하면 중간 Lambda 불필요 ▸ 가장 간단하고 직접적인 자동화 방식 【오답 체크】 (A) GuardDuty는 보안 위협 감지용이며 CPU 사용률 기반 검출 아님 (B) AWS Health Dashboard는 개별 리소스 모니터링 아님 (C) SNS + Lambda 조합은 EventBridge 직접 대상보다 복잡 【시험 포인트】 ▸ Trusted Advisor + EventBridge 자동화가 표준 패턴 ▸ Lambda 중간 단계 없이 API 대상 직접 호출이 효율적 ▸ 저사용 리소스 자동 처리는 Trusted Advisor + EventBridge 조합

해설

【핵심 용어】 ▸ AWS Service Catalog: 승인된 제품 카탈로그 ▸ 시작 제약 역할: IAM 권한 제한 ▸ 거버넌스: 승인된 구성만 배포 【정답 포인트】 ▸ Service Catalog는 비즈니스 단위가 카탈로그에서만 선택하도록 제한하므로 승인된 구성 강제화 ▸ 시작 제약 역할로 추가 권한 제어 가능 ▸ IAM 정책과 Service Catalog 제약을 결합하여 최강 거버넌스 제공 【오답 체크】 (A) 시작 구성은 단순히 EC2 속성만 정의하며 강제화 메커니즘 없음 (B) IAM 정책만으로는 CloudFormation 템플릿 선택 강제 불가능 (D) CloudFormation 템플릿은 누구나 수정 가능하며 통제 불가능 【시험 포인트】 ▸ 승인된 구성 강제 = Service Catalog 우선 선택 ▸ Service Catalog는 롤백, 승인, 비용 관리 등 통합 기능 제공 ▸ IAM 정책보다 더 높은 수준의 거버넌스

해설

【핵심 용어】 ▸ AWS Secrets Manager: 자격 증명 암호화 및 자동 회전 ▸ 동적 참조: CloudFormation에서 Secrets Manager 값 직접 사용 ▸ 자동 회전: Secrets Manager의 핵심 기능 【정답 포인트】 ▸ Secrets Manager는 자격 증명 자동 회전 기능을 기본 제공 ▸ CloudFormation의 resolve:secretsmanager 동적 참조로 직접 통합 ▸ CloudFormation 배포 중에 자동으로 Secrets Manager 값을 RDS에 전달 【오답 체크】 (B) resolve:ssm-secure는 Systems Manager Parameter Store이며 자동 회전 기능 없음 (C) Systems Manager Parameter Store는 기본적으로 자동 회전 미지원 (D) 평문 매개변수는 암호화 및 회전 기능 없음 【시험 포인트】 ▸ 자동 회전 = Secrets Manager 우선 선택 ▸ SSM Parameter Store는 정적 값 저장용 ▸ RDS 자격 증명은 Secrets Manager가 최고 권장 구성

해설

【핵심 용어】 ▸ AWS Config(Configuration Management): AWS 리소스의 현재 및 이전 구성을 추적하고 비준수 상태를 자동 감지하는 AWS 서비스 ▸ required-tags 관리형 규칙: 리소스가 지정된 태그를 가지고 있는지 평가하는 기본 제공 규칙 ▸ EventBridge: 실시간 이벤트 기반 아키텍처용(실시간 리소스 변경 추적) 【정답 포인트】 ▸ AWS Config의 관리형 규칙(required-tags)은 태깅 규정 준수를 지속적으로 모니터링하기 위해 설계됨 ▸ Config는 모든 기존 리소스와 새로운 리소스를 자동으로 평가 ▸ Lambda 함수 없이 기본 제공 규칙만으로 운영 오버헤드 최소화 ▸ 사용자 정의 로직이 불필요한 표준 태깅 검증에 가장 효율적 【오답 체크】 ▸ (A) EventBridge는 실시간 이벤트 기반이므로 기존 비준수 리소스 식별 불가, Lambda 함수로 인해 운영 복잡도 증가 ▸ (B) AWS Config 사용하지만 Lambda 함수로 인한 불필요한 복잡도 추가 ▸ (D) EventBridge에는 태깅 검증용 관리형 규칙 없음 【시험 포인트】 ▸ AWS Config는 규정 준수 모니터링 및 태깅 정책 강화의 표준 솔루션 ▸ 관리형 규칙과 사용자 정의 규칙의 구분: 표준 검증은 관리형 규칙 사용 ▸ EventBridge는 이벤트 기반 실시간 자동화, Config는 지속적 규정 준수 모니터링

해설

【핵심 용어】 ▸ FreeStorageCapacity: FSx for Windows File Server의 사용 가능한 스토리지 용량을 나타내는 CloudWatch 메트릭(바이트 단위) ▸ CloudWatch 알람: 메트릭 기반 임계값 모니터링으로 ALARM 상태 트리거 ▸ SNS 주제: 알람 상태 변경 시 이메일 구독자에게 알림 전달 【정답 포인트】 ▸ (B) CloudWatch 알람이 FSx 메트릭 모니터링의 표준 방식 ▸ (E) CloudWatch 알람이 ALARM 상태 진입 시 직접 SNS 주제에 게시 가능 ▸ 두 단계만으로 충분: 알람 생성 + SNS 발행 구성 ▸ Lambda 함수 불필요, 네이티브 CloudWatch-SNS 통합이 효율적 【오답 체크】 ▸ (A) EventBridge는 FSx 메트릭 기반 규칙 직접 지원 안 함, 실시간 이벤트 처리용 ▸ (C) Lambda 함수 불필요(과도한 복잡도), CloudWatch가 직접 SNS 발행 가능 ▸ (D) EventBridge는 FSx 메트릭 모니터링용이 아님 【시험 포인트】 ▸ CloudWatch 알람은 메트릭 기반 임계값 모니터링의 표준 ▸ 알람은 SNS, SQS, Lambda, Auto Scaling 등 직접 작업 가능 ▸ FSx/RDS/EBS 스토리지 용량 모니터링은 CloudWatch 알람 활용

해설

【핵심 용어】 ▸ EC2 Instance State-change Notification: EC2 인스턴스 상태(시작, 중지, 실행 등) 변경 이벤트를 EventBridge로 캡처 ▸ EventBridge 필터링: 이벤트 규칙에서 running 상태만 선택적으로 처리 ▸ 야간 모니터링: 이벤트 기반 방식으로 자동 감지 【정답 포인트】 ▸ (C) EventBridge 이벤트 기반 구조는 거의 실시간 알림 가능 ▸ Lambda 함수는 필터된 이벤트에만 반응(효율적) ▸ 태그 및 시간 검증은 Lambda 내 로직으로 처리 ▸ 폴링 방식보다 이벤트 기반이 실시간성과 효율성 우월 【오답 체크】 ▸ (A) AWS Health Dashboard는 AWS 서비스 상태용(EC2 상태 추적 불가), Pinpoint는 과도한 설정 ▸ (B) 1분마다 폴링은 응답 지연 발생, 야간 전체 시간 실행 비효율적 ▸ (D) 커스텀 애플리케이션 운영 오버헤드 증가, EC2 인스턴스 항상 실행 필요 【시험 포인트】 ▸ AWS 서비스 상태 변화 모니터링은 EventBridge 활용 ▸ EC2 상태 변화(running, stopped 등)는 자동 이벤트 포착 ▸ 실시간 알림 요구사항: 이벤트 기반 아키텍처(EventBridge + Lambda + SNS)

해설

【핵심 용어】 ▸ Systems Manager Parameter Store: 구성 데이터, 암호, API 키 등을 중앙에서 관리하는 안전한 저장소 ▸ State Manager: 선언적 구성 관리로 일관된 상태 유지 ▸ AmazonCloudWatch-ManageAgent: CloudWatch 에이전트 설치/구성용 AWS 기본 문서 【정답 포인트】 ▸ (C) Parameter Store는 구성 데이터 관리의 표준 방식, 버전 관리 및 권한 제어 지원 ▸ (D) State Manager가 태그 기반 인스턴스 대상화 및 일관된 구성 적용 ▸ CloudWatch-ManageAgent 문서는 Parameter Store에서 구성 자동 로드 ▸ 선언적 구성으로 드리프트 방지 【오답 체크】 ▸ (A) S3는 구성 저장소로 버전 관리 미흡, Parameter Store가 더 적절 ▸ (B) OpsCenter는 운영 작업 오케스트레이션용, 구성 저장소가 아님 ▸ (E) S3 기반 구성 소스는 AWS 권장 방식 아님, Parameter Store 우선 【시험 포인트】 ▸ 일관된 에이전트 구성: Parameter Store + State Manager 조합 ▸ 태그 기반 대상화는 State Manager의 핵심 기능 ▸ CloudWatch/SSM Agent 배포는 AWS 관리형 문서 활용

해설

【핵심 용어】 ▸ CloudWatch 알람: 메트릭 기반 임계값 모니터링으로 ALARM 상태 트리거 ▸ 알람 작업(Alarm Action): 임계값 초과 시 자동으로 실행되는 작업(EC2 재부팅, SNS 발행 등) ▸ EC2 인스턴스 재부팅: CloudWatch 알람이 직접 지원하는 작업 유형 【정답 포인트】 ▸ (B) CloudWatch 알람은 CPU 메트릭 모니터링의 표준 솔루션 ▸ 알람이 ALARM 상태 진입 시 직접 EC2 재부팅 작업 가능 ▸ AWS 관리형 기능으로 추가 코드나 Lambda 불필요 ▸ 최소 운영 오버헤드로 자동 복구 실현 【오답 체크】 ▸ (A) cron 작업은 항상 실행되고 에러 처리 필요, 클라우드 네이티브 방식 아님 ▸ (C) Lambda 함수 작성 및 관리로 오버헤드 증가, EventBridge는 과도함 ▸ (D) Systems Manager Automation은 더 복잡한 워크플로우용, 이 단순한 작업에는 과도함 【시험 포인트】 ▸ 메트릭 기반 자동 작업: CloudWatch 알람이 최우선 선택지 ▸ EC2 제어는 CloudWatch 알람이 직접 지원하는 작업 유형 ▸ 운영 효율성: 관리형 기능 > 커스텀 코드/자동화

해설

【핵심 용어】 ▸ 보안 그룹(Security Group): 인스턴스 레벨 Stateful 방화벽(아웃바운드 자동 응답) ▸ 네트워크 ACL(NACL): 서브넷 레벨 Stateless 방화벽(인바운드/아웃바운드 모두 명시 필요) ▸ HTTPS(포트 443): 아웃바운드 요청 시 필요한 포트 【정답 포인트】 ▸ (A) curl 요청은 아웃바운드 트래픽이므로 보안 그룹의 아웃바운드 규칙 필요 ▸ 포트 443(HTTPS)으로의 아웃바운드 접근 필수 ▸ 보안 그룹은 Stateful이므로 응답 트래픽 자동 처리 ▸ NACL은 이미 허용 상태(임시 포트) 가정 【오답 체크】 ▸ (B) curl은 아웃바운드 요청, 인바운드 규칙은 필요 없음 ▸ (C) 임시 포트 범위는 이미 열려있을 가능성 높음, HTTPS는 포트 443 명시 필요 ▸ (D) HTTP(포트 80)는 요청이 HTTPS(포트 443)이므로 관계없음 【시험 포인트】 ▸ 아웃바운드 트래픽은 보안 그룹의 아웃바운드 규칙으로 제어 ▸ 보안 그룹 Stateful 특성: 아웃바운드 허용 시 응답 자동 처리 ▸ 프라이빗 인스턴스 → 인터넷 통신: NAT gateway/Instance + 아웃바운드 보안 그룹

해설

【핵심 용어】 ▸ AWS Backup: EC2, RDS, EBS, S3 등 다양한 AWS 리소스의 통합 백업 관리 ▸ Amazon Data Lifecycle Manager: EBS 스냅샷에만 특화된 자동화 도구 ▸ 태그 기반 리소스 할당: 동적으로 여러 리소스에 백업 정책 적용 【정답 포인트】 ▸ (B) AWS Backup은 EC2와 RDS를 모두 통합 관리 가능 ▸ 다양한 보유 기간(6일, 4주, 11개월, 7년)을 단일 서비스로 관리 ▸ 태그 기반 자동 할당으로 관리 노력 최소화 ▸ 복잡한 다중 보유 요구사항 처리에 최적화 【오답 체크】 ▸ (A) Data Lifecycle Manager는 EBS 스냅샷만 지원, RDS 백업 불가 ▸ (C) Lambda 함수 개발 및 유지보수 필요, 운영 오버헤드 높음 ▸ (D) Data Lifecycle Manager는 EBS만 관리하고 RDS는 별도, 일관성 부족 【시험 포인트】 ▸ EC2+RDS 통합 백업: AWS Backup 선택 ▸ EBS 스냅샷만: Data Lifecycle Manager 고려 ▸ 복잡한 보유 정책(다중 주기): AWS Backup의 강점

해설

【핵심 용어】 ▸ Aurora Auto Scaling: 읽기 복제본 자동 추가/제거로 연결 수 부하 분산 ▸ DatabaseConnections 메트릭: Aurora 레플리카의 활성 연결 수 모니터링 ▸ 대상 추적 스케일링(Target Tracking): 설정한 메트릭 값 유지하도록 자동 조정 【정답 포인트】 ▸ (C) DatabaseConnections 메트릭으로 연결 수 기반 자동 스케일 ▸ 195 연결을 대상으로 설정하면 200 초과 전에 복제본 추가 ▸ 사용자 수요 증감에 자동 대응, 비용 효율적 ▸ Aurora 읽기 복제본 자동 확장이 표준 방식 【오답 체크】 ▸ (A) 다중 마스터는 연결 수 제한 해결 아님, 애플리케이션 수정 필요 ▸ (B) 서버리스 모드는 프로비저닝 자동화일 뿐, 연결 수 제한 없음 ▸ (D) 수직 확장으로 임시 해결이지만 자동화 없음, 확장성 제한 【시험 포인트】 ▸ Aurora 수평 확장: Auto Scaling + 읽기 복제본 추가 ▸ 연결 기반 스케일링: DatabaseConnections 메트릭 활용 ▸ 대상 메트릭은 최대값보다 낮게(195) 설정하여 임계값 도달 전 확장

해설

【핵심 용어】 ▸ EBS 빠른 스냅샷 복원(FSR): 스냅샷에서 볼륨 생성 시 전체 성능을 즉시 제공하는 기능 ▸ 가용 영역(AZ) 제한: FSR은 대상 AZ에서 미리 활성화 필요 ▸ 프로비저닝된 성능: 볼륨 생성 후 워밍업 시간 없이 최대 IOPS 제공 【정답 포인트】 ▸ (A) 두 번째 AZ에 FSR 활성화 → 해당 AZ에서 빠른 복원 가능 ▸ FSR이 없으면 스냅샷 복원 시 성능 워밍업에 시간 소요 ▸ 재해 복구 훈련에서 검증 테스트 신속 처리 가능 ▸ FSR은 추가 비용 발생하지만 복구 시간 우선 【오답 체크】 ▸ (B) 현재 AZ에 FSR 활성화 → 두 번째 AZ 복원 시 효과 없음, 성능 지연 발생 ▸ (C) FSR 활성화 없이 IOPS만 지정 → 복원 시 성능 완전 제공 안 됨 ▸ (D) 원본 볼륨 수정 후 스냅샷 생성, FSR 미언급, 성능 보장 불확실 【시험 포인트】 ▸ EBS FSR은 AZ별 별도 활성화 필수(대상 AZ에서) ▸ 재해 복구 훈련: 빠른 검증이 중요 → FSR 선택 ▸ 스냅샷 복원 성능: FSR 여부에 따라 크게 달라짐

해설

【핵심 용어】 ▸ t3.large: 범용 인스턴스, CPU 버스팅 능력 제한(CPU Credit 기반) ▸ 계산 최적화 인스턴스(c5, c6, c7 등): CPU 성능 극대화, 버스팅 제한 없음 ▸ 수직 확장(Vertical Scaling): 더 큰 인스턴스로 업그레이드 【정답 포인트】 ▸ (B) CPU 집약적 애플리케이션은 계산 최적화 인스턴스로 업그레이드 필요 ▸ t3는 CPU Credit 소진 후 성능 저하, c 시리즈는 지속적 고성능 ▸ 수직 확장만 가능하다는 제약 충족 ▸ 90% CPU 지속 사용량은 t3의 한계 초과 【오답 체크】 ▸ (A) EBS IO 프로비저닝은 CPU 문제 해결 불가, 스토리지 성능용 ▸ (C) 수평 확장 불가능하다는 조건 위배, t2는 더 저성능 ▸ (D) 예약 인스턴스는 비용 절감용, 성능 향상 아님 【시험 포인트】 ▸ t2/t3 인스턴스: 버스팅 기반, 지속적 고성능 불가 ▸ CPU 집약적 워크로드: c, m 시리즈(계산/일반 최적화) 선택 ▸ 수직 확장의 첫 번째 고려: 인스턴스 패밀리 변경(성능 특성)