정답 · 해설

해설

【핵심 용어】 ▸ CloudWatch Cross-Account Observability(교차 계정 관찰성) — 모니터링 계정에서 여러 소스 계정의 지표·로그·트레이스를 통합 조회 ▸ CloudFormation 템플릿 — 소스 계정에 데이터 공유 링크를 손쉽게 배포 ▸ SCP / IAM 사용자·정책 — 권한 경계·접근 제어용으로 관찰성 데이터 통합 조회 기능 아님 【정답 포인트】 ▸ "여러 계정 관찰성 데이터를 CloudWatch로 통합 쿼리·시각화" → CloudWatch 교차 계정 관찰성 활성화 ▸ 모니터링 계정 활성화 + 각 계정에 제공 CloudFormation 템플릿 배포로 데이터 공유 → 요구 충족 【오답 체크】 (B) SCP는 권한 제한 정책이며 관찰성 데이터 공유·조회 기능이 없음. (C) 계정별 IAM 사용자/정책 방식은 확장성·운영 부담이 크고 통합 관찰성 기능이 아님. (D) 교차 계정 IAM 정책 수작업 방식도 통합 관찰성 기능이 아니라 부적합. 【시험 포인트】 다계정 지표·로그 통합 조회 → CloudWatch Cross-Account Observability.

해설

【핵심 용어】 ▸ AWS WAF IP set / IP match condition — 특정 악성 IP를 룰로 차단(이미 CloudFront에 WAF 적용 중) ▸ CloudFront + WAF — 엣지에서 요청 필터링, IP 차단 룰 추가로 즉시 대응 ▸ NACL / Security Group — VPC 리소스용 L3/L4 제어이나 CloudFront 앞단 트래픽엔 부적용 【정답 포인트】 ▸ "악성 IP 차단" + "이미 WAF 사용 중" → WAF에 IP 매치 조건(IP set) 추가가 가장 직접적 ▸ 룰 추가만으로 엣지에서 해당 IP를 차단 → 최소 변경으로 요구 충족 【오답 체크】 (A) CloudFront에는 네트워크 ACL이라는 개념이 없음(잘못된 구성). (C) EC2 NACL 차단은 CloudFront 뒤 오리진 단이라 CloudFront/WAF를 우회하는 트래픽 흐름상 부적절. (D) 보안 그룹은 명시적 "거부" 규칙을 지원하지 않음(허용만 가능). 【시험 포인트】 WAF 사용 중 특정 IP 차단 → WAF IP set 룰 추가. SG는 deny 불가.

해설

【핵심 용어】 ▸ AWS IAM Identity Center(구 AWS SSO) — 외부 IdP 연동 + 조직 다계정 SSO를 대규모 사용자에 제공 ▸ 외부 IdP 연동(SAML/SCIM) — 기존 IdP로 인증, 사용자·그룹 프로비저닝 ▸ IAM 사용자 — 사용자당 개별 생성은 수천 명 규모·연합에 비효율 【정답 포인트】 ▸ "기존 IdP로 인증 + 조직 10계정 + 수천 명 접근" → IAM Identity Center를 IdP에 연결, 사용자/그룹 프로비저닝 ▸ 다계정 SSO + 연합 인증을 중앙에서 관리 → 대규모 확장·표준 방식 【오답 체크】 (A) 계정마다 IAM 사용자 생성은 수천 명 규모에서 관리 불가능·비효율. (B) 루트 사용자 동기화는 보안상 부적절하고 불가능한 방식. (D) RAM은 리소스 공유용이지 사용자 인증·연합 도구가 아님. 【시험 포인트】 기존 IdP + 다계정 대규모 SSO → IAM Identity Center 연동.

해설

【핵심 용어】 ▸ AdministratorAccess — 모든 서비스·리소스 전체 접근을 부여하는 AWS 관리형 자격 기반(identity-based) 정책 ▸ 자격 기반 정책(Identity-based) — IAM 사용자/그룹/역할에 연결하는 정책(그룹 부착 가능) ▸ 리소스 기반 정책(Resource-based) — S3 버킷·SQS 등 리소스에 붙는 정책(IAM 그룹엔 부착 불가) 【정답 포인트】 ▸ "5명에게 전체 접근 부여 + IAM 그룹 활용" → AdministratorAccess(자격 기반) 정책을 그룹에 연결하고 사용자 배치 ▸ 그룹 한 곳에 관리형 관리자 정책 부착 → 전체 권한 부여 요구 충족 【오답 체크】 (A) "AdministratorAccess 리소스 기반 정책"은 존재하지 않음(자격 기반임), 그룹에 리소스 기반 정책 부착 불가. (B) SystemAdministrator는 전체 접근이 아닌 제한된 권한 세트로 "full access" 요구 미달. (D) SystemAdministrator + 리소스 기반이라는 조합 자체가 부정확. 【시험 포인트】 IAM 그룹에 붙이는 것은 자격 기반 정책. 전체 관리자 권한 = AdministratorAccess.

해설

【핵심 용어】 ▸ SQS FIFO 큐 — 순서 보장 + 정확히 한 번(exactly-once) 처리 제공(중복 제거) ▸ AWS Lambda — 서버리스 컴퓨팅으로 인프라 관리 최소화 ▸ SNS / EC2 / EKS — 팬아웃·VM·컨테이너용이나 관리 최소 + 정확히 한 번 요구엔 부적합 【정답 포인트】 ▸ "인프라 관리 최소" → Lambda 서버리스 컴퓨팅(A) ▸ "정확히 한 번 전달 보장" → SQS FIFO 큐(D)가 exactly-once 처리·순서 보장 → 두 조합이 정답 【오답 체크】 (B) EC2는 인스턴스 관리 부담이 있어 "인프라 관리 최소" 요구에 반함. (C) SNS(표준)는 정확히 한 번 전달을 보장하지 못함. (E) EKS는 클러스터 운영 부담이 커 관리 최소화 요구에 부적합. 【시험 포인트】 "정확히 한 번 + 순서" → SQS FIFO. "인프라 관리 최소" → Lambda.

해설

【핵심 용어】 ▸ AWS Transfer for SFTP — 완전관리형 SFTP 엔드포인트(고가용성·복원력, 서버 관리 불필요) ▸ Amazon EFS — 다중 AZ 공유 파일 시스템으로 고가용성 스토리지 제공 ▸ EC2 Auto Scaling + 예약 스케일링 — 야간 배치를 정해진 시간에 실행 【정답 포인트】 ▸ "SFTP 수신 + 야간 배치 + 고가용성·복원력 + 최소 운영" → AWS Transfer for SFTP + EFS + Auto Scaling 예약 스케일링 ▸ 관리형 SFTP와 다중 AZ EFS로 HA 확보, 예약 스케일링으로 배치 실행 → 요구 충족 【오답 체크】 (B) EC2 자체 SFTP + EBS는 단일 AZ·자체 관리 부담, EBS는 다중 인스턴스 공유 불가. (C) EC2 자체 SFTP는 관리 오버헤드가 크고 관리형 대비 복원력·편의성 낮음. (D) Transfer + S3도 가능하나 배치가 S3→EC2로 파일을 당겨오도록 애플리케이션 수정이 필요해 오버헤드↑. 【시험 포인트】 관리형 SFTP + 공유 HA 스토리지 → AWS Transfer for SFTP + EFS.

해설

【핵심 용어】 ▸ AWS Global Accelerator — 정적 애니캐스트 IP 제공 + 글로벌 트래픽을 최적 리전 엔드포인트로 라우팅(가용성·성능 향상) ▸ Application Load Balancer (ALB) — HTTP/HTTPS L7 로드밸런싱, AWS WAF 연동 지원 ▸ AWS WAF — 웹 익스플로잇 방어(ALB/CloudFront에 연결 가능, NLB엔 직접 불가) 【정답 포인트】 ▸ "HTTP 앱 + 가용성·성능 향상 + 웹 익스플로잇 방어 + 정적 IP" 요구 ▸ 각 리전 ALB(HTTP L7) + ALB에 WAF(웹 공격 방어) + Global Accelerator(정적 IP·글로벌 라우팅) → 모든 요구 충족 【오답 체크】 (A) WAF는 NLB에 직접 연결할 수 없어 웹 익스플로잇 방어 요구를 충족 못함. (C) NLB + WAF 조합 불가 + CloudFront/Route 53 구성은 정적 IP 요구를 직접 충족 못함. (D) CloudFront + Route 53 지연 라우팅 방식은 정적 IP 요구를 충족하지 못함(Global Accelerator가 정적 IP 제공). 【시험 포인트】 "정적 IP + 글로벌 성능·가용성" → Global Accelerator. HTTP 웹 방어 → ALB + WAF.

해설

【핵심 용어】 ▸ Amazon RDS Proxy — DB 연결 풀링으로 "too many connections" 완화 + 장애 조치(failover) 시간을 크게 단축 ▸ Aurora MySQL 읽기 복제본 승격 — 라이터 장애 시 복제본을 프라이머리로 승격 ▸ RDS Proxy failover 개선 — 연결을 프록시가 유지해 페일오버 체감 시간 단축 【정답 포인트】 ▸ "연결 과다(too many connections) + 페일오버 시간 20% 단축" → RDS Proxy를 Aurora 앞에 배치 ▸ 연결 풀링으로 연결 폭주를 완화하고 프록시가 페일오버를 관리해 전환 시간 단축 → 요구 충족 【오답 체크】 (A) RDS Multi-AZ 클러스터로 전환은 아키텍처 변경이 크고 연결 과다 문제의 직접 해법이 아님. (C) DynamoDB + DAX 전환은 관계형 워크로드 재설계로 부적합. (D) Redshift는 분석용 DW로 트랜잭션 DB 페일오버 요구와 무관. 【시험 포인트】 연결 과다 + 페일오버 단축 → RDS Proxy(연결 풀링 + 빠른 페일오버).

해설

【핵심 용어】 ▸ S3 Object Lambda Access Point — S3 객체를 반환하기 직전 Lambda로 가공(PII 마스킹 등)해 제공 ▸ AWS Lambda — 파일 읽을 때 PII를 실시간 편집(redact)하는 서버리스 로직, 자동 확장 ▸ 별도 배치/웹앱(EC2) — 사전 가공·중복 저장으로 운영 부담 및 확장성 열위 【정답 포인트】 ▸ "PII 미공유 + 최신 대화까지 무작위 샘플 + 확장 + 최소 운영" → Object Lambda Access Point ▸ 원본은 그대로 두고 제공 시점에 Lambda가 PII를 마스킹 → 중복 저장 없이 자동 확장·최소 운영 【오답 체크】 (B) EC2 배치로 사전 마스킹·별도 버킷 저장은 인프라 관리·중복 저장 오버헤드가 큼. (D) DynamoDB로 비-PII만 별도 적재하는 방식은 원본 대화 샘플 제공 요구와 어긋나고 파이프라인 관리 부담이 큼. 【시험 포인트】 제공 시점 데이터 변환(PII 마스킹) + 원본 무변경 → S3 Object Lambda Access Point.

해설

【핵심 용어】 ▸ CloudWatch 기반 EC2 인스턴스 복구(auto recovery) — 시스템 상태 검사 실패 시 동일 인스턴스를 자동 복구해 복구 시간 단축 ▸ 단일 인스턴스 제약 — 앱을 다중 인스턴스로 확장 불가(Multi-AZ/ASG 부적합) ▸ 종료 방지 / RAID — 실수 종료 방지·스토리지 중복용으로 복구 시간과 무관 【정답 포인트】 ▸ "코드 수정 불가 + 단일 인스턴스만 실행 가능 + 복구 시간 개선" → CloudWatch 알람 기반 인스턴스 자동 복구 ▸ 장애 감지 시 동일 인스턴스를 자동 재기동해 복원력·복구 시간 개선 → 단일 인스턴스 제약에도 부합 【오답 체크】 (A) 종료 방지는 실수 종료를 막을 뿐 장애 복구·복구 시간 개선과 무관. (B) EC2 인스턴스는 Multi-AZ '배포' 대상이 아니며 단일 인스턴스 제약과도 상충. (D) RAID EBS는 스토리지 중복성일 뿐 인스턴스 장애 복구 시간을 개선하지 못함. 【시험 포인트】 단일 EC2 복원력·복구 시간 개선 → CloudWatch 기반 EC2 auto recovery.

해설

【핵심 용어】 ▸ Amazon ECS + Service Auto Scaling — 컨테이너 관리형 오케스트레이션, 대상 추적 오토스케일 ▸ 배치 전략 spread(Availability Zone) — 태스크를 AZ에 고르게 분산 배치해 AZ 장애 대비 ▸ EKS 셀프매니지드 / EC2 배치 그룹 / Lambda — 노드 관리 부담·컨테이너 부적합·최소 변경 요구 미달 【정답 포인트】 ▸ "컨테이너 워크로드 + 3개 AZ 고가용성 + 앱 최소 변경 + 최소 운영" → ECS + Service Auto Scaling ▸ 최소 용량 3 + AZ spread 배치 전략으로 3개 AZ에 분산 → 고가용성·최소 운영 충족 【오답 체크】 (B) EKS 셀프 매니지드 노드는 노드·클러스터 자체 관리 부담이 커 최소 운영에 반함. (C) EC2 spread 배치 그룹은 컨테이너 오케스트레이션이 아니라 앱 변경·운영 부담 증가. (D) Lambda는 컨테이너 워크로드를 최소 변경으로 옮기기 어렵고 장기 실행 서비스에 부적합. 【시험 포인트】 컨테이너 다중 AZ 고가용성 + 최소 운영 → ECS + Service Auto Scaling + AZ spread.

해설

【핵심 용어】 ▸ S3 Standard — 신작(고수요)용, 즉시 접근·고빈도 ▸ S3 Standard-Infrequent Access(Standard-IA) — 저빈도 접근용, 즉시(밀리초) 조회 가능·저장비 저렴 ▸ S3 Glacier Flexible Retrieval — 아카이브용이나 조회에 수 분~수 시간 소요, 5분 내 제공 요구엔 위험 【정답 포인트】 ▸ "구매 후 5분 내 스트리밍 제공 + 20년 미만 고수요 + 비용 최소화" → 신작 S3 Standard, 구작 Standard-IA ▸ Standard-IA는 즉시 조회 가능해 5분 요구 충족 + 저빈도 저장비 절감 → 수요 기반 비용 최적화 【오답 체크】 (A) Lifecycle으로 IA 전환만 하는 방식은 신작/구작 수요 구분·비용 최적화 설계가 불명확. (C) Glacier Flexible의 신속(expedited) 조회도 지연·비용이 있고 대용량엔 5분 보장이 어려움. (D) Glacier + 대량(bulk) 조회는 수 시간 소요로 "5분 내 제공" 요구를 명백히 위반. 【시험 포인트】 "즉시(5분) 조회 필요"면 Glacier 계열 제외. 저빈도는 Standard-IA(밀리초 조회).

해설

【핵심 용어】 ▸ AWS Fargate(ECS) — 서버리스 컨테이너 실행, EC2 노드 관리 불필요 ▸ Amazon EFS 볼륨 — Fargate 태스크에 마운트 가능한 대용량 공유 파일 스토리지(50GB+ 임시 파일 수용) ▸ Lambda 임시 스토리지 — /tmp 최대 10GB 한계, 50GB 요구 초과 + EBS/S3 마운트 미지원 【정답 포인트】 ▸ "Docker 이미지 + 50GB 임시 스토리지 + 서버리스 + 최소 운영" → Fargate + EFS 볼륨 ▸ Fargate로 서버리스 실행 + EFS 마운트로 50GB 이상 임시 파일 처리 → 요구 충족 【오답 체크】 (A) Lambda는 S3를 파일 시스템으로 마운트할 수 없고 임시 스토리지도 10GB 한계. (B) Lambda에 EBS 볼륨을 붙일 수 없음(지원하지 않는 구성). (D) ECS EC2 시작 유형 + EBS는 EC2 노드를 직접 관리해야 하므로 "서버리스"가 아님. 【시험 포인트】 서버리스 컨테이너 + 대용량 스토리지 → Fargate + EFS. Lambda /tmp는 10GB 한계.

해설

【핵심 용어】 ▸ 커스텀 자격 브로커(Identity Broker) + AWS STS — LDAP 인증 후 STS로 단기 자격증명 발급해 콘솔 접근 ▸ AWS STS — 임시(단기) 보안 자격증명 발급 서비스 ▸ IAM Identity Center — 일반적으로 SAML 기반 연동(문제는 SAML 비호환 LDAP) 【정답 포인트】 ▸ "온프레미스 LDAP로 콘솔 인증 + SAML 비호환" → 커스텀 자격 브로커 앱이 LDAP 인증 후 STS로 단기 자격증명 발급 ▸ SAML을 쓸 수 없으므로 브로커가 STS 임시 자격을 받아 콘솔 로그인 URL 제공 → 요구 충족 【오답 체크】 (A) IAM Identity Center는 주로 SAML/표준 연동에 의존하므로 SAML 비호환 LDAP엔 부적합. (B) IAM 정책에 AWS 자격증명을 넣어 LDAP에 통합한다는 것은 성립하지 않는 방식. (C) LDAP 갱신마다 IAM 자격증명 회전은 확장성·보안이 나쁜 임시방편. 【시험 포인트】 SAML 비호환 온프레 디렉터리 → 커스텀 identity broker + STS 임시 자격증명.

해설

【핵심 용어】 ▸ Recycle Bin(휴지통) 보존 규칙 — 삭제된 AMI/EBS 스냅샷을 지정 기간 보관해 실수 삭제를 신속 복구 ▸ AMI 백업 대체 방식 — 타 계정 복사/스냅샷/S3 복제는 별도 파이프라인·운영 부담 ▸ 최소 운영 오버헤드 — 규칙 하나로 자동 보존·복구가 이상적 【정답 포인트】 ▸ "실수로 삭제된 AMI를 신속·효율 복구 + 최소 운영" → Recycle Bin에 보존 규칙 생성 ▸ 삭제된 AMI가 규칙 기간 동안 휴지통에 보관되어 즉시 복원 가능 → 관리형·저운영 【오답 체크】 (A) 타 계정 EBS 스냅샷 저장은 수작업·파이프라인 부담이 크고 AMI 직접 복구가 아님. (B) 주기적 타 계정 복사는 스케줄·관리 오버헤드가 큼. (D) AMI를 S3로 업로드/CRR하는 방식은 표준 AMI 복구 경로가 아니고 복잡. 【시험 포인트】 삭제된 AMI/스냅샷 신속 복구 + 최소 운영 → Recycle Bin 보존 규칙.

해설

【핵심 용어】 ▸ AWS Snowball — 페타바이트급 이하 오프라인 대량 데이터 전송 디바이스(수십~수백 TB에 적합) ▸ AWS Snowmobile — 엑사바이트급 초대량 전송용(150TB엔 과도) ▸ 네트워크 업로드 한계 — 100Mbps·야간만이면 150TB 전송에 수개월 소요(1개월 마감 불가) 【정답 포인트】 ▸ "150TB + 1개월 마감 + 100Mbps 야간만" → 네트워크로는 마감 불가 → 물리 전송(Snowball) ▸ 여러 Snowball 디바이스를 주문·병렬 전송하면 마감 내 이전 + 비용 효율 → 정답 【오답 체크】 (A) Snowmobile은 엑사바이트급 초대형 전송용으로 150TB엔 과도·비효율. (C) S3 Transfer Acceleration도 100Mbps 야간 한계라 물리적으로 1개월 내 불가. (D) VPC 엔드포인트 + VPN 업로드 역시 동일한 대역폭 한계로 마감 불가. 【시험 포인트】 대량 데이터 + 대역폭·기한 부족 → Snowball. 엑사바이트급만 Snowmobile.

해설

【핵심 용어】 ▸ Amazon Aurora MySQL — MySQL 호환 관리형 DB, PITR(특정 시점 복구) 지원·운영 부담 낮음 ▸ 3티어 구성 — 웹(퍼블릭 서브넷) / 앱(프라이빗 서브넷) / DB(프라이빗 서브넷) ▸ PITR(Point-in-time Recovery) — 특정 시점으로 데이터 복원 【정답 포인트】 ▸ "MySQL DB + 특정 시점 복구 + 최소 아키텍처 변경/최소 운영" → 웹 퍼블릭, 앱 프라이빗, DB(Aurora MySQL) 프라이빗 ▸ Aurora MySQL은 MySQL 호환으로 마이그레이션 변경 최소 + PITR 제공 + 관리형으로 운영 부담↓ 【오답 체크】 (A) 웹/앱 모두 프라이빗 서브넷에 두면 웹 티어 인터넷 노출 구성이 어색(웹은 퍼블릭이 자연스러움). (C) 구성은 유사하나 Aurora 대비 RDS MySQL은 운영 부담·성능 이점이 낮아 "최소 운영" 관점에서 열위. (D) DB를 퍼블릭 서브넷에 두는 것은 보안 모범 사례 위반. 【시험 포인트】 DB는 프라이빗 서브넷 + PITR. MySQL 최소 변경·저운영 → Aurora MySQL.

해설

【핵심 용어】 ▸ SQS 액세스 정책(리소스 기반 정책) — 큐에 직접 부착해 다른 계정에 폴링/접근 권한 부여 ▸ 교차 계정 접근 — 상대가 자신의 계정 권한을 포기하지 않고 리소스 접근 ▸ IAM 정책(자격 기반) / 인스턴스 프로파일 — 자기 계정 주체에 부여, 상대 계정에 직접 접근 부여 부적합 【정답 포인트】 ▸ "다른 회사(계정)가 자신 권한 유지한 채 SQS 큐 폴링" → 큐에 SQS 액세스 정책(리소스 기반) 부여 ▸ 리소스 기반 정책으로 상대 계정 주체를 명시적으로 허용 → 교차 계정 접근 표준 방식 【오답 체크】 (A) 인스턴스 프로파일은 EC2 역할 부여용으로 타 계정 큐 접근 부여 방식이 아님. (B) 개발팀 계정의 IAM 정책만으로는 타 계정 주체에 접근을 직접 부여할 수 없음(리소스 정책 필요). (D) SNS 액세스 정책은 SQS 큐 접근 부여와 무관한 서비스 대상. 【시험 포인트】 교차 계정 리소스 접근(SQS/S3 등) → 리소스 기반 정책(SQS access policy).

해설

【핵심 용어】 ▸ AWS Systems Manager Session Manager — SSH 키·배스천·인바운드 포트 없이 안전한 셸 접근(IAM 인증·로그) ▸ AmazonSSMManagedInstanceCore — 인스턴스가 SSM에 등록되게 하는 IAM 정책 ▸ 배스천 호스트 / Site-to-Site VPN — 추가 인프라·관리·비용 발생(원격+사무실 모두 대응 부담) 【정답 포인트】 ▸ "안전한 SSH 접근 + 원격·사무실 모두 + 프라이빗 서브넷 + AWS 서비스 + 가장 비용 효율" → Session Manager ▸ EC2 역할에 AmazonSSMManagedInstanceCore 부착 후 Session Manager 접근 → 배스천·개방 포트 불필요, 추가 인프라 비용 없음 【오답 체크】 (A) 배스천 + ec2:CreateVpnConnection 권한 조합은 부정확하고 추가 인프라 관리 부담. (B) Site-to-Site VPN + 원격용 별도 VPN 구성은 비용·관리 부담이 크고 번거로움. (C) 퍼블릭 배스천은 추가 인스턴스 운영·공격 표면 증가로 비용 효율·보안 열위. 【시험 포인트】 프라이빗 EC2에 배스천 없이 안전 접근 → SSM Session Manager(+SSM 코어 정책).

해설

【핵심 용어】 ▸ Storage Gateway 볼륨 게이트웨이(캐시형 볼륨) — 전체 데이터는 S3, 자주 쓰는 서브셋만 로컬 캐시로 저지연 즉시 접근 ▸ 캐시형 볼륨(Cached Volumes) — 온프레 캐패시티 최소화 + 데이터 클라우드 저장으로 자본지출(capex) 절감 ▸ 파일 게이트웨이 / DataSync / EFS — 접근 방식·용도 차이로 캐시 서브셋 즉시 접근 요구엔 볼륨 게이트웨이가 부합 【정답 포인트】 ▸ "서브셋만 최소 지연으로 즉시 접근 + 전체 데이터 매일은 아님 + capex 절감" → 볼륨 게이트웨이 캐시형 볼륨 ▸ 전체 데이터를 S3에 두고 자주 쓰는 부분만 로컬 캐시 → 저지연 서브셋 접근 + 온프레 스토리지 축소로 capex↓ 【오답 체크】 (A) DataSync 크론 마이그레이션은 일회성/주기 전송이며 로컬 저지연 캐시 접근 모델이 아님. (B) 파일 게이트웨이는 NFS/SMB 파일 접근용으로 문제의 블록/캐시 서브셋 시나리오와 결이 다름. (D) Site-to-Site VPN + EFS는 네트워크 지연·상시 접근 비용이 있어 capex 절감·저지연 캐시 요구에 부적합. 【시험 포인트】 자주 쓰는 서브셋만 로컬 캐시 + 나머지는 S3 → Storage Gateway 캐시형 볼륨 게이트웨이.