EBS
-
한번에 하나의 인스턴스만 연결할 수 있다(multi-attach(다중 연결)가 되는 io1/io2 제외)
-
AZ(Availability Zone)에 고정됨
-
EBS의 gp2 볼륨은 디스크 크기가 증가해야 IO가 증가 BUT gp3, io1 볼륨 유형은 디스크 크기와 무관하게 IO 증가 가능
-
EBS에서 AZ간에 볼륨을 옮기려면 스냅샷을 이용해야 함
=> 스냅샷을 생성 후 다른 AZ에 복원하기
-
EBS 볼륨 백업이 IO를 사용하므로 애플리케이션이 많은 트래픽을 처리하고 있을 경우에는 실행하면 안 됨 => 성능에 영향을 줄 수 있기 때문
- EC2 인스턴스가 종료되면 기본적으로 인스턴스의 EBS 루트 볼륨도 종료됨 => 이는 설정에서 비활성화 가능
EFS
-
서로 다른 가용 영역의 수백 개의 인스턴스에 연결 가능
=> 하나의 EFS 파일 시스템으로 다른 여러 mount(탑재) 대상을 가질 수 있다
=> 여러 인스턴스가 하나의 파일 시스템을 공유할 수 있다 -
WordPress 사용시 매우 유용하고 리눅스 인스턴스에서만 사용 가능
-
가격
EFS가 EBS보다 비싼 편이지만 비용 절감을 위해 EFS-IA 활용 가능
인스턴스 스토어
물리적으로 EC2 인스턴스에 연결 => 인스턴스가 없어지면 스토리지 또한 잃음
EBS vs EFS vs EC2 인스턴스 스토어 표로 정리
| 항목 | EBS | EFS | EC2 Instance Store |
|---|---|---|---|
| 스토리지 타입 | 블록 스토리지 (디스크) | 네트워크 파일 스토리지 (NFS 파일 시스템) | 로컬 블록 스토리지 (호스트 물리 디스크) |
| 어디에 붙는지 | 특정 EC2 인스턴스에 디스크처럼 연결 | 여러 EC2 인스턴스에서 공유 마운트 | EC2 인스턴스가 올라가는 물리 서버에 직접 연결된 디스크 |
| 데이터 지속성 (인스턴스 종료 시) | 인스턴스 중지/시작, 종료 후에도 볼륨만 안 지우면 데이터 유지 | EFS는 EC2와 독립된 서비스 → 인스턴스와 상관없이 계속 유지 | 인스턴스 stop/terminate, 호스트 장애 나면 데이터 날아감 (ephemeral) |
| 수명 주기 | EC2와 느슨하게 연결됨 (EC2 죽어도 EBS는 따로 존재) | EC2랑 완전 독립 서비스 | 특정 인스턴스 + 물리 호스트와 운명 공동체 느낌 |
| 범위 (스코프) | AZ 단위 (ap-northeast-2a 같은 AZ에 귀속, 같은 AZ 인스턴스만 붙일 수 있음) | 리전 단위(Regional), 내부적으로 멀티 AZ 복제 | 단일 호스트 (같은 인스턴스 안에서만) |
| 공유 여부 | 기본은 한 인스턴스에만 연결 (일부 타입만 Multi-Attach로 여러 인스턴스 연결 가능하지만 제한적) | 여러 인스턴스에서 동시에 읽기/쓰기 공유 | 같은 인스턴스 내에서만 사용, 다른 인스턴스랑 공유 불가 |
| 성능 특성 | 저지연 블록 I/O, IOPS/Throughput 선택 가능 (gp3, io1/io2 등) | 파일 단위 처리량/동시접속에 최적화, 자동으로 처리량 확장 | 가장 빠른 스토리지 중 하나 (호스트에 직접 붙은 NVMe/SSD라서) |
| 용량 관리 | 미리 용량 프로비저닝 (예: 100GiB), 나중에 크기/IOPS 조정 가능 | 저장된 데이터 양에 따라 자동 확장/축소 (서버리스 느낌) | 인스턴스 타입이 제공하는 고정 용량 (사용자가 크기 못 바꿈) |
| 내구성/복제 | AZ 내에서 자동 복제, 스냅샷으로 S3에 백업 가능 | 기본적으로 멀티 AZ 복제, 높은 내구성 및 가용성 | 물리 디스크 – 호스트 장애 나면 데이터 손실. AWS 차원의 자동 복제 없음 |
| 백업 방법 | EBS Snapshot (시험 단골 키워드) | AWS Backup, 데이터 복제/동기화 스크립트 | 직접 EBS/S3로 복사해야 함 (스냅샷 같은 기능 없음) |
| 요금 구조 | 프로비저닝한 용량 + 성능(IOPS/Throughput) 기준 과금 | 사용한 저장 용량 + 요청량/처리량 기준 과금 (Standard/IA 등) | 인스턴스 요금에 포함된 개념 (별도 스토리지 비용 X) |
| 대표 사용 사례 | - EC2 루트 볼륨(OS) - RDS 같은 DB 직접 EC2에 설치 - 트랜잭션 많은 애플리케이션 | - 웹 서버 여러 대가 공유하는 정적 컨텐츠 - 사용자 홈 디렉토리 - 리눅스 NFS 기반 공유 스토리지 | - 캐시, 버퍼, 임시 파일 - 고성능이지만 유실돼도 되는 데이터 (예: Redis 캐시, 일시적인 스크래치 공간) |
| 지원 OS/프로토콜 | EC2 OS에서 디스크로 인식 (리눅스/윈도우 둘 다) | 리눅스 NFS(v4) 기반 (윈도우는 EFS 직접 X → FSx for Windows 사용) | EC2 내부에서 일반 디스크처럼 보임 (ext4/xfs 등) |
| 관리 난이도 | 타입/용량/IOPS 등 설계 필요 | 파일시스템 하나 만들고 마운트, 용량 자동 관리 | 사이즈/내구성 조정 불가, 데이터 날아갈 수 있어서 애플리케이션 레벨 설계 필요 |
오답노트
Q. 여러분은 기본 저장소에 대해 310,000의 IOPS를 요구하는 고성능 데이터베이스가 있습니다. 다음 중 무엇을 추천해야 할까요?
1. EC2 인스턴스 스토어 사용-
EBS gp2 드라이브 사용
-
EBS io1 드라이브 사용
4. EBS io2 Block Express 드라이브 사용
내가 고른 답: 4
정답: 1
1번을 고르지 않은 이유:
DB처럼 중요한 데이터를 인스턴스를 종료하면 날아가는 인스턴스 스토어에 사용한다고? 라고 생각함
DB 같은 “중요 데이터” → EBS(io1/io2)
Instance Store → 캐시/임시 데이터
“아니 DB를 인스턴스 스토어에 올리라고??” 라는 의문근데 이 문제는 “내구성”보다 “IOPS”라는 성능 조건에만 꽂혀 있는 문제
