인스턴스 스토어와 EBS 차이, 서버를 멈추면 사라지는 디스크는 언제 쓸까
EC2 인스턴스 유형 목록을 보다 보면 m5.large 옆에 m5d.large처럼 이름에 "d"가 붙은 유형이 있습니다. 이 유형은 인스턴스 스토어라는 로컬 디스크가 함께 딸려 나옵니다. 가격 차이가 크지 않고 디스크가 빠르다고 해서 아무 데나 쓰면, 서버를 한 번 중지했다가 시작하는 순간 데이터가 사라지는 일을 겪을 수 있습니다.
인스턴스 스토어와 EBS는 둘 다 EC2에 붙는 블록 스토리지이지만, 데이터가 어디에 있고 언제까지 남는지가 완전히 다릅니다. 이 차이를 알면 어떤 데이터를 어디에 두어야 하는지 쉽게 정할 수 있습니다.
이 글에서는 두 스토리지의 구조 차이, 인스턴스 스토어의 데이터가 사라지는 경우, 비용 비교, 그리고 알맞은 사용 사례를 정리합니다.
디스크가 있는 위치가 다릅니다
인스턴스 스토어는 인스턴스가 실행되는 물리 서버(호스트)에 직접 붙어 있는 디스크입니다. 반면 EBS는 네트워크로 연결되는 별도의 볼륨이라, 인스턴스와 따로 존재합니다.
| 구분 | 인스턴스 스토어 | EBS |
|---|---|---|
| 위치 | 호스트 서버에 직접 연결 | 네트워크로 연결되는 독립 볼륨 |
| 데이터 수명 | 인스턴스 수명과 같음(임시) | 인스턴스와 별도로 유지 |
| 분리·재연결 | 불가 | 다른 인스턴스에 다시 연결 가능 |
| 스냅샷 | 지원하지 않음 | 지원 |
| 요금 | 인스턴스 요금에 포함 | 볼륨 크기·성능에 따라 별도 |
| 사용 가능 유형 | 일부 유형만(이름에 d가 붙은 유형 등) | 대부분의 유형 |
데이터가 사라지는 경우와 남는 경우
| 상황 | 인스턴스 스토어 데이터 |
|---|---|
| 운영체제 재부팅 | 남음 |
| 인스턴스 중지 또는 최대 절전 | 사라짐 |
| 인스턴스 종료 | 사라짐 |
| 디스크 또는 호스트 장애 | 사라짐 |
중지 후 시작하면 인스턴스가 다른 호스트로 옮겨질 수 있기 때문에, 원래 호스트의 디스크에 있던 데이터는 따라오지 않습니다. 비용을 아끼려고 밤에 서버를 중지하는 스크립트를 쓰고 있다면, 인스턴스 스토어에 둔 데이터는 매일 사라진다는 뜻입니다.
비용은 어떻게 비교할까
버지니아 북부 Linux 온디맨드 기준으로 m5.large는 시간당 0.096달러, 75GB NVMe SSD 인스턴스 스토어가 딸린 m5d.large는 시간당 0.113달러입니다. 차이는 시간당 0.017달러, 한 달 730시간이면 약 12.41달러입니다.
같은 75GB를 EBS gp3로 붙이면 GB당 월 0.08달러로 월 6.00달러입니다. 용량 단가만 보면 EBS가 싸지만, 인스턴스 스토어는 호스트에 직접 붙은 NVMe SSD라 지연이 짧고 처리량이 높으며 입출력 횟수에 따른 추가 요금이 없습니다. 그래서 단가가 아니라 "사라져도 되는 데이터를 빠르게 처리해야 하는가"를 기준으로 고르는 것이 맞습니다.
인스턴스 스토어가 잘 맞는 데이터
- 캐시와 임시 파일 — 원본은 다른 곳에 있고, 사라지면 다시 만들면 되는 데이터입니다.
- 처리 중간 결과 — 대용량 데이터를 정렬하거나 변환할 때 쓰는 작업 공간(스크래치)입니다. 최종 결과만 S3나 EBS에 저장합니다.
- 여러 서버에 복제되는 데이터 — 분산 데이터베이스나 검색 엔진처럼 데이터가 여러 노드에 복제되어 한 노드가 사라져도 복구되는 구조라면 빠른 로컬 디스크의 장점을 살릴 수 있습니다.
반대로 데이터베이스 원본 파일, 업로드 파일, 설정 파일처럼 하나뿐인 데이터는 인스턴스 스토어에 두면 안 됩니다. 이런 데이터는 EBS에 두고 스냅샷으로 백업합니다.
인스턴스 스토어가 있는 유형 찾기와 준비
모든 인스턴스 유형에 인스턴스 스토어가 있는 것은 아닙니다. 이름에 d가 붙은 범용·컴퓨팅·메모리 최적화 유형(m5d, c6gd, r6id 등)과 I 계열 같은 스토리지 최적화 유형에 주로 딸려 있습니다. EC2 콘솔의 인스턴스 유형 화면에서 인스턴스 스토리지 열을 보거나, AWS CLI에서 다음처럼 조회할 수 있습니다.
aws ec2 describe-instance-types --filters Name=instance-storage-supported,Values=true --query "InstanceTypes[].InstanceType"
인스턴스 스토어는 시작할 때마다 빈 디스크이므로, 쓰기 전에 파일 시스템을 만들고 마운트하는 작업을 시작 스크립트로 자동화해 두는 것이 좋습니다.
| 순서 | 할 일 | 주의 |
|---|---|---|
| 1 | lsblk로 장치 이름 확인 |
NVMe 장치 번호는 유형과 붙은 순서에 따라 다름 |
| 2 | 파일 시스템 만들기(예: XFS) | EBS 루트 장치를 고르지 않도록 크기로 구분 |
| 3 | 캐시·임시 폴더로 마운트 | 재시작할 때마다 다시 실행되게 설정 |
애플리케이션은 이 폴더가 비어 있어도 정상적으로 시작되도록 만들어야 합니다. 캐시가 없으면 원본에서 다시 채우고, 작업 파일이 없으면 처음부터 다시 만드는 식으로 "사라져도 되는 데이터"라는 전제를 코드에도 반영하는 것이 핵심입니다.
인스턴스 스토어에서 자주 묻는 것
인스턴스 스토어는 따로 설정해야 쓸 수 있나요?
Linux에서는 NVMe 장치로 보이므로 파일 시스템을 만들고 마운트해야 합니다. 인스턴스를 중지 후 시작하면 빈 디스크로 다시 붙으므로, 시작할 때마다 포맷과 마운트를 자동으로 하도록 설정해 두면 편합니다.
인스턴스 스토어 데이터를 백업할 수 있나요?
스냅샷 기능이 없으므로 필요한 데이터는 애플리케이션에서 S3나 EBS로 직접 복사해야 합니다. 백업이 필요할 정도로 중요한 데이터라면 애초에 EBS에 두는 것이 낫습니다.
인스턴스 크기를 바꾸면 인스턴스 스토어는 어떻게 되나요?
유형 변경은 중지 후 시작이 필요하므로 기존 인스턴스 스토어의 데이터는 사라집니다. 새 유형에 딸린 인스턴스 스토어의 개수와 크기도 달라질 수 있습니다.
데이터 종류별로 어디에 둘까 — 결정표
인스턴스 스토어는 빠르지만 사라지고, EBS는 남지만 요금이 붙습니다(서울 리전 gp3 GB-월 0.0912달러, 100GB면 9.12달러). 데이터 종류별로 자리를 정하는 표입니다.
| 데이터 | 두는 곳 | 이유 |
| 운영체제·애플리케이션 파일 | EBS (루트 볼륨) | 재부팅·중지 뒤에도 남아야 함 |
| 데이터베이스 데이터 파일 | EBS gp3·io2 | 손실 불가, 스냅샷 백업 필요 |
| 임시 파일·캐시·중간 계산 결과 | 인스턴스 스토어 | 사라져도 다시 만들 수 있고, 로컬 NVMe가 가장 빠름 |
| 분산 데이터베이스의 복제본 (Cassandra·Kafka 등) | 인스턴스 스토어 + 복제 3개 이상 | 노드 하나가 사라져도 다른 복제본이 있음 |
| 로그 (수집 전) | 인스턴스 스토어 → 즉시 S3·CloudWatch로 전송 | 서버에 오래 두지 않음 |
| 여러 서버가 공유하는 파일 | EFS 또는 S3 | 둘 다 한 서버에 묶이지 않음 |
인스턴스 스토어가 포함된 유형(이름에 d가 붙은 m7gd·c7gd 등)은 같은 크기의 EBS 전용 유형보다 시간당 요금이 조금 높지만 디스크 요금이 따로 없으므로, 수백 GB의 임시 공간이 필요한 서버는 EBS를 크게 붙이는 것보다 d 유형이 싼 경우가 많습니다. 세 번째 줄과 네 번째 줄에 해당하지 않는 데이터를 인스턴스 스토어에 두는 것만 피하면 됩니다.
정리
인스턴스 스토어는 호스트에 직접 붙은 임시 디스크로 재부팅에는 데이터가 남지만, 중지·최대 절전·종료·장애 때는 사라집니다. 요금은 인스턴스에 포함되며, m5.large와 m5d.large의 차이는 월 약 12.41달러입니다. 캐시·임시 파일·복제되는 데이터에는 인스턴스 스토어를, 하나뿐인 원본 데이터에는 EBS와 스냅샷을 쓰는 것이 기본 원칙입니다.
함께 읽으면 좋은 글: EC2 인스턴스 유형 이름 읽는 법 / EBS 스냅샷과 AWS Backup 차이
참고 자료: 인스턴스 스토어 볼륨, Amazon EC2 인스턴스 스토어, Amazon EC2 온디맨드 요금
※ 본 글은 2026년 10월 기준 Amazon EC2 사용 설명서와 요금 페이지를 참고해 작성했으며, 인스턴스 유형별 스토리지 구성과 요금은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.