정답 · 해설

해설

【핵심 용어】 ▸ StackSet: 여러 AWS 계정과 리전에 스택을 배포하는 기능 ▸ 관리 계정: 스택 세트의 중앙 관리 지점 ▸ 멤버 계정: 스택이 배포되는 대상 계정 ▸ 조직 배포: AWS Organizations 통합으로 자동화 【정답 포인트】 ▸ CloudFormation StackSet은 다중 계정 배포를 위해 설계됨 ▸ 관리 계정에서 스택 세트를 정의하면 멤버 계정에 자동 배포 ▸ AWS Organizations 통합으로 조직의 모든 계정에 일괄 배포 가능 ▸ 버전 관리 및 업데이트 자동화 【오답 체크】 (A) Change Set은 단일 계정 내 변경 사항 미리보기용 (B) Nested Stack은 템플릿 재사용용이고 다중 계정 배포 기능 부족 (D) SAM은 서버리스 애플리케이션 패키징용이고 다중 계정 배포 전문성 부족 【시험 포인트】 ▸ CloudFormation StackSet의 다중 계정 배포 기능 ▸ AWS Organizations 통합으로 자동화된 프로비저닝 ▸ 관리 계정 중심의 리소스 배포 구조

해설

【핵심 용어】 ▸ SSE-KMS: AWS KMS를 통한 서버 측 암호화 ▸ CloudTrail: KMS 키 사용 기록 감사 ▸ 키 로테이션: AWS가 자동으로 관리하는 마스터 키 ▸ 감사 추적: CloudTrail에서 키 사용 이력 추적 【정답 포인트】 ▸ SSE-KMS는 AWS가 마스터 키를 관리하므로 고객이 키를 제공할 필요 없음 ▸ CloudTrail에서 모든 KMS 키 사용 기록을 추적(누가, 언제, 어디서 사용) ▸ 자동 키 로테이션으로 보안 강화 ▸ 감사 및 규정 준수 요구사항 충족 【오답 체크】 (A) 클라이언트 제공 키는 고객이 키 관리해야 하며, 감사 추적 미흡 (B) SSE-S3는 감사 추적 기능 부족(누가 사용했는지 추적 불가) (C) SSE-C도 고객이 키를 관리해야 하고 감사 추적 미흡 【시험 포인트】 ▸ S3 암호화 방식별 감사 추적 기능 차이 ▸ CloudTrail과 CloudWatch를 통한 KMS 감사 ▸ 규정 준수와 감사 요구사항을 만족하는 암호화 방식

해설

【핵심 용어】 ▸ cloudformation:CreateStack: CloudFormation 스택 생성 권한 ▸ s3:CreateBucket: S3 버킷 생성 권한 ▸ 암시적 거부: 권한 명시 없으면 기본 거부 ▸ 명시적 거부: 명시적으로 거부 규칙이 있을 때 거부 【정답 포인트】 ▸ CloudFormation 스택을 생성하려면 cloudformation:CreateStack 권한 필요 ▸ 스택의 리소스(S3 버킷)를 생성하려면 해당 리소스 생성 권한도 필요 ▸ S3 버킷 생성 시 s3:CreateBucket 권한이 필수 ▸ 두 권한 중 하나라도 없으면 스택 생성 실패 【오답 체크】 (B) CreateStackSet은 StackSet 생성 권한이며, 일반 스택에는 필요 없음 (D) ListBucket은 버킷 생성에 필요 없은 권한(나열 권한) (E) PutObject는 객체 저장 권한이며, 버킷 생성에 필요 없음 【시험 포인트】 ▸ CloudFormation 배포에 필요한 IAM 권한 구조 ▸ 암시적 거부와 명시적 거부의 차이 ▸ CloudFormation 스택 생성 권한과 리소스별 권한의 필요성

해설

【핵심 용어】 ▸ 자동화된 스냅샷: RDS가 자동으로 생성하는 정기 백업 ▸ 읽기 전용 복제본: 원본과 동기화되는 실시간 복사본 ▸ 포인트 인 타임 복원(PITR): 특정 시점의 데이터로 복원 ▸ RTO(Recovery Time Objective): 복구에 필요한 시간 【정답 포인트】 ▸ A: 자동화된 스냅샷 복원은 가장 빠르고 간단한 방법(낮은 운영 오버헤드) ▸ C: 읽기 전용 복제본 승격도 빠른 방법(데이터 최신 상태 유지) ▸ 두 방법 모두 관리 작업 최소화 ▸ 24시간 이내 데이터 보장 【오답 체크】 (B) S3 네이티브 백업/복원은 수동 프로세스로 오버헤드 증가 (D) AWS DMS는 복잡한 설정 필요로 오버헤드 증가 (E) pg_dump/pg_restore는 수동 도구 사용으로 시간 오래 걸림 【시험 포인트】 ▸ RDS 백업/복원 옵션별 시간과 오버헤드 ▸ 읽기 전용 복제본과 자동화 스냅샷의 차이 ▸ 빠른 복구가 필요한 상황에서 최적의 선택

해설

【핵심 용어】 ▸ CloudFront 원본(Origin): 콘텐츠를 가져오는 소스(ALB) ▸ 원본 액세스 ID(OAI): CloudFront만 S3에 액세스 허용(S3용) ▸ TTL(Time To Live): 캐시 유지 기간 ▸ DNS 레코드: 사용자가 실제로 방문하는 주소 【정답 포인트】 ▸ B: 사용자 DNS가 여전히 ALB를 직접 가리키면 CloudFront 캐싱 우회 ▸ D: TTL이 0이면 매 요청마다 원본(ALB)에서 새로 가져옴 ▸ 둘 다 CloudFront 캐싱을 무효화하여 웹 서버 로드 감소 없음 【오답 체크】 (A) OAI는 S3용이고, ALB는 다른 인증 방식 사용 (C) ALB 보안 그룹이 CloudFront 차단해도 DNS가 ALB 직접 가리키면 웹사이트 접속 가능 (E) 고정 세션은 특정 대상 고정일 뿐 로드 감소와 무관 【시험 포인트】 ▸ CloudFront 캐싱 동작 방식 이해 ▸ DNS 레코드 변경의 중요성(사용자가 실제로 가는 경로) ▸ TTL 설정이 캐싱 효율성에 미치는 영향 ▸ 원본 액세스 ID(OAI)는 S3용(ALB 아님)

해설

【핵심 용어】 ▸ 별칭 레코드(Alias Record): AWS 리소스를 가리키는 Route 53 전용 레코드 ▸ CNAME 레코드: DNS 도메인을 다른 도메인 이름으로 별칭 ▸ A 레코드: 도메인을 IP 주소로 매핑 ▸ 루트 도메인(example.com): CNAME 사용 불가(DNS 사양) 【정답 포인트】 ▸ C: example.com(루트 도메인)은 별칭 레코드로 ALB 가리킴 ▸ D: www.example.com은 Route 53의 example.com 별칭 레코드로 가리킴 ▸ 별칭 레코드는 동적으로 IP 변경 감지(A 레코드는 정적) ▸ 루트 도메인에는 CNAME 불가능 【오답 체크】 (A) ALB는 정적 IP가 아니므로 A 레코드 사용 불안정 (B) 동일하게 IP 주소 변경 문제 (E) 루트 도메인(example.com)에는 CNAME 사용 불가(DNS 규칙) 【시험 포인트】 ▸ Route 53 별칭 레코드와 표준 DNS 레코드의 차이 ▸ 루트 도메인과 서브도메인의 레코드 타입 제약 ▸ ALB를 가리킬 때 정적 IP 대신 별칭 레코드 사용

해설

【핵심 용어】 ▸ Route 53 인바운드 엔드포인트: 온프레미스에서 Route 53으로 DNS 쿼리 수신 ▸ Route 53 아웃바운드 엔드포인트: VPC에서 온프레미스 DNS로 쿼리 전달 ▸ 조건부 전달(Conditional Forwarding): 특정 도메인 쿼리만 특정 DNS로 전달 ▸ 하이브리드 DNS: 온프레미스와 AWS 간 DNS 통합 【정답 포인트】 ▸ 인바운드 엔드포인트는 온프레미스 → AWS 방향의 DNS 쿼리 수신 ▸ 온프레미스 DNS 서버가 인바운드 엔드포인트로 쿼리 조건부 전달 ▸ Direct Connect를 통해 안전한 하이브리드 네트워크 구축 ▸ 온프레미스 서버가 Route 53의 개인 호스팅 영역 조회 가능 【오답 체크】 (B) 아웃바운드 엔드포인트는 VPC → 온프레미스 방향(역방향) (C) TXT 레코드는 DNS 레코드 타입이 아니며, VPC CIDR + 2는 DNS 서버 주소가 아님 (D) PTR 레코드는 역방향 DNS용이며, 용도 불일치 【시험 포인트】 ▸ Route 53 인바운드/아웃바운드 엔드포인트의 방향성 이해 ▸ 하이브리드 환경에서 DNS 통합 아키텍처 ▸ Direct Connect와 Route 53을 이용한 보안 DNS 구성

해설

【핵심 용어】 ▸ 상태 확인(Health Check): DNS 응답 전 리소스 상태 검증 ▸ HTTP 상태 확인: HTTP 상태 코드(2xx, 3xx 등) 확인 ▸ 별칭 레코드: AWS 리소스 전용(온프레미스 서버에는 불가) ▸ 장애 조치(Failover): 기본 서버 다운 시 보조 서버로 전환 【정답 포인트】 ▸ 온프레미스 서버는 별칭 레코드가 아닌 A 레코드 사용 ▸ HTTP 상태 확인으로 2xx/3xx 코드 응답 확인 ▸ 상태 확인 실패 시 자동으로 보조 서버로 장애 조치 ▸ 온프레미스 웹 서버의 HTTP 응답 상태 검증 필요 【오답 체크】 (B) TCP 상태 확인은 연결 확인만 하고 HTTP 상태 코드 검증 불가 (C) 별칭 레코드는 AWS 리소스(ALB, CloudFront 등)용이며, 온프레미스 서버에는 사용 불가 (D) 별칭 레코드 + TCP 상태 확인은 두 가지 오류 조합 【시험 포인트】 ▸ 온프레미스 리소스와 AWS 리소스의 DNS 레코드 타입 차이 ▸ HTTP vs TCP 상태 확인의 차이와 사용 사례 ▸ Route 53 장애 조치 라우팅의 상태 확인 구성

해설

【핵심 용어】 ▸ IAM 역할(Role): EC2 인스턴스가 AWS 서비스에 안전하게 액세스 ▸ 임시 자격 증명: STS를 통한 자동 갱신 ▸ 최소 권한 원칙: 필요한 권한만 부여 ▸ 자격 증명 노출 방지: 환경 변수/코드에 저장하지 않음 【정답 포인트】 ▸ EC2 인스턴스에 IAM 역할 연결이 가장 안전함 ▸ 임시 자격 증명으로 자동 갱신되므로 보안 강화 ▸ sqs:SendMessage, sqs:ReceiveMessage, sqs:DeleteMessage만 부여(최소 권한) ▸ sqs:*은 과도한 권한으로 보안 위험 【오답 체크】 (A) IAM 사용자 자격 증명을 애플리케이션 구성에 하드코딩하면 노출 위험 (B) 환경 변수에 액세스 키 저장하면 보안 위험(프로세스 덤프, 로그 노출) (C) sqs:* 권한은 불필요한 권한까지 부여(최소 권한 원칙 위반) 【시험 포인트】 ▸ EC2 인스턴스의 IAM 역할 사용이 가장 안전한 방법 ▸ 임시 자격 증명 vs 장기 자격 증명의 보안 차이 ▸ 최소 권한 원칙(sqs:* 권한 회피) ▸ 자격 증명 노출 방지 메커니즘

해설

【핵심 용어】 ▸ 원본 액세스 ID(OAI): CloudFront만 S3에 액세스하도록 제한 ▸ S3 버킷 정책: 특정 주체에만 액세스 허용 ▸ 비공개 호스팅: 버킷 자체는 공개 아님, CloudFront를 통해서만 접근 ▸ s3:GetObject: 객체 읽기 권한 【정답 포인트】 ▸ CloudFront + OAI가 비공개 호스팅의 표준 방식 ▸ S3 버킷 정책에서 OAI만 s3:GetObject 권한 부여 ▸ 직접 S3 URL 접근 차단, CloudFront만 허용 ▸ 고가용성 및 성능 최적화 【오답 체크】 (B) 정적 웹사이트 호스팅은 버킷이 공개 상태여야 함(정책 위반) (C) ALB는 S3에 직접 트래픽 전달 불가(프로토콜 비호환) (D) Global Accelerator도 S3 버킷 공개 필요 【시험 포인트】 ▸ CloudFront + OAI로 비공개 S3 호스팅 ▸ S3 버킷 정책의 Principal 설정(OAI) ▸ 공개 웹 호스팅과 비공개 호스팅의 차이

해설

【핵심 용어】 ▸ Viewer Protocol Policy: 클라이언트-CloudFront 간 프로토콜 정책 ▸ HTTPS Redirect: HTTP 요청을 HTTPS로 자동 리디렉션 ▸ Alternate Domain Name(CNAME): CloudFront 배포에 도메인 매핑 ▸ Custom SSL Certificate: ACM 인증서 연결 【정답 포인트】 ▸ A: Viewer Protocol Policy를 "Redirect HTTP to HTTPS"로 설정 → 모든 HTTP 요청이 자동으로 HTTPS로 리디렉션 ▸ C: CloudFront에 도메인 이름(CNAME) 추가 → ACM 인증서를 CloudFront와 연결하여 HTTPS 활성화 ▸ 두 설정이 함께 전송 중 암호화 보장 【오답 체크】 (B) "Allow HTTP and HTTPS"는 HTTP 미암호화 트래픽 허용(요구사항 미충족) (D) AWS WAF는 DDoS/공격 방지이고 전송 중 암호화와 무관 (E) Origin Shield는 캐시 효율성 증대이고 암호화와 무관 【시험 포인트】 ▸ CloudFront의 Viewer Protocol Policy 설정 ▸ CNAME과 ACM 인증서 연결 ▸ 클라이언트-CloudFront 간 암호화 설정 방법 ▸ CloudFront 원본-서버 간 암호화는 별도 설정 필요

해설

【핵심 용어】 ▸ NAT 게이트웨이: 프라이빗 서브넷의 리소스가 인터넷으로 아웃바운드 연결을 수행할 수 있도록 하는 관리형 서비스. 고정 Elastic IP 주소를 사용하여 외부 시스템에 일관된 발신 주소 제공 ▸ 고정 IP 주소: 제3자 화이트리스팅 요구사항을 충족하기 위해 변경되지 않는 IP 【정답 포인트】 ▸ NAT 게이트웨이는 Elastic IP를 자동으로 할당받으며, 이를 통해 모든 프라이빗 EC2 인스턴스의 아웃바운드 트래픽이 동일한 고정 IP에서 발생하도록 보장합니다 ▸ 각 AZ별 NAT 게이트웨이를 구성하면 AZ 간 리전 간 데이터 전송 비용을 절감하고 가용성을 높일 수 있습니다 【오답 체크】 (B) 개별 인스턴스에 Elastic IP를 할당하면 확장성 문제 발생 및 관리 복잡성 증가 (C) NLB는 고정 발신 IP를 제공하지 않으며 로드 밸런싱 용도 (D) EC2 인스턴스는 라우트 테이블의 대상이 될 수 없으며 인스턴스 Elastic IP는 자동으로 변경될 수 있음 【시험 포인트】 ▸ 제3자 화이트리스팅 시나리오에서는 항상 NAT 게이트웨이를 고려하세요 ▸ 고정 발신 IP가 필요하면 NAT 게이트웨이 또는 NAT 인스턴스 사용 ▸ 각 AZ에 독립적인 NAT 게이트웨이를 배포하는 것이 모범 사례

해설

【핵심 용어】 ▸ AWS Backup: 중앙화된 백업 정책 관리 및 자동화 ▸ Amazon Data Lifecycle Manager: EBS 스냅샷 및 AMI의 자동 생성 ▸ 태그 기반 필터링: 특정 워크로드만 자동으로 백업 【정답 포인트】 ▸ AWS Backup은 백업 정책 자체에서 태그 필터링을 지원하므로 Lifecycle: Production 태그가 있는 볼륨만 자동으로 백업됩니다 ▸ AWS Backup은 복원력 있는 복원 지점을 생성하며 크로스 리전 복제도 지원합니다 ▸ 정책 레벨에서 권한 제어가 가능하여 더 강력한 보호 【오답 체크】 (A) Data Lifecycle Manager는 강력한 권한 제어 없이 스냅샷 삭제를 완벽히 방지할 수 없습니다 (B) SCP와 EventBridge 조합은 과도하게 복잡하며 스냅샷 자동화 메커니즘이 부족합니다 (D) AMI는 요구 사항이 아니며 스냅샷 생성이 아닙니다 【시험 포인트】 ▸ AWS Backup은 멀티 계정 환경에서 중앙화된 정책 관리에 최적입니다 ▸ 태그 기반 자동 백업이 필요한 경우 AWS Backup 우선 선택 ▸ 백업 정책에서 직접 태그 필터링을 지원하는 솔루션이 가장 효율적

해설

【핵심 용어】 ▸ FSx for Windows File Server: Windows 파일 서버 호환 관리형 파일 시스템 ▸ Multi-AZ 배포: 고가용성 및 자동 페일오버 ▸ SMB 프로토콜: Windows 네이티브 파일 공유 【정답 포인트】 ▸ FSx는 Windows 네이티브 SMB 프로토콜을 지원하므로 Windows 애플리케이션과 완벽하게 호환됩니다 ▸ Multi-AZ 구성으로 자동 페일오버 및 높은 가용성 제공 ▸ 기존 Windows 기반 인프라와의 통합이 매우 간단합니다 【오답 체크】 (A) EFS는 NFS 기반이므로 Windows 호환성 제한 (C) EBS Multi-Attach는 많은 인스턴스에 동시 연결을 지원하지 못함 (D) 이중 FSx 시스템과 DFS 복제는 불필요한 복잡성 추가 【시험 포인트】 ▸ Windows 환경에서 다중 인스턴스의 파일 공유는 FSx for Windows 우선 선택 ▸ EFS는 Linux 기반 워크로드에 최적화됨 ▸ 운영 효율성 요구 사항에서는 관리형 서비스(FSx) 선호

해설

【핵심 용어】 ▸ VPC 게이트웨이 엔드포인트: S3 및 DynamoDB에 대한 프라이빗 액세스 ▸ 라우트 테이블 통합: 엔드포인트는 라우트 테이블 항목으로 자동 추가됨 ▸ 무료 서비스: 추가 비용 없음 【정답 포인트】 ▸ 게이트웨이 엔드포인트는 프라이빗 서브넷의 라우트 테이블에 자동으로 통합되므로 EC2 인스턴스나 애플리케이션 변경이 불필요합니다 ▸ 기본 정책으로도 S3 액세스가 가능하며 추가 설정 최소화 ▸ 인터넷 게이트웨이 없이 S3 액세스 가능 【오답 체크】 (B) 인터페이스 엔드포인트는 비용 발생 및 더 복잡한 구성 (C) NAT 게이트웨이는 인터넷 액세스를 위한 것이므로 요구사항에 맞지 않음 (D) 프록시 인스턴스는 과도한 복잡성과 운영 오버헤드 【시험 포인트】 ▸ S3에 대한 프라이빗 액세스는 항상 게이트웨이 엔드포인트 우선 고려 ▸ "인터넷 액세스 금지" 요구사항에서는 게이트웨이 엔드포인트가 최적 솔루션 ▸ 변경 없음 요구사항은 게이트웨이 엔드포인트의 주요 특징

해설

【핵심 용어】 ▸ Cache-Control 헤더: Origin이 설정하는 HTTP 캐시 제어 ▸ max-age 지시문: 초 단위의 TTL 설정 ▸ CloudFront 최소/최대 TTL: Origin 헤더의 범위 제어 【정답 포인트】 ▸ Origin의 Cache-Control 헤더에서 max-age를 설정하면 CloudFront는 이 값을 존중하며 최소/최대 TTL 범위 내에서 조정됩니다 ▸ 페이지별로 서로 다른 max-age 지시문을 설정하면 개별 TTL 제어 가능 ▸ 추가 구성이 최소화됨 【오답 체크】 (A) CreateInvalidation은 캐시 무효화이지 TTL 제어 아님 (C) Lambda@Edge로 응답 헤더를 추가하면 Origin 설정이 무시되거나 우선순위 문제 발생 (D) Expires 헤더는 Legacy이며 Cache-Control이 우선 【시험 포인트】 ▸ CloudFront 캐싱 유연성이 필요하면 Origin의 Cache-Control 헤더 활용 ▸ CloudFront 함수는 응답 헤더 수정 제한이 있음 ▸ 페이지별 TTL 제어는 Origin 구성이 최선

해설

【핵심 용어】 ▸ 워밍 풀(Warm Pool): 미리 초기화된 대기 인스턴스 풀 ▸ Stopped 상태: 최소 비용으로 빠른 시작 ▸ 즉시 확장성: 기존 캐시로 즉시 트래픽 처리 【정답 포인트】 ▸ 워밍 풀의 인스턴스는 미리 부팅 및 캐시 초기화가 완료되었으므로 시작 시간이 최소화됩니다 ▸ Stopped 상태로 유지하면 비용은 적으면서도 Running 상태로 빠르게 전환 가능 ▸ 정확한 광고 시간을 예측할 필요 없이 항상 준비 상태 유지 【오답 체크】 (B) 캐시를 instance store에 저장한 후 중지하면 나중에 시작 시 캐시가 손실되거나 복원 과정이 복잡함 (C) 워밍업 시간 증가는 확장 속도 개선 안 함 (D) 예측 스케일링은 정확한 광고 시간을 모를 때는 부정확 【시험 포인트】 ▸ 즉시 확장이 필요한 경우 워밍 풀이 최적 솔루션 ▸ 긴 초기화 시간이 문제면 미리 초기화된 인스턴스 풀 사용 ▸ 예측 불가능한 트래픽 급증에는 워밍 풀이 더 효과적

해설

【핵심 용어】 ▸ Service Quotas: AWS 서비스의 할당량 관리 및 모니터링 ▸ CloudWatch 알람 통합: Service Quotas는 자동으로 CloudWatch 메트릭 발행 ▸ 할당량 사용률: 현재 사용량 대 최대 할당량의 비율 【정답 포인트】 ▸ Service Quotas는 할당량 사용률을 CloudWatch 메트릭으로 자동 발행하므로 Lambda 함수 필요 없음 ▸ Service Quotas 콘솔에서 직접 CloudWatch 알람 생성 가능하여 구성 간단 ▸ 할당량 사용률에 대한 표준 메트릭 지원 【오답 체크】 (A) Service Quotas API를 사용한 Lambda 함수는 과도하게 복잡하고 수동 개발 필요 (B) CloudWatch Metrics API는 할당량 정보 제공 안 함 (D) CPUUtilization과 할당량 사용률은 다른 메트릭이며 할당량 모니터링 용도 부족 【시험 포인트】 ▸ 할당량 모니터링은 Service Quotas의 내장 CloudWatch 통합 활용 ▸ Lambda로 수동 확인하는 것보다는 CloudWatch 알람이 훨씬 효율적 ▸ 할당량 관련 알람은 항상 Service Quotas 콘솔 우선 고려

해설

【핵심 용어】 ▸ AWS 계정 이름: 계정 설정의 최상위 속성 ▸ 루트 사용자: 계정의 모든 리소스에 대한 전체 제어 ▸ 계정 보안 설정: 루트 사용자만 수정 가능 【정답 포인트】 ▸ AWS 계정 이름은 IAM 권한으로 변경할 수 없으며 루트 사용자만이 계정 설정을 수정할 수 있습니다 ▸ 계정 이름은 계정의 기본 식별자이므로 최고 수준의 권한 필요 ▸ AWS 계정의 보안 설정은 루트 사용자 인증만 허용 【오답 체크】 (A) AdministratorAccess도 계정 이름 변경 권한 미제공 (B) AWS_ConfigureRole은 실제 정책 아님 (C) Trusted Advisor는 권장사항 제공만 함 【시험 포인트】 ▸ 계정 수준의 설정 변경은 루트 사용자 필요 ▸ IAM 권한만으로 불가능한 작업 식별하는 능력 중요 ▸ 최고 수준의 계정 관리는 항상 루트 사용자 사용

해설

【핵심 용어】 ▸ S3 Transfer Acceleration: CloudFront 에지 로케이션을 활용한 빠른 업로드 ▸ s3-accelerate.amazonaws.com: 가속화된 엔드포인트 ▸ 지역별 성능 최적화: 전 세계 사용자의 빠른 업로드 【정답 포인트】 ▸ S3 Transfer Acceleration은 AWS의 글로벌 엣지 네트워크를 사용하여 업로드 성능을 향상시킵니다 ▸ 활성화 후 가속화된 엔드포인트를 사용하기만 하면 되므로 구현 간단 ▸ 전 세계 여러 지역에서의 업로드 성능 개선 【오답 체크】 (A) ElastiCache는 캐싱용이며 업로드 가속과 무관 (B) CloudFront는 다운로드 최적화이며 업로드 성능 개선 안 함 (D) Multipart 업로드는 대용량 파일 분할 기법이지만 지역별 성능 문제 해결 안 함 【시험 포인트】 ▸ 지역별 업로드 성능 문제는 S3 Transfer Acceleration이 최적 솔루션 ▸ 다운로드 vs 업로드 최적화 구분 필요 (CloudFront는 다운로드) ▸ 글로벌 사용자의 빠른 업로드는 가속화된 엔드포인트 사용