[storage] 스토리지 비교
블록이냐 파일이냐 객체냐. 스토리지를 고르기 전에, 내가 필요한 게 정확히 무엇인지부터 가려냅니다.
One-Line Summary
스토리지 문제는 보통 block, file, object, temporary local 중 무엇을 요구하는지 먼저 나누면 풀린다.
왜 이렇게 나누나 — 4가지 저장 모델
AWS 스토리지는 **접근 방식(access model)**이 근본적으로 다른 4종류로 갈린다. "어떻게 읽고 쓰느냐"가 서비스를 결정한다.
| 모델 | 접근 방식 | 핵심 질문 | 대표 |
|---|---|---|---|
| Block | OS가 볼륨을 붙여 파일시스템을 직접 올림 | "한 서버의 디스크가 필요한가?" | EBS, Instance Store |
| File | 네트워크로 마운트해 여러 클라이언트가 공유 | "여러 서버가 같은 파일을 동시에?" | EFS, FSx |
| Object | HTTP API(GET/PUT)로 키-값처럼 접근 | "무한 확장·정적 자산·데이터 레이크?" | S3 |
| Temporary local | 물리 호스트에 직접 붙은 로컬 디스크 | "초고속인데 사라져도 되는가?" | Instance Store |
결정 순서: "공유가 필요한가?" → 아니오면 Block(EBS)/로컬(Instance Store), 예면 File(EFS·FSx). "API로 무한 저장?" → Object(S3). "영속성이 필요 없고 최고 속도?" → Instance Store.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
SAA-C03 | AWS Certified Solutions Architect - Associate exam code | AWS 솔루션스 아키텍트 어소시에이트 시험 |
EBS | Elastic Block Store | EC2에 연결하는 블록 스토리지 |
EFS | Elastic File System | 여러 EC2에서 공유 가능한 관리형 파일 시스템 |
FSx | Amazon FSx | 특정 파일 시스템을 AWS 관리형으로 제공하는 서비스 |
S3 | Simple Storage Service | 객체 스토리지 |
AZ | Availability Zone | 하나의 리전 안에 있는 독립적인 가용 영역 |
Quick Decision Table
| 요구사항 | 고를 것 |
|---|---|
| EC2에 붙는 영구 블록 스토리지 | Amazon EBS |
| 여러 EC2가 동시에 공유하는 Linux 파일 시스템 | Amazon EFS |
| Windows 파일 공유, SMB, Active Directory 연동 | Amazon FSx for Windows File Server |
| 고성능 Lustre 파일 시스템, HPC, ML, S3 연동 | Amazon FSx for Lustre |
| 객체 저장, 웹 정적 파일, 데이터 레이크, 아카이브 | Amazon S3 |
| EC2 호스트에 붙은 임시 초고속 로컬 디스크 | Instance Store |
EBS vs EFS vs FSx vs Instance Store
| 구분 | EBS | EFS | FSx | Instance Store |
|---|---|---|---|---|
| 스토리지 유형 | Block | File | File | Local block |
| 대표 연결 대상 | EC2 한 대 | 여러 EC2 | 여러 클라이언트/EC2 | 특정 EC2 인스턴스 |
| 지속성 | 유지 | 유지 | 유지 | 임시 |
| 범위 | 단일 AZ | Regional/Multi-AZ | 파일 시스템 종류에 따라 다름 | EC2 호스트 로컬 |
| 공유 | 기본적으로 아님 | 가능 | 가능 | 아님 |
| 백업/복구 | Snapshot | Backup/replication | Backup 지원 | 직접 설계 |
| 대표 키워드 | boot volume, DB, block | shared Linux file system, NFS | Windows SMB, Lustre, NetApp ONTAP, OpenZFS | cache, buffer, temporary data |
핵심 결정 뉘앙스 (빈출)
표만으로 안 갈리는, 시험이 파고드는 지점들:
- EBS는 단일 AZ에 묶인다 → 다른 AZ로 옮기거나 백업하려면 Snapshot(S3에 저장) 후 재생성. "AZ 장애에도 볼륨 데이터 보존" = Snapshot.
- 여러 EC2가 하나의 블록 볼륨 공유 필요 → EBS Multi-Attach(io1/io2, 같은 AZ·클러스터 파일시스템 한정). 다만 범용 공유는 보통 EFS가 정답.
- EBS 타입 선택: 일반적으론 gp3(비용/성능 균형), 초고 IOPS DB는 io2 Block Express, 대용량 순차 처리(빅데이터/로그)는 st1(HDD).
- EFS는 리전 서비스(Multi-AZ 자동) → 고가용 공유 파일시스템의 기본. 단일 AZ로 비용 절감하려면 EFS One Zone.
- FSx는 "특정 파일시스템"을 관리형으로 제공 → Windows SMB=FSx for Windows, HPC/ML 고성능=FSx for Lustre(S3 연동), NAS 기능=NetApp ONTAP, ZFS=OpenZFS.
- S3 vs EFS 혼동 주의: S3는 파일시스템이 아니다(마운트해 랜덤 쓰기 X, HTTP API 접근). "레거시 앱이 POSIX 파일시스템을 마운트" = EFS/FSx, "정적 자산·데이터 레이크·아카이브" = S3.
- Instance Store는 stop/종료 시 소멸 → DB·상태 데이터 금지. 캐시·스크래치·셔플 영역처럼 재생성 가능한 데이터에만.
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "block storage attached to EC2" | EBS |
| "persistent boot volume" | EBS |
| "high IOPS database on EC2" | EBS io2 |
| "shared file system for multiple Linux EC2 instances" | EFS |
| "NFS" | EFS |
| "Windows file share" | FSx for Windows File Server |
| "SMB protocol" | FSx for Windows File Server |
| "HPC, machine learning, high performance file system" | FSx for Lustre |
| "temporary cache or buffer" | Instance Store |
| "data must survive instance stop" | EBS, not Instance Store |
| "object storage or static website" | S3 |
Common Wrong Directions
| 상황 | 헷갈리는 오답 | 정리 |
|---|---|---|
| 여러 EC2가 파일을 공유해야 함 | EBS | 보통 EFS 또는 FSx |
| Windows SMB 파일 공유 | EFS | EFS는 Linux/NFS 계열, Windows SMB는 FSx for Windows |
| EC2 stop 후 데이터 유지 필요 | Instance Store | Instance Store는 임시 데이터용 |
| 객체를 장기 보관 | EBS/EFS | 객체 저장과 아카이브는 보통 S3 |
| 고성능 임시 scratch space | EBS만 고려 | Instance Store가 더 적합할 수 있음 |
Memory Sentence
EC2 한 대의 디스크는 EBS, 여러 Linux EC2 공유 파일은 EFS, Windows/Lustre 같은 특수 파일 시스템은 FSx, 임시 로컬 초고속 저장은 Instance Store.
Notes To Expand
댓글
아직 댓글이 없습니다.