정답 · 해설

해설

【핵심 용어】 ▸ CloudWatch Logs Subscription Filter — 로그 스트리밍 대상 지정 ▸ Amazon Kinesis Data Firehose — S3로의 자동 배치 전송 ▸ S3 Glacier — 저렴한 장기 아카이브 스토리지 ▸ S3 Lifecycle Policy — 자동 스토리지 클래스 전환 ▸ 3,650일 ≈ 10년 【정답 포인트】 ▸ "아카이브로 S3 전송" → Subscription Filter + Firehose 조합 ▸ Firehose는 CloudWatch Logs 직접 지원하는 유일한 실시간 전송 서비스 ▸ S3 Lifecycle으로 90일 후 Glacier 전환 → 저비용 10년 보관 ▸ Reduced Redundancy는 deprecated 스토리지 클래스 【오답 체크】 (A) AWS Glue는 데이터 통합/ETL 도구, CloudWatch 스트리밍 대상 아님 (C) 직접 S3 전송 불가 → 별도 서비스 필요 (E) Reduced Redundancy는 이제 사용 불가, 보안 위험 【시험 포인트】 CloudWatch Logs 아카이브 패턴: Subscription Filter → Firehose → S3 S3 Lifecycle Glacier 전환으로 비용 최적화 10년 보관 = 3,650일 또는 10 years Firehose 배치 전송으로 비용 효율적

해설

【핵심 용어】 ▸ AWS SAM (Serverless Application Model) — Lambda 배포 최적화 ▸ DeploymentPreference — LambdaCanary10Percent10Minutes 설정 ▸ AutoPublishAlias — 버전과 별칭 자동 게시 ▸ CloudWatch Alarms — 오류 감지 및 롤백 트리거 【정답 포인트】 ▸ 선택지 B (SAM): CloudFormation보다 Lambda 카나리 배포에 특화 - AutoPublishAlias와 DeploymentPreference로 자동 배포 - LambdaCanary10Percent10Minutes = 카나리 배포 설정 ▸ 선택지 C (CodePipeline + CodeBuild): SAM 배포를 위한 CI/CD - buildspec.yml로 SAM 빌드 및 배포 자동화 ▸ 선택지 F (CloudWatch 알람): 각 함수별 Errors 메트릭 감시 - 버전별 차원 추가로 정확한 오류 감지 【오답 체크】 (A) CloudFormation + Lambda::Version + Alias는 카나리 배포 미지원 (D) appspec.yml은 CodeDeploy용, CloudFormation 배포에 부적절 (E) Composite Alarm은 종합 감시용, 개별 함수 오류 감지 불가 【시험 포인트】 SAM vs CloudFormation 선택: 카나리 배포는 SAM 필수 DeploymentPreference와 AutoPublishAlias 조합 각 Lambda 버전에 대한 CloudWatch Errors 메트릭 감시 CI/CD는 SAM 배포 지원하는 CodeBuild 프로젝트 필요

해설

【핵심 용어】 ▸ CodeDeploy 배포 그룹 — 배포할 인스턴스 모음 ▸ CodeDeploy 에이전트 — EC2에서 배포 수행 ▸ Instance Profile — EC2가 AWS 서비스와 통신하기 위한 IAM 역할 ▸ "Skipped" 상태 — 배포 전 사전 조건 불만족 【정답 포인트】 ▸ "모든 이벤트가 Skipped" = 배포 시작 단계에서 실패 ▸ 원인 A: 네트워크 연결 불가 - EC2가 CodeDeploy 엔드포인트 연결 불가 → 에이전트가 명령 수신 불가 - NAT/IGW 없음 → 아웃바운드 인터넷 연결 불가 ▸ 원인 D: Instance Profile IAM 역할 부족 - EC2가 S3에서 배포 아티팩트 다운로드 불가 - CodeDeploy API 호출 권한 부족 【오답 체크】 (B) IAM 사용자 권한 부족 → 배포 생성 단계에서 실패, 배포는 시작됨 (C) 인스턴스 등록 불필요 → Auto Scaling 그룹이나 태그 기반 선택 가능 (E) appspec.yml 누락 → 배포 개시 후 BeforeInstall 단계에서 실패, Skipped 아님 【시험 포인트】 CodeDeploy "Skipped" 상태 → 사전 검증 실패 인스턴스 연결성: 인터넷 접근 + 에이전트 실행 Instance Profile: CodeDeploy 아티팩트 액세스 필수

해설

【핵심 용어】 ▸ Amazon EC2 Image Builder — AMI 자동 생성 및 관리 ▸ AWS Systems Manager Parameter Store — 애플리케이션 설정 중앙 저장소 ▸ CloudFormation 동적 참조 — SSM 파라미터 자동 참조 ▸ 확장성 — 개발자의 추가 작업 최소화 【정답 포인트】 ▸ "가장 확장성 있는 솔루션" → 자동화된 중앙 배포 + 최소 개입 ▸ EC2 Image Builder: 보안 팀이 AMI를 자동으로 구축하고 Parameter Store에 게시 ▸ CloudFormation SSM 동적 참조: - Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> - 개발자는 Parameter Store 이름만 지정 - 가장 최신 AMI 자동 반영 ▸ "수동 개입 없음" → 이메일 검색 프로세스 완전 제거 【오답 체크】 (A) CloudFormation으로 AMI 생성 → 이미지 빌드 도구 아님 (B) CodePipeline + S3 → 개발자가 S3 위치 관리 필요 (확장성 낮음) (D) SNS + Lambda → 개발 팀이 수동으로 Lambda 함수 작성 (자동화 불완전) 【시험 포인트】 EC2 Image Builder → Parameter Store → CloudFormation 자동화 체인 CloudFormation 동적 참조로 최신 파라미터 자동 사용 확장성 = 새 개발 팀이 추가 구성 없이 사용 가능

해설

【핵심 용어】 ▸ AllowTraffic 라이프사이클 이벤트 — CodeDeploy 배포 마지막 단계 ▸ ALB 대상 그룹 상태 검사 — 배포 후 트래픽 흐름 가능 여부 확인 ▸ BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic 순서 【정답 포인트】 ▸ "AllowTraffic 단계에서만 실패" → 배포 자체는 성공 ▸ AllowTraffic 목적: ALB가 새 인스턴스를 "healthy" 상태로 표시할 때까지 대기 ▸ 상태 검사 오류 종류: - 상태 검사 경로 잘못됨 - 상태 검사 포트 잘못됨 - 정상 코드 범위 잘못됨 (예: 200 기대하나 503 수신) ▸ "배포 로그에 원인이 없음" → 배포는 성공했으나 ALB가 인스턴스를 healthy로 표시 못함 【오답 체크】 (A) appspec.yml 스크립트 오류 → BeforeAllowTraffic 단계에서 실패, AllowTraffic 아님 (B) IAM 권한 부족 → 배포 생성 단계에서 실패, AllowTraffic 도달 불가 (D) CodeDeploy 에이전트 부재 → 초기 배포 단계에서 실패, AllowTraffic 도달 불가 【시험 포인트】 AllowTraffic은 "대상 그룹 상태 검사" 통과 대기 ALB 상태 검사 구성이 배포 성공 결정 배포 성공 ≠ ALB 상태 검사 통과

해설

【핵심 용어】 ▸ AWS PrivateLink — VPC 간 프라이빗 연결 ▸ VPC 엔드포인트 — PrivateLink를 통한 서비스 노출 ▸ 서비스 엔드포인트 공급자 — NLB + PrivateLink 조합 ▸ 최소 변경 — 기존 VPC 및 서브넷 유지 【정답 포인트】 ▸ "각 팀의 변경사항 최소" → 팀별 VPC 유지, 중앙 공유 자원 제거 ▸ PrivateLink + NLB 장점: - 각 VPC가 독립적으로 NLB 생성 (팀이 제어) - PrivateLink로 cross-VPC 프라이빗 연결 - VPC 피어링 수동 관리 불필요 - 20개 팀 × 19개 팀 = 190개 피어링 불필요 ▸ "각 NLB를 다른 팀이 구독" → 자동 권한 관리 【오답 체크】 (A) 중앙 VPC 공유 → 팀이 다른 팀 리소스와 섞임, 보안/관리 복잡 (C) VPC 피어링 → 20개 VPC = C(20,2) = 190개 피어링 (관리 과다) (D) Transit Gateway → 복잡한 라우팅 테이블 관리, 변경사항 많음 【시험 포인트】 PrivateLink는 "서비스" 모델: NLB 뒤에 구독자 붙임 VPC 피어링은 "메시(mesh)" 모델: O(n²) 복잡도 Cross-account 다중 팀 → PrivateLink 우수 최소 변경 = 팀별 리소스 유지

해설

【핵심 용어】 ▸ AccessDenied — 인증 또는 권한 검증 실패 ▸ S3 버킷 정책 — 버킷 레벨 액세스 제어 ▸ IAM 역할 — EC2 인스턴스의 권한 설정 ▸ 두 계층 인증: (IAM 역할 허용) AND (버킷 정책 허용) 【정답 포인트】 ▸ AccessDenied 원인은 권한 체계에만 관련 ▸ 원인 B: S3 버킷 정책 오류 - 버킷 정책에 EC2의 IAM 역할 ARN 누락 - 버킷 정책의 Principal이 잘못됨 - Effect가 "Deny"로 설정됨 ▸ 원인 D: IAM 역할 구성 오류 - EC2 인스턴스 프로필이 없음 - 역할에 s3:GetObject 권한 없음 - 역할의 Trust relationship이 EC2 서비스를 신뢰하지 않음 【오답 체크】 (A) 기본 암호화 → 투명적 암호호 해제, AccessDenied 원인 아님 (C) S3 Glacier 객체 → NoSuchKey 또는 InvalidObjectState 에러, AccessDenied 아님 (E) S3 Versioning → 버전 메타데이터일 뿐, 액세스 권한과 무관 【시험 포인트】 S3 액세스 = IAM 역할 AND 버킷 정책 AND (객체 ACL) AccessDenied = 권한 체계 검증 실패 "오류"라는 표현 → 설정 미스 또는 오류 설정

해설

【핵심 용어】 ▸ AWS OpsWorks Stacks — Chef 레시피 기반 애플리케이션 배포 ▸ 라이프사이클 이벤트 — Setup, Configure, Deploy, Undeploy, Shutdown ▸ Configure 이벤트 — 레이어 멤버십 변경 시 자동 실행 ▸ Chef 레시피 — 자동화된 인프라 구성 【정답 포인트】 ▸ "노드 추가/제거할 때마다 클러스터 재구성" → OpsWorks Configure 이벤트 ▸ Configure 이벤트의 특징: - 인스턴스가 레이어에 추가/제거될 때 자동 실행 - 해당 레이어의 모든 인스턴스에서 실행 - 현재 레이어 멤버 정보 접근 가능 ▸ Chef 레시피: - EC2::SecurityGroup에서 IP 리스트 추출 - nodes.config 파일 자동 생성 - 서비스 자동 재시작 【오답 체크】 (B) CodeDeploy + 버전 제어 → 수동 커밋 필요, 자동화 불완전 (C) S3 + crontab → 폴링 방식, 실시간 반응 지연 (D) User Data → 인스턴스 시작 시만 실행, 추가/제거 이벤트 미감지 【시험 포인트】 OpsWorks Configure 라이프사이클 → 클러스터 멤버 변경 감지 Chef 레시피로 nodes.config 자동 생성 OpsWorks vs CodeDeploy: OpsWorks는 라이프사이클 이벤트 풍부

해설

【핵심 용어】 ▸ Content-MD5 — PutObject 요청 헤더, S3 검증 ▸ ETag — S3 응답 헤더, 객체 무결성 확인 ▸ MD5 체크섬 — 전송 중 손상 감지 ▸ PutObject 요청-응답 검증 【정답 포인트】 ▸ Content-MD5 매개변수 (선택지 B): - PutObject 요청에 client-computed MD5 제시 - S3이 업로드된 바이트의 MD5와 비교 - 불일치 → 요청 거부 (오류 반환) - 확인됨 → 정상 업로드 ▸ ETag 확인 (선택지 D): - PutObject 응답의 ETag는 S3 저장 객체의 MD5 - ETag와 원본 파일의 MD5 비교 - 일치 → 안전한 전송 확인 【오답 체크】 (A) VersionId는 object versioning ID, MD5와 무관 (C) 태깅 매개변수는 객체 태그용, 체크섬 저장소 아님 (E) Metadata에 저장하면 검증 기능 없음, 단순 저장소 【시험 포인트】 Content-MD5: 요청 시 전송 오류 감지 (사전 검증) ETag: 응답 시 저장된 객체 검증 (사후 검증) 두 방법 조합 = 완벽한 무결성 확인

해설

【핵심 용어】 ▸ AWS CodePipeline 작업 — 배포 단계 간 연결 ▸ Lambda 함수 — 무서버 계산 ▸ CloudFront 무효화 — 캐시 갱신 ▸ API Gateway SDK 내보내기 — 자동화 가능 【정답 포인트】 ▸ "배포 중에 자동으로" → CodePipeline 단계에 통합 ▸ CodePipeline 기반 솔루션이 이벤트 기반보다 우수: - 배포 성공 직후 자동 실행 (순차 보장) - 배포와 SDK 갱신의 순서 보장 ▸ Lambda 함수: 1. API Gateway에서 SDK 다운로드 2. S3에 업로드 3. CloudFront 무효화 요청 【오답 체크】 (B) CodePipeline-S3 통합 없음, CloudFront 캐시 무효화만으로는 부족 (C) UpdateStage 이벤트 → 배포 시점과 맞지 않음 (시간 편차 있음) (D) CreateDeployment 이벤트는 API Gateway 배포 생성 시점 - UpdateStage와 달리 스테이지 변경까지의 지연 존재 - S3 캐시 무효화는 CloudFront 캐시 문제 미해결 【시험 포인트】 CodePipeline 단계 내 Lambda 실행 → 순차 보장 EventBridge 기반은 비동기 → 타이밍 불일치 위험 CloudFront 무효화 필수 (S3 캐시 무효화로는 부족)

해설

【핵심 용어】 ▸ CodeDeploy Lambda 라이프사이클: BeforeInstall → AfterInstall → BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic ▸ BeforeAllowTraffic — 트래픽 허용 전 검증 ▸ AppSpec 훅 — 배포 단계별 커스텀 스크립트 【정답 포인트】 ▸ "배포 후 몇 초" → 트래픽 허용 후 발생 ▸ "데이터베이스 변경사항 전파 대기" → AllowTraffic 직전 검증 필요 ▸ BeforeAllowTraffic 훅: - 목적: 새 Lambda 버전이 트래픽 수신 전 준비 확인 - 동작: 데이터베이스 상태 체크, 필요한 레코드 존재 확인 - 성공 시 → AllowTraffic 진행 - 실패 시 → 배포 실패 (트래픽 허용 안 함) 【오답 체크】 (B) AfterAllowTraffic → 이미 트래픽 허용 후, 지연 발생 (C) BeforeInstall → 배포 전, 배포 후 발생하는 문제와 무관 (D) ValidateService는 CodeDeploy Lambda 표준 훅 아님 【시험 포인트】 CodeDeploy Lambda 라이프사이클 단계 순서 BeforeAllowTraffic = 트래픽 허용 전 최종 검증 AppSpec 훅으로 데이터베이스 준비 상태 확인

해설

【핵심 용어】 ▸ AWS Config — 규정 준수 감시 ▸ EventBridge — 이벤트 기반 아키텍처 ▸ Input Transformer — 이벤트 데이터 변환 ▸ restricted-ssh 규칙 → 보안 그룹 SSH 포트(22) 제한 【정답 포인트】 ▸ 요구사항: NON_COMPLIANT 보안 그룹의 "이름과 ID" 포함 ▸ EventBridge 규칙: - 소스: aws.config - 이벤트 유형: ComplianceStateChange - 필터: detail.newEvaluationResult.complianceType = "NON_COMPLIANT" ▸ Input Transformer: - AWS Config 이벤트에서 보안 그룹 이름, ID, 상태 추출 - SNS 메시지 커스텀 포맷 생성 ▸ 결과: 사용자 정의된 알림 발송 【오답 체크】 (B) AWS Config는 직접 SNS 발행 기능 없음, 필터 정책도 문자 기반이라 보안 그룹 ID 추출 불가 (C) AWS Systems Manager Run Command는 SNS에서 실행 불가, 잘못된 아키텍처 (D) "모든 NON_COMPLIANT" → restricted-ssh만 필터링 필요, 과도한 이벤트 【시험 포인트】 AWS Config 평가 변경 이벤트 → EventBridge 규칙 Input Transformer로 이벤트 데이터 추출 및 포맷 restricted-ssh 규칙 특화 → 특정 규칙으로 필터링

해설

【핵심 용어】 ▸ RPO (Recovery Point Objective) — 2시간: 최대 2시간의 데이터 손실 허용 ▸ RTO (Recovery Time Objective) — 10분: 10분 내 복구 필요 ▸ Aurora Global Database — 다중 리전 비동기 복제 (RPO: 1초 이상) ▸ Aurora Multi-Master — 다중 리전 동기 클러스터 【정답 포인트】 ▸ 선택지 B (Aurora Global Database): - 데이터: 기본 리전에서 보조 리전으로 비동기 복제 - RPO: 일반적으로 1~5초 (2시간 요구 충족) - RTO: 보조 리전 승격 10분 이내 가능 - 애플리케이션: Route 53 + 두 리전 ALB로 자동 장애 조치 ▸ 선택지 D (Route 53 + 다중 리전): - 애플리케이션: 두 리전 배포 - 라우팅: Route 53 장애 조치 + 상태 검사 - RTO: 건강 검사 실패 감지 → 장애 조치 (1~3분) - Auto Scaling: 각 리전의 수요 대응 【오답 체크】 (A) "단일 가용 영역" → AZ 실패 시 복구 불가, 다중 리전 아님 (C) Aurora Multi-Master → 동기 복제는 성능 저하, 관리 복잡 (선택지 아님) (E) "다중 리전 Auto Scaling 그룹" → AWS 기능 없음, 수동 capacity 조정 필요 (RTO 10분 초과) 【시험 포인트】 RPO/RTO 계산 Aurora Global Database vs Multi-Master Route 53 장애 조치 라우팅 Multi-region 애플리케이션 배포 패턴

해설

【핵심 용어】 ▸ AWS CodePipeline runOrder — 작업 실행 순서 ▸ runOrder 값이 같음 → 병렬 실행 ▸ runOrder 값이 다름 → 순차 실행 【정답 포인트】 ▸ "5개 독립적 Lambda 함수" → 서로 의존성 없음 ▸ "순차적으로 빌드, 테스트, 패키징, 배포" → 현재 sequential ▸ 솔루션: CodePipeline 각 Lambda에 대한 작업의 runOrder를 같은 값으로 설정 ▸ 효과: - Lambda 1, 2, 3, 4, 5를 동시 처리 - 파이프라인 실행 시간 = 1개 Lambda 처리 시간 (기존은 5배) 【오답 체크】 (A) 네트워크 처리량 증가 → 각 Lambda의 처리 시간만 단축 (병렬화 아님) (B) 대칭 멀티프로세싱 → CodeBuild 내부 병렬화, 이미 진행 중 가능성 높음 (D) VPC 전용 인스턴스 → 처리량 증가만, 병렬화 아님 【시험 포인트】 CodePipeline 병렬 실행 = runOrder 값 독립적 리소스 = 병렬 처리 기회 파이프라인 성능 최적화의 첫 단계

해설

【핵심 용어】 ▸ UPDATE_ROLLBACK_FAILED — 롤백 실패 상태 (복구 필요) ▸ continue-update-rollback — 롤백 재시도 ▸ cancel-update-stack — 스택 업데이트 취소 ▸ IAM 역할 — CloudFormation 리소스 생성/삭제 권한 【정답 포인트】 ▸ 오류 분석: - "deployment failed" → Auto Scaling 그룹 업데이트 실패 - "rollback also failed" → 롤백 중 추가 오류 (권한 부족) - UPDATE_ROLLBACK_FAILED → IAM 역할 권한 부족 ▸ 원인: CloudFormation 스택 역할이 Auto Scaling 그룹 작업(CreateAutoScalingGroup, UpdateAutoScalingGroup, DeleteAutoScalingGroup) 권한 부족 ▸ 해결: 1. IAM 역할에 필요한 권한 추가 (autoscaling:*, ec2:*) 2. continue-update-rollback 실행 → 롤백 재시도 3. 롤백 완료 후 스택 UPDATE_ROLLBACK_COMPLETE 상태 【오답 체크】 (A) 서브넷 매핑 업데이트 → Auto Scaling 문제와 무관, update-stack-set은 StackSet용 (C) 할당량 증가 → 오류 메시지에 할당량 언급 없음, cancel-update-stack은 상태 해결 불가 (D) Auto Scaling 그룹 수동 삭제 → CloudFormation 스택 불일치, 추후 문제 발생 【시험 포인트】 UPDATE_ROLLBACK_FAILED 상태는 IAM 권한 부족 신호 continue-update-rollback 명령의 정확한 사용 시기 CloudFormation 역할 권한 범위

해설

【핵심 용어】 ▸ CloudWatch Logs Insights — 여러 로그 그룹을 통합하여 쿼리하는 전용 도구 ▸ CloudTrail delivery — API 활동 로깅 기능 【정답 포인트】 ▸ CloudWatch Logs와 CloudTrail 통합 → CloudWatch Logs Insights로 단일 인터페이스에서 모두 검색 가능 ▸ 비용 효율적이고 운영 편의성 우수 【오답 체크】 (A) S3로 저장한 CloudTrail 로그는 CloudWatch에서 직접 쿼리 불가 (C) Redshift는 과도한 복잡성 및 비용 증가 (D) Athena는 S3 쿼리 전용이지만 CloudWatch Logs 데이터는 S3가 아님 【시험 포인트】 로그 통합 및 쿼리 → CloudWatch 에코시스템 활용이 최선

해설

【핵심 용어】 ▸ Amazon Inspector — EC2 취약점 스캔 전문 서비스 ▸ CloudWatch Logs — 시스템 로그 캡처 및 감사 추적 저장소 【정답 포인트】 ▸ 취약점 탐지 → Inspector (취약점 스캔 기능) ▸ 로그인 감사 → CloudWatch Agent로 로그 수집 및 Logs 저장 【오답 체크】 (A) Kinesis Agent는 오버헤드, 감사 추적에 부적합 (B) CloudTrail은 AWS API 활동용, 시스템 로그인 감시 불가 (C) CloudWatch는 취약점 탐지 불가, Config daemon도 이용 목적 불명확 【시험 포인트】 취약점 → Inspector, 감사 로그 → CloudWatch Logs 조합

해설

【핵심 용어】 ▸ Auto Scaling lifecycle events — 인스턴스 시작/종료 시 자동 트리거 ▸ SNS 알림 — 직접 이메일 전송 기능 【정답 포인트】 ▸ "failed instance launch" → Auto Scaling 그룹 자체가 이벤트 감지 및 SNS 알림 전송 기능 보유 ▸ 가장 직접적이고 빠른 방법 【오답 체크】 (A) 상태 체크는 이미 시작 후 상태 모니터링용, 시작 실패 감지 불가 (C) AttachInstances API는 실제 시작 실패와 무관 (D) EC2 상태 체크는 시작 실패 아닌 이미 실행 중인 인스턴스 모니터링 【시험 포인트】 Auto Scaling 그룹 → lifecycle 알림 → SNS 최적경로

해설

【핵심 용어】 ▸ AWS Config conformance pack — 조직 전체 규칙 일괄 배포 및 관리 메커니즘 ▸ 위임된 관리자 — 계정 권한 제어의 중심 【정답 포인트】 ▸ 멤버 사용자의 수정 불가 → AWS Config conformance pack은 중앙 관리로 읽기 전용 강제 ▸ 위임된 관리자 배포 → 중앙 제어 및 보안 정책 일관성 보장 【오답 체크】 (A) CloudFormation StackSets + 관리 계정 = 멤버가 직접 수정 가능성 높음 (B) StackSets로 배포하면 멤버 수정 통제 불가 (C) CloudFormation은 구성 전용, 거버넌스 강제력 약함 【시험 포인트】 중앙 거버넌스 강제 → conformance pack + 위임 관리자

해설

【핵심 용어】 ▸ GetRecords.IteratorAgeMilliseconds — 소비자가 처리 못한 데이터 적체도 지표 ▸ 수평 확장 — EC2 인스턴스 자동 추가로 처리량 증가 【정답 포인트】 ▸ "fall behind" → 소비자 처리 능력 부족 ▸ GetRecords.IteratorAgeMilliseconds로 자동 확장 트리거 → EC2 추가 인스턴스 배포 ▸ 보존 기간 연장 → 데이터 손실 방지 【오답 체크】 (A) S3 저장은 실시간 처리 아님 (C) Lambda는 동시성 제한, 갑작스러운 버스트에 부적합 (D) 샤드 증가는 비용 증가하고 소비자 능력 없으면 도움 안 됨 【시험 포인트】 메트릭 기반 자동 확장 → EC2 수평 확장이 최적