정답 · 해설

해설

【핵심 용어】 ▸ Auto Scaling — 트래픽에 따른 자동 확장 ▸ Aurora Replicas — 읽기 전용 복제본 ▸ 읽기 집약적(Read-intensive) — 읽기 작업 많음 ▸ 개발 노력 최소 — 기존 코드 수정 최소 【정답 포인트】 ▸ Auto Scaling으로 높은 부하 자동 처리, 수동 재시작 불필요 ▸ ELB로 트래픽 분산 ▸ Aurora는 MySQL 호환이므로 기존 애플리케이션 코드 변경 불필요 ▸ Aurora Replicas로 읽기 작업 분산, 데이터베이스 부하 감소 ▸ 개발 노력: 연결 문자열 수정 정도만 필요 【오답 체크】 (A) CloudFront + Multi-AZ는 읽기 부하 해결 불가(Standby는 읽기용 아님) (C) Global Accelerator는 성능 개선이지 확장성 해결 아님 (D) Lambda 마이그레이션은 개발 노력 많음 【시험 포인트】 "최소 개발 노력"이 핵심입니다. Aurora는 MySQL 호환이므로 기존 애플리케이션 수정 거의 없고, Auto Scaling과 Replicas로 신뢰성을 동시에 해결합니다.

해설

【핵심 용어】 ▸ PGP 개인 키 — 복호화에 필요한 키(공개 키로는 복호화 불가) ▸ 명목상 단계(Nominal Step) — 정상 흐름 처리 ▸ 예외 처리 단계 — 오류 발생 시 처리 ▸ 복호화 매개변수 — 복호화에 필요한 설정 【정답 포인트】 ▸ PGP로 암호화된 데이터 복호화 → 개인 키 필요 ▸ Secrets Manager에서 개인 키 안전하게 저장 ▸ 정상적인 파일 수신 → 명목상 단계에서 처리 ▸ Transfer Family 서버와 연결 → 자동화 흐름 ▸ 복호화 매개변수 설정 → 키 위치, 알고리즘 등 【오답 체크】 (A) PGP 복호화는 개인 키 필요, 공개 키 아님 (B) 예외 처리 단계는 오류 시에만 실행, 정상 복호화는 명목상 단계 (D) 공개 키로 복호화 불가 【시험 포인트】 PGP 암호화/복호화 메커니즘 이해가 중요합니다. 암호화된 데이터 복호화는 개인 키가 필요하며, Transfer Family 워크플로우의 단계 선택(명목상 vs 예외 처리)도 중요합니다.

해설

【핵심 용어】 ▸ MemoryDB for Redis — 내구성 있는 메모리 데이터베이스 ▸ 마이크로초 지연 — 극저지연 요구 ▸ 1분 내 페일오버 — RPO/RTO 요구사항 ▸ 데이터 지속성 — 분석 처리를 위한 데이터 보존 【정답 포인트】 ▸ MemoryDB: 마이크로초 읽기, 밀리초 쓰기 지연 제공 ▸ 다중 AZ 모드: 기본 노드 장애 시 1분 이내 페일오버 ▸ 데이터 지속성: 데이터 파이프라인 분석 지원 ▸ 관리형 서비스: 운영 오버헤드 최소 【오답 체크】 (A) ElastiCache: 메모리 캐시로 데이터 지속성 보장 안 함, 장애 시 데이터 손실 가능 (B) Aurora: 밀리초 수준 지연이 필요하나 마이크로초 달성 어려움 (D) 수동 Redis 관리로 운영 오버헤드 증대 【시험 포인트】 이 문제는 "마이크로초 지연" + "데이터 지속성" + "페일오버" 세 조건을 동시에 만족해야 합니다. MemoryDB는 Redis API 호환이면서도 내구성 스토리지를 제공하는 유일한 선택지입니다.

해설

【핵심 용어】 ▸ 비용 할당 태그(Cost Allocation Tag) — 관리 계정에서 활성화 필요 ▸ AWS CUR(Cost and Usage Report) — 상세한 비용 데이터 ▸ AWS Organizations — 다중 계정 관리 ▸ Amazon Athena — SQL로 CUR 데이터 쿼리 ▸ Amazon QuickSight — 시각화 및 BI 【정답 포인트】 ▸ 비용 할당 태그는 관리 계정에서만 활성화 가능 ▸ CUR은 관리 계정에서 집중식으로 생성하여 모든 계정 비용 수집 ▸ Athena로 S3의 CUR 데이터 쿼리 가능 ▸ QuickSight로 비즈니스 단위별 비용 시각화 ▸ 단일 데이터 소스로 조직 전체 비용 분석 【오답 체크】 (B) 비용 할당 태그는 관리 계정에서만 활성화, CloudWatch는 CUR 분석 도구 아님 (C) CUR을 각 계정에서 생성하면 데이터 분산, 통합 분석 어려움 (D) 비용 할당 태그를 각 계정에서 생성할 수 없음 【시험 포인트】 AWS Organizations 환경에서 비용 할당 및 시각화는 "관리 계정에서의 중앙 집중식 처리"가 핵심입니다. 비용 할당 태그, CUR, Athena, QuickSight의 조합으로 최적 솔루션을 구성합니다.

해설

【핵심 용어】 ▸ ProvisionedThroughputExceededException — DynamoDB 쓰기 용량 초과 ▸ TooManyRequestsException — Lambda 동시성 초과 ▸ 배치 처리 — 요청 통합으로 처리량 개선 ▸ 메모리 증가 — Lambda 성능 향상(CPU도 함께 증가) 【정답 포인트】 ▸ (A) DynamoDB 쓰기 용량 증가: ProvisionedThroughputExceededException 해결 ▸ (D) Kinesis로 요청 버퍼링 + 배치 처리: Lambda 동시성 초과 해결, DynamoDB 처리량 최적화 ▸ 두 가지 병목 동시 해결: DynamoDB 용량 + Lambda 동시성 【오답 체크】 (B) 메모리 증가는 Lambda 실행 속도 개선이나 동시성 자체는 해결 안 함 (C) 페이로드 증가는 처리 시간만 더 증가, 근본 해결 아님 (E) SQS FIFO는 순서 보장이지만 배치 처리 효율 미흡, Kinesis가 더 나음 【시험 포인트】 이 문제는 두 가지 병목을 식별해야 합니다: (1) DynamoDB 쓰기 처리량 부족 (2) Lambda 동시성 부족. Kinesis 스트림은 요청을 버퍼링하고 배치 처리로 효율을 높입니다. 메모리 증가만으로는 동시성 문제 해결 불가합니다.

해설

【핵심 용어】 ▸ WorkSpaces 연결 별칭(Connection Alias) — 클라이언트 접속 엔드포인트 ▸ 페일오버 라우팅(Failover Routing) — 기본 리소스 장애 시 보조 리소스로 전환 ▸ Evaluate Target Health — 헬스 체크 기반 자동 페일오버 ▸ 고가용성(High Availability) — 다중 리전 구성 【정답 포인트】 ▸ 두 리전 각각에 연결 별칭 생성: 각 리전에서 WorkSpaces 접속 가능 ▸ 각 연결 별칭을 해당 리전의 디렉터리와 연결: 사용자 인증 및 리소스 관리 ▸ Route 53 페일오버 라우팅: 기본 리전 장애 시 자동으로 페일오버 리전으로 전환 ▸ Evaluate Target Health = Yes: 헬스 체크 기반 자동 페일오버 【오답 체크】 (B) 다중값 응답은 페일오버 자동화 안 함, 두 리전 모두에 별칭 필요 (C) 가중치 기반은 고가용성이 아니라 트래픽 분산용 (D) 단일 별칭으로는 페일오버 리전 접속 불가 【시험 포인트】 WorkSpaces 고가용성은 "각 리전의 독립적 구성" + "Route 53 페일오버"의 조합입니다. 각 리전은 별도의 연결 별칭과 디렉터리를 가져야 하고, Route 53은 헬스 체크 기반 페일오버를 제공해야 합니다.

해설

【핵심 용어】 ▸ Application Discovery Agent — VM 기반 에이전트, 상세 성능 데이터 수집 ▸ Migration Evaluator Collector — TCO/비용 분석용 ▸ AWS Migration Hub — 통합 마이그레이션 관리 ▸ Quick Insights — 자동 생성 평가 보고서 ▸ 운영 오버헤드 최소 — 단순하고 통합된 흐름 【정답 포인트】 ▸ Application Discovery Agent: VM 설치로 성능, 네트워크, 종속성 데이터 수집 ▸ Migration Hub: 통합 대시보드에서 종속성 시각화 ▸ Quick Insights: Migration Hub에서 직접 평가 보고서 생성 ▸ 단일 에이전트로 모든 요구사항 충족 ▸ 추가 도구 없음 → 운영 오버헤드 최소 【오답 체크】 (B) Migration Evaluator는 비용 분석용이지 종속성 분석 아님, QuickSight 추가 불필요 (C) Agentless는 설정 복잡, 여러 도구 조합 필요 (D) Agent와 Collector 모두 설치는 중복, 운영 오버헤드 증대 【시험 포인트】 Migration Evaluator와 Application Discovery Service는 용도가 다릅니다. 종속성 시각화와 Quick Insights 평가는 Application Discovery Agent + Migration Hub 조합에서 나옵니다.

해설

【핵심 용어】 ▸ AWS WAF — 웹 애플리케이션 방화벽, DoS 공격 방지 ▸ Amazon Inspector — EC2 취약점 검사 ▸ Amazon GuardDuty — 위협 탐지 및 모니터링(차단 아님) ▸ API Gateway — AWS 관리형 서비스 ▸ EC2 인스턴스 — 관리형이 아님 【정답 포인트】 ▸ (WAF) API Gateway에만 WAF 적용: API Gateway는 AWS WAF와 통합, EC2는 별도 보호 불필요 ▸ (Inspector) EC2 레거시 API에 Inspector 적용: EC2 인스턴스의 취약점 검사 ▸ (GuardDuty) 악의적 접속 모니터링: GuardDuty는 탐지 및 분석 역할 【오답 체크】 (A) WAF로 두 API 모두 보호 불가: EC2는 별도 WAF 설정 필요 (B) WAF로 두 API 모두 보호 불가, Inspector로 API Gateway 분석 불필요 (D) Inspector는 보호 도구가 아니라 분석 도구, GuardDuty는 차단 아니라 모니터링 【시험 포인트】 API 보안 3가지 계층: (1) DoS 방지(WAF) (2) 취약점 검사(Inspector) (3) 위협 탐지(GuardDuty). 각 서비스의 용도를 정확히 이해하고, API Gateway(AWS 관리형)와 EC2(고객 관리형)의 차이를 구분해야 합니다.

해설

【핵심 용어】 ▸ RDS Proxy — 데이터베이스 연결 풀링 관리 ▸ 프로비저닝된 동시성(Provisioned Concurrency) — Lambda 워밍, 지연 최소화 ▸ 예약된 동시성(Reserved Concurrency) — 동시성 상한 ▸ 연결 풀 고갈 — 많은 Lambda 동시 실행 시 문제 【정답 포인트】 ▸ RDS Proxy: Lambda의 많은 연결 요청을 관리, 데이터베이스 연결 풀 재사용 ▸ Secrets Manager: 안전한 데이터베이스 자격증명 관리 ▸ 프로비저닝된 동시성: Lambda Cold Start 제거, 지연 최소화 ▸ 애플리케이션 코드: 연결 문자열만 변경(최소한의 변경) 【오답 체크】 (A) 핸들러 외부 연결만으로는 연결 풀 고갈 해결 안 됨 (C) max_connections 증가는 일시적, 근본 해결 아님, DB 재부팅 필요 (D) 예약된 동시성은 동시성 상한, 프로비저닝된 동시성이 필요 【시험 포인트】 API 성능 저하의 원인은 "Lambda Cold Start" + "데이터베이스 연결 고갈". RDS Proxy는 연결 풀링으로 데이터베이스 부하를 줄이고, 프로비저닝된 동시성은 Lambda Cold Start를 제거합니다.

해설

【핵심 용어】 ▸ 인터페이스 엔드포인트 — VPC 엔드포인트로 AWS 서비스 접속 ▸ 프라이빗 DNS 옵션 — 서비스 호스트명을 엔드포인트 프라이빗 IP로 리졸브 ▸ 공개 IP 해석 — DNS가 서비스의 공개 IP를 반환 ▸ 사설 IP 요구사항 — 모든 트래픽 프라이빗 경로 【정답 포인트】 ▸ 문제: DNS 쿼리가 공개 IP 주소를 반환 ▸ 원인: VPC의 프라이빗 DNS 옵션이 비활성화되어 있음 ▸ 해결책: VPC 속성에서 "Enable DNS hostnames" + "Private DNS enabled" 설정 ▸ 효과: 서비스 호스트명이 인터페이스 엔드포인트의 프라이빗 IP로 리졸브 【오답 체크】 (A) 라우팅 테이블은 트래픽 흐름과 무관, DNS 리졸버 문제 (C) 보안 그룹 설정은 이미 구성되어 있을 가능성 높음 (D) Route 53 프라이빗 호스팅 영역도 가능하나, 더 간단한 방법 【시험 포인트】 VPC 엔드포인트 설정 시 "프라이빗 DNS 활성화"는 필수입니다. 이 설정이 없으면 DNS 쿼리가 공개 엔드포인트로 리졸브되어 프라이빗 연결이 불가능합니다.

해설

【핵심 용어】 ▸ Lambda SnapStart — Java 함수의 초기화 스냅샷 캐싱 ▸ 사전 스냅샷 훅(Pre-snapshot Hook) — 스냅샷 전 실행 코드 ▸ 고유 ID — 모든 호출에서 달라야 함 ▸ $LATEST 버전 — SnapStart 미지원 ▸ 게시된 버전 — SnapStart 지원 【정답 포인트】 ▸ SnapStart의 문제: 스냅샷 생성 후 모든 호출에서 동일한 상태로 복원 ▸ 고유 ID 중복 문제: 스냅샷된 고유 ID가 모든 호출에서 동일 ▸ 해결책: (1) 고유 ID 생성 코드를 핸들러로 이동 (런타임에 생성) ▸ (2) 사전 스냅샷 훅으로 라이브러리 초기화 수행 ▸ (3) 게시된 버전에서 SnapStart 활성화 【오답 체크】 (A) $LATEST는 SnapStart 미지원, 모든 코드를 핸들러로 이동하면 성능 저하 (B) SnapStart 없이 프로비저닝된 동시성만으로는 Cold Start 해결 미흡 (C) 고유 ID 생성 코드가 핸들러 외부면 중복 ID 문제 【시험 포인트】 Lambda SnapStart는 자동 초기화 캐싱으로 Cold Start를 최소화합니다. 하지만 호출마다 달라야 하는 값(고유 ID)은 사전 스냅샷 훅과 핸들러에서 처리해야 합니다.

해설

【핵심 용어】 ▸ Systems Manager Agent — EC2에서 Systems Manager와 통신 ▸ IAM 역할 — Systems Manager 작업 권한 부여 ▸ 관리형 인스턴스 — Systems Manager에 등록된 인스턴스 ▸ VPC 엔드포인트 — 선택사항(퍼블릭 IP 있으면 불필요) 【정답 포인트】 ▸ (A) Systems Manager Agent 설치 + 실행: 기본 필수 조건 ▸ (B) IAM 역할: EC2가 Systems Manager API 호출 권한 필요 ▸ 두 가지 모두 없으면 관리형 인스턴스 등록 불가 【오답 체크】 (C) VPC 엔드포인트: 퍼블릭 IP가 있으므로 불필요(추가 보안일 뿐) (D) Application Discovery Agent: Systems Manager와 무관 (E) 서비스 연결 역할: Systems Manager 서비스 자체 역할, 인스턴스와 무관 【시험 포인트】 Systems Manager 등록의 핵심은 (1) Agent 설치 (2) IAM 권한입니다. VM Import로 생성된 AMI는 Systems Manager Agent가 없을 수 있으므로 수동 설치 필요합니다.

해설

【핵심 용어】 ▸ AWS CodeBuild — CI/CD 빌드 및 테스트 실행 ▸ EventBridge — AWS 서비스 간 이벤트 기반 자동화 ▸ Amazon SNS — 알림 배포 ▸ AWS CDK — Infrastructure as Code ▸ 매니페스트 파일 — 구성 기반 기능 토글 ▸ CodePipeline 수동 승인 — 파이프라인 단계 【정답 포인트】 ▸ CodeBuild: CodePipeline 통합, 단위 테스트 및 보안 검사 표준 ▸ EventBridge: CodeBuild 실패 이벤트 캡처 → SNS 알림 ▸ CDK + 매니페스트: 동적 기능 토글, 배포 사용자 정의 ▸ CodePipeline 수동 승인: 리드 개발자 승인 단계 【오답 체크】 (B) Lambda로 테스트 실행 불편, Amplify는 모바일/FE용 (C) Jenkins는 외부 도구, CloudFormation 중첩 스택으로 기능 토글 복잡 (D) CodeDeploy는 배포 도구이지 테스트 도구 아님 【시험 포인트】 이 문제는 5가지 요구사항을 모두 충족하는 서비스 조합을 찾는 것입니다. CodeBuild + EventBridge/SNS + CDK + 수동 승인이 가장 표준적인 조합입니다.

해설

【핵심 용어】 ▸ Storage Gateway 볼륨 게이트웨이 — iSCSI 블록 스토리지 ▸ 캐시 모드 — 자주 액세스하는 데이터 캐싱 ▸ AWS Backup — 특정 시점 복사본(스냅샷) ▸ iSCSI — 블록 스토리지 마운트 ▸ 저지연 액세스 — 자주 액세스하는 데이터 로컬 캐싱 【정답 포인트】 ▸ 볼륨 게이트웨이: iSCSI 인터페이스 제공 (파일 게이트웨이 아님) ▸ 캐시 모드: 자주 액세스하는 데이터를 로컬에 캐싱하여 저지연 ▸ 스토리지 백엔드: Amazon EBS, S3로 자동 백업 ▸ AWS Backup: 특정 시점 복사본 자동 생성 【오답 체크】 (A) 테이프 게이트웨이: 아카이빙용, iSCSI 블록 스토리지 아님 (B) FSx/S3 파일 게이트웨이: 파일 프로토콜(NFS/SMB), iSCSI 아님 (D) 파일 게이트웨이: 파일 프로토콜용, iSCSI 블록 스토리지 아님 【시험 포인트】 Storage Gateway의 3가지 유형: (1) 테이프 게이트웨이 (2) 파일 게이트웨이 (3) 볼륨 게이트웨이. iSCSI 요구사항은 볼륨 게이트웨이를 의미합니다.

해설

【핵심 용어】 ▸ KMS 다중 리전 기본 키 — 여러 리전에서 사용 가능한 마스터 키 ▸ KMS 다중 리전 복제본 키 — 각 리전의 자동 복제본 ▸ 동일 키 — 같은 암호화 키로 모든 리전에서 암호화/복호화 ▸ S3 크로스 리전 복제 — 데이터 자동 복제 【정답 포인트】 ▸ KMS 다중 리전 기본 키: 모든 리전에서 동일한 키 ID 사용 ▸ 각 리전에 복제본 키 자동 생성: 리전별 독립 관리 ▸ 암호화/복호화: 모든 리전에서 동일한 키로 처리 ▸ 애플리케이션 코드: 각 리전의 복제본 키를 가리키도록 업데이트(선택사항) ▸ 자동 복제 및 회전: AWS 관리 【오답 체크】 (B) 각 리전의 별도 키는 동일 키 요구사항 미충족 (C) 인증서는 암호화용이 아니라 인증용 (D) 키 자료 내보내기: 보안 위험, KMS 다중 리전 기능 무시 【시험 포인트】 KMS 다중 리전 키는 크로스 리전 데이터 암호화를 위해 설계된 서비스입니다. 모든 리전에서 동일한 마스터 키로 동작하면서도 각 리전에서 독립적으로 관리됩니다.

해설

【핵심 용어】 ▸ Health Check Grace Period — 인스턴스 시작 후 상태 확인을 시작하기 전의 대기 시간 ▸ User Data Script — 인스턴스 시작 시 실행되는 초기화 스크립트 【정답 포인트】 ▸ 문제의 원인: S3에서 콘텐츠를 다운로드하는 사용자 데이터 스크립트가 완료되기 전에 ALB 상태 확인이 시작되어 인스턴스가 실패로 표시됨 ▸ 해결책: Auto Scaling 그룹의 Health Check Grace Period를 증가시켜 스크립트가 완료될 때까지 상태 확인을 지연 【오답 체크】 (A) 인스턴스 크기 증대는 S3 다운로드 시간 단축과 무관 (B) ALB 상태 확인 시간 제한은 의미 있는 파라미터가 아님 (Grace Period와 다름) (C) 상태 확인 경로 변경은 근본 원인인 초기화 시간 미흡을 해결하지 못함 【시험 포인트】 ▸ Auto Scaling + Health Check: Grace Period는 인스턴스 워밍업 시간을 제공 ▸ User Data 스크립트 완료 시간 고려: 프로덕션 변경 금지 시 Grace Period 조정이 유일한 해결책

해설

【핵심 용어】 ▸ Foreign Table — 원격 데이터베이스의 데이터를 로컬에서 쿼리할 수 있도록 하는 기능 ▸ AWS Direct Connect — 온프레미스와 AWS 간의 전용 네트워크 연결 ▸ PostgreSQL Native Spatial Data — PostGIS를 통한 공간 데이터 지원 【정답 포인트】 ▸ RDS PostgreSQL: 공간 데이터, cron 작업, 외부 테이블 쿼리 모두 지원 가능 ▸ AWS Direct Connect: 온프레미스 Oracle 데이터베이스와 안전한 직접 연결 제공 ▸ SCT + DMS: Oracle에서 PostgreSQL로의 마이그레이션 도구 【오답 체크】 (A) DynamoDB는 공간 데이터와 외부 테이블 쿼리 미지원 (B) SQL Server는 PostgreSQL보다 공간 데이터 지원이 제한적 (C) EC2 호스팅은 운영 오버헤드 증가 【시험 포인트】 ▸ Oracle → PostgreSQL 마이그레이션 패턴: SCT + DMS + RDS ▸ 온프레미스 연결 + 외부 테이블: Direct Connect가 최적

해설

【핵심 용어】 ▸ CloudFormation DeletionPolicy — 스택 삭제 시 리소스 처리 방식 지정 (Delete, Retain, Snapshot) ▸ Custom Resource — CloudFormation에서 Lambda 함수를 실행하여 사용자 정의 작업 수행 ▸ Non-empty S3 Bucket — CloudFormation 삭제 실패의 일반적인 원인 【정답 포인트】 ▸ 문제: S3 버킷에 객체가 남아있으면 스택 삭제 실패 ▸ 해결책: Lambda 함수를 사용자 지정 리소스로 추가하여 스택 삭제 전 S3 객체 정리 ▸ DependsOn: S3 버킷 정리 후 리소스 삭제 순서 보장 【오답 체크】 (B) Delete 정책은 비어있지 않은 S3 버킷 삭제 불가 (C) DeletionPolicy Snapshot은 S3에 미지원 (RDS 전용) (D) EFS로 전환하면 아키텍처 변경이 됨 (요구사항 위반) 【시험 포인트】 ▸ CloudFormation + S3 + 임시 데이터: Custom Resource + Lambda 패턴 ▸ 스택 삭제 전 정리: DependsOn으로 실행 순서 제어

해설

【핵심 용어】 ▸ Multipart Upload Incompleteness — 실패한 멀티파트 업로드 조각이 비용 발생 ▸ S3 Lifecycle Policy — 객체 수명 주기에 따른 자동 정책 ▸ S3 Storage Class — Standard, Standard-IA, Glacier 등 접근 패턴에 따른 선택 【정답 포인트】 ▸ (C) 불완전 멀티파트 업로드 정리: 7일 만료로 저장 비용 절감 (인터넷 연결 불안정 대비) ▸ (E) 180일 이후 Standard-IA 전환: 접근 패턴 맞춤형 비용 최적화 【오답 체크】 (A) Requester Pays는 익명 사용자에게 비용 전가 (응급 요청 아님) (B) Transfer Acceleration은 업로드 속도만 개선, 비용 절감 아님 (D) 1일 후 Glacier는 너무 빠름 (180일 동안 자주 액세스하는 데이터) 【시험 포인트】 ▸ 비용 최적화 3단계: 불완전 객체 정리 → 접근 패턴 기반 스토리지 클래스 전환 ▸ 멀티파트 업로드 실패: AbortIncompleteMultipartUpload로 자동 정리

해설

【핵심 용어】 ▸ Provisioned Concurrency — Lambda 콜드 스타트 제거 (미리 초기화된 인스턴스 대기) ▸ Reserved Instances — 일정한 사용 패턴에 대한 비용 최적화 (12개월 일정 사용) ▸ AWS WAF — Application Layer 공격(SQL Injection) 차단 ▸ AWS Shield Advanced — DDoS 보호 (웹 악용과는 다름) 【정답 포인트】 ▸ Lambda 성능: Provisioned Concurrency로 콜드 스타트 제거 ▸ DB 비용: RDS 예약 인스턴스 (일정한 온디맨드 사용) ▸ 보안: AWS WAF가 SQL Injection/웹 공격 방어에 최적 (Shield Advanced는 DDoS 전용) 【오답 체크】 (A) Timeout 증가는 성능 개선이 아님 (B) Redshift는 OLAP용, OLTP(주문 처리)에 부적합 / Inspector는 애플리케이션 취약점 분석용 (C) Aurora Serverless는 비용 절감이지만, 예약 인스턴스가 더 저렴 (일정 사용) 【시험 포인트】 ▸ Lambda + 트래픽 피크: Provisioned Concurrency 필수 ▸ 공격 유형별 방어: WAF(L7 공격) vs Shield(DDoS) 구분