[Daily morning study] AWS 스토리지 서비스 비교: EBS, EFS, S3
in Daily morning study / Cloud
#daily morning study
AWS의 세 가지 스토리지 서비스
AWS는 목적에 따라 성격이 전혀 다른 세 가지 스토리지 서비스를 제공한다. 어떤 걸 써야 할지 모르면 비용이 낭비되거나 아키텍처가 꼬인다.
| 항목 | EBS | EFS | S3 |
|---|---|---|---|
| 유형 | 블록 스토리지 | 파일 스토리지 (NFS) | 객체 스토리지 |
| 접근 방식 | 단일 EC2 인스턴스 (기본) | 다중 EC2 인스턴스 동시 마운트 | HTTP API (REST) |
| 가용 영역 | 단일 AZ | 다중 AZ | 리전 전체 (글로벌) |
| 용량 관리 | 사전 프로비저닝 | 자동 확장 | 무제한 |
| 주요 사용처 | OS 부팅 볼륨, DB 데이터 | 공유 파일, 콘텐츠 관리 | 이미지·영상·로그·백업 |
EBS (Elastic Block Store)
EBS는 EC2 인스턴스에 붙이는 블록 디바이스다. 리눅스로 치면 /dev/xvda 같은 디스크 하나를 네트워크로 연결한 것이다.
특징
- 단일 AZ 한정: EBS 볼륨은 특정 가용 영역 안에 생성된다. 같은 AZ의 EC2만 연결 가능.
- 멀티 어태치: 기본적으로 하나의 EC2에만 연결되지만, io1/io2 타입은 Multi-Attach 기능으로 최대 16개 인스턴스에 동시 연결 가능.
- 볼륨 타입: 목적에 따라 타입을 선택한다.
| 타입 | IOPS | 용도 |
|---|---|---|
| gp3 | 최대 16,000 | 범용 (기본 선택) |
| io2 | 최대 256,000 | 고성능 DB |
| st1 | 처리량 최적화 | 순차 읽기 (로그, 빅데이터) |
| sc1 | 저비용 | 콜드 데이터 |
- 스냅샷: EBS 볼륨의 특정 시점 상태를 S3에 백업. 스냅샷 자체는 증분(incremental) 방식.
- 암호화: AWS KMS 기반 암호화를 기본 제공.
언제 쓰나
- EC2의 루트 볼륨 (OS가 부팅되는 디스크)
- MySQL, PostgreSQL 등 관계형 DB의 데이터 파일
- 랜덤 I/O 성능이 중요한 워크로드
EFS (Elastic File System)
EFS는 NFS(Network File System) 기반의 완전 관리형 파일 스토리지다. 여러 EC2 인스턴스에서 동시에 같은 파일 시스템을 마운트할 수 있다.
특징
- 완전 관리형: 용량을 미리 지정하지 않아도 된다. 데이터가 늘어나면 자동으로 확장, 줄어들면 자동으로 축소.
- 다중 AZ 지원: 기본적으로 여러 AZ에 걸쳐 분산 저장. 특정 AZ 장애가 발생해도 데이터 접근 가능.
- 마운트: EC2 콘솔에서 마운트 타겟 IP를 지정하거나, EFS 마운트 헬퍼를 통해 간단하게 연결.
# EFS 마운트 예시
sudo mount -t efs fs-12345678:/ /mnt/efs
# 또는 /etc/fstab 등록
fs-12345678:/ /mnt/efs efs defaults,_netdev 0 0
- 스토리지 클래스: 자주 접근하지 않는 파일은 EFS Infrequent Access(IA)로 자동 전환해 비용 절감.
- 퍼포먼스 모드:
- General Purpose: 지연 시간 최소화, 대부분의 워크로드에 적합
- Max I/O: 높은 처리량, 지연 시간 다소 증가 (대규모 병렬 처리)
언제 쓰나
- 여러 EC2 인스턴스가 같은 파일에 동시 접근해야 하는 경우
- 웹 서버 클러스터에서 공유 콘텐츠 디렉토리
- CMS(Content Management System) 미디어 파일 공유
- 컨테이너 환경에서 공유 볼륨 (EKS, ECS)
S3 (Simple Storage Service)
S3는 객체 스토리지다. 파일 시스템처럼 디렉토리 구조를 흉내낼 수 있지만 실제로는 키-값 구조로 저장된다.
특징
- 버킷과 객체: 버킷(bucket)이 컨테이너고, 그 안에 객체(object)를 저장. 객체 하나의 최대 크기는 5TB.
- 리전 범위: 버킷은 특정 리전에 생성되지만, 복제(CRR, Cross-Region Replication)로 다른 리전에 자동 복제 가능.
- 스토리지 클래스: 접근 패턴에 따라 비용 최적화.
| 클래스 | 특징 |
|---|---|
| S3 Standard | 기본, 자주 접근하는 데이터 |
| S3 Standard-IA | 덜 자주 접근, 검색 비용 발생 |
| S3 One Zone-IA | 단일 AZ, 더 저렴 |
| S3 Glacier Instant | 즉시 검색, 보관 용도 |
| S3 Glacier Flexible | 수 분~수 시간 검색 |
| S3 Glacier Deep Archive | 가장 저렴, 12시간 내 검색 |
- 버저닝: 같은 키로 업로드하면 기존 객체를 덮어쓰지 않고 버전 보관.
- 수명 주기 정책: 일정 기간 지난 객체를 자동으로 Glacier로 전환하거나 삭제.
- 정적 웹사이트 호스팅: HTML/CSS/JS 파일을 S3에 올리고 정적 사이트로 서빙 가능.
- 액세스 제어: IAM 정책, 버킷 정책, ACL, 퍼블릭 액세스 차단 설정으로 세밀하게 제어.
언제 쓰나
- 이미지, 동영상, 정적 파일 저장 및 CDN(CloudFront)과 연동
- 로그 파일 장기 보관
- 데이터 레이크 (S3 + Athena, Glue)
- 애플리케이션 백업 및 아카이브
- Terraform state 파일, Kubernetes etcd 백업
비교 정리
접근 방식의 차이
EBS → 하나의 EC2에 연결된 전용 디스크 (로컬 디스크처럼 사용)
EFS → NFS 프로토콜로 여러 서버가 동시 마운트 (공유 드라이브)
S3 → HTTP REST API로 어디서든 접근 (URL 기반)
성능 비교
- 지연 시간: EBS < EFS < S3
- 처리량 확장: S3 > EFS > EBS
- IOPS: EBS(io2)가 가장 높음
비용 구조
- EBS: GB당 월 요금 + IOPS 추가 요금 (gp3 기준 약 $0.08/GB)
- EFS: GB당 월 요금이 EBS보다 높지만 사용한 만큼만 지불 (Standard 약 $0.30/GB)
- S3: GB당 월 요금이 가장 저렴 (Standard 약 $0.023/GB) + 요청 건수 요금
아키텍처 선택 기준
단일 EC2의 OS/DB 디스크가 필요하다
→ EBS (gp3 기본, 고성능은 io2)
여러 서버가 파일을 공유해야 한다
→ EFS
오브젝트(이미지, 문서, 백업)를 저장하고 API로 접근한다
→ S3
비용이 중요하고 자주 접근하지 않는 데이터다
→ S3 Glacier 계열
실제로 세 가지를 함께 쓰는 경우가 많다. 예를 들어 웹 애플리케이션 서버의 루트 볼륨은 EBS, 여러 인스턴스가 공유하는 업로드 디렉토리는 EFS, 사용자가 업로드한 이미지는 S3에 올려서 CloudFront로 배포하는 식이다.
