AWS EC2 인스턴스를 프로비저닝할 때 스토리지 선택을 대충 넘기는 경우가 많습니다. 저도 초반에는 그냥 EBS 붙이면 되는 거 아닌가 싶었는데, 실제로 고성능 워크로드를 다루다 보니 스토리지 아키텍처 하나가 전체 시스템 성능과 비용을 완전히 바꿔놓는다는 걸 체감했습니다. 오늘은 EBS와 인스턴스 스토어의 기술적 차이와 실무에서 어떻게 조합해야 하는지 정리해 보겠습니다.
1. 두 스토리지, 근본적으로 무엇이 다른가
가장 핵심적인 차이는 컴퓨팅 노드와 스토리지가 물리적으로 어디에 위치해 있느냐입니다.
Amazon EBS는 EC2 인스턴스가 구동되는 물리 호스트와 완전히 분리된 별도의 스토리지 영역 네트워크(SAN)에 존재합니다. AWS Nitro System의 전용 가상 네트워크 가속 아키텍처를 통해 컴퓨팅 노드와 연결되는 구조입니다. 인스턴스 수명 주기와 무관하게 데이터가 영구 보존되고 독립적인 볼륨 관리가 가능한 이유가 여기에 있습니다.
인스턴스 스토어는 EC2 인스턴스가 호스팅되는 물리 서버 내부에 직접 장착된 NVMe/SSD 드라이브입니다. 네트워크 가상화 레이어를 거치지 않고 호스트 버스 인터페이스에 직접 연결되기 때문에 가상화 환경에서 도달할 수 있는 극단적인 I/O 속도와 최소한의 레이턴시를 제공합니다. 단, 그 물리 서버를 벗어나는 순간 데이터는 사라집니다.
| 비교 항목 | Amazon EBS | 인스턴스 스토어 |
|---|---|---|
| 물리적 위치 | 네트워크 연결형 블록 스토리지 (SAN) | 호스트 서버 내부 장착 드라이브 (로컬 DAS) |
| 데이터 영구성 | 인스턴스 종료 후에도 유지 가능 | 종료, 중지, 하드웨어 장애 시 데이터 소멸 |
| I/O 레이턴시 | 밀리초(ms) 단위 | 마이크로초(μs) 단위 |
| 최대 IOPS | io2 Block Express 기준 최대 256,000 IOPS | 인스턴스 유형별 물리 한계 (수백만 IOPS) |
| 스냅샷 지원 | S3 네이티브 스냅샷 지원 | 네이티브 백업 없음 (OS 레벨 수동 복제 필요) |
| 볼륨 크기 조정 | 실시간 확장 가능 (Elastic Volumes) | 인스턴스 타입에 고정, 임의 확장 불가 |
2. 인스턴스 스토어의 휘발성, 정확히 언제 데이터가 사라지나
현장에서 가장 많이 실수하는 부분입니다. 저도 초반에 Stop 후 Start했다가 데이터가 통째로 날아간 경험이 있습니다. 운영 상황별로 정확히 정리해 두는 게 중요합니다.
[운영 상황별 데이터 보존 여부]
상황 1: OS 내부 소프트웨어 재부팅 (Reboot)
- Amazon EBS: 데이터 보존
- 인스턴스 스토어: 데이터 보존
상황 2: 인스턴스 중지 후 재시작 (Stop & Start)
- Amazon EBS: 데이터 보존 (새로운 호스트에 볼륨 재연결)
- 인스턴스 스토어: 데이터 완전 소멸 (호스트 변경으로 물리적 분리)
상황 3: 물리 호스트 장애 발생
- Amazon EBS: 안전하게 보존 (타 호스트로 볼륨 이동 가능)
- 인스턴스 스토어: 물리 하드웨어와 함께 복구 불가
재부팅은 살아남지만 Stop & Start는 데이터가 사라진다는 점이 핵심입니다. 인스턴스를 중지하면 AWS가 물리 호스트를 바꿔버리기 때문입니다. 이 구조를 이해하지 못한 채 인스턴스 스토어에 중요 데이터를 올려놓으면 아키텍처적 재앙이 됩니다.
3. 현장에서 자주 받는 질문들
Q. 인스턴스 스토어를 쓰는 인스턴스는 왜 중지(Stop) 버튼이 비활성화되어 있나요?
인스턴스를 중지하면 AWS가 물리 호스트 자원을 반납하고 재시작 시 다른 호스트에 배정합니다. 인스턴스 스토어는 이전 호스트의 물리 디스크에 바인딩되어 있어 중지 시 데이터 연속성을 유지할 수 없습니다. 그래서 인스턴스 스토어만 전용으로 쓰는 일부 구형 인스턴스 타입은 중지를 지원하지 않고 종료(Terminate)만 가능합니다.
Q. EBS 최적화(EBS Optimized)가 정확히 무엇인가요?
EC2 인스턴스가 일반 네트워크 트래픽과 EBS I/O 트래픽을 같은 NIC으로 공유하면 대규모 데이터 전송 시 상호 병목이 생깁니다. EBS 최적화 인스턴스는 EBS 전용 네트워크 채널을 물리적으로 격리해서 요금표에 명시된 최대 처리량과 IOPS를 온전히 보장하는 구조입니다. 요즘 출시되는 인스턴스 타입은 대부분 기본으로 활성화되어 있습니다.
Q. 인스턴스 스토어의 성능을 활용하면서도 가용성을 확보하는 방법이 있나요?
MongoDB, Cassandra, Elasticsearch 같이 애플리케이션 프레임워크 자체에서 샤딩 기반 복제를 지원하는 분산 시스템에서 주로 활용합니다. 개별 노드는 인스턴스 스토어의 초고속 성능을 쓰되, 노드 하나가 물리 장애로 날아가면 나머지 노드에서 데이터를 실시간 동기화하는 방식으로 소프트웨어 레이어에서 인프라 취약점을 커버합니다.
Q. gp3와 io2는 어떤 기준으로 선택하나요?
gp3는 볼륨 크기와 무관하게 기본 3,000 IOPS와 125MB/s 처리량을 제공하는 범용 SSD입니다. 비용 대비 성능이 좋아서 대부분의 일반 워크로드에 적합합니다. io2는 99.999% 볼륨 내구성을 보장하는 엔터프라이즈 핵심 DB용 고성능 SSD입니다. 서브 밀리초 레이턴시가 필수인 미션 크리티컬 워크로드에서만 io2를 선택하는 게 비용 낭비 없는 선택입니다.
Q. EBS 스냅샷은 찍을 때마다 전체 용량이 과금되나요?
첫 스냅샷만 전체 데이터 블록을 S3에 복제해서 전체 크기만큼 과금됩니다. 이후 스냅샷은 직전 이후 변경되거나 추가된 블록만 추적해서 저장하는 증분(Incremental) 방식이라 비용이 획기적으로 줄어듭니다. 주기적인 스냅샷을 부담 없이 운영할 수 있는 이유입니다.
Q. 가동 중인 EBS 볼륨 크기를 늘릴 때 다운타임이 발생하나요?
Elastic Volumes를 지원하는 인스턴스와 볼륨 유형(gp2, gp3, io1, io2 등)이라면 서비스 중단 없이 실시간으로 크기와 IOPS를 변경할 수 있습니다. AWS 콘솔이나 CLI에서 볼륨 설정 변경 후 OS 내부에서 resize2fs 또는 xfs_growfs 명령으로 파일 시스템이 확장을 인식하게 해주면 끝납니다. 직접 여러 번 해봤는데 서비스 영향 없이 깔끔하게 됩니다.
Q. 대용량 로그 수집 서버의 버퍼 디스크는 어떤 스토리지가 적합한가요?
인스턴스 스토어가 최적입니다. S3나 데이터 웨어하우스로 전송하기 전 수 분에서 수 시간 임시 보관하는 스테이징 버퍼는 높은 쓰기 처리량이 필요합니다. EBS로 처리하면 IOPS와 프로비저닝 비용이 추가되지만, 인스턴스 스토어가 포함된 인스턴스 타입을 쓰면 추가 비용 없이 고속 I/O 버퍼를 확보할 수 있습니다.
마무리
EBS와 인스턴스 스토어는 어느 것이 더 낫다기보다 계층형으로 함께 써야 하는 구조입니다.
부트 디스크, 애플리케이션 코어, 메인 RDB처럼 영속성과 상태 유지가 필요한 레이어는 EBS를 기반으로 안정성을 확보하고, 인메모리 캐시 스왑 공간, 분산 파일 시스템 데이터 노드, 임시 배치 가공 데이터처럼 초고속 I/O가 필요한 레이어는 인스턴스 스토어를 전면 배치하는 것이 비용과 성능을 동시에 잡는 현실적인 설계입니다.