EBS는 네트워크로 붙는 블록 스토리지라서 성능이 좋지만, “물리적으로 로컬 디스크(NVMe Instance Store)만큼 무제한은 아니다”
❓왜 “네트워크 드라이브 + 제한된 성능”이라고 할까?
-
네트워크 경유: EBS는 인스턴스 바깥의 스토리지 장비에 저장되고, 전용 네트워크로 블록 I/O를 주고받아요. 로컬 장치가 아니라서 추가 지연(latency)이 발생
-
볼륨 자체 한도: 각 볼륨 타입(gp3, io2, st1 등)은 IOPS/Throughput 상한이 있음 (원하는 만큼 무한히 늘지 않음)
-
인스턴스 한도: 인스턴스 타입별로 EBS 대역폭(GB/s)과 총 IOPS에 상한이 있어음 => 볼륨이 빨라도, 인스턴스가 허용하는 총량을 넘을 수 없음
-
버스트/크레딧 모델: 일부 타입은 버스트 크레딧이 있어 짧게는 빠르지만 지속 부하는 떨어질 수 있음
- 멀티테넌시: 동일 AZ 내 여러 사용자가 공유하는 인프라 위에서 돌아가므로, 일부 상황에서 변동성이 있을 수 있음(요즘은 꽤 안정적이지만 개념적으로 존재)
💡 하드웨어적인 고성능이 필요하면 EC2 인스턴스 스토어를 사용❗️
EC2 vs EC2 Instance vs EC2 Instance Store vs EBS
-
EC2: 컴퓨트 서비스 이름(플랫폼)
-
EC2 인스턴스: 그 서비스 위에서 실행되는 가상 머신(네가 띄우는 서버)
-
EC2 Instance Store: 인스턴스가 올라가는 물리 호스트에 붙은 로컬 NVMe 디스크(옵션) / 인스턴스 타입에 따라 있을 수도, 없을 수도 있음
보통 …d, i3/i4 같은 일부 인스턴스 타입이 그 로컬 디스크를 탑재 -
EBS: 네트워크로 붙는 영속 블록 스토리지(같은 AZ에 있어야 attach 가능)
EC2 Instance Store를 쓰는 이유?
-
더 나은 I/O(저장장치에 읽고/쓰는 속도와 반응성) performance를 위해
I/O Performance-
지연시간(Latency)
“한 번 읽기/쓰기 요청을 처리하는 데 걸리는 시간”(ms, µs)
낮을수록 즉각 반응. 데이터베이스 트랜잭션처럼 작고 랜덤한 작업에 중요. -
IOPS (Input/Output Operations Per Second)
"1초에 읽기 /쓰기를 몇 번 처리하나" (보통 작은 블록, 랜덤 I/O 가정)
수치가 높을수록 작은 요청을 많이 동시에 처리 가능. 키–값 저장소, OLTP DB 등에 핵심.
-
처리량/스루풋(Throughput)
“초당 몇 MB/GB를 연속으로 옮기나” (MB/s, GB/s).
큰 파일을 순차적으로 이동/처리하는 작업(ETL, 로그 압축, 영상 처리)에 중요.
-
-
왜 EC2 Instance Store가 I/O에 유리하냐?
로컬 NVMe라서 네트워크를 안 타고 바로 호스트 디스크에 접근 →
지연시간이 매우 낮고, IOPS/처리량이 크게 나옴단, 휘발성이라 중지/종료/호스트 이슈 시 데이터가 사라짐 → 캐시/임시/버퍼/스크래치 용도에 적합
=> 필요에 따라 백업이나 복제를 해두는 것이 좋다
Instance Store vs EBS
| 항목 | Instance Store(로컬 NVMe) | EBS(네트워크 블록 스토리지) |
|---|---|---|
| 지연/속도 | 매우 낮은 지연·고성능 | 좋지만 네트워크 경유 |
| 지속성 | 휘발성(중지/종료/호스트 이슈 시 소실) | 영속 |
| 관리 기능 | 스냅샷/암호화/크로스AZ 없음(직접 설계) | 스냅샷·암호화·크기조정 등 풍부 |
| 루트 볼륨 | 가능(Instance-store-backed: 정지/시작 불가) | 표준(EBS-backed: 정지/시작 가능) |
| 사용처 | 캐시/스크래치/빌드 temp, 초고 I/O | DB 데이터, 영속 파일, 일반 워크로드 |
