기본개념 · 9장

파일 스토리지와 데이터 전송

이 장의 문항은 두 가지 질문으로 압축됩니다. 애플리케이션이 어떤 프로토콜로 스토리지를 붙잡는가와 데이터를 어떤 수단으로 옮기는가입니다. 전자는 EFS와 FSx 네 종류 중 하나를 지목하고, 후자는 가용 대역폭과 허용 기간이라는 두 숫자가 답을 정합니다. 서비스를 외우는 것이 아니라 판단 기준을 외우는 장입니다.

이 장은 고성능 아키텍처 설계(24%)와 비용 최적화 아키텍처 설계(20%)에 속하며, 하이브리드 구성이 걸릴 때는 복원력 있는 아키텍처 설계(26%)와도 이어집니다.

학습 목표

블록 · 객체 · 파일 스토리지의 접근 방식을 구분하고 요구사항에 맞는 계열을 고를 수 있습니다.
Amazon EFS의 프로토콜과 가용 영역 범위, 성능 모드와 처리량 모드를 설명할 수 있습니다.
Amazon FSx 네 종류를 워크로드 기준으로 구분해 선택할 수 있습니다.
Storage Gateway 세 종류에서 온프레미스에 무엇이 남고 무엇이 AWS로 가는지 설명할 수 있습니다.
DataSync · Transfer Family · Snow Family · Direct Connect를 대역폭과 기간으로 가를 수 있습니다.

블록 · 객체 · 파일 — 어떤 계열이 필요한가

스토리지 선택 문항의 첫 갈림길은 성능이 아니라 접근 방식입니다. 애플리케이션이 스토리지를 어떻게 붙잡는지가 계열을 정하고, 계열이 정해진 다음에야 서비스와 성능 옵션을 고릅니다.

스토리지 세 계열의 접근 방식과 대표 서비스
계열	접근 방식	동시 접근	대표 서비스
블록	운영체제가 디스크로 인식하고 파일 시스템을 직접 올린다	원칙적으로 인스턴스 한 대	Amazon EBS, 인스턴스 스토어 (6장)
객체	HTTP API로 객체 단위 읽기·쓰기. 부분 수정 없음	제한 없음	Amazon S3 (8장)
파일	NFS · SMB 같은 파일 프로토콜로 마운트한다	여러 인스턴스가 동시에	Amazon EFS, Amazon FSx

시험에서 파일 스토리지를 지목하는 문장은 거의 정해져 있습니다. "애플리케이션 코드를 바꾸지 않고", "기존 파일 경로를 그대로 쓰면서", "여러 서버가 같은 디렉터리를 공유해야"가 그것입니다. 애플리케이션이 파일 시스템 호출을 그대로 쓰고 있다면 S3로 바꾸는 것은 코드 변경을 뜻하고, "코드 변경 없이"라는 한정어와 충돌합니다.

프로토콜과 동시 접근 범위를 축으로 배치한 공유 스토리지 선택 매트릭스 — Amazon EFS(NFS · 다중 가용 영역), FSx for Windows File Server(SMB), FSx for Lustre(고성능 컴퓨팅), Amazon EBS(단일 인스턴스)의 영역이 갈립니다

Amazon EFS — 리눅스용 NFS 공유 파일 시스템

Amazon EFS는 NFS 프로토콜로 마운트하는 완전 관리형 파일 시스템입니다. 여러 EC2 인스턴스, 컨테이너, Lambda 함수가 동시에 같은 파일 시스템을 마운트할 수 있고, 용량을 미리 정할 필요 없이 파일을 넣고 지우는 대로 자동으로 늘고 줄어듭니다.

접속 지점은 각 가용 영역의 마운트 타깃(mount target)입니다. 가용 영역마다 마운트 타깃을 만들어 두면 그 가용 영역의 인스턴스가 자기 가용 영역의 마운트 타깃으로 붙습니다. 마운트 타깃은 VPC 안의 네트워크 인터페이스이므로 보안 그룹으로 접근을 통제합니다.

성능 모드와 처리량 모드

Amazon EFS의 성능 모드와 처리량 모드
구분	값	특성
성능 모드	`generalPurpose` (기본값)	지연 시간이 낮다. AWS가 모든 파일 시스템에 이 모드를 권장한다
성능 모드	`maxIO`	총 처리량과 초당 작업 수를 더 높일 수 있으나 작업당 지연이 다소 높다. One Zone 파일 시스템에서는 지원되지 않는다
처리량 모드	`bursting` (기본값)	저장 용량에 따라 기준 처리량이 정해지고 버스트가 허용된다
처리량 모드	`elastic`	워크로드에 맞춰 처리량이 자동으로 오르내린다
처리량 모드	`provisioned`	필요한 처리량을 직접 지정한다. 유효 범위는 1–3,414 MiB/s이며 상한은 리전에 따라 다르다

성능 모드는 파일 시스템을 만든 뒤에 바꿀 수 없습니다. 처리량 모드는 시간 제약이 있지만 나중에 바꿀 수 있습니다. 판단이 서지 않으면 generalPurpose로 만드는 것이 안전합니다.

스토리지 클래스와 수명 주기

EFS도 접근 빈도에 따라 자동으로 계층을 옮깁니다. 수명 주기 관리 정책에서 며칠간 접근하지 않은 파일을 저빈도 계층이나 아카이브 계층으로 옮길지 지정합니다. 지정할 수 있는 값은 1일 · 7일 · 14일 · 30일 · 60일 · 90일 · 180일 · 270일 · 365일입니다.

가용 영역 범위도 두 가지입니다.

리전 파일 시스템 — 여러 가용 영역에 데이터를 저장합니다. 기본 선택입니다.
One Zone 파일 시스템 — 지정한 단일 가용 영역에만 저장해 더 저렴합니다. 가용 영역 장애에 취약하다는 교환 조건은 S3 One Zone-IA와 똑같습니다. One Zone으로 만들면 자동 백업이 기본 활성화됩니다.

암호화는 생성 시 켤 수 있고, KMS 키를 지정하지 않으면 EFS 기본 KMS 키 (aws/elasticfilesystem)가 쓰입니다. 여러 애플리케이션이 한 파일 시스템의 서로 다른 디렉터리만 보게 하려면 액세스 포인트(access point)로 진입 디렉터리와 POSIX 사용자·그룹을 고정합니다.

create-efs.sh — 파일 시스템 생성과 마운트 타깃 구성 (리소스 ID와 가용 영역은 예시입니다)

FS_ID=$(aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode elastic \
  --encrypted \
  --query 'FileSystemId' --output text)

# 가용 영역마다 마운트 타깃을 만들어야 그 가용 영역에서 마운트할 수 있습니다.
aws efs create-mount-target \
  --file-system-id "$FS_ID" \
  --subnet-id subnet-0123456789abcdef0 \
  --security-groups sg-0123456789abcdef0

# 인스턴스에서 마운트합니다.
sudo mount -t nfs4 -o nfsvers=4.1 \
  "$FS_ID".efs.ap-northeast-2.amazonaws.com:/ /mnt/shared

Amazon FSx 네 종류 — 워크로드가 선택 기준 SAA 빈출

Amazon FSx는 널리 쓰이는 파일 시스템을 그대로 관리형으로 제공합니다. API의 파일 시스템 유형 열거값은 WINDOWS · LUSTRE · ONTAP · OPENZFS 네 가지입니다. 네 종류는 성능 등급이 아니라 서로 다른 파일 시스템이므로, 선택 기준은 언제나 워크로드가 무엇을 요구하는가입니다.

Amazon FSx 네 종류의 대상 워크로드와 배포 유형
종류	이럴 때 고른다	배포 유형
FSx for Windows File Server	Windows 애플리케이션이 SMB로 접근해야 하고 Active Directory 통합이 필요하다. 기존 Windows 파일 서버를 그대로 옮기는 경우	`SINGLE_AZ_1`(기본) · `SINGLE_AZ_2` · `MULTI_AZ_1`. 다중 가용 영역은 가용 영역이 3개 이상인 리전에서만 만들 수 있다
FSx for Lustre	고성능 컴퓨팅, 기계 학습 학습, 미디어 처리처럼 대규모 병렬 처리량이 필요하다. Amazon S3와 연동해 데이터 리포지토리로 쓸 수 있다	`SCRATCH_1` · `SCRATCH_2`(임시·단기 처리) / `PERSISTENT_1` · `PERSISTENT_2`(장기 저장·처리량 중심)
FSx for NetApp ONTAP	NFS · SMB · iSCSI를 한 파일 시스템에서 함께 써야 하거나, 온프레미스 ONTAP 환경의 기능과 운영 방식을 그대로 유지해야 한다	`SINGLE_AZ_1` · `SINGLE_AZ_2` · `MULTI_AZ_1` · `MULTI_AZ_2`
FSx for OpenZFS	NFS 기반 리눅스 워크로드를 ZFS 기능(스냅샷·복제)과 함께 옮긴다	`SINGLE_AZ_1` · `SINGLE_AZ_2` · `SINGLE_AZ_HA_1` · `SINGLE_AZ_HA_2` · `MULTI_AZ_1`

Lustre의 배포 유형 구분이 자주 출제됩니다. 스크래치(scratch)는 임시 스토리지와 단기 처리용이고, 지속형(persistent)은 장기 저장과 처리량 중심 워크로드용입니다. SCRATCH_2는 SCRATCH_1보다 전송 중 암호화와 더 높은 버스트 처리량을 제공하고, PERSISTENT_2는 지연에 민감하고 가장 높은 IOPS·처리량이 필요한 워크로드를 대상으로 합니다.

FSx for Lustre의 S3 연동은 시험에서 자주 쓰이는 조합입니다. S3 버킷을 데이터 리포지토리로 연결해 두면 객체를 파일처럼 읽고, 결과를 다시 S3로 내보낼 수 있습니다. "S3에 있는 대용량 데이터셋으로 고성능 분석을 돌려야 한다"가 그 신호입니다.

EFS와 FSx를 가르는 한 문장

요구사항에서 공유 스토리지 서비스로 가는 대응
요구사항의 신호	선택	근거
리눅스 서버 여러 대가 같은 디렉터리를 공유	Amazon EFS	NFS, 다중 가용 영역, 용량 자동 확장
Windows 애플리케이션이 SMB 공유를 요구	FSx for Windows File Server	SMB와 Active Directory 통합을 제공하는 유일한 선택
수천 개 코어가 동시에 읽는 병렬 파일 시스템	FSx for Lustre	고성능 컴퓨팅용 병렬 파일 시스템이며 S3와 연동된다
한 스토리지를 리눅스와 Windows가 함께 사용	FSx for NetApp ONTAP	NFS · SMB · iSCSI 다중 프로토콜을 한 파일 시스템에서 제공
인스턴스 한 대만 붙는 저지연 디스크	Amazon EBS	공유가 필요 없으면 파일 시스템 서비스는 과잉이다
HTTP로 객체를 읽고 쓰며 무한히 확장	Amazon S3	파일 시스템 의미가 필요 없다면 객체 스토리지가 가장 저렴하고 확장된다

Storage Gateway — 온프레미스와 AWS의 경계

AWS Storage Gateway는 온프레미스 애플리케이션이 익숙한 프로토콜을 그대로 쓰면서 데이터는 AWS에 저장하게 하는 하이브리드 서비스입니다. 온프레미스에는 게이트웨이 어플라이언스(가상 머신 또는 하드웨어)를 두고, 그 뒤로 데이터가 AWS로 넘어갑니다. 자주 쓰는 데이터의 캐시가 온프레미스에 남는다는 점이 지연 시간 요구를 만족시키는 근거입니다.

Storage Gateway 세 종류에서 온프레미스에 남는 것과 AWS로 넘어가는 것의 경계 — 파일 게이트웨이는 파일 공유를 S3 객체로, 볼륨 게이트웨이는 iSCSI 볼륨을 스냅샷으로, 테이프 게이트웨이는 가상 테이프를 아카이브로 옮깁니다

Storage Gateway 세 종류의 프로토콜과 저장 위치
종류	온프레미스가 보는 인터페이스	AWS 쪽 저장 형태	대표 용도
파일 게이트웨이 (S3 File Gateway)	NFS 또는 SMB 파일 공유	파일 하나가 S3 객체 하나로 저장된다	파일 서버의 데이터를 S3로 옮기되 애플리케이션은 그대로 두기
볼륨 게이트웨이 — 캐시형(cached)	iSCSI 블록 볼륨	주 데이터가 AWS에 있고 자주 쓰는 부분만 온프레미스에 캐시	온프레미스 스토리지 용량을 늘리지 않고 데이터를 키우기
볼륨 게이트웨이 — 저장형(stored)	iSCSI 블록 볼륨	주 데이터가 온프레미스에 있고 스냅샷이 AWS로 비동기 백업된다	전체 데이터에 낮은 지연으로 접근하면서 클라우드 백업 확보
테이프 게이트웨이 (VTL)	가상 테이프 라이브러리	가상 테이프가 아카이브 스토리지로 저장된다	기존 백업 소프트웨어를 그대로 쓰면서 물리 테이프 없애기

볼륨 게이트웨이의 두 유형을 뒤집어 외우는 실수가 흔합니다. "캐시형은 주 데이터가 클라우드에, 저장형은 주 데이터가 온프레미스에"가 구분의 전부입니다. 이름이 가리키는 것은 온프레미스 디스크의 역할입니다 — 캐시형에서는 캐시이고, 저장형에서는 원본 저장소입니다.

Storage Gateway를 지목하는 신호는 "기존 인프라를 유지하면서", "온프레미스 애플리케이션을 수정하지 않고", "온프레미스 스토리지 용량이 부족한데 장비를 더 사고 싶지 않다"입니다. 대체가 아니라 연장이라는 점이 판단의 핵심입니다.

유형 대응은 이렇게 외웁니다. 파일 공유이면 파일 게이트웨이, 블록 볼륨이면 볼륨 게이트웨이, 백업 소프트웨어와 테이프이면 테이프 게이트웨이입니다. 그리고 일회성 대량 이전이면 Storage Gateway가 아니라 DataSync입니다 — 게이트웨이는 상시 운영을 위한 것입니다.

데이터 전송 — 대역폭과 기간이 판단 기준 SAA 빈출

전송 수단 문항은 서비스 이름을 외워서 푸는 것이 아니라 두 숫자를 대입해서 푸는 문제입니다. 옮길 데이터의 양과 쓸 수 있는 회선 대역폭을 나누면 걸리는 시간이 나오고, 그 시간이 허용 기간을 넘으면 회선으로 보내는 선택지는 전부 소거됩니다.

데이터량과 가용 대역폭을 두 축으로 놓고 나눈 전송 수단 영역 — 회선으로 몇 달이 걸리는 구간이 물리 전송의 영역이고, 반복 동기화가 필요한 구간이 DataSync의 영역입니다

데이터 전송 수단의 성격과 선택 신호
수단	성격	이럴 때 고른다
AWS DataSync	에이전트가 온라인으로 대량 파일을 옮기고 검증한다. 일회성 이전과 반복 동기화 모두 지원한다	회선으로 감당할 수 있는 데이터량이고, NFS · SMB · HDFS · 객체 스토리지에서 S3 · EFS · FSx로 옮겨야 한다. 예약 실행과 대역폭 제한이 필요하다
AWS Transfer Family	SFTP · FTPS · FTP · AS2 서버를 관리형으로 제공하고 저장소로 Amazon S3 또는 Amazon EFS를 쓴다	외부 파트너가 기존 전송 프로토콜을 계속 써야 한다. 프로토콜을 바꿀 수 없는 상대가 있을 때
AWS Snow Family	물리 장비에 데이터를 담아 배송한다	회선으로 보내면 몇 주에서 몇 달이 걸린다. 대역폭이 좁거나 회선이 없다. 아래 변경 이력을 함께 확인한다
AWS Direct Connect	온프레미스와 AWS를 잇는 전용 네트워크 연결이다	일회성 이전이 아니라 지속적으로 많은 데이터가 오가고, 인터넷을 거치지 않는 일관된 대역폭이 필요하다 (4장 VPC 연결과 하이브리드)

네 수단은 서로 대체재가 아닙니다. Direct Connect는 회선을 까는 일이고, DataSync는 그 회선 위로 데이터를 옮기는 일이며, Snow Family는 회선을 포기하는 선택이고, Transfer Family는 외부 사용자에게 창구를 여는 일입니다. 실제 설계에서는 Direct Connect 위에서 DataSync를 돌리는 조합도 흔합니다.

AWS DataSync

DataSync는 위치(location) 두 개와 작업(task) 하나로 구성됩니다. 지원하는 위치 유형에는 NFS · SMB · HDFS · 객체 스토리지 · Amazon S3 · Amazon EFS · FSx 네 종류가 있어서, 온프레미스에서 AWS로 옮기는 것뿐 아니라 AWS 스토리지 사이의 이동에도 씁니다. 작업에는 대역폭 제한과 실행 일정을 지정할 수 있어 업무 시간의 회선을 비워 둘 수 있습니다.

datasync-task.sh — 온프레미스 NFS 공유에서 S3로 옮기는 작업 생성 (ARN과 경로는 예시입니다)

SRC=$(aws datasync create-location-nfs \
  --server-hostname fileserver.example.internal \
  --subdirectory /export/shared \
  --on-prem-config AgentArns=arn:aws:datasync:ap-northeast-2:123456789012:agent/agent-0123456789abcdef0 \
  --query 'LocationArn' --output text)

DST=$(aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::example-migration-target \
  --s3-config BucketAccessRoleArn=arn:aws:iam::123456789012:role/datasync-s3-role \
  --query 'LocationArn' --output text)

aws datasync create-task \
  --source-location-arn "$SRC" \
  --destination-location-arn "$DST" \
  --name onprem-nfs-to-s3

AWS Transfer Family

Transfer Family는 파일 전송 프로토콜 서버를 관리형으로 제공합니다. 지원 프로토콜은 SFTP · FTPS · FTP · AS2이고, 저장소는 Amazon S3 또는 Amazon EFS를 고릅니다. 엔드포인트는 퍼블릭 또는 VPC 내부로 만들 수 있어서, 전송 창구를 인터넷에 노출하지 않는 구성도 가능합니다.

핵심은 상대방을 바꿀 수 없을 때 쓴다는 것입니다. 파트너가 수십 년째 SFTP로 파일을 보내고 있고 그 관행을 바꿀 수 없다면, S3 API로 바꾸라고 요구하는 대신 SFTP 창구를 열어 주고 도착지만 S3로 만드는 것이 답입니다.

AWS Snow Family

Snow Family는 물리 장비에 데이터를 담아 배송하는 오프라인 전송 수단입니다. 판단 기준은 언제나 같습니다 — 회선으로 보내면 허용 기간을 넘기는가입니다. 전송 시간은 데이터량을 가용 대역폭으로 나누어 계산하고, 그 결과가 몇 주에서 몇 달이라면 물리 전송이 유일한 현실적 선택입니다.

Snow Family의 구성이 최근 몇 년 사이 크게 바뀌었습니다.

AWS Snowmobile — 2024년 3월에 서비스가 종료되었습니다. "엑사바이트급이면 Snowmobile"이라는 서술이 시중 자료에 아직 남아 있지만 현재는 주문할 수 없습니다.
AWS Snowcone — 2024년 11월 12일부로 서비스가 중단되어, 신규·기존 고객 모두 더 이상 주문할 수 없습니다.
이전 세대 Snowball 장비 세 모델 — 같은 날 단종되었습니다.
AWS Snowball Edge — 2025년 11월 7일부로 기존 고객에게만 제공됩니다. 현행 세대는 데이터 이전용 Storage Optimized 210TB 장비와 엣지 컴퓨팅용 Compute Optimized 104 vCPU 장비 두 가지입니다.
AWS는 신규 고객에게 온라인 전송은 AWS DataSync, 물리적 전송은 AWS Data Transfer Terminal, 그리고 파트너 솔루션을 안내합니다.

시험은 "대역폭이 부족하면 오프라인 물리 전송"이라는 판단 자체를 묻습니다. 그 판단은 여전히 유효하므로 Snow Family를 학습 대상에서 빼지 않되, 장비 라인업과 용량 수치를 외우는 것은 의미가 없습니다.

전송 수단 문항의 판단 순서입니다.

일회성인가 상시인가 — 상시 접근이면 Storage Gateway나 Direct Connect, 일회성 이전이면 DataSync나 Snow Family입니다.
회선으로 기간 안에 끝나는가 — 데이터량을 대역폭으로 나눕니다. 넘으면 물리 전송입니다.
상대가 특정 프로토콜을 요구하는가 — SFTP·FTPS·AS2가 나오면 Transfer Family입니다.
인터넷을 거치면 안 되는가 — Direct Connect 또는 VPN입니다.

"몇 페타바이트를 한 달 안에 옮겨야 하는데 회선은 좁다"에 DataSync를 고르는 것이 전형적인 오답입니다. 반대로 "매일 밤 변경분만 동기화"에 Snow Family를 고르는 것도 오답입니다 — 반복 동기화는 온라인 수단의 영역입니다.

온프레미스 파일 서버를 옮기는 시나리오

실제 문항은 위 서비스를 하나씩 묻지 않고 조합해서 묻습니다. 전형적인 시나리오는 이렇습니다 — Windows 파일 서버 수십 테라바이트를 AWS로 옮기되, 사용자는 지금처럼 파일 공유에 접근해야 하고, 이전 기간에는 양쪽이 동기화되어야 한다.

온프레미스 파일 서버 이전의 단계별 선택
단계	질문	선택
1. 도착지 결정	애플리케이션이 어떤 프로토콜을 쓰는가	SMB이면 FSx for Windows File Server, NFS이면 Amazon EFS, 파일 의미가 필요 없으면 Amazon S3
2. 이전 수단 결정	회선으로 기간 안에 끝나는가	끝나면 AWS DataSync, 넘으면 물리 전송
3. 이전 기간 운영	이전이 끝날 때까지 양쪽을 함께 써야 하는가	DataSync 작업을 일정에 걸어 반복 동기화한다
4. 남는 온프레미스 처리	온프레미스에서 계속 접근해야 하는가	계속 필요하면 Storage Gateway로 연장하고, 아니면 전환 후 정리한다

여기서 자주 헷갈리는 지점은 2단계와 4단계를 같은 문제로 보는 것입니다. DataSync는 옮기는 도구이고 Storage Gateway는 남기는 도구입니다. "이전 후 온프레미스 애플리케이션이 계속 파일 공유를 쓴다"면 게이트웨이가 필요하고, "이전 후 온프레미스를 폐기한다"면 게이트웨이는 불필요한 구성 요소입니다.

흔한 오해

시험 포인트 정리

9장 핵심 암기 항목과 함정
항목	사실	함정
파일 스토리지의 신호	"코드 변경 없이", "여러 서버가 같은 디렉터리", "기존 파일 경로 유지"	코드 변경 금지 조건에서 S3로 바꾸는 선택지를 고름
Amazon EFS의 프로토콜	NFS. 리눅스 계열이며 여러 가용 영역에서 동시 마운트	Windows SMB 요구에 EFS를 고름
EFS 마운트 타깃	가용 영역마다 만들고 보안 그룹으로 접근을 통제한다	마운트 타깃 없이 다른 가용 영역에서 붙으려 함
EFS 성능 모드	`generalPurpose`(기본·권장) / `maxIO`. 생성 후 변경 불가, One Zone에서는 `maxIO` 미지원	기본값이 `maxIO`라고 가정하거나 나중에 바꿀 수 있다고 답함
EFS 처리량 모드	`bursting`(기본) / `elastic` / `provisioned`. 프로비저닝 유효 범위 1–3,414 MiB/s	처리량이 항상 용량에 묶인다고 가정
EFS One Zone	단일 가용 영역 저장으로 더 저렴. 자동 백업이 기본 활성	가용 영역 장애 내성이 필요한 요구에 One Zone을 고름
FSx for Windows File Server	SMB + Active Directory. 다중 가용 영역 배포는 가용 영역 3개 이상 리전에서만	Windows 파일 공유 요구에 EFS를 고름
FSx for Lustre	고성능 컴퓨팅·기계 학습용 병렬 파일 시스템. S3와 연동 가능	S3 데이터셋으로 HPC를 돌리는 요구에 EFS를 고름
Lustre 배포 유형	스크래치는 임시·단기 처리, 지속형은 장기 저장·처리량 중심	장기 보관 요구에 스크래치를 고름
FSx for NetApp ONTAP	NFS · SMB · iSCSI 다중 프로토콜을 한 파일 시스템에서 제공	리눅스와 Windows가 함께 쓰는 요구에 두 서비스를 따로 두는 선택지를 고름
FSx for OpenZFS	리눅스 NFS 워크로드를 ZFS 기능과 함께 옮길 때	ONTAP과 구분하지 못함 (다중 프로토콜 요구가 없으면 OpenZFS)
Storage Gateway의 성격	대체가 아니라 연장. 캐시가 온프레미스에 남아 지연 요구를 만족시킨다	일회성 대량 이전에 게이트웨이를 고름 (그때는 DataSync)
파일 게이트웨이	NFS · SMB 공유를 제공하고 파일 하나가 S3 객체 하나가 된다	블록 볼륨이 필요한 요구에 파일 게이트웨이를 고름
볼륨 게이트웨이 캐시형	주 데이터는 AWS, 자주 쓰는 부분만 온프레미스 캐시	저장형과 뒤집어 기억
볼륨 게이트웨이 저장형	주 데이터는 온프레미스, 스냅샷이 AWS로 비동기 백업	전체 데이터 저지연 접근 요구에 캐시형을 고름
테이프 게이트웨이	가상 테이프 라이브러리로 기존 백업 소프트웨어를 그대로 쓴다	백업 소프트웨어 교체를 전제한 선택지를 고름
DataSync	온라인 대량 전송과 반복 동기화. NFS · SMB · HDFS · 객체 스토리지에서 S3 · EFS · FSx로. 대역폭 제한과 일정 지정 가능	반복 동기화 요구에 물리 전송을 고름
Transfer Family	SFTP · FTPS · FTP · AS2 관리형 서버. 저장소는 S3 또는 EFS	외부 파트너가 SFTP를 고수하는 상황에서 프로토콜 변경을 정답으로 고름
Snow Family 판단 기준	데이터량 ÷ 가용 대역폭 > 허용 기간이면 물리 전송	데이터량만 보고 고르거나, 회선이 충분한데도 물리 전송을 고름
Direct Connect	일회성 이전 수단이 아니라 지속적인 전용 연결이다	한 번 옮기고 끝나는 이전에 Direct Connect 신설을 고름

이 장의 비용 판단은 세 가지입니다. (1) 필요한 계열을 넘지 않습니다 — 파일 시스템 의미가 필요 없는데 EFS나 FSx를 쓰면 S3보다 비쌉니다. (2) EFS도 계층을 나눕니다 — 수명 주기 정책으로 접근하지 않는 파일을 저빈도·아카이브 계층으로 보냅니다. (3) 전송 수단을 기간으로 고릅니다 — 회선으로 몇 달이 걸리는 이전을 밀어붙이면 회선 증설 비용과 지연이 함께 발생합니다. 이 사이트는 금액을 싣지 않으므로 판단은 언제나 상대 비교로 합니다.

이 주제들은 고성능 아키텍처 설계(24%)와 비용 최적화 아키텍처 설계(20%)에 걸쳐 출제됩니다.

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

이어서 볼 곳

공식 문서 출처

이 장의 수치 · 기본값 · 동작은 모두 아래 문서에서 확인했습니다.

Amazon EFS 사용 설명서 — 작동 방식 — NFS 마운트, 가용 영역별 마운트 타깃, 용량 자동 확장
Amazon EFS 사용 설명서 — 성능 모드 — generalPurpose가 기본이며 권장이라는 서술, maxIO의 지연 교환 조건, One Zone 미지원, 생성 후 변경 불가
Amazon EFS 사용 설명서 — 수명 주기 관리 — 저빈도 계층과 아카이브 계층 전환 일수(1 · 7 · 14 · 30 · 60 · 90 · 180 · 270 · 365일)
Amazon EFS 사용 설명서 — 자동 백업 — One Zone 파일 시스템에서 자동 백업이 기본 활성화된다는 서술
Amazon EFS 사용 설명서 — 액세스 포인트 — 진입 디렉터리와 POSIX 사용자·그룹 고정
Amazon FSx API 레퍼런스 — DescribeFileSystems — 파일 시스템 유형 네 가지(WINDOWS · LUSTRE · ONTAP · OPENZFS)와 배포 유형 열거값
Amazon FSx for Windows File Server — 다중 가용 영역 고가용성 — 다중 가용 영역 배포가 가용 영역 3개 이상 리전에서만 가능하다는 서술
Amazon FSx for Lustre — 데이터 리포지토리 연결 — Amazon S3 버킷을 데이터 리포지토리로 연결하는 구성
AWS Storage Gateway 사용 설명서 — 게이트웨이 개념 — 파일 · 볼륨 · 테이프 게이트웨이의 구조와 캐시 · 업로드 버퍼의 역할
AWS Storage Gateway API 레퍼런스 — 게이트웨이 유형 값(STORED · CACHED · VTL · FILE_S3)과 캐시형·저장형 볼륨의 데이터 배치 차이
Amazon S3 File Gateway 사용 설명서 — NFS · SMB 파일 공유가 S3 객체로 저장되는 구조
AWS DataSync 사용 설명서 — 작업 일정 — 작업 예약 실행과 반복 동기화
AWS DataSync 사용 설명서 — S3 위치 생성 — 지원 위치 유형과 Amazon S3를 대상으로 하는 전송 구성
AWS Transfer Family API 레퍼런스 — EndpointDetails — 퍼블릭 및 VPC 엔드포인트 유형
AWS Transfer Family 사용 설명서 — VPC에 서버 생성 — SFTP · FTPS · FTP · AS2 프로토콜과 Amazon S3 · Amazon EFS 저장소 선택
AWS Snowball 개발자 안내서 — 장치 유형 — 현행 Snow 장비 유형
AWS Storage Blog — AWS Snow 장비 업데이트 — Snowcone 서비스 중단(2024-11-12), 이전 세대 Snowball 모델 단종, Snowball Edge의 기존 고객 한정 제공(2025-11-07)과 신규 고객 대안 안내