AWS SAA 해설 261~

도은호·2025년 12월 20일

AWS SAA

목록 보기

49/53

A. Amazon CloudFront를 구성하여 콘텐츠의 여러 버전을 캐시합니다.
C. User-Agent 헤더를 기반으로 특정 객체를 사용자에게 전송하도록 Lambda@Edge 함수를 구성합니다.

요구 사항 분석:

글로벌 대상 고객: 전 세계 사용자에게 낮은 지연 시간으로 서비스를 제공해야 하므로 CDN(Amazon CloudFront)이 필수적입니다.
장치별 콘텐츠 제공: 모바일, 태블릿, 데스크톱 등 사용자의 장치(Device)에 따라 서로 다른 버전의 웹페이지나 이미지를 보여줘야 합니다. 이를 위해서는 HTTP 요청 헤더의 User-Agent를 검사해야 합니다.

해결책 (CloudFront + Lambda@Edge):
- CloudFront (캐싱): 전 세계 엣지 로케이션에 콘텐츠를 캐시하여 글로벌 사용자에게 빠르게 전송합니다. 설정에 따라 헤더 값별로 다른 버전을 캐시할 수 있습니다.
- Lambda@Edge (로직 실행): CloudFront가 요청을 받을 때(Viewer Request) 또는 오리진으로 보낼 때(Origin Request) 실행되는 Lambda@Edge 함수를 사용하여, 들어오는 요청의 User-Agent 헤더를 분석합니다. 장치 유형을 파악한 후, 모바일용 페이지(mobile.html)나 데스크톱용 페이지(desktop.html)를 오리진에서 가져오도록 요청을 다시 작성(Rewrite)하거나 리다이렉트하여 사용자에게 맞춤형 콘텐츠를 제공할 수 있습니다.

오답 노트

B, D, E (Network Load Balancer - NLB):
NLB는 OSI 4계층(전송 계층)에서 작동하는 로드 밸런서입니다. TCP/UDP 트래픽을 처리하며, HTTP 헤더(Host, User-Agent, Path 등)를 검사하여 라우팅하는 7계층 기능(Layer 7 Routing)을 지원하지 않습니다.
호스트 기반 라우팅이나 경로 기반 라우팅은 ALB(Application Load Balancer)의 기능입니다. 따라서 NLB를 사용하여 헤더 기반 분기를 하겠다는 설명은 기술적으로 틀린 내용입니다.

1. Lambda@Edge

정의: Amazon CloudFront의 엣지 로케이션에서 실행되는 서버리스 컴퓨팅 기능.
사용 사례:
- 헤더 조작: User-Agent 검사 후 장치별 콘텐츠 리다이렉션.
- 보안: 요청 인증, 봇 차단.
- SEO: 검색 엔진 크롤러에게 렌더링 된 페이지 제공.
- A/B 테스팅: 사용자 쿠키에 따라 다른 버전의 사이트 제공.

2. NLB vs ALB (라우팅 기능 차이)

기능	Network Load Balancer (NLB)	Application Load Balancer (ALB)
계층	Layer 4 (TCP/UDP)	Layer 7 (HTTP/HTTPS)
라우팅 기준	IP 주소, 포트	URL 경로, 호스트 헤더, HTTP 헤더, 쿼리 문자열
속도	초저지연 (Millions of RPS)	L7 처리를 위한 약간의 오버헤드

VPC 간에 피어링 연결을 만듭니다. 두 VPC 모두에서 피어링 연결에 대한 경로 테이블 항목을 추가합니다. ElastiCache 클러스터의 보안 그룹에 대한 인바운드 규칙을 구성하여 애플리케이션의 보안 그룹에서 인바운드 연결을 허용합니다.

비용 효율성 (Cost-Effective):
VPC 피어링 (VPC Peering): 두 VPC를 연결하는 가장 저렴하고 기본적인 방법입니다. 피어링 연결 자체에는 시간당 요금이 없으며, 동일 리전 내 데이터 전송 요금만 발생합니다.
Transit VPC / Transit Gateway: 별도의 인프라(EC2 또는 TGW)를 사용하므로 시간당 비용과 데이터 처리 비용이 추가로 발생하여 비용 효율성이 떨어집니다.

구성 단계:

연결: Cache VPC와 App VPC 간에 피어링 연결 생성.
라우팅: 양쪽 VPC의 라우팅 테이블(Route Table)에 상대방 VPC CIDR로 가는 경로(Target: pcx-xxxxx) 추가.
보안: ElastiCache 클러스터의 보안 그룹(Inbound)에서 애플리케이션 인스턴스의 트래픽을 허용해야 함. 이때 소스(Source)로 App VPC의 보안 그룹 ID를 참조할 수 있습니다(동일 리전 피어링의 장점).

VPC Peering (VPC 피어링)

정의: 비공개 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하는 네트워킹 연결.
특징:
게이트웨이, VPN 연결, 물리적 하드웨어 없이 통신 가능.
단일 실패 지점이 없음 (고가용성).
Transitive Peering(전이적 피어링) 미지원: A-B가 연결되고 B-C가 연결되어도, A-C는 통신 불가 (A-C를 직접 연결해야 함).

Security Group Referencing (피어링 환경)

동일 리전 내의 VPC 피어링에서는 상대방 VPC의 보안 그룹 ID를 인바운드/아웃바운드 규칙의 소스/대상으로 지정할 수 있습니다. 이를 통해 IP 주소가 바뀌어도 보안 규칙을 자동으로 유지할 수 있습니다.

A. Amazon Elastic Container Service(Amazon ECS) 클러스터를 배포합니다.
D. Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 서비스를 배포합니다. 원하는 작업 번호 수준을 2 이상 지정하세요.

요구 사항 분석:

마이크로서비스 & 컨테이너: 컨테이너 오케스트레이션 도구 필요 (ECS 또는 Kubernetes).
유지 관리 최소화 & 인프라 관리 불가: 서버(EC2)를 직접 관리하고 싶지 않음. 즉, Serverless 방식이 필요함.

해결책 (ECS + Fargate):
- ECS 클러스터: 컨테이너를 관리하고 배포하기 위한 논리적인 그룹인 ECS 클러스터를 먼저 생성해야 합니다. 이는 컨테이너 오케스트레이션의 기본 단계입니다.
- Fargate 시작 유형: AWS Fargate는 EC2 인스턴스를 프로비저닝하거나 관리할 필요 없이 컨테이너를 실행할 수 있는 서버리스(Serverless) 컴퓨팅 엔진입니다.
- 이 조합을 사용하면 회사는 서버 OS 패치, 확장, 보안 그룹 설정 등의 인프라 관리 작업 없이 오직 애플리케이션(컨테이너) 배포에만 집중할 수 있습니다.

Amazon ECS 시작 유형(Launch Type) 비교

특징	Fargate (정답)	EC2 Launch Type
모델	Serverless (서버 없음)	IaaS (인프라 관리)
관리 대상	컨테이너와 작업 정의만 관리	EC2 인스턴스, 클러스터 용량, OS 패치 관리 필요
가격 정책	vCPU 및 메모리 사용량에 따라 과금	실행 중인 EC2 인스턴스 비용 + EBS 비용
사용 사례	운영 오버헤드 최소화, 불규칙한 트래픽	리소스 세밀한 제어, 비용 최적화(RI/Spot), 기존 인스턴스 활용

EC2 인스턴스 앞에 상태 확인이 있는 애플리케이션 로드 밸런서(ALB)를 만듭니다. Route 53에서 ALB로 경로 지정합니다.

핵심 요약

문제 원인: 현재 Route 53이 10개의 EC2 인스턴스 IP를 직접 반환하고 있습니다. DNS 기반 부하 분산은 클라이언트의 DNS 캐싱(TTL) 때문에, 인스턴스가 비정상(Unhealthy) 상태가 되어도 Route 53이 이를 감지하고 레코드를 갱신하기 전까지(또는 클라이언트 캐시가 만료되기 전까지) 클라이언트는 계속해서 죽은 인스턴스의 IP로 접속을 시도하게 됩니다. 이로 인해 시간 초과(Timeout) 오류가 발생합니다.
해결책 (ALB 도입):
- Application Load Balancer(ALB)는 등록된 EC2 인스턴스에 대해 지속적으로 상태 검사(Health Check)를 수행합니다.
- 특정 인스턴스가 비정상으로 판명되면, ALB는 즉시 해당 인스턴스로의 트래픽 전송을 중단하고 정상적인 인스턴스로만 트래픽을 보냅니다.
- Route 53은 ALB의 DNS 이름만 가리키면 되므로, 클라이언트는 항상 정상 작동 중인 ALB와 통신하게 되어 시간 초과 오류가 해결됩니다.

Simple Routing + Health Check: 단순 라우팅 정책(Simple Routing)은 단일 레코드에 여러 IP를 나열할 수 있지만, 개별 IP에 대한 상태 검사를 기반으로 특정 IP만 쏙 빼고 반환하는 기능을 제공하지 않습니다. 이를 위해서는 다중 값 응답(Multivalue Answer) 라우팅 정책을 사용해야 합니다. 하지만 설령 다중 값 응답을 쓰더라도 DNS 캐싱 문제로 인해 ALB보다 반응 속도가 느립니다.
Failover Routing: 장애 조치(Failover) 라우팅은 주(Primary) 사이트와 보조(Secondary/DR) 사이트 간의 Active-Passive 구성을 위한 것입니다. 10개의 인스턴스에 트래픽을 분산하는 부하 분산(Load Balancing) 용도가 아닙니다.
CloudFront: CloudFront는 콘텐츠 전송 네트워크(CDN)입니다. 원본(Origin)으로 EC2를 직접 지정할 수도 있지만, 10개의 인스턴스를 개별적으로 관리하며 부하를 분산하는 것은 CloudFront의 주 역할이 아닙니다. 일반적으로 CloudFront 뒤에 ALB를 두는 구성을 사용합니다.

DNS Load Balancing vs ELB Load Balancing

DNS (Route 53): 클라이언트가 도메인을 IP로 바꿀 때 부하 분산. 단점: 클라이언트나 로컬 DNS 리졸버가 IP를 캐싱(TTL)하고 있으면, 서버가 죽어도 캐시가 만료될 때까지 계속 죽은 서버로 접속을 시도함.
ELB (Load Balancer): 트래픽을 받아 뒷단(Backend)의 서버로 전달. 장점: 인스턴스 상태를 실시간으로 확인하고 즉시 트래픽을 차단하므로 사용자는 오류를 겪지 않음. 웹 애플리케이션 트래픽 제어에는 ELB가 표준.

프라이빗 서브넷에 여러 개의 중복 Amazon EC2 인스턴스가 있는 퍼블릭 애플리케이션 로드 밸런서(ALB)를 구성합니다. 퍼블릭 ALB를 원본으로 사용하여 HTTPS 콘텐츠를 전송하도록 Amazon CloudFront를 구성합니다.

요구 사항 분석:

엣지 전송 & 최단 시간: 전 세계 엣지 로케이션을 사용하는 Amazon CloudFront가 필수입니다.
가장 안전한 구성 (Most Secure): 애플리케이션 서버(EC2)는 외부 인터넷에서 직접 접근할 수 없도록 프라이빗 서브넷(Private Subnet)에 배치해야 합니다.
고가용성: 여러 중복 EC2 인스턴스와 로드 밸런서(ALB)를 사용합니다.

해결책 (CloudFront + ALB + Private EC2):
- 보안 계층화: EC2 인스턴스를 프라이빗 서브넷에 숨겨 공격 면을 줄입니다. 외부와의 통신은 오직 퍼블릭 ALB를 통해서만 이루어집니다.
- 트래픽 흐름: 사용자 -> CloudFront (엣지) -> 퍼블릭 ALB -> 프라이빗 EC2 순서로 안전하게 데이터가 전달됩니다. CloudFront는 ALB를 오리진(Origin)으로 바라보며, ALB가 트래픽을 프라이빗 인스턴스로 분산합니다.

오답 노트

A, D (퍼블릭 서브넷의 EC2): EC2 인스턴스를 퍼블릭 서브넷에 두면 인터넷에 직접 노출될 위험이 있어 "가장 안전한" 구성이 아닙니다. 보안 모범 사례는 컴퓨팅 리소스를 프라이빗 영역에 두는 것입니다.
B, D (EC2를 원본으로 사용):
- B: 프라이빗 서브넷에 있는 EC2는 퍼블릭 IP가 없으므로 CloudFront가 직접 접근(Origin으로 설정)할 수 없습니다. 반드시 ALB를 거쳐야 합니다.
- D: EC2를 직접 원본으로 사용하면 로드 밸런싱의 이점을 살리기 어렵고 구성이 복잡해집니다. 또한 A와 마찬가지로 퍼블릭 서브넷 사용으로 인한 보안 취약점이 있습니다.

안전한 웹 애플리케이션 아키텍처 (Standard Secure Pattern)

CloudFront: 전역 콘텐츠 전송 및 DDoS 방어(AWS Shield Standard).
Public ALB: 인터넷(CloudFront) 트래픽을 수신하여 내부로 전달. 보안 그룹을 통해 CloudFront의 IP 대역만 허용하거나 사용자 지정 헤더(Custom Header)를 통해 액세스 제한 가능.
Private EC2: 인터넷 접근이 차단된 안전한 공간에서 실제 애플리케이션 로직 처리. ALB의 트래픽만 허용(Security Group Referencing).

AWS Global Accelerator에서 가속기를 구성합니다. 애플리케이션이 수신 대기하는 포트에 대한 리스너를 추가하고 각 지역의 지역 엔드포인트에 연결합니다. ALB를 엔드포인트로 추가합니다.

요구 사항 분석:

지연 시간 민감 (Latency-sensitive): 게임 플랫폼의 특성상 낮은 지연 시간과 네트워크 안정성(Jitter 최소화)이 필수입니다.
글로벌 배포: 모든 AWS 리전에 애플리케이션이 배포되어 있습니다.
상태 모니터링 및 리디렉션: 엔드포인트(ALB)의 상태를 확인하고, 장애 발생 시 정상적인 리전으로 트래픽을 즉시 전환해야 합니다.

해결책 (AWS Global Accelerator):
- 네트워크 최적화: Global Accelerator는 사용자의 트래픽을 가장 가까운 AWS 엣지 로케이션으로 유입시킨 후, 혼잡한 공용 인터넷 대신 AWS 글로벌 네트워크(백본망)를 통해 애플리케이션으로 전송합니다. 이를 통해 지연 시간과 패킷 손실을 줄이고 일관된 성능을 제공합니다.
- 자동 상태 확인 및 장애 조치: Global Accelerator는 지속적으로 엔드포인트(ALB)의 상태를 모니터링합니다. 특정 리전의 ALB가 비정상 상태가 되면, 클라이언트의 변경 없이 트래픽을 즉시(1분 이내) 다른 리전의 정상적인 엔드포인트로 리디렉션합니다. 이는 게임 서비스의 가용성과 공정성을 유지하는 데 최적의 솔루션입니다.

AWS Global Accelerator

정의: 로컬 또는 글로벌 사용자를 위해 애플리케이션의 가용성과 성능을 개선하는 네트워킹 서비스.
핵심 기능:
- 고정 IP (Anycast IP): 전 세계 어디서나 동일한 2개의 정적 IP로 접속.
- AWS 백본망 사용: 공용 인터넷을 우회하여 지연 시간 및 패킷 손실 감소.
- 게임/미디어 최적화: UDP/TCP 트래픽을 가속화하여 게임, VoIP 등에 적합.
- 빠른 장애 조치: DNS 캐시 갱신을 기다릴 필요 없이 즉시 트래픽 경로 변경.

Amazon S3에 데이터를 저장하기 위해 Amazon Kinesis Data Firehose 전송 스트림을 만듭니다. 데이터를 분석하기 위해 Amazon Kinesis Data Analytics 애플리케이션을 만듭니다.

요구 사항 분석:

거의 실시간 분석: 스트리밍 데이터를 즉시 분석해야 함.
Parquet 포맷 저장 & 암호화: 데이터를 S3에 저장하기 전에 포맷을 변환하고 암호화해야 함.
가장 적은 운영 오버헤드: 서버 관리나 복잡한 설정이 없는 완전 관리형(Serverless) 서비스를 사용해야 함.

해결책 (Firehose + Data Analytics):
- Amazon Kinesis Data Firehose: 스트리밍 데이터를 S3로 전송하는 가장 쉬운 방법입니다. 특히 데이터 포맷 변환(JSON → Parquet) 기능과 암호화 기능을 자체적으로 지원하므로, 별도의 Lambda 함수나 변환 서버를 구축할 필요 없이 설정만으로 요구 사항을 충족합니다. (운영 오버헤드 최소화).
- Amazon Kinesis Data Analytics: 스트리밍 데이터에 대해 표준 SQL을 사용하여 실시간 분석을 수행할 수 있는 서버리스 서비스입니다. 서버를 프로비저닝하거나 관리할 필요가 없습니다.

오답 노트

A (Lambda 호출): Kinesis Data Streams에서 S3로 데이터를 저장할 때 포맷 변환 등을 위해 Lambda를 직접 구현하고 관리해야 하므로 Firehose보다 오버헤드가 큽니다.
B, C (Amazon EMR): EMR은 하둡/스파크 클러스터입니다. 강력하지만 클러스터 구성, 사이징, 패치 등 운영 오버헤드가 매우 높습니다. 단순히 데이터를 변환하고 분석하기 위해 EMR을 띄우는 것은 "가장 적은 운영 오버헤드" 요건에 맞지 않습니다.

Amazon Kinesis Data Firehose의 주요 기능 (빈출)

목적: 스트리밍 데이터를 데이터 스토어(S3, Redshift, Elasticsearch, Splunk)로 로드.
데이터 변환:
- 포맷 변환: JSON 데이터를 Apache Parquet 또는 Apache ORC로 자동 변환하여 S3에 저장 (Athena/Redshift 쿼리 성능 향상 및 비용 절감).
- Lambda 연동: 데이터를 전송하기 전에 Lambda를 호출하여 커스텀 변환 가능.

완전 관리형: 자동 확장, 서버 관리 불필요.

데이터베이스 앞에 Amazon ElastiCache를 사용합니다.

핵심 요약

문제 원인: 게임 애플리케이션의 점수(Score) 데이터에 대한 읽기 부하(Read Performance)로 인해 데이터베이스 지연과 중단이 발생하고 있습니다.
해결책 (ElastiCache):
- 캐싱(Caching): 점수판(Leaderboard)이나 상위 점수와 같이 자주 조회되는 데이터를 메모리 기반의 Amazon ElastiCache (Redis 또는 Memcached)에 저장합니다.
- 부하 분산: 애플리케이션이 데이터베이스에 직접 쿼리하는 대신 캐시를 먼저 조회하도록 하여, RDS MySQL의 읽기 부하를 획기적으로 줄이고 응답 속도를 밀리초(ms) 단위로 단축할 수 있습니다.
- 아키텍처 변경 최소화: 데이터베이스를 교체(DynamoDB)하거나 컴퓨팅 계층을 변경(Lambda)하는 것에 비해, 캐시 계층을 추가하는 것은 기존 아키텍처를 유지하면서 성능을 개선하는 가장 효율적인 방법입니다.

오답 노트

RDS Proxy: RDS Proxy는 데이터베이스 연결(Connection) 관리와 풀링(Pooling)을 통해 연결 오버헤드를 줄이고 장애 조치 시간을 단축하는 데 사용됩니다. 대규모 연결로 인한 문제가 아니라 "데이터베이스 읽기 성능" 자체의 문제이므로 캐싱(ElastiCache)이 더 적절한 해결책입니다.
AWS Lambda: EC2에서 Lambda로 마이그레이션하는 것은 컴퓨팅 환경을 바꾸는 것으로, 애플리케이션 코드를 리팩토링해야 하며 데이터베이스 읽기 성능 문제를 직접 해결하지 못합니다.
DynamoDB: 관계형 데이터베이스(MySQL)에서 NoSQL(DynamoDB)로 마이그레이션하려면 데이터 모델과 애플리케이션 코드를 완전히 새로 작성해야 하므로 "아키텍처 변경 최소화" 요구 사항에 위배됩니다.

Amazon ElastiCache

용도: 데이터베이스 앞단에서 읽기 중심의 워크로드를 가속화.
사용 사례:
게이밍: 실시간 순위표(Leaderboard), 플레이어 세션 저장.
웹: 자주 액세스하는 콘텐츠 캐싱, 세션 관리.

Redis vs Memcached:
- Redis: 복잡한 데이터 구조(Sorted Sets - 순위표 구현에 유용), 고가용성, 백업 지원.
- Memcached: 단순한 멀티스레드 캐시.

기본 데이터베이스의 읽기 복제본(Read Replica)을 만들고 비즈니스 분석가에게 쿼리를 실행하게 합니다.

문제 상황: 비즈니스 분석가들이 수행하는 읽기 전용(Read-only) 쿼리가 급증하여 메인 DB(RDS)의 부하를 유발하고 웹 애플리케이션 성능을 저하시킴.
해결책 (Read Replica):
- 부하 분리: RDS의 기능인 읽기 복제본을 생성하면 메인 DB의 데이터를 비동기적으로 복제받는 읽기 전용 인스턴스가 만들어집니다.
- 최소한의 변경: 웹 애플리케이션은 기존대로 메인 DB를 바라보게 두고, 분석가들에게만 복제본의 엔드포인트(주소)를 제공하여 그쪽에서 쿼리를 날리게 하면 됩니다. 애플리케이션 코드를 수정하거나 데이터 구조를 바꿀 필요가 가장 적은 방법입니다.

Amazon RDS Read Replica (읽기 복제본)

목적: 단일 DB 인스턴스의 읽기 용량 한계를 극복하고 트래픽을 분산.
작동 방식: 기본 인스턴스(Source)의 데이터를 비동기식으로 복제.
활용 사례:
비즈니스 리포팅/분석: 분석가들이 메인 서비스에 영향을 주지 않고 데이터를 조회할 때.
읽기 중심 앱: 웹 애플리케이션의 읽기 트래픽 분산.

클라이언트 측 암호화를 사용하여 S3 버킷에 업로드되는 데이터를 암호화합니다.

요구 사항 분석:

시점: 데이터가 S3 버킷에 업로드되기 전(Before Upload)에 암호화되어야 함.
전송 보안: 전송 중(In-transit)에도 암호화되어야 함.

해결책 (Client-Side Encryption):
- 클라이언트 측 암호화(Client-Side Encryption): 데이터를 AWS로 보내기 전에 사용자의 로컬 환경(클라이언트)에서 직접 암호화하는 방식입니다. 암호화된 상태로 업로드되므로 "업로드되기 전" 요구 사항을 완벽하게 충족하며, 전송 구간에서도 데이터 자체가 암호화되어 있어 안전합니다.

S3 암호화 방식 비교

방식	클라이언트 측 암호화 (CSE)	서버 측 암호화 (SSE)
암호화 시점	업로드 전 (사용자 PC/서버)	업로드 후 (S3 데이터 센터)
키 관리	사용자가 직접 관리하거나 KMS 사용	AWS가 관리 (S3-Managed, KMS, Customer-Key)
전송 중 보안	데이터 자체가 암호화됨 (이중 보호)	HTTPS(TLS)에 의존
사용 사례	데이터가 클라우드로 떠나기 전에 보안이 필수일 때	데이터 관리 편의성 및 규정 준수

원하는 컴퓨팅 수준까지 확장하도록 예약된 확장을 구성합니다.

핵심 요약

요구 사항 분석:

예측 가능한 패턴: 작업이 "매일 밤 오전 1시"에 시작됨.
일정한 부하: 최대 용량이 "매일 밤 동일"함.
문제점: 현재 반응형 확장(Reactive Scaling)으로 인해 용량 도달까지 1시간이나 소요됨.
목표: 즉시 용량 확보 및 작업 후 축소 (비용 효율성).

해결책 (Scheduled Scaling):
- 예측 기반(Proactive): 트래픽이 발생하기 전(예: 오전 0시 50분)에 미리 Desired Capacity(원하는 용량)를 최대치로 변경하도록 일정을 설정합니다.
- 지연 시간 제거: 작업 시작 시점에 이미 인스턴스가 준비되어 있으므로, 1시간 동안 서서히 늘어나는 지연 시간을 완전히 제거할 수 있습니다.
- 비용 절감: 작업이 끝나는 시간에 맞춰 다시 용량을 줄이도록 예약하면 필요한 시간만 과금되므로 비용 효율적입니다.

Auto Scaling 전략 비교

전략	예약된 확장 (Scheduled Scaling)	동적 확장 (Dynamic Scaling)	예측 확장 (Predictive Scaling)
작동 방식	특정 시간에 맞춰 용량 변경	CPU 등 지표 변화에 반응	머신 러닝으로 과거 패턴 분석 후 예측
적합한 사례	출/퇴근 시간, 월말 배치 작업 등 시간이 고정된 패턴	예고 없는 트래픽 급증 (Viral 등)	주기적인 패턴이 있지만 복잡할 때
장점	가장 확실한 사전 확보 (지연 0)	실시간 부하에 유연하게 대응	사전 확보 + 유연성 결합

ALB를 원본으로 하여 Amazon CloudFront 배포를 구성합니다. Accept-Language 요청 헤더에 따라 캐시하도록 캐시 동작 설정을 설정합니다.

핵심 요약

요구 사항 분석:

동적 웹사이트: EC2 + ALB 기반 (단순 정적 파일 아님).
글로벌 지연 시간 해결: 전 세계 사용자에게 빠르게 콘텐츠 전송 필요.
다국어 지원: 언어별(Accept-Language)로 다른 콘텐츠 제공 및 캐싱 필요.
제약 사항: 기존 아키텍처를 여러 리전에 다시 만들고 싶지 않음 (Single Region Origin).

해결책 (CloudFront + Header Caching):
- CloudFront (CDN): 전 세계 엣지 로케이션(Edge Location)을 통해 콘텐츠를 캐싱하고 사용자에게 가장 가까운 곳에서 전송하여 지연 시간을 획기적으로 줄입니다. 오리진(Origin)이 단일 리전(us-west-1)에 있어도 글로벌 성능 가속이 가능합니다.
- 헤더 기반 캐싱 (Accept-Language): CloudFront가 캐싱할 때 Accept-Language 헤더 값을 기준으로 별도의 객체를 저장하도록 설정(Whitelist Headers)합니다. 이를 통해 한국어 사용자에게는 한국어 페이지를, 영어 사용자에게는 영어 페이지를 캐시에서 바로 제공할 수 있습니다.

오답 노트

A (S3 정적 호스팅): 문제에서 "동적 웹사이트(Dynamic Website)"라고 명시했습니다. S3는 정적 콘텐츠(HTML, CSS, JS 등)만 호스팅할 수 있으므로, 서버 측 로직이 필요한 동적 웹사이트를 대체할 수 없습니다.
C (API Gateway): API Gateway는 REST/HTTP API를 위한 관리형 서비스입니다. 일반적인 웹사이트의 페이지 로딩 속도를 개선하거나 글로벌 CDN 역할을 하는 데에는 CloudFront가 훨씬 적합하고 비용 효율적입니다.
D (Nginx in Multi-region): "각 추가 지역에서 EC2 인스턴스를 시작"한다는 설명은 "기존 아키텍처를 여러 리전에 다시 만들고 싶지 않다"는 회사의 핵심 제약 사항을 정면으로 위배합니다. 운영 오버헤드도 매우 큽니다.

Amazon CloudFront의 캐싱 동작 (Cache Behavior)

기본 동작: URL 경로를 기준으로 캐싱.
요청 헤더 기반 캐싱 (Cache Based on Selected Request Headers):
특정 헤더(예: Accept-Language, User-Agent, Referer)의 값에 따라 콘텐츠가 달라지는 경우 사용.
설정: 'Whitelist' 목록에 Accept-Language를 추가하면, CloudFront는 언어별로 캐시 버전을 따로 생성하여 저장함.
주의: 너무 많은 헤더를 허용하면 캐시 적중률(Hit Ratio)이 낮아질 수 있음.

웜 스탠바이 배포를 통해 Amazon Aurora 글로벌 데이터베이스를 사용합니다.

요구 사항 분석:

재해 복구(DR) 전략: 다른 AWS 리전 포함.
데이터베이스: 지연 시간 최소화(Minimal Latency), 최신 상태 유지.
인프라: 축소된 용량으로 실행, 필요 시 확장.
핵심 목표: 가장 낮은 복구 시간 목표(Lowest RTO).

해결책 (Warm Standby + Aurora Global Database):
- Aurora Global Database: 단일 AWS 리전의 성능에 영향을 주지으면서 전용 인프라를 통해 1초 미만의 일반적인 지연 시간으로 데이터를 보조 리전에 복제합니다. 재해 발생 시 1분 이내에 보조 리전을 승격할 수 있어 RTO가 매우 낮습니다. RDS의 리전 간 복제보다 훨씬 빠르고 효율적입니다.
- 웜 스탠바이(Warm Standby): DR 리전에서 애플리케이션과 인프라가 "축소된 용량"으로 항상 실행 중인 상태를 말합니다. 재해 발생 시 트래픽을 처리하기 위해 스케일 업(Scale-up)만 하면 되므로, 서버를 처음부터 켜야 하는 파일럿 라이트(Pilot Light) 방식보다 복구 시간(RTO)이 훨씬 짧습니다.

오답 노트

A (파일럿 라이트 + Aurora Global DB): 파일럿 라이트는 데이터베이스는 켜져 있지만 애플리케이션 서버 등은 꺼져 있는 상태입니다. 재해 시 서버를 부팅하고 설정하는 시간이 필요하므로 웜 스탠바이보다 RTO가 높습니다(느립니다).
C, D (RDS Multi-AZ): RDS Multi-AZ는 기본적으로 단일 리전 내의 고가용성(HA)을 위한 기능입니다. 다른 리전으로의 DR을 위해서는 리전 간 읽기 전용 복제본(Cross-Region Read Replica)을 사용해야 하는데, 이는 Aurora Global Database에 비해 복제 지연 시간이 길고 승격 절차가 복잡하여 RTO/RPO 측면에서 불리합니다.

1. DR 전략 스펙트럼 (비용 vs RTO/RPO)

전략	설명	비용	RTO (복구 시간)
백업 및 복원 (Backup & Restore)	데이터를 S3 등에 백업해두고 필요 시 복구.	가장 낮음	가장 높음 (수 시간~수일)
파일럿 라이트 (Pilot Light)	DB 데이터는 실시간 동기화하되, 앱 서버는 꺼둠.	낮음	중간 (수십 분)
웜 스탠바이 (Warm Standby)	DB와 앱 서버가 최소 용량으로 항상 실행 중. (정답)	중간	낮음 (수 분)
멀티 사이트 액티브/액티브	두 리전에서 모두 트래픽을 실시간 처리.	가장 높음	거의 0 (즉시)

시험 팁: "가장 낮은 RTO", "빠른 복구", "축소된 용량으로 실행 중"이라는 키워드가 나오면 웜 스탠바이가 정답일 확률이 높고, "서버가 꺼져 있음", "비용 최소화"가 강조되면 파일럿 라이트가 정답일 확률이 높습니다.

2. Amazon Aurora Global Database

특징:
물리적 복제: 스토리지 레벨에서 복제가 일어나므로 논리적 복제(binlog 등)를 사용하는 일반 RDS보다 훨씬 빠름.
지연 시간: 리전 간 복제 지연 시간(Lag)이 통상 1초 미만.
빠른 승격: DR 리전을 마스터로 승격하는 데 1분 미만 소요.

EC2 인스턴스를 백업하기 위해 Amazon Machine Images(AMI)를 만듭니다. AMI를 보조 AWS 리전에 복사합니다. AWS CloudFormation을 사용하여 보조 리전에서 인프라 배포를 자동화합니다.

요구 사항 분석:

RTO < 4시간: 복구 시간이 4시간 미만이어야 함. (비교적 여유로운 RTO).
최소 리소스 사용: 평상시에는 비용이 거의 발생하지 않아야 함.
운영 효율성: 인프라 배포 관리가 쉬워야 함.

해결책 (Backup & Restore + IaC):
- AMI 복사: 주 리전의 EC2를 AMI로 만들어 보조 리전으로 복사해 두면, 평상시에는 S3 스토리지 비용만 발생하므로 "가능한 가장 적은 AWS 리소스 사용" 요건을 완벽하게 충족합니다.
- CloudFormation (IaC): 재해 발생 시 인프라(VPC, 서브넷, EC2 등)를 수동으로 만들거나 스크립트로 짜는 대신, 미리 정의된 CloudFormation 템플릿을 실행하면 수십 분 내에 전체 환경을 일관성 있게 배포할 수 있습니다. 이는 4시간 RTO를 충분히 만족하며, 사용자 지정 스크립트(Lambda)보다 유지 보수가 훨씬 쉽고 운영적으로 효율적입니다.

AWS DR 전략 비교 (리소스 효율성 중심)

전략	설명	비용 (리소스 사용)	RTO (복구 시간)
백업 및 복원 (정답)	데이터/AMI만 보조 리전에 저장. 장애 시 인프라 생성.	가장 낮음 (스토리지 비용만 발생)	높음 (수 시간)
파일럿 라이트	DB는 켜두고(데이터 복제), 앱 서버는 꺼둠.	낮음 (DB 비용 발생)	중간 (수십 분)
웜 스탠바이	축소된 규모로 전체 시스템 가동.	중간 (컴퓨팅 비용 발생)	낮음 (수 분)
멀티 사이트	양쪽 리전 모두 active 상태.	높음 (2배 비용)	거의 0

시험 팁: "RTO가 여유롭다(수 시간)", "비용 최소화", "평상시 리소스 최소화"라는 키워드가 나오면 백업 및 복원(Backup and Restore) 전략이 정답입니다. 이때 인프라 배포 도구로는 CloudFormation이 가장 운영 효율적인 선택입니다.

정답: A

사무실이 문을 열기 직전에 원하는 수용 인원(Desired Capacity)을 20명으로 설정하는 예약된 작업을 구현합니다.

핵심 요약

문제 분석:
- 증상: 애플리케이션이 하루 업무 시작 시점(오전)에 매우 느립니다. 이는 직원들이 출근하여 트래픽이 급증할 때, Auto Scaling 그룹이 반응형으로 인스턴스를 늘리는 데 시간이 걸리기 때문입니다(Warm-up delay).
- 패턴: "근무 시간 동안" 트래픽이 발생하며, 이는 매우 예측 가능한 패턴입니다.
- 목표: 성능 저하(지연)를 해결하고 비용을 최소화해야 합니다.

해결책 (예약된 조정 - Scheduled Scaling):
- 예약된 작업(Scheduled Action)을 사용하여 사무실 문을 열기 직전에 원하는 용량(Desired Capacity)을 미리 20으로 늘립니다. 이렇게 하면 직원이 도착하기 전에 인스턴스가 미리 프로비저닝되어(Pre-warming), 트래픽 급증 시 즉각적인 처리가 가능해져 느려지는 현상을 막을 수 있습니다. 또한, 고정된 크기를 유지하는 것이 아니라 트래픽이 줄어들면 동적 조정 정책에 의해 줄어들 수 있어(설정에 따라 다름) 유연한 비용 관리가 가능합니다.
- 트래픽이 예측 가능할 때는 사후 대응하는 동적 조정보다 사전 대응하는 예약된 조정이 가장 적합합니다.

오답 노트

B, C (동적 조정 - 단계적/대상 추적):
- 이 방식들은 CPU 사용량이 이미 높아진 후에 반응하여 확장을 시작합니다. 따라서 아무리 민감도를 높이더라도(임계값을 낮추더라도), 아침 출근 시간의 급격한 트래픽 스파이크에 대응하는 초기 지연 시간(Lag)을 완전히 없앨 수는 없습니다. 문제의 핵심인 "시작될 때 매우 느리다"는 불만을 해결하기 어렵습니다.

D (최소/최대 용량을 20으로 고정):
- 최소(Min)와 최대(Max)를 모두 20으로 설정하면 Auto Scaling 그룹의 크기가 20개로 고정(Static)됩니다.
- 이렇게 하면 업무 시간 중 점심시간이나 오후에 트래픽이 줄어들더라도 인스턴스 수를 줄일 수 없게 되어, 비용을 최소화하라는 요구 사항에 위배됩니다. 반면 A(원하는 용량 설정)는 초기 부팅 후 트래픽 패턴에 따라 조정 정책이 작동할 여지를 남길 수 있어(또는 다른 예약 작업으로 축소 가능) 더 효율적입니다.

AWS Auto Scaling 전략

예측 조정 (Predictive Scaling): 머신 러닝을 사용하여 과거 트래픽 패턴을 분석하고 향후 트래픽을 예측하여 조정.
예약된 조정 (Scheduled Scaling): 특정 시간(예: 매일 오전 9시, 매주 월요일)에 트래픽이 급증하는 것이 확실할 때 사용. 사전에 용량을 확보하여 지연 방지.
동적 조정 (Dynamic Scaling):

대상 추적 (Target Tracking): 특정 지표(예: CPU 50%)를 유지하도록 조정. 가장 권장되는 방식.
단계적 조정 (Step Scaling): 경보 위반 크기에 따라 단계적으로(예: +1, +3) 조정.
단순 조정 (Simple Scaling): 단일 조정 후 쿨다운 대기. (구식)

A. RDS for Oracle 인스턴스에서 스토리지 자동 크기 조정을 구성합니다.
D. 자동 크기 조정 그룹을 구성하여 평균 CPU를 크기 조정 지표로 사용합니다.

핵심 요약

문제 분석
- EC2 과부하: 트래픽 증가에 따른 컴퓨팅 리소스 부족.
- RDS 스토리지 부족: 데이터 증가로 인한 공간 부족.
- 제약: Oracle PL/SQL 사용 (DB 엔진 변경 어려움), 자동화 필요.

해결책
- RDS 스토리지 오토 스케일링 (옵션 A): RDS for Oracle은 스토리지 자동 조정 기능 지원. 여유 공간 부족 시 가동 중단 없이 스토리지 용량 자동 확장 가능.
- ASG 조정 정책 (옵션 D): 현재 메트릭이 없는 상태. 평균 CPU 사용률은 EC2의 기본 제공 지표이며, 부하 증가를 판단하는 가장 표준적인 기준. 대상 추적(Target Tracking) 정책으로 CPU 일정 수준 유지 가능.

오답 노트

B (Aurora 마이그레이션): Oracle PL/SQL 함수 사용 중. Aurora(MySQL/PostgreSQL)로 마이그레이션 시 코드 재작성 및 스키마 변환 비용 과다 발생. (Babelfish for Aurora PostgreSQL이 있으나 T-SQL용임).
C (알람 구성): 알람은 '통지' 기능일 뿐, 스토리지를 자동으로 늘려주지 않음. 운영자 개입 필요.
E (평균 메모리): 메모리 사용량은 EC2 기본 지표가 아님. CloudWatch Agent 설치 필요. CPU가 가장 보편적이고 즉시 적용 가능한 지표.

1. Amazon RDS Storage Auto Scaling

기능: 감지된 워크로드에 맞춰 데이터베이스 스토리지 용량을 자동으로 확장.
조건:
- 여유 공간이 할당된 스토리지의 10% 미만.
- 스토리지 부족 상태가 5분 이상 지속.
- 마지막 수정 후 6시간 경과.

지원 엔진: MariaDB, MySQL, PostgreSQL, Oracle, SQL Server.

2. ASG Scaling Metrics (오토 스케일링 지표)

기본 지표 (Default):
- CPU Utilization: 가장 일반적인 부하 척도.
- Network In/Out: 네트워크 대역폭 기준.

사용자 지정 지표 (Custom):
- Memory Utilization: OS 내부 정보이므로 CloudWatch Agent 설치 필수.
- Disk Usage: 역시 에이전트 필요.

비디오 콘텐츠를 저장하기 위해 Amazon S3를 사용합니다. 파일을 처리를 위해 서버에 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨으로 임시로 옮깁니다.

핵심 요약

문제 원인: Amazon EFS Standard는 고성능 파일 스토리지이나, 대용량 비디오 원본을 장기간 저장하기에는 비용이 매우 높음 ($0.30/GB 대).
해결책 (S3 + EBS 임시 처리):
- 저장소 변경 (Cost): Amazon S3는 EFS 대비 약 1/10 수준으로 저렴 ($0.023/GB 대)하며 무제한 확장 가능. 비디오 아카이브 및 서비스용 스토리지로 최적.
- 처리 방식: 트랜스코딩 작업 시에만 S3에서 파일을 가져와 EC2에 연결된 EBS(고성능 블록 스토리지)에서 빠르게 처리한 후, 결과물을 다시 S3에 업로드하고 EBS 데이터는 삭제(임시 사용).
결과: 스토리지 비용 최소화 + 처리 성능 유지.

AWS 스토리지 비용 비교 (대략적 순서)

Amazon EC2 Instance Store: 무료 (휘발성, 임시)
Amazon S3 Glacier Deep Archive: 가장 저렴 (장기 보관)
Amazon S3 Standard: 저렴 (범용 객체 스토리지)
Amazon EBS (GP3): 중간 (OS, DB, 고성능 디스크)
Amazon EFS Standard: 비쌈 (공유 파일 시스템, 탄력성)
Amazon FSx for Windows: 비쌈 (Windows 네이티브)

Tip: 대용량 미디어 파일의 "저장 비용" 문제가 나오면 무조건 S3로의 전환이 1순위 정답.

B. Amazon DynamoDB를 사용하여 직원 데이터를 계층 구조로 저장합니다. 매월 Amazon S3로 데이터를 내보냅니다.
E. AWS 계정에 대해 Amazon Macie를 구성합니다. Macie를 Amazon EventBridge와 통합하여 Amazon Simple Notification Service(Amazon SNS) 구독을 통해 월별 알림을 보냅니다.

핵심 요약

요구 사항 분석:

데이터 구조: 직원 데이터, 계층 구조(Hierarchical).
성능: 트래픽이 많고, 최소 지연(Low Latency) 응답 필수.
보안/규정 준수: 민감한(재무) 데이터 보호 및 감지 시 월별 이메일 알림.

해결책 (DynamoDB + Macie):
- DynamoDB (성능 & 구조): DynamoDB는 10밀리초 미만의 지연 시간을 제공하여 트래픽이 많은 쿼리에 최적화됨. 인접 목록(Adjacency List) 패턴 등을 통해 계층적 데이터를 효과적으로 모델링 가능. S3로의 데이터 내보내기 기능을 통해 보안 스캔을 위한 데이터 준비 가능.
- Amazon Macie (민감 데이터 감지): S3에 저장된 데이터를 머신 러닝으로 스캔하여 PII(개인 식별 정보)나 재무 정보를 자동으로 식별함.
- EventBridge + SNS (알림): Macie의 검색 결과(Findings)를 EventBridge가 감지하고, SNS 주제(Topic)를 트리거하여 관리자에게 이메일 알림을 발송. (S3 내보내기가 월별로 이루어지므로, 스캔 및 알림도 주기에 맞게 구성 가능).

오답 노트

A (Redshift): 데이터 웨어하우스(OLAP)로 대규모 분석에 적합하지만, 애플리케이션의 실시간/저지연 트랜잭션 처리에는 부적합.
C (Macie + Lambda): Lambda를 사용하여 이메일을 보낼 수도 있지만, 단순 알림 전송에는 SNS가 더 간편하고 표준적인 방법(Serverless/No-code).
D (Athena + QuickSight): 데이터를 분석하고 시각화하는 도구임. 애플리케이션의 백엔드 스토리지나 민감 데이터 자동 감지/알림 요구 사항을 충족하지 못함.

1. Amazon Macie

기능: Amazon S3 버킷을 스캔하여 민감한 데이터(이름, 주소, 신용카드 번호 등)를 발견하고 분류하는 완전 관리형 데이터 보안 서비스.
용도: 데이터 프라이버시 규정 준수, 데이터 유출 방지.

2. DynamoDB Hierarchical Data (계층형 데이터)

모델링: 단일 테이블 설계(Single Table Design)에서 Partition Key와 Sort Key를 활용하거나, 자체 참조(Self-referencing) 구조를 통해 조직도 같은 트리 구조 저장 가능.
성능: 어떤 규모에서도 일관된 속도 보장.

매월 1일에 DynamoDB 테이블을 백업하기 위한 AWS 백업 계획을 만듭니다. 6개월 후 백업을 콜드 스토리지로 전환하는 수명 주기 정책을 지정합니다. 각 백업의 보관 기간을 7년으로 설정합니다.

핵심 요약

요구 사항 분석:

주기: 매월(Monthly).
가용성: 6개월 동안 즉시 사용 가능(Warm Storage).
보관: 총 7년 보관(Long-term Retention).
관리: 자동화 및 규정 준수.

해결책 (AWS Backup):
- 중앙 집중식 관리: AWS Backup은 DynamoDB를 포함한 여러 AWS 서비스의 백업 정책을 중앙에서 관리하는 완전 관리형 서비스임.
- 수명 주기(Lifecycle) 정책: 백업 계획(Backup Plan) 내에서 "6개월 후 콜드 스토리지로 전환(Transition to Cold Storage)" 및 "7년 후 만료(Expire)" 규칙을 손쉽게 설정 가능.
- DynamoDB 통합: AWS Backup은 DynamoDB의 콜드 스토리지 계층(Cold Storage Tier)을 지원하여, 장기 보관 비용을 획기적으로 절감하면서도 규정 준수 요건을 만족함.

오답 노트

B (On-Demand Backup + S3): DynamoDB의 기본 온디맨드 백업은 DynamoDB 콘솔 내에서 관리되며, 사용자의 S3 버킷에 객체로 직접 노출되지 않음. 따라서 S3 Lifecycle 정책을 직접 적용할 수 없음. (S3로 '내보내기' 기능을 써야 하는데, 이는 백업 관리와는 다른 개념).
C, D (스크립트/CLI + EventBridge): AWS Backup이라는 완성된 관리형 서비스가 있는데 굳이 스크립트를 짜서 유지 관리하는 것은 운영 오버헤드가 큼. 또한, 단순 CLI 명령어로 수명 주기(콜드 티어링)를 직접 제어하는 것은 복잡함.

AWS Backup Lifecycle (수명 주기)

Warm Storage: 백업 직후 저장되는 공간. 복구 속도가 빠름.
Cold Storage: 장기 보관용 저렴한 공간. (DynamoDB의 경우 AWS Backup을 통해서만 사용 가능).
정책 설정 예시:
- Schedule: Cron(0 0 1 ? ) - 매월 1일.
- Move to cold storage: After 6 months.
- Retention period: 7 years.

Amazon Athena에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. Amazon QuickSight로 결과를 시각화합니다.

핵심 요약

요구 사항 분석:

데이터 소스: Amazon S3에 저장된 로그 파일.
분석 도구: 별도의 데이터 이동 없이 S3 데이터를 바로 분석해야 함.
시각화 도구: 분석 결과를 차트나 그래프로 시각화해야 함.

해결책 (Athena + QuickSight):
- Amazon Athena: S3에 저장된 데이터를 서버리스 환경에서 표준 SQL을 사용하여 즉시 쿼리할 수 있는 서비스입니다. 로그 분석에 업계 표준으로 사용됩니다.
- Amazon QuickSight: AWS의 비즈니스 인텔리전스(BI) 도구로, Athena와 통합하여 쿼리 결과를 바탕으로 대시보드 및 시각화를 생성할 수 있습니다.

오답 노트

A, C (AWS Glue): AWS Glue는 데이터 추출, 변환, 적재(ETL) 및 카탈로그 생성을 위한 서비스이지, 시각화 도구가 아닙니다.
C, D (Amazon DynamoDB): DynamoDB는 NoSQL 데이터베이스입니다. S3에 있는 로그 파일을 대상으로 표준 SQL 분석 쿼리를 직접 실행하는 용도로는 적합하지 않으며, 이를 위해서는 데이터를 DynamoDB로 먼저 마이그레이션해야 하는 비효율이 발생합니다.

Serverless Log Analytics Stack

S3: 로그 저장소 (Data Lake).
Athena: 쿼리 엔진 (SQL).
QuickSight: 시각화 및 대시보드 (BI).
Glue: 데이터 스키마 자동 검색 및 카탈로그 생성 (메타데이터 관리).

DB 인스턴스에 대해 다중 AZ 배포를 활성화합니다.

핵심 요약

요구 사항: RPO(복구 시점 목표) < 1초 (데이터 손실이 거의 없어야 함).
해결책 (Multi-AZ):
- 동기식 복제 (Synchronous Replication): Amazon RDS의 다중 AZ(Multi-AZ) 배포는 데이터를 기본 인스턴스와 대기(Standby) 인스턴스에 동시에 기록합니다. 대기 인스턴스에 쓰기가 완료되어야 트랜잭션이 성공한 것으로 간주합니다.
- RPO 0: 기본 인스턴스에 장애가 발생해도 대기 인스턴스는 최신 데이터를 완벽하게 보유하고 있으므로 데이터 손실이 발생하지 않습니다(RPO = 0).

오답 노트

C (읽기 복제본): 읽기 복제본(Read Replica)은 비동기식 복제(Asynchronous Replication)를 사용합니다. 기본 DB와 복제본 사이에 미세한 지연(Lag)이 발생할 수 있어, 장애 시 마지막 1초 미만의 데이터가 손실될 가능성이 있으므로 엄격한 RPO 요건을 충족하기 어렵습니다.
B (자동 크기 조정): 스토리지나 컴퓨팅 용량을 늘리는 기능일 뿐, 데이터 복제나 내구성(Durability)과는 무관합니다.
D (AWS DMS): 데이터 마이그레이션 도구이며, 기본적으로 비동기 방식이므로 고가용성/RPO 보장용 솔루션이 아닙니다.

RDS 복제 방식 비교

특징	Multi-AZ (다중 AZ)	Read Replica (읽기 복제본)
복제 방식	동기식 (Synchronous)	비동기식 (Asynchronous)
주 목적	고가용성 (HA), 재해 복구, RPO 0	성능 향상 (읽기 분산)
장애 조치	자동 (CNAME 변경)	수동 승격 필요 (기본)
RPO	0 (데이터 손실 없음)	> 0 (복제 지연에 따라 손실 가능)

ALB의 보안 그룹에서 오는 트래픽만 허용하도록 EC2 인스턴스의 보안 그룹을 구성합니다.

요구 사항 분석:

ALB → EC2 트래픽 허용: 로드 밸런서를 통한 정상적인 서비스 요청은 통과시켜야 함.
기타 접근 차단: 내부 네트워크의 다른 소스나 외부에서의 직접 접근은 모두 막아야 함.

해결책 (보안 그룹 참조 / Security Group Referencing):
- 소스(Source) 지정: EC2 인스턴스의 보안 그룹 인바운드 규칙에서, 허용할 소스로 IP 주소 대역(CIDR)이 아닌 ALB의 보안 그룹 ID (sg-xxxxx)를 지정합니다.
- 효과: 이렇게 설정하면 ALB에서 출발한 트래픽만 정확하게 허용되며, 그 외의 모든 트래픽(다른 내부 서버, 직접 접속 시도 등)은 보안 그룹의 기본 차단 정책(Deny All)에 의해 자동으로 차단됩니다. IP 주소가 바뀌어도 보안 그룹 ID는 유지되므로 관리가 용이합니다.

오답 노트

A (경로 테이블): 경로 테이블은 트래픽이 나가는 길(Outbound)을 안내하는 용도입니다. 인터넷에서 사설 IP로 직접 들어오는 경로는 만들 수 없으며, 이는 방화벽(보안) 설정이 아닙니다.
C (퍼블릭 서브넷 이동): 인스턴스를 퍼블릭 서브넷으로 옮기고 공인 IP(Elastic IP)를 부여하면 인터넷에 직접 노출되어 보안 위험이 커집니다. "다른 소스에서 액세스를 차단"하라는 요구 사항에 위배됩니다.
D (ALB 보안 그룹 개방): ALB의 보안 그룹을 모든 포트에 대해 여는 것은 ALB 자체의 보안을 취약하게 만들 뿐, 뒷단의 EC2 인스턴스를 보호하는 설정이 아닙니다.

Security Group Chaining (보안 그룹 체이닝)

개념: 3-Tier 아키텍처(Web-App-DB) 등에서 계층 간 보안을 강화하기 위해 사용하는 표준 패턴.
작동 방식:

Web(ALB) SG: 80/443 포트 (Source: 0.0.0.0/0) 허용.
App(EC2) SG: 앱 포트 (Source: Web SG ID) 허용.
DB(RDS) SG: DB 포트 (Source: App SG ID) 허용.

장점: IP 관리 불필요, 계층 간 접근 제어 확실.

시뮬레이션 애플리케이션을 Linux Amazon EC2 인스턴스로 마이그레이션합니다. 시각화 애플리케이션을 Windows EC2 인스턴스로 마이그레이션합니다. 스토리지를 위해 Amazon FSx for NetApp ONTAP을 구성합니다.

핵심 요약

문제 분석:

OS 불일치: 시뮬레이션(Linux) vs 시각화(Windows).
프로토콜 불일치: Linux는 NFS, Windows는 SMB 필요.
데이터 중복: 두 개의 파일 시스템을 동기화하는 비효율성 제거 필요.
제약 사항: "코드 변경 없음".

해결책 (FSx for NetApp ONTAP):
- 멀티 프로토콜 지원: Amazon FSx for NetApp ONTAP은 동일한 데이터 볼륨에 대해 NFS(Linux용)와 SMB(Windows용) 프로토콜을 통한 동시 액세스를 지원하는 유일한 솔루션입니다.
- 단일 저장소: 데이터를 복제하거나 동기화할 필요 없이, Linux 인스턴스가 NFS로 쓴 파일을 Windows 인스턴스가 SMB로 즉시 읽을 수 있습니다.
- 마이그레이션: 기존 애플리케이션 코드를 수정할 필요 없이 마운트 포인트만 변경하면 됩니다.

오답 노트

A (Lambda + S3): S3는 객체 스토리지로 NFS/SMB 파일 시스템 인터페이스를 제공하지 않습니다. 애플리케이션이 S3 API를 사용하도록 코드를 변경해야 합니다.
B (FSx File Gateway): 주로 온프레미스에서 클라우드 스토리지에 액세스하기 위한 하이브리드 솔루션입니다. 클라우드 네이티브 환경에서 고성능 멀티 프로토콜 공유를 위해서는 NetApp ONTAP이 표준입니다.
C (SQS): SQS는 메시지 큐 서비스입니다. 파일 공유가 필요한 애플리케이션을 메시지 기반으로 바꾸려면 상당한 코드 재작성이 필요합니다.

Amazon FSx for NetApp ONTAP

정의: 널리 사용되는 NetApp의 ONTAP 파일 시스템을 AWS에서 완전 관리형으로 제공하는 서비스.
핵심 기능:
Multi-protocol Access: NFS와 SMB로 동시에 동일한 데이터 접근 가능 (이 문제의 핵심).
스토리지 효율성: 중복 제거(Deduplication), 압축(Compression) 기능 내장.
하이브리드: 온프레미스 NetApp 스토리지와 쉬운 복제(SnapMirror).

Cost Explorer에서 보고서를 만들고 보고서를 다운로드합니다.

핵심 요약

요구 사항 분석:

목표: 사용자별(또는 부서별) 비용 보고서 생성.
용도: 부서 예산 수립.
핵심 제약: 가장 효율적인 방법 (운영 오버헤드 최소화).

해결책 (AWS Cost Explorer):
- 기능: AWS 비용 및 사용량을 시각화, 이해, 관리할 수 있는 도구.
- 효율성: 별도의 인프라 구축이나 쿼리 작성 없이 클릭 몇 번으로 데이터를 필터링하고 그룹화할 수 있음.
- 사용자별 추적: 비용 할당 태그(Cost Allocation Tags)를 활성화한 후, Cost Explorer에서 해당 태그(예: User, Department)를 기준으로 그룹화(Group by)하여 보고서를 생성하고 CSV로 다운로드할 수 있음.

오답 노트

A (Amazon Athena): 비용 및 사용 보고서(CUR)를 S3에 저장하고, Glue로 테이블을 만든 후 SQL 쿼리를 실행해야 함. Cost Explorer보다 설정 및 관리 오버헤드가 훨씬 큼.
C (청구 대시보드): 청구서(Bill)는 서비스별 총계를 보여주는 데 집중되어 있음. 사용자별/태그별로 세분화된 데이터를 분석하여 보고서 형태로 만들기에는 기능이 제한적임.
D (AWS Budgets): 예산 한도를 설정하고 초과 시 알람을 받는 도구임. 과거 데이터를 분석하여 상세 보고서를 생성하는 도구가 아님.

AWS Cost Explorer (비용 탐색기)

주요 기능:
- 지난 12개월의 데이터 조회 및 향후 12개월 예측.
- 필터링/그룹화: 서비스, 리전, 인스턴스 유형, 태그(Tag), 연동 계정별로 비용 분석.
- RI/SP 권장 사항: 예약 인스턴스 및 Savings Plans 구매 추천.

보고서: 기본 제공 보고서 사용 또는 사용자 지정 보고서 생성 후 저장/다운로드 가능.

Amazon Simple Email Service(Amazon SES)를 호출하는 AWS Lambda 백엔드가 있는 Amazon API Gateway 엔드포인트를 생성합니다.

요구 사항 분석:

현재 아키텍처: Amazon S3 정적 웹사이트.
기능 추가: 연락처 양식(이메일 발송 등 동적 기능).
트래픽: 월 100건 미만 (매우 낮음).
목표: 가장 비용 효율적인 솔루션.

해결책 (Serverless Pattern):
- 비용 효율성 (Pay-as-you-go): AWS Lambda와 API Gateway는 요청이 있을 때만 과금되는 서버리스 서비스입니다. 월 100건 정도의 트래픽은 AWS 프리 티어(Free Tier) 범위에 넉넉히 포함되거나, 프리 티어가 끝나도 비용이 거의 0원에 가깝습니다.
- 구성: S3에 있는 정적 HTML 양식(Form)이 자바스크립트를 통해 API Gateway 엔드포인트로 데이터를 POST하면, Lambda 함수가 실행되어 Amazon SES를 통해 관리자에게 이메일을 발송합니다. 서버를 상시 켜둘 필요가 없어 가장 저렴합니다.

오답 노트

A (ECS): 컨테이너 오케스트레이션 서비스를 위해 로드 밸런서나 컴퓨팅 자원을 유지해야 하므로, 월 100건 처리를 위해 사용하기엔 비용과 구성이 과도합니다.
C (Lightsail), D (EC2): 가상 서버(VPS) 방식은 트래픽이 없어도 시간당/월당 고정 비용(최소 몇 달러 이상)이 발생합니다. 또한 OS 패치 등 관리 오버헤드가 있습니다.
리

Serverless Contact Form Architecture

Frontend: S3 (Static HTML/JS).
API Layer: API Gateway (REST API endpoint).
Compute: Lambda (Business logic - validate input, format email).
Service: SES (Send email).
장점: No Idle Cost (유휴 비용 없음), No Server Management (서버 관리 불필요).

CloudFront 캐시를 무효화(Invalidation)합니다.

핵심 요약

문제 원인 (Stale Cache):
- CI/CD 파이프라인이 S3(원본)의 파일을 성공적으로 업데이트했더라도, CloudFront(CDN)는 엣지 로케이션에 이전 버전의 파일을 캐시(Cache)하고 있습니다.
- CloudFront의 캐시 만료 시간(TTL)이 지나기 전까지는 원본 S3에서 새 파일을 가져오지 않고 캐시된 구버전을 사용자에게 보여줍니다.

해결책 (Cache Invalidation):
- CloudFront 배포에서 무효화(Invalidation) 요청을 생성하여 강제로 캐시를 삭제해야 합니다.
- 일반적으로 CI/CD 파이프라인의 마지막 단계에 aws cloudfront create-invalidation 명령을 추가하여 배포 직후 자동으로 캐시를 비우도록 설정합니다.

오답 노트

A (ALB 추가): 정적 웹사이트 호스팅(S3+CloudFront) 구조에서 로드 밸런서는 필요하지 않으며, 캐싱 문제를 해결해주지 않습니다.
B (ElastiCache): 이는 데이터베이스 쿼리 성능을 위한 캐시입니다. 웹사이트의 정적 파일(HTML/JS/CSS) 갱신 문제와는 관련이 없습니다.
D (ACM 인증서): SSL/TLS 인증서 검증은 HTTPS 보안 연결을 위한 것이며, 콘텐츠 갱신 여부와는 무관합니다.

CloudFront Invalidation (무효화)

기능: CloudFront 엣지 캐시에서 파일을 제거하고 다음 요청 시 원본(Origin)에서 최신 버전을 가져오게 함.
비용: 매월 1,000개의 경로까지 무료. 이후 건당 과금.
대안: 버전 관리(Versioning) 파일 이름 사용 (예: style_v1.css -> style_v2.css). 파일명이 바뀌면 무효화 없이 즉시 갱신 효과.

Amazon EC2 인스턴스에서 세 계층을 모두 호스팅합니다. 계층 간 파일 공유를 위해 Amazon FSx for Windows File Server를 사용합니다.

SQL Server on EC2:
- 요구 사항: Data Quality Services(DQS)와 같은 특정 SQL Server 기능 및 네이티브 백업에 대한 완전한 제어가 필요합니다.
- 선택 이유: Amazon RDS는 관리형 서비스로 OS 수준의 접근이 제한되어 DQS와 같은 특정 기능 지원에 제약이 있을 수 있습니다. 따라서 EC2에 직접 SQL Server를 설치하여 운영하는 것이 모든 기능을 사용하는 가장 확실한 방법입니다.

Windows 파일 공유:
- Windows 환경: 애플리케이션이 Windows 기반입니다.
- 공유 스토리지: 여러 인스턴스(계층)가 파일을 공유하려면 SMB 프로토콜을 지원해야 합니다.
- FSx for Windows File Server: 완전 관리형 Windows 파일 시스템으로, Windows EC2 인스턴스 간의 파일 공유에 최적화된 표준 솔루션입니다.

오답 노트

A (FSx File Gateway): 이는 온프레미스 서버에서 클라우드 스토리지에 액세스하기 위한 하이브리드 솔루션입니다. 클라우드 내부의 EC2 인스턴스 간 공유에는 적합하지 않습니다.
C (RDS + EFS):
- EFS: 리눅스(NFS)용 파일 시스템입니다. Windows 인스턴스에서 기본적으로 사용하기 어렵습니다.

D (RDS + EBS):
- EBS: 블록 스토리지입니다. io2 볼륨이 다중 연결(Multi-Attach)을 지원하더라도, 파일 시스템 클러스터링 없이는 일반적인 '파일 공유' 용도로 사용할 수 없습니다. 또한 RDS는 DQS 기능 지원 여부를 확인해야 하는 리스크가 있습니다.

Amazon FSx for Windows File Server

프로토콜: SMB (Server Message Block).
기능: Active Directory 통합, DFS(분산 파일 시스템), Windows ACL 지원.
용도: Windows 기반 애플리케이션의 공유 폴더, 홈 디렉터리, 미디어 처리 워크플로.

Amazon Elastic File System(Amazon EFS) 파일 시스템을 만듭니다. 모든 웹 서버에 EFS 파일 시스템을 마운트합니다.

핵심 요약

요구 사항 분석:

Linux 기반: 리눅스 운영체제 환경.
공유 파일 저장소: 여러 웹 서버가 동시에 동일한 파일에 접근해야 함.
애플리케이션 변경 없음: 기존 코드를 그대로 사용하려면 표준 파일 시스템 인터페이스(POSIX)가 필요함.

해결책 (Amazon EFS):
- NFS 프로토콜: EFS는 리눅스 표준인 NFS(Network File System) 프로토콜을 지원하는 완전 관리형 파일 스토리지입니다.
- 공유 액세스: 수천 개의 EC2 인스턴스에서 동시에 마운트하여 데이터를 읽고 쓸 수 있습니다.
- 무중단 마이그레이션: 기존 리눅스 애플리케이션이 로컬 디스크를 쓰는 것처럼 경로만 마운트하면 되므로 코드 변경이 전혀 필요 없습니다.

오답 노트

A (Amazon S3): S3는 객체 스토리지로, 파일 시스템이 아닙니다. 애플리케이션이 S3 API를 호출하도록 코드를 수정하거나 별도의 유틸리티를 써야 하므로 "변경 없음" 요건에 맞지 않습니다.
B (CloudFront): CDN 서비스로, 정적 콘텐츠 캐싱용입니다. 서버 간 파일 공유 저장소가 아닙니다.
D (Amazon EBS): EBS는 블록 스토리지입니다. 기본적으로 단일 인스턴스에만 마운트할 수 있습니다. (io2 볼륨의 다중 연결 기능이 있지만, 클러스터 파일 시스템 없이는 데이터 손상이 발생하며 gp3는 이를 지원하지 않습니다.)

AWS 스토리지 서비스 비교

서비스	Amazon EFS	Amazon EBS	Amazon S3
유형	파일 스토리지 (NAS)	블록 스토리지 (DAS/SAN)	객체 스토리지
프로토콜	NFS (Linux용)	Block Device	HTTP/HTTPS API
공유 가능 여부	가능 (수천 대 동시 연결)	불가능 (단일 연결 원칙)	가능 (웹 접근)
주요 용도	웹 서버 공유 파일, 홈 디렉터리	DB, OS 부팅 볼륨	백업, 정적 웹, 미디어

Lambda 함수에 IAM 역할을 적용합니다. 역할에 IAM 정책을 적용하여 S3 버킷에 대한 읽기 액세스 권한을 부여합니다.

IAM 역할 (IAM Role):
- 임시 자격 증명: Lambda 함수는 실행 시 IAM 역할을 수임(Assume)하여 AWS 자격 증명을 안전하게 관리합니다. 코드에 키를 저장할 필요가 없습니다.
- 가장 안전한 방식: AWS 컴퓨팅 서비스(EC2, Lambda 등)가 다른 AWS 리소스에 액세스할 때 사용하는 표준 보안 방식입니다.

최소 권한 원칙 (Least Privilege):
- 계정 내의 '모든' 버킷이 아닌, '필요한 특정 버킷'에 대해서만 읽기 권한을 부여해야 합니다. 이는 보안 침해 시 피해 범위를 최소화합니다.

오답 노트

A (S3 버킷 정책): 버킷 정책은 주로 교차 계정 액세스나 공용 액세스 제어에 사용됩니다. 동일 계정 내의 Lambda 권한 관리는 IAM 역할(ID 기반 정책)을 사용하는 것이 관리 및 보안 측면에서 더 적합합니다.
C (하드코딩된 키): 보안상 절대 금지. 코드에 액세스 키와 비밀 키를 직접 입력하면 소스 코드 유출 시 계정 전체가 위험해집니다.
D (모든 버킷 권한): "계정의 모든 S3 버킷"에 권한을 부여하는 것은 최소 권한 원칙에 위배됩니다. 불필요하게 넓은 권한은 보안 위험을 높입니다.

IAM Role (IAM 역할)

정의: 특정 권한을 가진 AWS 자격 증명. 특정 사용자나 그룹과 연결되지 않고, 필요할 때 '맡을(Assume)' 수 있는 모자(Hat)와 같음.
사용 대상:
- AWS 서비스: EC2, Lambda, ECS 등.
- 외부 사용자: SAML 2.0 연동, 웹 자격 증명 연동.
- 다른 계정: 교차 계정 액세스.

온디맨드 인스턴스와 스팟 인스턴스의 혼합

요구 사항 분석:

목표: 비용 절감 최적화.
핵심 제약: "장기적 약속(Long-term commitment) 없이".
환경: Auto Scaling Group을 사용하는 웹 애플리케이션.

해결책 (Mixed Instances Policy):
- 스팟 인스턴스 (Spot Instances): AWS의 남는 유휴 용량을 사용하여 온디맨드 대비 최대 90% 저렴함. 별도의 약정 기간이 없음.
- 혼합 구성: Auto Scaling 그룹에서 온디맨드(기본 부하 담당)와 스팟(확장 부하 담당)을 혼합하여 구성하면, 안정성을 유지하면서도 전체 컴퓨팅 비용을 획기적으로 낮출 수 있음.
결과: "약정 없이" 비용을 최적화하는 유일한 방법.

EC2 구매 옵션 비교 (제약 조건 중심)

옵션	비용 절감 효과	약정(Commitment) 필요 여부	특징
온디맨드 (On-Demand)	없음 (기준 가격)	없음	유연성 높음, 가장 비쌈.
스팟 인스턴스 (Spot)	최상 (최대 90%)	없음	중단 가능성 있음, 무상태(Stateless) 앱에 적합.
예약 인스턴스 (RI)	높음 (최대 72%)	필수 (1년/3년)	장기 사용 시 유리.
Savings Plans	높음 (최대 72%)	필수 (1년/3년)	RI보다 유연한 구조.

Tip: "비용 절감" + "약정 없음" 키워드 조합은 무조건 스팟 인스턴스가 정답.

서명된 쿠키 (Signed Cookies)
서명된 URL (Signed URLs)

핵심 요약

문제 분석:
- 보안: CloudFront/S3 콘텐츠에 대한 액세스 제어 필요.
- 그룹 1 (쿠키 미지원): 사용자 지정 HTTP 클라이언트 사용 → 서명된 쿠키 사용 불가.
- 그룹 2 (URL 변경 불가): 하드코딩된 URL 사용 → 쿼리 문자열이 붙는 서명된 URL 사용 불가.

해결책 (하이브리드 접근):
- 서명된 URL (Signed URLs): 쿠키를 지원하지 않는 클라이언트를 위해 사용합니다. URL 뒤에 서명 쿼리 파라미터가 붙는 방식입니다.
- 서명된 쿠키 (Signed Cookies): URL을 변경할 수 없는 클라이언트를 위해 사용합니다. URL을 그대로 유지(.../video.mp4)하면서 브라우저나 클라이언트의 쿠키 헤더를 통해 인증하므로 현재 URL 구조를 유지할 수 있습니다.

오답 노트

AWS AppSync: GraphQL API 서비스로, 정적 콘텐츠 스트리밍 보호와는 무관합니다.
JSON 웹 토큰(JWT): 인증 토큰 표준이지만, CloudFront의 기본 콘텐츠 제한 기능은 서명된 URL/쿠키입니다. (JWT는 이를 생성하기 위한 인증 과정에서 사용될 수는 있음).
Secrets Manager: 데이터베이스 암호 등 기밀 정보를 관리하는 서비스입니다.

CloudFront 액세스 제어 비교

기능	서명된 URL (Signed URLs)	서명된 쿠키 (Signed Cookies)
작동 방식	URL 뒤에 `?Signature=...` 쿼리 추가	HTTP `Set-Cookie` 헤더 사용
사용 사례	1. 클라이언트가 쿠키 미지원 2. 개별 파일(단일 파일) 접근 제한	1. 현재 URL 유지 필요 (HLS/DASH 스트리밍 등) 2. 다수 파일(폴더)에 대한 일괄 권한 부여
제약 사항	URL이 변경됨 (하드코딩 시 사용 불가)	클라이언트가 쿠키 저장소 지원 필수

A. Amazon Kinesis Data Streams를 사용하여 데이터를 스트리밍합니다. Amazon Kinesis Data Analytics를 사용하여 데이터를 변환합니다. Amazon Kinesis Data Firehose를 사용하여 데이터를 Amazon S3에 씁니다. Amazon Athena를 사용하여 Amazon S3에서 변환된 데이터를 쿼리합니다.

B. Amazon Managed Streaming for Apache Kafka(Amazon MSK)를 사용하여 데이터를 스트리밍합니다. AWS Glue를 사용하여 데이터를 변환하고 Amazon S3에 씁니다. Amazon Athena를 사용하여 Amazon S3에서 변환된 데이터를 쿼리합니다.

핵심 요약

데이터 파이프라인 흐름: 수집(Ingest) → 변환(Transform) → 저장(Store) → 분석(Analyze).
옵션 A (Kinesis Native):
- 수집: Kinesis Data Streams (실시간 데이터 스트림 저장).
- 변환: Kinesis Data Analytics (스트림 데이터에 SQL/Flink를 사용하여 실시간 변환).
- 적재: Kinesis Data Firehose (변환된 데이터를 S3로 전송하는 가장 쉬운 방법).
- 분석: Amazon Athena (S3에 저장된 데이터에 대해 서버리스로 표준 SQL 쿼리 실행).

옵션 B (Open Source/Managed):
- 수집: Amazon MSK (Kafka 기반 스트리밍).
- 변환/적재: AWS Glue (Spark Streaming을 사용하여 실시간으로 데이터를 변환하고 S3에 적재).
- 분석: Amazon Athena (S3 데이터 쿼리).

오답 노트

D, E (RDS 쿼리 편집기): Amazon RDS 쿼리 편집기는 RDS 데이터베이스를 쿼리하는 도구입니다. S3에 저장된 파일(Data Lake)을 직접 SQL로 쿼리하는 표준 도구는 Athena입니다.
C (AWS DMS): DMS는 주로 데이터베이스 간 마이그레이션이나 복제(CDC)에 사용됩니다. "여러 소스의 실시간 스트리밍 데이터 수집"에는 Kinesis나 MSK가 더 적합한 전용 서비스입니다.

1. 데이터 분석 도구 매핑

데이터 위치	쿼리 도구 (SQL)
Amazon S3 (Data Lake)	Amazon Athena (정답)
Amazon Redshift (Data Warehouse)	Redshift Query Editor
Amazon RDS (RDBMS)	RDS Query Editor, SQL Client

2. 스트리밍 데이터 변환 서비스

Amazon Kinesis Data Analytics (KDA): SQL 또는 Apache Flink를 사용하여 스트림 데이터를 실시간 분석/변환.
AWS Glue Streaming ETL: Serverless Spark를 사용하여 스트림 데이터를 배치/변환 처리.

AWS Storage Gateway를 사용하고 저장된 볼륨 게이트웨이를 구성합니다. 온프레미스에서 Storage Gateway 소프트웨어 어플라이언스를 실행 하고 게이트웨이 스토리지 볼륨을 온프레미스 스토리지에 매핑합니다. 게이트웨이 스토리지 볼륨을 마운트하여 데이터에 대한 로컬 액세스를 제공 합니다.

핵심 요약

요구 사항 분석:

백업: AWS를 백업 대상(Target)으로 사용.
데이터 접근: "모든 데이터"에 대해 로컬 액세스 유지 (Low Latency).
자동화/보안: 안전한 자동 전송.

해결책 (Stored Volume Gateway):
- 작동 방식: 기본 데이터(Primary Data) 전체를 온프레미스 스토리지에 로컬로 저장합니다.
- 백업: 데이터의 비동기 스냅샷(EBS Snapshots)을 생성하여 AWS(S3)로 백업합니다.
- 결과: 사용자는 모든 데이터에 대해 지연 시간 없이 로컬에서 접근할 수 있으며, 재해 복구용으로 AWS에 백업본을 유지하게 됩니다.

오답 노트

C (캐시된 볼륨 - Cached Volume):
- 기본 데이터를 S3(클라우드)에 저장하고, 자주 사용하는 데이터(Hot Data)만 온프레미스에 캐싱합니다.
- "모든 데이터"를 로컬에 유지해야 한다는 요구 사항을 충족하지 못합니다. (데이터 세트가 로컬 디스크보다 클 때 사용).

A, B (Snowball):
대용량 데이터 마이그레이션(이동)을 위한 물리적 디바이스입니다. 지속적인 실시간/일일 백업 솔루션이 아니며, 영구적인 로컬 스토리지로 사용하기에는 부적합합니다.

AWS Storage Gateway: Volume Gateway 유형 비교

유형	보관된 볼륨 (Stored Volumes)	캐시된 볼륨 (Cached Volumes)
기본 데이터 위치	온프레미스 (로컬)	AWS S3 (클라우드)
로컬 스토리지	전체 데이터 (Full Dataset)	자주 액세스하는 데이터 (Cache)
주요 목적	로컬 성능 유지 + 클라우드 백업	스토리지 확장 (무제한 S3 활용)
적합한 사례	대기 시간 민감(Low Latency) 앱, 전체 데이터 로컬 필요	데이터 아카이빙, 로컬 스토리지 절약

Tip: 문제에서 "모든 데이터 로컬 액세스" = Stored, "스토리지 확장/S3를 기본으로 사용" = Cached.

VPC에서 Amazon S3에 대한 게이트웨이 VPC 엔드포인트(Gateway VPC Endpoint)를 설정합니다.

핵심 요약

요구 사항: EC2 → S3 접근 시 "인터넷을 통과하지 않음" (프라이빗 연결).
해결책 (Gateway Endpoint):
- 작동 원리: VPC 라우팅 테이블(Route Table)에 S3용 경로(Target)를 추가하여 트래픽을 인터넷 게이트웨이 없이 AWS 내부 네트워크로 직접 라우팅함.
- 대상 서비스: S3와 DynamoDB 두 서비스만 게이트웨이 유형을 사용 (나머지는 인터페이스 유형 사용).
- 장점: 별도의 게이트웨이 장비가 필요 없으며 비용이 무료임.

VPC Endpoint 유형 비교

유형	게이트웨이 엔드포인트 (Gateway)	인터페이스 엔드포인트 (Interface / PrivateLink)
지원 서비스	S3, DynamoDB (단 2개)	EC2, SNS, Kinesis 등 대부분의 서비스
구현 방식	라우팅 테이블(Route Table) 수정	서브넷에 ENI(네트워크 인터페이스) 생성 및 사설 IP 할당
비용	무료	시간당 요금 + 데이터 처리 요금
인터넷 통과	아니요 (AWS 백본망 사용)	아니요 (AWS 백본망 사용)

Tip: 문제에서 "S3" 또는 "DynamoDB" 접속 시 "프라이빗 네트워크 사용"을 묻는다면 게이트웨이 엔드포인트가 정답.

Amazon S3 버킷에 데이터를 저장합니다. 요청하는 애플리케이션에 데이터를 반환하기 전에 S3 Object Lambda를 사용하여 데이터를 처리하고 변환합니다.

요구 사항 분석:

데이터: TB 규모, PII 포함.
소비자: 3개 앱 중 1개는 원본(PII) 필요, 2개는 익명화(PII 제거) 필요.
목표: 운영 오버헤드 최소화 (데이터 중복 저장 방지).

해결책 (S3 Object Lambda):
- 단일 저장소: 데이터를 S3에 원본 그대로 한 번만 저장합니다. (스토리지 비용 및 동기화 문제 해결).
- 실시간 변환: S3 Object Lambda는 S3 GET 요청을 가로채서 AWS Lambda 함수를 실행합니다.
- 작동 방식: PII가 필요한 앱은 표준 S3 접근을 사용하고, PII 제거가 필요한 앱은 S3 Object Lambda 액세스 포인트를 통해 요청하여 실시간으로 마스킹된 데이터를 받습니다. 별도의 프록시 서버를 구축하거나 데이터를 복제할 필요가 없어 운영 효율성이 가장 높습니다.

오답 노트

A (프록시 앱): 별도의 애플리케이션 계층을 개발하고 유지 관리하는 것은 운영 오버헤드가 매우 큽니다.
C, D (데이터 복제): TB 규모의 데이터를 3개의 버킷이나 테이블로 복제하면 스토리지 비용이 3배로 증가하며, 데이터 변경 시 동기화(Consistency)를 맞추는 복잡한 ETL 프로세스가 필요합니다.

Amazon S3 Object Lambda

정의: S3에서 가져온 데이터를 애플리케이션으로 반환하기 전에 자체 코드를 사용하여 처리하는 기능.
사용 사례:
- PII 데이터 수정 (Redacting): 주민번호, 전화번호 마스킹.
- 데이터 형식 변환: XML -> JSON 변환.
- 이미지 크기 조정: 요청 시 썸네일 생성.

VPC 피어링 제약 조건: 피어링하는 두 VPC의 CIDR 블록은 절대 중복되어서는 안 됨.
- 기존 VPC(192.168.0.0/24)와 옵션 B(192.168.0.0/24)는 완벽히 겹치므로 불가능.

AWS VPC 크기 제약: VPC 생성 시 허용되는 CIDR 블록의 크기는 /16 (가장 큼) ~ /28 (가장 작음) 사이여야 함.
- 옵션 A, C (/32): 단일 IP 주소를 의미하며, VPC CIDR로 생성 불가능한 크기임 (최소 /28 필요).

결론: 유일하게 유효한 크기이면서 중복되지 않는 CIDR은 D뿐임.

오답 노트

가, 다 (/32): AWS에서 VPC 생성 시 허용하는 최소 서브넷 마스크는 /28입니다. /32는 호스트 하나를 의미하므로 네트워크 대역으로 사용할 수 없습니다.
나 (중복): 피어링 대상과 IP 대역이 겹치면 라우팅이 불가능하여 연결할 수 없습니다.

AWS VPC CIDR 규칙

범위: RFC 1918 사설 IP 대역 권장 (10.x.x.x, 172.16.x.x, 192.168.x.x).
크기 제한:

최대: /16 (65,536개 IP)
최소: /28 (16개 IP)

피어링: 연결된 VPC 간 CIDR 중복 불가.

EC2 자동 확장 그룹을 만듭니다. 기존 ALB를 로드 밸런서로 선택하고 기존 대상 그룹을 대상 그룹으로 선택합니다. ASGAverageCPUUtilization 메트릭을 기반으로 하는 대상 추적 확장 정책을 설정합니다. 최소 인스턴스를 2로, 원하는 용량을 3으로, 최대 인스턴스를 6으로, 대상 값을 50%로 설정합니다. EC2 인스턴스를 자동 확장 그룹에 추가합니다.

핵심 요약

요구 사항 분석:

현재 비효율: 5개 인스턴스 실행 중이나 평균 CPU는 10% 미만 (과다 프로비저닝/비용 낭비).
스파이크 대응: 가끔 65%까지 치솟음 (확장성 필요).
목표: 자동화된 확장 및 비용 최적화.

해결책 (ASG + 대상 추적 정책):
- Auto Scaling Group (ASG): 고정된 5개 대신, 부하에 따라 인스턴스 수를 조절하는 그룹을 생성합니다.
- 대상 추적 확장(Target Tracking Scaling): "CPU 사용률을 50%로 유지하라"는 정책을 설정합니다.
  - CPU가 10%일 때: 인스턴스를 줄여(Scale-in) 비용 절감 (최소 2개까지).
  - CPU가 50%를 넘을 때: 인스턴스를 늘려(Scale-out) 65% 스파이크에 대응 (최대 6개까지).

ALB 통합: 기존 로드 밸런서 뒤에 ASG를 연결하여 트래픽을 자동으로 분산합니다.

오답 노트

A (Lambda): 사용자 지정 스크립트로 인스턴스를 종료하는 것은 복잡하며, 스파이크 시 인스턴스를 늘리는(Scale-out) 로직이 빠져있습니다.
C (정책 없음): ASG를 만들었지만 확장 정책(Policy)이 없습니다. 트래픽이 변해도 인스턴스 수가 자동으로 변하지 않습니다.
D (수동 개입): 알람을 받고 사람이 "로그인하여 수동으로 조절"하는 방식입니다. 자동화 요구 사항 위배.

Target Tracking Scaling (대상 추적 크기 조정)

개념: 온도 조절기(Thermostat)와 유사. "실내 온도를 24도로 유지해"라고 설정하면 에어컨이 알아서 세기를 조절하듯, "CPU를 50%로 유지해"라고 설정하면 ASG가 인스턴스 수를 알아서 조절함.
장점: 설정이 가장 간편하고 부하 변화에 가장 최적화된 방식.

각 가용성 영역에 서브넷을 프로비저닝합니다. EC2 인스턴스를 두 가용성 영역에 분산하도록 자동 확장 그룹을 구성합니다. 다중 AZ 배포를 위해 DB 인스턴스를 구성합니다.

핵심 요약

서브넷 규칙 (Networking): AWS에서 서브넷은 단일 가용 영역(AZ) 내에만 존재할 수 있습니다. 하나의 서브넷이 여러 AZ에 걸쳐 있을 수 없으므로, 각 AZ마다 별도의 서브넷을 만들어야 합니다.
고가용성 구성 (HA):
- App 계층: Auto Scaling Group(ASG) 설정에 두 개의 서브넷(각 AZ별)을 포함시켜 인스턴스를 분산 배치합니다.
- DB 계층: Amazon RDS의 다중 AZ(Multi-AZ) 기능을 활성화합니다. 이는 자동으로 보조 AZ에 대기(Standby) 인스턴스를 생성하고 데이터를 동기화하여 장애 시 자동 조치(Failover)를 수행합니다.

오답 노트

B, D (서브넷 범위 오류): "두 가용성 영역에 걸쳐 확장되는 서브넷"이라는 설명은 기술적으로 불가능합니다. 서브넷은 리전(Region) 단위가 아니라 가용 영역(AZ) 단위 리소스입니다.
A (DB 구성 미흡): DB 인스턴스를 각 네트워크에 연결한다고 해서 자동 장애 조치가 보장되지 않습니다. RDS의 "다중 AZ(Multi-AZ)" 기능을 명시적으로 사용해야 합니다.

AWS VPC 구조의 기본

Region (리전): 지리적 영역.
VPC: 리전 내의 논리적 네트워크 (여러 AZ 포괄 가능).
Availability Zone (AZ): 물리적으로 분리된 데이터 센터 군.
Subnet (서브넷): 단일 AZ에 귀속되는 IP 주소 범위. (1 Subnet = 1 AZ).

원시 데이터를 저장할 Amazon S3 버킷을 만듭니다. 영구 SSD 스토리지를 사용하는 Amazon FSx for Lustre 파일 시스템을 만듭니다. Amazon S3에서 데이터를 가져오고 내보내는 옵션을 선택합니다. EC2 인스턴스에 파일 시스템을 마운트합니다.

요구 사항 분석:

워크로드: 연구실 데이터 처리, 수백 개의 EC2 인스턴스 (HPC: 고성능 컴퓨팅).
성능: 밀리초 미만(Sub-millisecond) 지연 시간, 6GBps 이상의 높은 처리량.

해결책 (FSx for Lustre + SSD):
- Amazon FSx for Lustre: 수백/수천 개의 EC2 인스턴스에서 동시에 데이터에 액세스해야 하는 HPC 워크로드에 최적화된 병렬 파일 시스템입니다. 6GBps 이상의 처리량을 손쉽게 제공합니다.
- 영구 SSD (Persistent SSD): "밀리초 미만"의 지연 시간을 달성하려면 HDD가 아닌 SSD 스토리지가 필수입니다.
- S3 통합: S3를 데이터 레이크로 사용하면서, 처리 시에만 FSx for Lustre로 고속 로딩(Lazy Loading)하여 처리하고 결과를 다시 S3로 내보내는 방식이 표준 패턴입니다.

오답 노트

A, D (FSx for NetApp ONTAP): 범용 엔터프라이즈 워크로드(NAS)에 적합하지만, 수백 개의 인스턴스가 붙는 초고속 처리량의 HPC 연구 환경에는 Lustre가 더 적합합니다. 특히 A의 Tiering Policy: ALL은 데이터를 느린 용량 풀(S3)로 즉시 이동시키므로 지연 시간 요건을 충족할 수 없습니다.
C (Lustre + HDD): Lustre는 맞지만, HDD는 물리적 디스크 특성상 밀리초 미만의 초저지연 응답 속도를 보장하기 어렵습니다. 처리량(Throughput) 중심의 워크로드에는 쓸 수 있으나 지연 시간(Latency) 요건에서 탈락입니다.

Amazon FSx for Lustre

용도: HPC(고성능 컴퓨팅), 머신 러닝, 미디어 렌더링, 시뮬레이션.
특징:
- 병렬 처리: 데이터를 여러 서버에 스트라이핑하여 처리량을 선형적으로 확장.
- 스토리지 유형:
  - SSD: 지연 시간에 민감한 작업 (정답).
  - HDD: 처리량 중심의 대규모 데이터 작업.

S3 연동: S3 버킷을 파일 시스템처럼 투명하게 연결 (Repository).

애플리케이션 계층을 Amazon EC2 예약 인스턴스로 마이그레이션합니다. 데이터 스토리지 계층을 Amazon Aurora 예약 인스턴스로 마이그레이션합니다.

요구 사항 분석:

워크로드: 주 7일, 24시간 실행 (상시 가동).
데이터: 시간이 지남에 따라 증가하는 데이터베이스.
목표: 가장 비용 효율적인 방법.

해결책 (All Reserved Instances):
- EC2 예약 인스턴스 (RI): 24/7 가동되는 정형화된 워크로드는 온디맨드(On-Demand) 대비 최대 72% 저렴한 예약 인스턴스를 사용하는 것이 가장 경제적입니다.
- Amazon Aurora 예약 인스턴스: 데이터베이스 역시 24/7 가동되므로 RI를 적용해야 비용을 줄일 수 있습니다. 또한, Aurora는 스토리지 자동 확장 기능을 제공하여 데이터 증가에 유연하게 대처할 수 있습니다.

오답 노트

A (Spot + S3):
- Spot: 스팟 인스턴스는 예고 없이 중단될 수 있어, 중단에 대비되지 않은 레거시 애플리케이션 운영에는 부적합합니다.
- S3: 데이터베이스 스토리지로 S3를 직접 사용하는 것은 애플리케이션 코드의 대대적인 수정(Rewrite)이 필요하므로 마이그레이션에 적합하지 않습니다.

B, D (On-Demand 포함):
- B: DB에 온디맨드를 사용하여 비용이 비쌉니다.
- D: 앱 계층에 온디맨드를 사용하여 C보다 비용이 훨씬 비쌉니다. 24시간 돌아가는 서버에 온디맨드를 쓰는 것은 비용 최적화 실패입니다.

EC2 비용 모델 선택 가이드

구매 옵션	On-Demand (온디맨드)	Reserved Instances (RI)	Spot Instances (스팟)
특징	약정 없음, 초 단위 과금	1년/3년 약정, 대폭 할인	남는 용량 사용, 중단 가능
비용	가장 비쌈 (표준)	저렴 (최대 72% 할인)	가장 저렴 (최대 90% 할인)
적합한 사례	단기, 불규칙한 워크로드	24/7 상시 가동, DB 서버	배치 작업, 무상태(Stateless) 앱

Tip: 문제에서 "24/7 실행", "꾸준한 사용", "예측 가능" 키워드가 나오면 예약 인스턴스(RI) 또는 Savings Plans가 정답입니다.

요구 사항 분석:

소스/타겟: Windows 파일 서버(SMB) → FSx for Windows File Server.
데이터: 30TB.
제약 사항: 대역폭 제어 필수 (다른 부서 영향 최소화), 5일 이내 완료.

해결책 (AWS DataSync):
- 대역폭 제한 (Bandwidth Throttling): DataSync는 데이터 전송 시 사용할 최대 대역폭을 설정할 수 있는 기능을 내장하고 있습니다. 이를 통해 공용 1Gbps 링크의 혼잡을 방지할 수 있습니다.
- 프로토콜 최적화: 독점적인 데이터 전송 프로토콜을 사용하여 SMB/NFS보다 빠른 속도로 데이터를 전송합니다.
- 시간 계산: 1Gbps 속도로 30TB 전송 시 이론적으로 약 3일(약 70~80시간) 소요됩니다. 대역폭을 적절히 조절하더라도 5일 이내 마이그레이션이 가능합니다.

오답 노트

AWS Snowcone: Snowcone의 용량은 디바이스당 약 8TB(HDD) 또는 14TB(SSD)로 작아 30TB를 옮기기엔 부족하며, 배송 기간을 고려할 때 5일 이내 완료가 불확실합니다.
FSx File Gateway: 하이브리드 액세스(캐싱)를 위한 솔루션이지, 일회성 대규모 마이그레이션 및 정밀한 대역폭 제어용 도구는 아닙니다.
AWS Transfer Family: SFTP, FTP 프로토콜을 사용하여 파트너와 파일을 교환하기 위한 서비스입니다. 서버 간 대규모 데이터 마이그레이션 도구가 아닙니다.

AWS DataSync

주요 기능: 온프레미스와 AWS 스토리지(S3, EFS, FSx) 간의 데이터 자동 이동.
특징:
에이전트(Agent) 기반 방식.
대역폭 조절(Throttling) 가능.
데이터 무결성 검증, 메타데이터 보존.
SMB, NFS, Object Storage 프로토콜 지원.

A. 콘텐츠 전송 및 캐싱을 위해 Amazon CloudFront를 배포합니다.
C. Amazon Elastic Transcoder를 사용하여 비디오 파일을 보다 적절한 형식으로 변환합니다.

핵심 요약

문제점: 원시(Raw) 비디오 파일의 용량이 너무 큼 → 버퍼링 발생, 직접 S3 다운로드는 속도가 느림.
해결책 1 (파일 최적화): Amazon Elastic Transcoder(또는 AWS Elemental MediaConvert)를 사용하여 원시 파일을 모바일 스트리밍에 최적화된 포맷(MP4, HLS 등)과 용량으로 변환합니다. 이는 관리형 서비스이므로 EC2를 직접 운영하는 것보다 오버헤드가 적습니다.
해결책 2 (전송 최적화): Amazon CloudFront(CDN)를 사용하여 전 세계 엣지 로케이션에 비디오를 캐싱합니다. 이를 통해 사용자에게 가장 가까운 곳에서 콘텐츠를 전송하여 대기 시간(Latency)과 버퍼링을 획기적으로 줄입니다.

Video on Demand (VOD) 표준 아키텍처

Source: S3 (원본 영상 저장).
Processing: Elastic Transcoder / MediaConvert (코덱 변환, 해상도 조절, HLS/DASH 패키징).
Delivery: CloudFront (전 세계 고속 전송 및 캐싱).
User: Mobile App / Web Player.

ECS 메트릭 위반으로 인해 Amazon CloudWatch 알람이 트리거되면 대상 추적 정책과 함께 AWS Application Auto Scaling을 사용하여 확장합니다.

핵심 요약

ECS Fargate 확장: Fargate는 서버리스이므로 EC2 인스턴스를 관리하지 않습니다. 따라서 EC2 Auto Scaling이 아닌 AWS Application Auto Scaling 서비스를 사용하여 ECS 서비스(Service) 수준에서 태스크(Task) 수를 조정해야 합니다.
Target Tracking Policy (대상 추적 정책):
- 작동 방식: "평균 CPU 사용률을 50%로 유지하라"는 식으로 목표값을 설정합니다.
- 효과: 트래픽이 몰리면 목표값을 맞추기 위해 태스크를 늘리고(Scale-out), 트래픽이 줄어들면 태스크를 줄여(Scale-in) 비용을 절감합니다. 이 과정이 완전히 자동화되어 관리 오버헤드가 가장 적습니다.

오답 노트

A, C (Amazon EC2 Auto Scaling): 이는 EC2 인스턴스(클러스터 노드)를 확장하는 도구입니다. Fargate는 인스턴스를 관리하지 않으므로 이 도구를 직접 사용할 수 없습니다.
B (Lambda): 네이티브 Auto Scaling 기능이 있는데 굳이 Lambda 함수를 작성하여 관리하는 것은 비효율적인 'Undifferentiated heavy lifting'(차별화되지 않는 무거운 작업)입니다.

AWS Application Auto Scaling

지원 서비스: Amazon ECS, DynamoDB, Aurora Replicas, SageMaker Endpoint 등 (EC2가 아닌 리소스들의 확장을 담당).
정책 유형:
- Target Tracking: 특정 지표 유지 (권장).
- Step Scaling: 단계별 조정.
- Scheduled Scaling: 시간 기반 조정.

요구 사항 분석:

대상: 리전 간 NFS 파일 시스템 동기화.
주기: 정기적인 데이터 전송 (Periodic).
목표: 운영 오버헤드 최소화.

해결책 (AWS DataSync):
- 완전 관리형 서비스: 인프라를 관리할 필요 없이 네트워크 대역폭 최적화, 데이터 검증, 암호화 등을 자동으로 처리합니다.
- 리전 간 전송: AWS 리전 간의 EFS, FSx, S3 등 스토리지 간 데이터 이동을 기본적으로 지원합니다.
- 스케줄링: "주기적으로" 작업을 실행하도록 예약을 걸어둘 수 있어 재해 복구(DR) 데이터 동기화에 최적입니다.

AWS DataSync 주요 사용 사례

마이그레이션: 온프레미스 스토리지 → AWS로 대량 데이터 이동.
아카이빙: 콜드 데이터를 S3 Glacier 등으로 이동.
데이터 보호(DR): 리전 간 스토리지 복제 및 동기화 (본 문제의 사례).

AWS 파일 스토리지 서비스 선택 가이드

서비스	FSx for Windows File Server	Amazon EFS	Amazon S3
프로토콜	SMB	NFS	REST API (HTTP)
OS 호환성	Windows (Linux도 SMB 지원 시 가능)	Linux	모든 OS (웹 기반)
주요 용도	홈 디렉터리, Windows 앱, AD 통합	리눅스 웹 서버 공유, 컨테이너 스토리지	정적 웹, 백업, 데이터 레이크

Tip: 문제에서 "SMB" 또는 "Windows 애플리케이션"이 나오면 FSx for Windows File Server가 정답일 확률이 매우 높습니다.

동일한 AWS 지역 내의 동일한 가용성 영역에서 모든 EC2 인스턴스를 시작합니다. EC2 인스턴스를 시작할 때 클러스터 전략이 있는 배치 그룹을 지정합니다.

요구 사항 분석:

지연 민감 (Latency Sensitive): 인스턴스 간 물리적 거리가 최소화되어야 함.
높은 처리량 (High Throughput): 100k+ TPS 처리를 위한 넓은 대역폭 필요.
비용 절감: 데이터 전송 요금 최소화.

해결책 (Cluster Placement Group + Single AZ):
- 클러스터 배치 그룹 (Cluster Placement Group): 단일 가용 영역(AZ) 내에서 인스턴스들을 물리적으로 서로 가깝게 묶어(Pack) 배치하는 전략입니다. 이는 랙 간의 네트워크 홉을 최소화하여 가장 낮은 지연 시간과 가장 높은 네트워크 처리량을 제공합니다. HPC(고성능 컴퓨팅)나 인메모리 DB에 이상적입니다.
- 단일 AZ 비용: 동일한 가용 영역 내에서 프라이빗 IP를 통신할 경우 데이터 전송 비용이 무료입니다. (AZ 간 전송은 비용 발생).

EC2 배치 그룹 (Placement Groups) 전략

전략	클러스터 (Cluster)	파티션 (Partition)	분산 (Spread)
목적	최고 성능 (HPC)	분산 처리 (Big Data)	고가용성 (HA)
배치 방식	단일 AZ 내에서 밀집 배치	파티션별로 랙을 분리	각각 다른 랙에 배치 (엄격한 분리)
장점	초저지연, 고대역폭	하드웨어 장애 격리	동시 장애 확률 최소화
사용 사례	인메모리 DB, 게놈 분석	HDFS, Kafka, Cassandra	중요 인스턴스 소수 운영

AWS Storage Gateway Volume Gateway 캐시 볼륨 (Cached Volumes)

핵심 요약

요구 사항 분석:

프로토콜: iSCSI (블록 스토리지) 사용.
용량 관리: 온프레미스 스토리지 확장을 최소화해야 함 (클라우드 스토리지 활용).
데이터 접근: "최근에 액세스한 데이터"만 로컬에 저장 (캐싱).

해결책 (Cached Volumes):
- 아키텍처: 모든 기본 데이터는 Amazon S3에 저장하고, 자주 사용하는(Hot) 데이터의 일부만 온프레미스 스토리지 게이트웨이의 로컬 캐시에 보관합니다.
- 이점: 온프레미스 스토리지 용량을 크게 늘리지 않고도 S3의 무제한 확장성을 iSCSI 블록 스토리지처럼 사용할 수 있습니다.

오답 노트

S3 File Gateway: NFS나 SMB 프로토콜을 사용하여 파일 단위로 접근하는 방식입니다. 문제의 iSCSI 요구 사항과 맞지 않습니다.
Tape Gateway: 가상 테이프 라이브러리(VTL) 방식으로 백업 아카이브 용도입니다. 일반 애플리케이션 서버의 블록 스토리지 확장용이 아닙니다.
Stored Volumes - 보관된 볼륨: 모든 데이터를 로컬에 저장하고, 백업본(스냅샷)만 AWS로 보냅니다. 로컬 스토리지 확장을 최소화하려는 문제의 의도와 정반대입니다.

Volume Gateway 유형 비교

유형	캐시 볼륨 (Cached Volumes)	보관된 볼륨 (Stored Volumes)
기본 데이터 위치	AWS S3 (클라우드)	온프레미스 (로컬)
로컬 스토리지	자주 쓰는 데이터 (캐시)만 저장	전체 데이터 저장
온프레미스 용량	작아도 됨 (비용 절감)	전체 데이터를 담을 만큼 커야 함
주요 목적	스토리지 확장, 클라우드 마이그레이션	로컬 성능 보장, 재해 복구(DR)

B. 통합 청구 계정의 신뢰할 수 있는 자문가 권장 사항을 사용하여 모든 RDS 인스턴스 확인을 동시에 확인하세요.
C. Amazon RDS 예약 인스턴스 최적화에 대한 신뢰할 수 있는 자문을 검토합니다.

핵심 요약

배경: 통합 결제(Consolidated Billing) 환경, 90일간 지속된 활성(Active) 워크로드, 현재 온디맨드(On-Demand) 사용 중.
해결책 (비용 최적화):
- 위치 (Option B): 통합 결제 관리 계정(Payer Account)의 Trusted Advisor는 조직 내 모든 연결 계정(Linked Accounts)의 사용량을 집계하여 분석합니다. 재무 팀은 각 계정에 일일이 로그인할 필요 없이 관리 계정에서 전체적인 최적화 권장 사항을 한 번에 확인할 수 있습니다.
- 방법 (Option C): 인스턴스가 "활성(Active)" 상태이고 90일 동안 지속적으로 실행되었다면 "유휴(Idle)" 상태가 아닙니다. 따라서 비용을 줄이는 가장 확실한 방법은 온디맨드 요금보다 훨씬 저렴한 예약 인스턴스(RI)를 구매하는 것입니다. Trusted Advisor의 'RDS 예약 인스턴스 최적화' 항목이 바로 이 구매 제안을 제공합니다.

오답 노트

A: 개별 계정에서도 확인 가능하지만, 재무 팀 입장에서 여러 계정의 데이터를 통합적으로 보고 구매 계획을 세우기에는 통합 결제 계정을 사용하는 것이 훨씬 효율적입니다.
D (유휴 DB 인스턴스): 문제에서 인스턴스가 "활성(Active)" 상태라고 명시했습니다. 사용 중인 인스턴스를 종료하는 것이 아니라, 요금제를 변경해야 하므로 유휴 인스턴스 확인은 적절하지 않습니다.
E (Redshift): 문제의 대상은 RDS for Oracle입니다. Redshift 권장 사항은 관련이 없습니다.

AWS Trusted Advisor (비용 최적화 부문)

RDS Idle DB Instances: 지난 7일 동안 연결이 없거나 CPU 사용률이 매우 낮은 DB를 찾아내어 삭제(종료)를 권장.
RDS Reserved Instance Optimization: 지난 사용 기록(보통 30일~60일 이상)을 분석하여, 온디맨드 대신 예약 인스턴스(RI)를 구매했을 때 예상되는 비용 절감액을 계산하여 제안.

S3 Storage Lens 대시보드를 사용하여 버킷 액세스 패턴을 분석하여 고급 활동 지표를 확인합니다.

핵심 요약

요구 사항 분석:

목표: 더 이상 사용되지 않거나(Cold), 액세스가 거의 없는 버킷 식별.
목적: 스토리지 비용 최적화.
제약: 운영 오버헤드 최소화.

해결책 (S3 Storage Lens):
- S3 Storage Lens: 조직 전체의 객체 스토리지 사용량 및 활동 추세를 시각화해 주는 분석 도구입니다.
- 고급 활동 지표 (Advanced Metrics): 기본 무료 지표(스토리지 크기 등) 외에 "고급 지표"를 활성화하면 GET 요청 수, 다운로드 바이트, 4xx/5xx 오류 등의 활동(Activity) 데이터를 수집합니다.
- 효과: 별도의 쿼리 작성이나 로그 분석 파이프라인 구축 없이, 대시보드에서 즉시 "활성 버킷 vs 비활성 버킷"을 시각적으로 식별할 수 있어 오버헤드가 가장 적습니다.

오답 노트

B (S3 관리 콘솔): 기본 콘솔 대시보드는 버킷의 목록과 용량만 보여줄 뿐, 기간별 액세스 빈도나 통계 데이터를 분석하는 기능을 제공하지 않습니다.
C (CloudWatch BucketSizeBytes): 이 지표는 버킷의 크기(용량)만 알려줍니다. 데이터가 언제 마지막으로 읽혔는지(액세스 패턴)는 알 수 없습니다.
D (CloudTrail + CloudWatch Logs): S3 객체 수준 로깅(Data Events)을 활성화하면 엄청난 양의 로그가 생성되어 비용이 급증합니다. 또한, 로그를 분석하여 "액세스되지 않는 버킷"을 찾아내려면 복잡한 쿼리를 작성해야 하므로 운영 오버헤드가 매우 큽니다.

Amazon S3 Storage Lens

기능: 대시보드를 통해 스토리지 사용량 및 활동 지표 제공.
범위: AWS Organizations 전체, 특정 계정, 리전, 버킷 등 다양한 계층별 집계.
Bubble Chart: 버킷 크기(X축) vs 액세스 빈도(Y축)를 한눈에 보여주어 "비용 최적화 대상(크지만 액세스 없는 버킷)"을 즉시 발견 가능.

기존 S3 버킷을 원본으로 하여 Amazon CloudFront 배포를 배포합니다. 고객 요청을 CloudFront URL로 보냅니다. 액세스 제어를 위해 CloudFront 서명 URL로 전환합니다.

요구 사항 분석:

대상: 대용량 AI/ML 데이터 세트 (S3 저장).
사용자: 북미 및 유럽 전역 분포 (지리적 분산).
목표: 데이터 전송 비용 절감 + 성능 유지/개선.
보안: 유료 고객만 액세스 (서명된 URL).

해결책 (CloudFront + 서명된 URL):
- 비용 절감: 일반적으로 CloudFront의 인터넷 데이터 전송 요금(DTO)은 S3에서 직접 인터넷으로 전송하는 요금보다 저렴합니다. 또한 S3에서 CloudFront로의 데이터 전송은 무료입니다.
- 성능 향상: CloudFront는 전 세계 엣지 로케이션(Edge Location)에 콘텐츠를 캐싱하여, 유럽 사용자가 미국(us-east-1)까지 오지 않고 가까운 엣지에서 빠르게 다운로드할 수 있게 합니다.
- 보안: CloudFront도 서명된 URL(Signed URL) 기능을 제공하여 S3 서명된 URL과 동일하게 유료 사용자에게만 기간 한정 액세스 권한을 부여할 수 있습니다.

오답 노트

A (S3 Transfer Acceleration): 속도는 빨라지지만, 표준 데이터 전송 요금 외에 추가 요금이 부과됩니다. 비용 절감 목표에 위배됩니다.
C (Cross-Region Replication): 유럽 리전에 버킷을 하나 더 만들면 스토리지 비용이 2배가 되며, 리전 간 복제(Replication) 전송 비용이 추가로 발생합니다. CloudFront보다 비용 효율성이 떨어집니다.
D (앱 스트리밍): EC2 인스턴스를 거쳐 데이터를 전송하면 EC2 부하가 심해지고 처리량이 병목 현상을 일으킬 수 있습니다. 대용량 파일 전송에는 적합하지 않습니다.

S3 vs CloudFront 서명된 URL 비교

특징	S3 서명된 URL (S3 Signed URL)	CloudFront 서명된 URL (CloudFront Signed URL)
원본	S3 버킷 직접 접근	CloudFront 배포 (CDN) 경유
주요 장점	구현이 매우 간단함	전송 속도 빠름, 전송 비용 저렴
사용 사례	사용자 간 파일 공유, 업로드 권한 부여	전 세계 배포, 대용량 미디어 스트리밍/다운로드
비용 구조	S3 데이터 전송 요금 (비쌈)	CloudFront 데이터 전송 요금 (저렴)

Tip: "성능 향상" + "비용 절감" + "글로벌 배포" 키워드가 나오면 CloudFront가 정답입니다.

AWS Backup을 사용하여 야간 백업을 수행하여 백업 계획을 만듭니다. 백업을 다른 Region에 복사합니다. 애플리케이션의 EC2 인스턴스를 리소스로 추가합니다.

요구 사항:

대상: EC2 구성 + EBS 데이터 볼륨 (전체 시스템).
DR: 다른 리전으로 복구 가능 (Cross-Region).
효율성: 운영 오버헤드 최소화.

해결책 (AWS Backup + EC2 Resource):
- AWS Backup: 백업 예약, 보존 관리, 리전 간 복사(Cross-Region Copy)를 자동화하는 완전 관리형 서비스입니다. Lambda를 작성할 필요가 없어 운영 효율성이 가장 높습니다.
- EC2 인스턴스 백업: AWS Backup에서 리소스를 'EBS 볼륨'이 아닌 'EC2 인스턴스'로 지정하면, AWS는 AMI(Amazon Machine Image)를 생성합니다. AMI는 모든 연결된 EBS 볼륨의 데이터뿐만 아니라 인스턴스의 구성 정보(메타데이터, 가상화 유형 등)를 모두 포함하므로, 재해 복구 시 인스턴스를 즉시 다시 시작할 수 있습니다.

오답 노트

C (EBS 볼륨만 백업): EBS 볼륨만 백업하면 데이터는 보존되지만, EC2 인스턴스의 구성 정보는 누락됩니다. 복구 시 수동으로 인스턴스를 만들고 볼륨을 연결해야 하므로 복구 시간이 오래 걸리고 "구성 및 데이터 백업" 요건을 완전히 충족하지 못합니다.
A, D (Lambda): 사용자 지정 스크립트를 작성하고 유지 관리하는 것은 관리형 서비스(AWS Backup)를 사용하는 것보다 운영 오버헤드가 훨씬 큽니다. 또한 D는 다른 리전이 아닌 가용 영역(AZ)으로 복사하므로 DR 요건을 충족하지 못합니다.

AWS Backup 대상: EC2 vs EBS

백업 대상 리소스	EC2 인스턴스	EBS 볼륨
생성 결과물	AMI (Amazon Machine Image)	EBS Snapshot
포함 내용	모든 볼륨 데이터 + 인스턴스 설정	단일 볼륨의 데이터만
복구 방식	이미지를 통해 서버를 통째로 띄움 (빠름)	빈 서버를 만들고 볼륨을 연결해야 함 (느림)
적합한 사례	전체 시스템 백업/DR	특정 데이터 디스크만 복구할 때

MySQL용 Amazon Aurora Serverless

요구 사항 분석:

워크로드: 글로벌 영업팀 사용, "액세스 패턴이 드묾(Infrequent)".
제약 사항: 미래의 성장을 대비해야 하지만, 현재 "특정 인스턴스 유형을 선택하고 싶지 않음".
목표: 최소한의 다운타임, AWS 마이그레이션.

해결책 (Aurora Serverless):
- 인스턴스 관리 불필요: 사용자가 EC2 인스턴스 유형이나 크기를 미리 지정할 필요가 없습니다.
- 자동 확장 (Auto Scaling): 애플리케이션 수요에 따라 데이터베이스 용량을 자동으로 시작, 확장, 축소합니다.
- 비용 효율성: "드문 액세스 패턴"의 경우, 사용하지 않을 때는 용량을 0으로 줄이거나 최소화하여 비용을 획기적으로 절감할 수 있습니다.
- 고가용성: Aurora의 분산 스토리지 아키텍처를 그대로 사용하여 최소한의 다운타임 요건을 충족합니다.

오답 노트

A (Aurora MySQL - 프로비저닝됨): 인스턴스 유형(예: r5.large)을 미리 선택해야 합니다. 사용하지 않을 때도 비용이 계속 발생하므로 드문 액세스 패턴에는 비효율적입니다.
D (RDS for MySQL): 전통적인 RDS 역시 인스턴스 유형을 선택해야 하며, 확장을 위해서는 수동 개입이나 다운타임이 필요할 수 있습니다. "인스턴스 유형을 선택하지 않고"라는 요구 사항에 위배됩니다.
C (Redshift Spectrum): 데이터 웨어하우스(OLAP) 서비스입니다. S3에 있는 데이터를 쿼리하는 용도이며, MySQL과 같은 트랜잭션 데이터베이스(OLTP)를 대체하는 용도가 아닙니다.

Amazon Aurora Serverless v1 vs v2

공통점: 인스턴스 프로비저닝 없이 온디맨드로 자동 확장. 예측 불가능하거나 간헐적인 워크로드에 최적.
ACU (Aurora Capacity Unit): Aurora Serverless의 용량 단위. CPU와 메모리의 조합으로 계산되며, 초 단위로 과금됨.

Amazon Inspector를 켭니다. EC2 인스턴스에 Amazon Inspector 에이전트를 배포합니다. 결과를 자세히 설명하는 보고서의 생성 및 배포를 자동화하도록 AWS Lambda 함수를 구성합니다.

요구 사항 분석:

목표: EC2 인스턴스의 취약성(Vulnerability)을 능동적으로 스캔.
후속 조치: 결과 보고서 생성 및 전송 자동화.

해결책 (Amazon Inspector):
- 취약성 스캔: Amazon Inspector는 EC2 인스턴스, 컨테이너 이미지(ECR), Lambda 함수에 대해 CVE(알려진 보안 취약점) 및 네트워크 노출을 자동으로 스캔하는 서비스입니다.
- 작동 방식: EC2 인스턴스 내부에 설치된 에이전트(SSM Agent)를 통해 OS 패키지와 소프트웨어 구성을 분석합니다.
- 자동화: 스캔 결과(Findings)가 생성되면 Amazon EventBridge 등을 통해 AWS Lambda를 트리거하여 관리자에게 이메일 보고서를 보내거나 티켓을 생성하도록 구성할 수 있습니다.

오답 노트

AWS Shield : DDoS(분산 거부 서비스) 공격 방어 서비스입니다. 애플리케이션 내부의 소프트웨어 취약점을 스캔하지 못합니다.
Amazon Macie : S3 버킷에 저장된 민감한 데이터(PII, 신용카드 번호 등)를 식별하는 데이터 보안 서비스입니다. EC2 인스턴스 스캔용이 아닙니다.
Amazon GuardDuty : 위협 탐지(Threat Detection) 서비스입니다. 로그(CloudTrail, DNS, VPC Flow Logs)를 분석하여 해킹 시도나 이상 징후를 탐지하지만, 소프트웨어 패치가 필요한 정적인 취약점(CVE)을 스캔하는 도구는 아닙니다.

⭐AWS 보안 서비스 분류

서비스	Amazon Inspector	Amazon GuardDuty	Amazon Macie	AWS Shield
주요 기능	취약점 관리	위협 탐지	데이터 식별	DDoS 방어
분석 대상	EC2, ECR, Lambda의 소프트웨어 패키지	VPC 로그, DNS 로그, CloudTrail (행동 분석)	S3 내의 민감한 파일	네트워크 트래픽
사용 사례	"패치되지 않은 OS 찾기"	"해킹 시도/채굴기 탐지"	"주민번호가 포함된 파일 찾기"	"대규모 트래픽 공격 방어"

Tip: 문제에서 "취약성(Vulnerability) 스캔" 또는 "CVE"라는 단어가 나오면 Amazon Inspector가 정답입니다.

적절한 런타임을 사용하여 EC2 인스턴스의 스크립트를 AWS Lambda 함수로 마이그레이션합니다.

요구 사항: SQS 메시지 처리, 확장성 유지(점점 더 많은 메시지), 운영 비용 절감.
현재 문제점: EC2 인스턴스는 메시지가 없을 때도 실행 상태를 유지해야 하므로 유휴 비용이 발생하며, 확장을 위해 Auto Scaling 등을 관리해야 하는 오버헤드가 있습니다.
해결책 (Serverless):
- 비용 절감: AWS Lambda는 요청(이벤트)이 발생할 때만 코드를 실행하고, 실행된 시간만큼만 비용을 지불합니다. 메시지가 없을 때는 비용이 0원입니다.
- 자동 확장: 메시지가 늘어나면 Lambda는 자동으로 동시 실행 횟수를 늘려(Scaling) 처리량을 맞춥니다.
- SQS 통합: Lambda는 SQS를 이벤트 소스로 기본 지원하므로, 폴링(Polling) 로직을 직접 구현할 필요 없이 메시지가 들어오면 자동으로 함수가 트리거됩니다.

오답 노트

A (EC2 크기 증가): 더 큰 인스턴스는 시간당 비용이 더 비쌉니다. 메시지 처리 속도는 빨라질 수 있지만, 메시지가 없는 유휴 시간에도 비싼 요금을 내야 하므로 비용 절감 목표에 부적합합니다.
B (EventBridge로 중지): 인스턴스를 끄면 메시지가 들어왔을 때 즉시 처리할 수 없습니다(Cold Start보다 훨씬 긴 부팅 시간). 또한, 대기열 깊이를 모니터링하여 인스턴스를 켜고 끄는 복잡한 로직을 직접 구현해야 합니다.
D (Run Command): Run Command를 실행하려면 명령을 받을 EC2 인스턴스가 이미 실행 중이어야 합니다. 즉, EC2 비용이 계속 발생하므로 근본적인 해결책이 아닙니다.

SQS + Lambda 아키텍처

이벤트 소스 매핑(Event Source Mapping): Lambda 서비스 내부에서 SQS 큐를 지속적으로 폴링(Long Polling)하다가, 메시지가 감지되면 Lambda 함수를 동기적으로 호출하여 배치를 처리하는 방식.
배치 처리(Batching): 비용 효율성을 위해 여러 메시지(예: 10개)를 묶어서 한 번의 Lambda 실행으로 처리할 수 있음.

일정에 따라 실행되는 AWS Glue 추출, 변환 및 로드(ETL) 작업을 만듭니다. ETL 작업을 구성하여 .csv 파일을 처리하고 처리된 데이터를 Amazon Redshift에 저장합니다.

핵심 요약

요구 사항 분석:

소스: S3에 저장된 CSV 파일 (레거시 앱 생성).
대상: Amazon Redshift
(COTS 앱이 SQL로 쿼리해야 함).
제약 사항: COTS 앱은 CSV를 직접 처리 불가.
목표: 가장 적은 운영 오버헤드로 데이터 변환 및 적재.

해결책 (AWS Glue):
- 완전 관리형 (Serverless): 서버를 프로비저닝하거나 관리할 필요가 없습니다.
- ETL 최적화: AWS Glue는 S3의 CSV 데이터를 읽어 스키마를 파악하고, 필요한 데이터 포맷으로 변환한 뒤 Redshift로 로드(Load)하는 작업에 최적화되어 있습니다.
- 자동화: 스케줄러가 내장되어 있어 별도의 크론(Cron) 서버 없이 정기적인 작업을 쉽게 설정할 수 있습니다.

오답 노트

B (EC2 + Script): EC2 인스턴스를 관리(패치, 보안, 가용성 유지)해야 하므로 서버리스인 Glue보다 운영 오버헤드가 훨씬 큽니다.
C (Lambda + DynamoDB): 문제의 요구 사항은 "복잡한 SQL 쿼리"를 수행하고 "Amazon Redshift"를 분석 대상으로 사용하는 것입니다. NoSQL인 DynamoDB에 데이터를 저장하는 것은 이 요구 사항을 충족하지 못합니다.
D (Amazon EMR): EMR은 대규모 빅데이터 처리(Hadoop/Spark)를 위한 서비스입니다. 단순한 CSV 적재 작업을 위해 클러스터를 구성하고 관리하는 것은 Glue에 비해 오버헤드가 크고 비용 효율적이지 않습니다.

AWS Glue

정의: 완전 관리형 추출, 변환 및 로드(ETL) 서비스.
주요 기능:
- Data Catalog: 데이터의 위치와 스키마 중앙 관리.
- Job: Python 또는 Scala 코드를 생성하여 데이터 변환 및 적재 실행.
- Crawler: 데이터 저장소를 스캔하여 스키마 자동 생성.

사용 사례: S3 데이터를 Redshift로 적재, 데이터 레이크(S3) 데이터 변환(Parquet 변환 등).

AWS CloudTrail을 활성화하여 감사에 사용합니다.
AWS Config를 활성화하고 감사 및 규정 준수를 위한 규칙을 생성합니다.

핵심 요약

요구 사항 분석:

문제: 무단 변경(과도한 인스턴스 생성, 보안 그룹 수정) 발생.
목표: 변경 사항을 추적(Track)하고 감사(Audit)해야 함.

해결책 (Governance & Auditing):
- AWS CloudTrail : AWS 계정 내에서 일어나는 모든 API 호출(누가, 언제, 어디서)을 기록합니다. "누가 보안 그룹을 열었는지", "누가 인스턴스를 시작했는지" 감사하는 데 필수적입니다.
- AWS Config : 리소스의 구성 기록(Configuration History)을 추적합니다. "어제와 오늘 보안 그룹 설정이 어떻게 달라졌는지"를 시각적으로 보여주며, 규칙(Rules)을 통해 규정 위반(예: 22번 포트 전체 개방)을 자동으로 탐지합니다.

오답 노트

Trusted Advisor: 비용 절감이나 보안 권장 사항을 제공하지만, 리소스의 변경 이력을 시계열로 추적하거나 법적 감사를 위한 상세 로그를 제공하는 도구는 아닙니다.
데이터 수명 주기: EBS 스냅샷이나 S3 객체의 생성/삭제 주기를 관리하는 것으로, 리소스 구성 변경 추적과는 무관합니다.
CloudFormation: 인프라를 코드로 관리하는 도구입니다. 이미 발생한 무단 변경을 추적하거나 감사하는 도구가 아니라, 배포 도구입니다.

CloudTrail vs Config 비교 (시험 단골 출제)

구분	AWS CloudTrail	AWS Config
핵심 질문	Who? (누가 했나?)	What? (무엇이 변했나?)
기능	API 호출 로그 기록 (활동 감사)	리소스 구성 변경 기록 (형상 관리)
예시	"UserA가 `RunInstances` API를 호출함"	"인스턴스 타입이 `t2.micro`에서 `m5.large`로 변함"
주요 목적	보안 감사, 법적 준수	변경 관리, 규정 준수 확인

⭐Tip: 문제에서 "누가 변경했는지"를 물으면 CloudTrail, "구성이 어떻게 변했는지"를 물으면 Config가 정답입니다. 이 문제처럼 둘 다 필요하면 두 가지를 모두 선택합니다.

AWS Systems Manager Session Manager를 사용하여 EC2 인스턴스에 연결합니다.

핵심 요약

문제 상황: 수백 대의 인스턴스에 대한 SSH 키 관리 부담과 보안 위험(공유 키 사용).
해결책 (Session Manager):
- SSH 키 불필요: Session Manager는 SSH 키 쌍을 사용하지 않고 IAM 권한을 통해 인증합니다. 따라서 "공유 키 제거"라는 보안 팀의 요구 사항을 완벽하게 충족합니다.
- 관리 오버헤드 최소화: 별도의 배스천 호스트(Bastion Host)를 구축하거나 관리할 필요가 없습니다. SSH 포트(22번)를 열 필요도 없어 보안이 강화됩니다.
- 감사: 모든 세션 활동을 기록하고 로깅할 수 있어 감사가 쉽습니다.

오답 노트

B (AWS STS): STS는 임시 AWS 자격 증명(Access Key/Secret Key)을 발급하는 서비스입니다. 리눅스 접속용 SSH 키 쌍을 직접 생성해주는 서비스가 아니며, 이를 구현하려면 추가적인 복잡한 스크립팅이 필요합니다.
C (배스천 호스트): 배스천 호스트를 운영하는 것 자체가 추가적인 인프라 관리 오버헤드(패치, 유지보수)를 발생시킵니다. 또한, 배스천과 대상 인스턴스 간의 키 관리가 여전히 필요합니다.
D (Cognito + Lambda): 사용자 지정 인증 시스템을 직접 개발하고 유지 관리해야 하므로 가장 높은 관리 오버헤드가 발생합니다.

AWS Systems Manager Session Manager 장점

기존 방식 (SSH / Bastion)	Session Manager 방식
SSH 키 관리 필수 (분실/유출 위험)	키 없음 (Keyless) (IAM으로 인증)
22번 포트 개방 필요 (공격 표면 노출)	인바운드 포트 불필요 (아웃바운드 HTTPS 사용)
배스천 호스트 유지 관리 비용 발생	서버리스 (관리할 인프라 없음)
명령어 감사 어려움	CloudWatch/S3에 명령어 로그 저장

⭐Tip: 문제에서 "SSH 키 제거" 또는 "배스천 호스트 없이 접근", "포트 22번 닫기" 등의 요구 사항이 나오면 Systems Manager Session Manager가 정답입니다.

Amazon Kinesis Data Streams에 데이터를 게시하고 Kinesis Data Analytics를 사용하여 데이터를 쿼리합니다.

요구 사항 분석:

데이터 손실 방지: EC2 재부팅 시 데이터가 손실되므로, 생성된 데이터를 즉시 내구성 있는 외부 저장소로 보내야 합니다.
거의 실시간(Near Real-time) 쿼리: 데이터가 들어오는 즉시 분석/쿼리가 가능해야 합니다.
확장성: 1MB/s 이상의 속도에도 대응할 수 있어야 합니다.

해결책 (Kinesis Streams + Analytics):
- Amazon Kinesis Data Streams (KDS): 데이터를 수집하자마자 KDS로 전송하면, EC2가 재부팅되더라도 데이터는 이미 Kinesis에 3중으로 복제되어 안전하게 저장(내구성 확보)됩니다.
- Amazon Kinesis Data Analytics: 스트림에 들어온 데이터를 실시간으로 SQL 쿼리를 통해 분석할 수 있는 서비스입니다. 별도의 DB에 적재하고 인덱싱하는 시간을 기다릴 필요 없이 흐르는 데이터에 대해 즉시 질문을 던질 수 있습니다.

오답 노트

B (Firehose -> Redshift): Kinesis Data Firehose는 데이터를 모아서(Buffering) 적재하는 구조라 최소 60초 정도의 지연 시간이 발생하며, Redshift에 적재되는 시간까지 포함하면 "거의 실시간"보다는 느립니다. 또한 1MB/s 정도의 소규모 스트림을 위해 Redshift 클러스터를 운영하는 것은 비용 효율적이지 않을 수 있습니다.
C (Instance Store + Athena): 인스턴스 스토어는 휘발성이 강해 재부팅/중지 시 데이터가 삭제될 위험이 있어 "데이터 손실 최소화" 요건에 가장 부적합합니다. 또한 Athena는 S3에 저장된 파일을 스캔하는 방식이라 실시간성이 떨어집니다.
D (EBS + Redis): EBS에 저장하더라도 EC2가 죽으면 접근이 불가능할 수 있습니다. 또한 Redis는 Key-Value 스토어로서 복잡한 JSON 데이터를 SQL처럼 유연하게 쿼리하는 분석 용도에는 적합하지 않습니다.

Amazon Kinesis 서비스 구분

Kinesis Data Streams: 실시간 데이터 수집 및 처리 파이프라인의 '버퍼' 역할 (사용자 코드나 프레임워크 필요).
Kinesis Data Firehose: 데이터를 S3, Redshift, OpenSearch 등으로 '배달(Load)'하는 역할 (관리형, 버퍼링 존재).
Kinesis Data Analytics: 스트림 데이터에 대해 '실시간 분석(SQL/Java)'을 수행하는 역할.

PutObject에 x-amz-server-side-encryption 헤더가 설정되어 있지 않으면 거부하도록 버킷 정책을 업데이트합니다.

참고: 질문의 문맥상 "모든 객체가 [암호화되어] Amazon S3 버킷에 업로드되도록 하려면"이 정확한 질문일 것입니다. 이 문제는 전송 중 암호화(SSL)가 아니라 서버 측 암호화(Server-Side Encryption)를 강제하는 방법을 묻는 전형적인 패턴입니다.

핵심 요약

요구 사항: 사용자가 객체를 업로드할 때, 반드시 서버 측 암호화(SSE)를 요청하도록 강제해야 합니다.
해결책 (Bucket Policy):
- 클라이언트가 S3에 파일을 업로드(PutObject)할 때, 암호화를 원하면 HTTP 헤더에 x-amz-server-side-encryption 정보를 포함해서 보냅니다.
- 버킷 정책에서 "이 헤더가 없으면(Null) 업로드를 거부(Deny)한다"라는 조건을 걸어두면, 암호화되지 않은 객체의 업로드를 원천 차단할 수 있습니다.

오답 노트

C (aws:SecureTransport): 이것은 HTTPS(TLS/SSL)를 통한 전송, 즉 전송 중 암호화를 강제하는 조건 키입니다. "객체 자체의 암호화 저장"을 강제하는 헤더 검사(Option D)와는 구별됩니다.
A, B (s3:x-amz-acl): ACL(Access Control List)은 객체의 권한(공개/비공개 여부)을 설정하는 헤더입니다. 암호화와는 관련이 없습니다.

S3 암호화 강제를 위한 버킷 정책 예시

{
  "Version": "2012-10-17",
  "Id": "PutObjPolicy",
  "Statement": [
    {
      "Sid": "DenyIncorrectEncryptionHeader",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    }
  ]
}

설명: 업로드 시 x-amz-server-side-encryption 헤더가 AES256(또는 aws:kms)이 아니면 요청을 거부합니다.

Amazon Simple Queue Service(Amazon SQS) 메시지 대기열을 만듭니다. 이미지가 업로드되면 SQS 대기열에 메시지를 넣어 썸네일을 생성합니다. 애플리케이션 메시지를 통해 사용자에게 이미지가 수신되었음을 알립니다.

핵심 요약

요구 사항 분석:

작업: 이미지 업로드 + 썸네일 생성(최대 60초 소요).
목표: 빠른 응답 시간 (사용자가 기다리지 않게 함).
방법: 비동기(Asynchronous) 처리 및 계층 간 분리.

해결책 (SQS를 이용한 디커플링):
- 비동기 오프로딩: 애플리케이션은 이미지를 받자마자 SQS 대기열에 "썸네일 생성 작업" 메시지를 넣고, 즉시 사용자에게 "업로드 성공" 응답을 보냅니다. (소요 시간: 밀리초 단위)
- 백엔드 처리: 별도의 작업자(Worker) 계층이 SQS에서 메시지를 꺼내어 60초가 걸리는 썸네일 작업을 수행합니다. 사용자는 이미 응답을 받았으므로 이 시간을 기다릴 필요가 없습니다.

오답 노트

A (Lambda): S3 이벤트로 Lambda를 트리거하는 것도 좋은 방법이지만, "비동기적으로 요청을 다른 계층에 전송"하는 명시적인 아키텍처 패턴으로는 SQS가 더 정석적인 답변입니다. 또한 Lambda 자체 실행 시간 제약이나 동시성 관리가 필요할 수 있습니다.
B (Step Functions): 워크플로 오케스트레이션 도구입니다. 단순한 작업 대기열(Queue) 기능보다는 복잡한 상태 관리에 적합하며, 즉각적인 응답을 위한 단순 비동기 핸드오프에는 오버헤드일 수 있습니다.
D (SNS): SNS는 메시지를 푸시(Push)하는 방식(Fan-out)입니다. 작업자가 바쁠 때 메시지를 보관(버퍼링)해주는 기능이 없어, 백엔드 부하 관리 및 작업 보장 측면에서 SQS보다 부적합합니다.

느슨한 결합 (Loose Coupling)

정의: 시스템의 컴포넌트들이 서로의 내부 구현을 모르고, 메시지를 통해 독립적으로 통신하는 구조.
⭐SQS의 역할: 프론트엔드와 백엔드 사이에 버퍼(Buffer) 역할을 하여, 백엔드 작업이 오래 걸리거나 장애가 발생해도 프론트엔드의 응답 속도와 가용성을 보장함.

Amazon API Gateway에서 HTTPS 엔드포인트를 만듭니다. API Gateway 엔드포인트를 구성하여 AWS Lambda 함수를 호출하여 메시지를 처리하고 결과를 Amazon DynamoDB 테이블에 저장합니다.

핵심 요약

요구 사항 분석:

입력: 배지 판독기가 HTTPS로 메시지 전송.
처리: 메시지 처리 로직 필요.
특성: 고가용성(HA) 필수.
출력: 보안팀 분석용 저장.

해결책 (Serverless Architecture):
- Amazon API Gateway: HTTPS 엔드포인트를 제공하는 완전 관리형 서비스로, 트래픽에 따라 자동 확장되며 기본적으로 고가용성을 보장합니다. 배지 판독기가 메시지를 보낼 수 있는 REST API 주소 역할을 합니다.
- AWS Lambda: 서버 없이 코드를 실행하여 메시지를 구문 분석하고 처리합니다. 다중 가용 영역(Multi-AZ) 고가용성을 자동으로 제공합니다.
- Amazon DynamoDB: 처리된 데이터를 저장하는 NoSQL 데이터베이스로, 빠르고 확장성이 뛰어나며 고가용성을 제공하여 추후 분석에 용이합니다.

오답 노트

A (EC2): 단일 EC2 인스턴스는 고가용성을 제공하지 않습니다 (장애 발생 시 서비스 중단). HA를 위해서는 로드 밸런서(ALB)와 오토 스케일링 그룹(ASG)이 추가로 필요합니다.
C (Route 53): DNS 서비스입니다. 도메인 이름을 IP로 변환해 줄 뿐, HTTPS 요청의 본문(Body)을 받아 Lambda로 전달하는 애플리케이션 계층의 역할은 수행할 수 없습니다.
D (VPN + S3): 배지 판독기가 S3 API(PUT Object)를 직접 호출할 수 있도록 설정하는 것은 복잡하며, 단순 메시지 처리(Processing) 로직을 수행할 컴퓨팅 계층이 없습니다.

API Gateway + Lambda 패턴

정의: 서버리스 웹 애플리케이션이나 마이크로서비스를 구축할 때 가장 널리 사용되는 표준 아키텍처.
장점:
No Ops: 서버 관리 불필요.
Cost: 요청 수에 따른 과금 (유휴 비용 없음).
HA: 별도 설정 없이 고가용성 확보.

기존 파일 스토리지 볼륨과 동일한 양의 디스크 공간으로 AWS Storage Gateway Volume Gateway 저장 볼륨을 프로비저닝합니다. iSCSI를 사용하여 Volume Gateway 저장 볼륨을 기존 파일 서버에 마운트하고 모든 파일을 스토리지 볼륨에 복사합니다. 스토리지 볼륨의 예약된 스냅샷을 구성합니다. 재해에서 복구하려면 Amazon Elastic Block Store(Amazon EBS) 볼륨에 스냅샷을 복원하고 EBS 볼륨을 Amazon EC2 인스턴스에 연결합니다.

요구 사항 분석:

프로토콜: iSCSI 사용 (기존 인프라 변경 최소화).
성능: "지연(Latency) 없이" 모든 파일에 "즉시 액세스".
데이터: 수백 TB의 대용량.
목표: 재해 복구(DR) 계획 수립.

해결책 (Volume Gateway - Stored Volumes):
- Stored Volumes (보관된 볼륨): 전체 데이터 세트를 로컬(온프레미스) 하드웨어에 저장하고, 비동기적으로 AWS(S3)에 스냅샷 형태로 백업합니다.
- 성능 보장: 모든 데이터가 로컬에 존재하므로 AWS로의 네트워크 대기 시간(Latency)이 전혀 발생하지 않습니다. 사용자는 기존과 동일한 속도로 데이터를 사용할 수 있습니다.
- DR: 데이터는 AWS에 EBS 스냅샷으로 저장되므로, 재해 발생 시 이를 EBS 볼륨으로 복원하여 EC2에 연결할 수 있습니다.

오답 노트

C (Cached Volumes - 캐시 볼륨): 기본 데이터를 AWS S3에 저장하고, 자주 쓰는 데이터만 로컬에 캐싱합니다. 수백 TB 중 캐시에 없는 데이터를 요청하면 AWS에서 다운로드해야 하므로 지연 시간(Latency)이 발생합니다. "지연 없이 즉시 액세스" 요건을 충족하지 못합니다.
A (S3 File Gateway): iSCSI가 아닌 NFS/SMB 프로토콜을 사용합니다. 문제에서 "애플리케이션을 수정"해야 한다고 명시되어 있어 "인프라 변경 최소화" 요건에 위배됩니다.
B (Tape Gateway): 가상 테이프 라이브러리(VTL) 방식으로, 백업 및 아카이빙 전용입니다. 실시간 파일 시스템 액세스를 제공하지 않습니다.

Storage Gateway Volume Gateway 유형 비교

유형	보관된 볼륨 (Stored Volumes)	캐시 볼륨 (Cached Volumes)
기본 데이터 위치	온프레미스 (로컬 스토리지)	AWS S3 (클라우드)
로컬 필요 용량	전체 데이터 크기 (수백 TB)	자주 쓰는 데이터 크기 (캐시용)
지연 시간	없음 (Low Latency)	캐시 미스 시 지연 발생
주요 목적	로컬 성능 유지 + 클라우드 백업	스토리지 용량 확장, 비용 절감

⭐Tip: 문제에서 "지연 시간 없음(Low Latency)", "전체 데이터 로컬 액세스"가 핵심이라면 Stored Volumes가 정답입니다. 반면 "스토리지 확장", "온프레미스 용량 부족"이 핵심이라면 Cached Volumes가 정답입니다.

보호된 콘텐츠에 액세스하기 위한 적절한 IAM 역할을 맡도록 Amazon Cognito 자격 증명 풀(Identity Pool)을 업데이트합니다.

아키텍처 흐름:

인증 (Authentication): 사용자는 Cognito User Pool을 통해 로그인하고 JWT(토큰)를 받습니다.
권한 부여 (Authorization): 애플리케이션은 이 JWT를 Cognito Identity Pool로 보내 임시 AWS 자격 증명(Access Key, Secret Key, Session Token)으로 교환합니다.
리소스 액세스: 이 AWS 자격 증명은 특정 IAM 역할(Role)과 연결되어 있으며, 이 역할에 정의된 권한에 따라 S3 버킷에 접근할 수 있습니다.

문제 해결: 사용자가 S3에 접근하지 못하는 것은 Identity Pool이 사용자에게 부여하는 IAM 역할(Authenticated Role)에 해당 S3 버킷에 대한 읽기 권한(s3:GetObject 등)이 없기 때문입니다. 따라서 Identity Pool이 적절한 권한을 가진 IAM 역할을 맡도록(Assume) 구성하거나, 연결된 IAM 역할의 정책을 수정해야 합니다.

Amazon Cognito: User Pool vs Identity Pool

기능	Cognito User Pool	Cognito Identity Pool
주요 목적	인증 (Authentication)	권한 부여 (Authorization)
하는 일	회원가입, 로그인, JWT 발급	AWS 자격 증명(IAM 역할) 발급
결과물	ID Token, Access Token (JWT)	AWS Access/Secret Key
S3 접근 방식	직접 접근 불가 (Identity Pool 필요)	발급받은 키로 S3 API 직접 호출 가능

⭐Tip: 문제에서 "S3, DynamoDB 같은 AWS 리소스에 직접 액세스해야 한다"라는 내용이 나오면 Identity Pool이 정답의 핵심입니다.

A. 30일 후 자산을 S3 Intelligent-Tiering으로 이동합니다.
B. 불완전한 다중 파트 업로드를 정리하기 위해 S3 수명 주기 정책을 구성합니다.

핵심 요약

요구 사항 분석:

업로드 방식: 대규모 자산, 멀티파트 업로드(Multipart Upload) 사용.
액세스 패턴: 30일 이후에는 덜 자주 사용되나, 패턴이 일관되지 않음(Inconsistent).
목표: 비용 최적화 + 높은 가용성 및 복원력 유지.

해결책 1 (S3 Intelligent-Tiering):
- 이유: 30일 후 액세스 패턴이 "일관되지 않음"이 핵심입니다. S3 Standard-IA는 데이터 검색 비용(Retrieval Fee)이 발생하므로, 예상치 못하게 자주 접근하면 비용이 오히려 증가할 수 있습니다.
- Intelligent-Tiering: 액세스 패턴을 모니터링하여 자주 사용하는 계층(Frequent)과 자주 사용하지 않는 계층(Infrequent) 간에 객체를 자동으로 이동시킵니다. 검색 비용이 없고 성능 저하가 없으며, S3 Standard와 동일한 고가용성을 제공하므로 최적의 선택입니다.

해결책 2 (불완전한 멀티파트 업로드 정리):
- 이유: 멀티파트 업로드가 중단되거나 실패하면, 업로드되다 만 '조각(Parts)'들이 버킷에 남아 스토리지 공간을 차지하고 비용을 발생시킵니다. 이 조각들은 일반적인 파일 목록에는 보이지 않습니다.
- 조치: 수명 주기 정책(Lifecycle Policy)을 설정하여 오래된 불완전한 멀티파트 업로드 삭제(AbortIncompleteMultipartUpload)를 구성해야 불필요한 비용 낭비를 막을 수 있습니다.

오답 노트

D (S3 Standard-IA): 저장 비용은 저렴하지만 데이터 검색 비용이 부과됩니다. 액세스 패턴이 불규칙할 때 사용하면 비용 효율이 떨어질 수 있습니다.
E (S3 One Zone-IA): 데이터가 단일 가용 영역(AZ)에만 저장되므로, 문제의 요구 사항인 "높은 가용성과 복원력"을 충족하지 못합니다 (AZ 장애 시 데이터 손실 가능).
C (삭제 마커 정리): 이는 S3 버전 관리(Versioning)를 사용하는 버킷에서 객체를 삭제했을 때 발생하는 문제입니다. 문제에서는 덮어쓰기(Overwrite)를 언급했으나 버전 관리에 대한 명시적 언급보다는 '멀티파트 업로드' 이슈가 더 직접적입니다.

S3 스토리지 클래스 선택 가이드

클래스	S3 Intelligent-Tiering	S3 Standard-IA	S3 One Zone-IA
적합한 데이터	액세스 패턴을 알 수 없거나 변동이 심한 데이터	자주 쓰지 않지만 필요할 때 바로 꺼내야 하는 데이터	중요도가 낮고 재생성 가능한 데이터
비용 구조	모니터링 비용 발생, 검색 비용 무료	저장 비용 저렴, 검색 비용 유료	저장 비용 가장 저렴 (단일 AZ)
가용성	높음 (Multi-AZ)	높음 (Multi-AZ)	낮음 (Single-AZ)

Tip: 문제에서 "액세스 패턴이 불규칙하다(Inconsistent, Unpredictable, Changing)"라는 말이 나오면 Intelligent-Tiering이 정답입니다. "멀티파트 업로드"가 나오면 "불완전한 업로드 정리"가 비용 최적화의 짝꿍입니다.

프라이빗 서브넷의 라우팅 테이블을 업데이트하여 아웃바운드 트래픽을 AWS 네트워크 방화벽(AWS Network Firewall)으로 라우팅합니다. 도메인 목록 규칙 그룹을 구성합니다.

핵심 요약

요구 사항 분석:

보안 대상: 프라이빗 서브넷의 EC2 인스턴스 (민감 데이터 보유).
허용 정책: 특정 타사 URL(도메인)만 허용 (화이트리스트).
차단 정책: 그 외 모든 인터넷 트래픽 차단.

해결책 (AWS Network Firewall):
- 도메인 필터링: AWS Network Firewall은 상태 저장(Stateful) 규칙을 통해 아웃바운드 트래픽에 대해 정규화된 도메인 이름(FQDN) 기반의 필터링을 지원합니다.
- 구현: VPC의 라우팅 테이블을 수정하여 인터넷으로 나가는 트래픽이 NAT 게이트웨이를 거치기 전(또는 후)에 Network Firewall 엔드포인트를 통과하도록 구성하면, 지정된 저장소 URL(예: repo.vendor.com)로 가는 트래픽만 허용하고 나머지는 모두 차단할 수 있습니다.

오답 노트

보안 그룹: 보안 그룹(Security Group)과 네트워크 ACL은 IP 주소와 포트 기반의 규칙만 지원합니다. www.example.com과 같은 URL이나 도메인 이름을 규칙에 직접 입력할 수 없습니다. 타사 저장소의 IP 주소는 수시로 변경될 수 있어 IP 기반 관리는 불가능합니다.
AWS WAF: WAF는 웹 애플리케이션으로 들어오는 인바운드(Inbound) 공격(SQL 인젝션, XSS 등)을 방어하는 도구입니다. 내부 서버에서 외부로 나가는 아웃바운드(Outbound) 트래픽을 필터링하는 용도가 아닙니다.
ALB: ALB는 인바운드 트래픽 부하 분산 장치입니다. 내부 인스턴스가 외부 인터넷에 접속하기 위한 포워드 프록시(Forward Proxy)나 게이트웨이 역할을 수행할 수 없습니다.

AWS Network Firewall

정의: VPC를 위한 관리형 네트워크 방화벽 및 침입 탐지/방지 서비스.
주요 기능:
- URL/도메인 필터링: HTTP/HTTPS 트래픽의 SNI(Server Name Indication)를 검사하여 특정 도메인으로의 접근 제어.
- IPS (침입 방지 시스템): 알려진 위협 서명 기반의 트래픽 차단.

사용 사례: "내부 서버가 update.microsoft.com만 접속하게 하고 싶다"와 같은 아웃바운드 통제 요구 사항에 최적.

AWS Key Management Service(AWS KMS)에서 키를 만듭니다. DB 인스턴스에 대한 암호화를 활성화합니다.

요구 사항 분석:

대상: Amazon RDS DB 인스턴스.
목표: 휴면 데이터(Data at Rest) 암호화.

해결책 (AWS KMS):
- 작동 방식: Amazon RDS의 암호화 기능은 AWS KMS(Key Management Service)와 통합되어 있습니다. DB 인스턴스를 생성할 때 암호화를 활성화하고 KMS 키(AWS 관리형 키 또는 고객 관리형 키)를 선택하면 됩니다.
- 범위: 기본 스토리지, 자동 백업, 읽기 전용 복제본, 스냅샷이 모두 암호화됩니다.

AWS 암호화 서비스 구분

용도	데이터 저장 시 (At Rest)	데이터 전송 시 (In Transit)	자격 증명 관리
관련 서비스	AWS KMS	ACM (Certificate Manager) / SSL	Secrets Manager
적용 대상	EBS, RDS, S3 객체 등	HTTPS 웹 트래픽, DB 연결	DB 암호, OAuth 토큰

상황 분석 (계산):
가용 대역폭: 15Mbps의 70% = 10.5Mbps.
전송 데이터: 20TB.
소요 시간: 10.5Mbps 속도로 20TB 전송 시 약 176일(약 6개월) 소요됨.
제약 사항: 30일 이내에 완료해야 함.

해결책 (오프라인 마이그레이션):
- 네트워크 속도가 너무 느려 물리적 한계로 인해 온라인 전송이 불가능합니다.
- AWS Snowball 디바이스를 배송받아 로컬 네트워크(LAN)에서 데이터를 복사한 뒤 AWS로 반송하면, 배송 기간을 포함해도 1~2주 내에 처리가 가능하므로 유일한 해결책입니다.

오답 노트

B, C, D (네트워크 기반 전송): DataSync, VPN, S3 Transfer Acceleration 모두 회사의 인터넷 회선(15Mbps)을 사용합니다. 물리적인 대역폭 한계를 넘을 수 없으므로 30일 기한을 맞추는 것이 수학적으로 불가능합니다.

AWS 마이그레이션 결정 가이드 (Rule of Thumb)

Snowball 사용 시점: 네트워크로 전송했을 때 일주일 이상 걸리거나, 대역폭 비용이 너무 비쌀 때.
계산기:
(예: 100Mbps 선으로 100TB 전송 시 약 100일 이상 소요 → Snowball 필수)

도은호

`•.¸¸.•´´¯`••._.• 🎀 𝒸𝓇𝒶𝓏𝓎 𝓅𝓈𝓎𝒸𝒽💞𝓅𝒶𝓉𝒽 🎀 •._.••`¯´´•.¸¸.•`