EFS vs EBS vs S3: AWS 스토리지 선택 기준
AWS 스토리지 문서를 열면 EBS, EFS, S3가 나란히 나오지만, 셋은 같은 용도를 두고 경쟁하는 서비스가 아닙니다. 인스턴스 하나에 붙는 디스크는 EBS, 여러 인스턴스가 동시에 마운트하는 공유 파일시스템은 EFS, 애플리케이션 밖에서 파일을 저장하고 꺼내는 객체 저장소는 S3입니다. 접근 모델이 다르므로 대부분의 시스템은 셋을 함께 씁니다. 고민이 생기는 지점은 경계에 걸친 워크로드이고, 이 글은 그 경계를 요금과 함께 정리합니다. 요금은 us-east-1 기준입니다.
한눈에 보는 비교 #
| 구분 | EBS (gp3) | EFS (Standard) | S3 (Standard) |
|---|---|---|---|
| 타입 | 블록 스토리지 | 파일 스토리지 (NFS) | 객체 스토리지 (HTTP API) |
| 접근 | 인스턴스 1대에 연결 | 수백〜수천 대 동시 마운트 | 어디서나 API 호출 |
| 범위 | 단일 AZ | 리전 (멀티 AZ) | 리전 (멀티 AZ) |
| 지연 | 밀리초 미만 | 밀리초대 | 수십 밀리초 (첫 바이트) |
| 용량 | 프로비저닝 (최대 64TiB) | 자동 확장 | 사실상 무제한 |
| GB·월당 단가 | 약 $0.08 | 약 $0.30 | 약 $0.023 |
접근 모델: 디스크인가, 공유 폴더인가, API인가 #
EBS는 인스턴스에 붙이는 디스크입니다. OS가 블록 디바이스로 인식하므로 파일시스템을 얹어 부팅 볼륨, 데이터베이스 데이터 디렉터리처럼 씁니다. 지연이 밀리초 미만으로 셋 중 가장 낮고 IOPS를 스펙으로 보장받을 수 있어, 랜덤 I/O가 많은 데이터베이스는 사실상 EBS 외의 선택지가 없습니다. 제약은 연결 범위입니다. 볼륨은 단일 AZ에 있고 기본적으로 인스턴스 1대에만 붙습니다(io1·io2의 Multi-Attach가 예외지만 클러스터 파일시스템을 요구하는 특수 구성입니다). 볼륨 타입 선택은 gp3 vs io2에서 다뤘습니다.
EFS는 NFS로 마운트하는 공유 파일시스템입니다. 수백〜수천 대의 인스턴스, 컨테이너, Lambda가 같은 경로를 동시에 마운트하고, 용량은 쓰는 만큼 자동으로 늘어납니다. Standard 클래스는 멀티 AZ라 AZ 장애에도 살아남습니다. 웹 서버 여러 대가 공유하는 업로드 디렉터리, 여러 태스크가 같은 모델 파일을 읽는 ML 서빙, 리프트 앤 시프트로 옮겨 온 NFS 의존 레거시가 전형적인 사용처입니다.
S3는 HTTP API로 넣고 꺼내는 객체 저장소입니다. 마운트하는 것이 아니라 PUT과 GET을 호출합니다. 파일 일부만 수정하는 것은 불가능하고 객체 전체를 다시 올려야 하며, 첫 바이트까지 수십 밀리초가 걸립니다. 대신 용량이 사실상 무제한이고, 99.999999999%(일레븐 나인) 내구성에, 정적 웹 호스팅과 버전 관리, 수명 주기 정책까지 붙어 있습니다. 백업, 로그, 이미지·동영상, 데이터 레이크처럼 “쓰고 나서 통째로 읽는” 데이터의 기본값입니다.
요금: 단가만 보면 틀리고, 과금 방식까지 봐야 맞습니다 #
GB·월당 단가는 S3 $0.023, EBS gp3 $0.08, EFS Standard $0.30 순으로, EFS는 gp3의 약 4배, S3의 13배입니다. 하지만 과금 방식이 달라 단가 비교만으로는 결론이 안 납니다.
- EBS는 프로비저닝한 만큼 나갑니다. 500GB를 잡고 100GB만 쓰면 500GB 요금입니다. gp3는 3,000 IOPS와 125MB/s가 기본 포함이라 추가 성능을 안 사면 저 단가가 전부입니다.
- EFS는 저장한 만큼 나가되, Elastic Throughput 기준으로 읽기 GB당 약 $0.03, 쓰기 GB당 약 $0.06의 처리량 요금이 별도로 붙습니다. 데이터를 자주 읽고 쓰는 파일시스템이라면 저장 요금보다 처리량 요금이 커질 수 있습니다. 대신 수명 주기 정책으로 안 쓰는 파일을 IA(GB당 약 $0.016), Archive(약 $0.008)로 내리면 저장 단가가 gp3 아래로 내려가고, 단일 AZ로 충분하면 One Zone(약 $0.16)도 있습니다.
- S3는 저장한 만큼 + 요청 수만큼 나갑니다. PUT 1,000건당 약 $0.005, GET 1,000건당 약 $0.0004입니다. 대용량 저장에는 압도적으로 싸지만, 작은 파일 수백만 개를 자주 만지는 패턴이면 요청 요금이 저장 요금을 넘어섭니다. 접근 빈도별 클래스 선택은 S3 스토리지 클래스 비교에서 다뤘습니다.
흔한 과잉 설계와 함정 #
- 공유가 필요 없는데 EFS: 인스턴스 1대만 쓰는 데이터를 EFS에 두면 gp3의 4배 단가에 처리량 요금까지 내는 셈입니다. 공유 요구가 실제로 생길 때 옮겨도 늦지 않습니다.
- S3를 파일시스템처럼: Mountpoint for S3로 마운트할 수는 있지만 순차 읽기·쓰기 중심의 도구이고, 파일 일부 수정과 잠금 같은 POSIX 동작은 지원되지 않습니다. 파일시스템 의미론이 필요하면 EFS를 써야 합니다.
- 데이터베이스를 EFS에: 밀리초대 지연과 NFS 의미론은 데이터베이스의 랜덤 I/O와 상성이 나쁩니다. 데이터 디렉터리는 EBS에 두는 것이 기본입니다.
- 스냅샷과 고아 볼륨: EBS 스냅샷은 S3 기반 저장(GB·월당 약 $0.05)에 쌓이고, 인스턴스를 지워도 볼륨과 스냅샷은 남아 과금됩니다. 상시 점검 목록에서 다룬 대표 누수 항목입니다.
선택 순서 #
- 접근 모델부터 정합니다: OS가 디스크로 봐야 하면 EBS, 여러 컴퓨팅이 같은 파일 트리를 마운트해야 하면 EFS, API로 넣고 꺼내면 되는 데이터면 S3입니다. 여기서 대부분 끝납니다.
- 공유 요구를 검증합니다: EFS를 고르기 전에 “정말 여러 대가 동시에 같은 경로를 써야 하는지"를 묻습니다. 아니라면 EBS나 S3로 내려옵니다.
- 지연 요구를 확인합니다: 밀리초 미만이 필요하면 EBS뿐입니다. 수십 밀리초가 허용되면 S3까지 열립니다.
- 비용은 과금 방식대로 계산합니다: EBS는 프로비저닝 용량, EFS는 저장 + 처리량, S3는 저장 + 요청으로 각각 계산해야 실제 청구서가 나옵니다.
- 수명 주기를 설계합니다: EFS는 IA·Archive로, S3는 클래스 전환으로 오래된 데이터의 단가를 내립니다. EBS는 안 쓰는 볼륨·스냅샷 정리가 수명 주기 관리의 전부입니다.
정리 #
- 인스턴스 1대의 디스크는 EBS, 여러 대가 공유하는 파일시스템은 EFS, API로 접근하는 객체는 S3입니다. 셋은 경쟁이 아니라 분업 관계입니다.
- 단가는 S3 $0.023, gp3 $0.08, EFS $0.30으로 13배까지 벌어지지만, 과금 방식(프로비저닝, 저장+처리량, 저장+요청)이 달라 단가만으로는 비교가 안 됩니다.
- EFS의 처리량 요금(읽기 $0.03, 쓰기 $0.06)은 자주 잊히는 항목입니다. I/O가 많으면 저장 요금을 넘습니다.
- 가장 흔한 과잉 설계는 공유가 필요 없는 데이터를 EFS에 두는 것입니다. 공유 요구가 실제로 있는지부터 검증합니다.
- 데이터베이스는 EBS, 업로드·모델 공유는 EFS, 백업·로그·정적 파일은 S3라는 기본 배치에서 출발해 예외를 검증하는 순서가 빠릅니다.