개요
EC2 관련 작업을 도맡으면서 서버 운영을 위해서는 Storage 개념을 잘 이해하고 있어야 한다는 점을 알게되었다. 운영 관점에서 고려해보니 루트 볼륨, 이퍼머럴 스토리지, 부팅 디스크 등등 여러 용어를 잘 알고 정리해두어야겠다는 생각이 들어 포스팅함!
1. EC2 Storage: EBS와 Instance Store
EC2에 연결할 수 있는 스토리지는 크게 다음과 같다. 이 포스팅에서는 EBS, Instance Store를 중점적으로 알아보려고 한다.
EC2 스토리지
├── * EBS (Elastic Block Store)
│ ├── 루트 볼륨 (부팅용)
│ └── 추가 볼륨 (데이터용)
│
├── * Instance Store (Ephemeral / Local Storage)
│
└── EFS (Elastic File System)
EBS와 Instance Store를 직관적으로 이해할 수 있는 이미지는 다음과 같은데.. 하나씩 살펴보자.

2. EBS(Elastic Block Store)
2.1 Block Store

블록 단위로 데이터를 저장하는 스토리지 방식으로, SAN(Storage Area Network)나 클라우드 기반 스토리지 환경에서 사용되는 기술이다.
- 데이터를 일정한 크기의 블록으로 나누고, 각 블록에는 고유 주소가 부여된다.
- 이 식별자를 통해서 데이터를 매우 빠르게 검색할 수 있다.
- 빠른 성능에 최적화되어있기에 다른 스토리지에 비해 비쌈!
2.2 Elastic Block Store
EC2에 연결하여 사용하는 블록 스토리지로, EC2 Instance와 독립적으로 데이터 유지가 가능하다.
- EC2 Instance와 네트워크로 연결되어, 독립적으로 구성되므로 인스턴스 종료 후에도 데이터가 보존된다.
- 하나의 EC2 Instance에 여러 용도의 EBS를 붙일 수 있다.
- 단, 속도를 위해 동일한 가용영역 내의 EC2만 연결이 가능하다.
- 거꾸로, 하나의 EBS를 여러 EC2에 장착 가능하다. (EBS Multi Attach)
2.3 루트 볼륨/부팅 디스크
EC2 Instance를 생성하면 EBS가 루트 볼륨으로 설정된다.
루트 볼륨의 역할

EC2 Instance에 설정할 수 있는 루트 볼륨
EC2 Instance의 루트 볼륨은 EBS, Instance Store 모두 가능하다. (관련 문서)
문서에 따르면 두 가지 AMI에 따라 달라지는데, 우리가 쓰는 거의 모든 AMI는 루트 볼륨을 EBS로 생성한다.

- Instance Store를 루트 볼륨으로 사용하는 건, AMI 이미지 자체는 S3에 저장되어 있고 인스턴스를 띄우면 S3 템플릿을 기반으로ㅓ Ec2에 연결된 로컬 디스크를 사용하는 것이다. Instance Store는 인스턴스 내부에 위치한 저장소이므로, Instance가 다운되면 같이 정보가 날아간다. 따라서 Instance Store를 루트 볼륨으로 둔 인스턴스는 시작, 중지가 불가능하다.
- 현재는 Deprecated! 즉, 거의 대부분의 AMI로 EC2를 생성하면, Root Volume은 EBS다.
2.5 EBS 볼륨 유형 타입
EBS 볼륨 타입은 일반 컴퓨터에서 SSD를 쓸지, HDD를 쓸지 고르는 것과 비슷한데, AWS는 용도별로 세분화해서 제공한다.
- SSD: gp3, gp2, io2, io1
- gp 계열은 웹서버, 개발환경, 소규모 DB에 사용하고 가격 대비 성능 균형이 좋아서 보편적으로 사용하는 타입이다. io 계열은 대규모 DB가 필요할 때 사용하고 IOPS를 직접 지정할 수 있다.
- HDD: st1, sc1
3. Instance Store
3.1 Instance Store
Instance Store는 EBS처럼 붙였다 떼었다 하는 것이 아니라, 인스턴스 타입 자체에 물리적으로 포함되어 있다. Amazon에서는 인스턴스 유형으로 EC2에 Instance Store가 포함되었는지, 아닌지 구분한다.
- Instance Store를 지원하는 인스턴스 유형: 'd' suffix가 붙는다. (관련 문서)

3.2 Instance Store, Ephemeral Storage, Local Storage
Instance Store는 상황에 따라 다른 이름으로 불리기도 한다.
- Local Storage: 네트워크가 아닌 물리적 서버로 붙어있는 것
- Ephemeral Storage: 인스턴스가 종료될 때 사라지는 임시 스토리지 (↔ EBS는 인스턴스가 다운되어도 영구 저장됨.)
🔖 실제 운영에서 알게된 Local Storage 관련 지식
온콜을 하면서 알게된 건데.. kubelet의 Disk Pressure는 특정 컨테이너의 Instance Local Storage 점유로 인해서 발생할 수 있다. 특정 파드의 노드 로컬 스토리지 점유를 막기 위해서 아래와 같은 정책을 적용할 수 있다.
resources:
limits:
ephemeral-storage: 10Gi
requests:
ephemeral-storage: "0"
해당 정책으로 죽은 Pod는 ContainerStatusUnknown 또는 Failed 상태를 보인다. (Pod ephemeral local storage usage exceeds the total limit of containers 와 같은 메시지도 참고할 수 있다.)
3.3 Instance Storage가 유용한 경우
로컬 스토리지는 날아가도 되지만 속도가 중요한 데이터에 사용한다. (로컬 캐시와 같은...)
- Kafka Broker
- 메시지 쓰기/읽기가 초당 수십만건: 속도 필요
- 카프카는 여러 복제본(3대)를 유지하기 때문에 1대가 죽어도 데이터는 그대로!
- Spark/EMR
- 여러 Stage 간 데이터를 주고 받을 때, Shuffle 데이터를 Instance Store에 저장
- 대략 이런 구조임: [Stage 1] → shuffle 데이터 → [Stage 2] → shuffle 데이터 → [Stage 3]
- 캐싱! Redis
- 로그 버퍼 (S3 전송 전 임시 저장)
- 실제 장애 상황에서 i3en.24xlarge 인스턴스를 여러 대 띄우고, Tantivy 라이브러리로 특정 필드가 존재하는 파일을 다우로드하는 케이스를 본 적 있다.
- S3로 보내기 전에 잠깐 모아두는 용도이고 주기적으로 S3로 Flush하는 방식
- ML 임시 데이터
- S3 원본 데이터를 로컬에 복사해서 학습 중 빠른 I/O를 확보
4. NVMe
용어를 알면 좋을 것같아서 추가 정리
NVMe(Non-Volatile Memory Express)
NVMe는 스토리지와 CPU 사이의 통신 방식을 정의한 인터페이스 표준으로, SSD를 빠르게 사용하기 위해 최적화된 최신 스토리지 프로토콜이다.
- NVMe 인스턴스 스토어 볼륨이 있는 인스턴스 유형의 경우 지원되는 모든 인스턴스 스토어 볼륨이 시작 시 인스턴스에 자동으로 연결된다.
- 최신 EC2(Nitro 시스템)에서는 EBS도 NVMe 인터페이스로 연결된다.
# 대략적으로 이런 구조
Instance Store: CPU ──(PCIe)──→ 물리 NVMe SSD (진짜 로컬)
EBS: CPU ──(NVMe 인터페이스)──→ 네트워크 ──→ EBS 볼륨 (원격)
↑
가상 NVMe 드라이버
정리
EC2 운영을 하려면 스토리지 선택 기준과 각 볼륨의 역할을 알아두는 게 중요한 것 같다.
- EBS vs Instance Store: 네트워크로 연결되는 영구 스토리지 vs 물리 서버에 붙은 휘발성 로컬 스토리지
- 루트 볼륨 vs 추가 볼륨: 부팅 디스크 vs 데이터 저장용 볼륨
- 부팅 디스크 역할! EC2가 시작될 때 OS를 로드하는 루트 볼륨
- Ephemeral / Local Storage: Instance Store를 부르는 다른 이름들로, 빠르지만 인스턴스 종료 시 사라지는 스토리지
- 로컬 스토리지의 역할: 캐시, 임시 데이터, shuffle 데이터 등 빠른 I/O가 필요한 용도
- NVMe: EBS와 Instance Store 모두에서 사용하는 스토리지 인터페이스 표준
또, 스토리지 용도를 잘 알고 사용하는 것
- 영구 저장이 필요한 데이터를 Instance Store에 두거나
- 반대로 빠른 I/O가 필요한 워크로드를 EBS에만 의존하거나
- 루트 볼륨과 데이터 볼륨의 역할을 명확히 나누지 않은 경우
등등..! 이제 실제 운영 환경에서 쓰인 케이스나 온콜 대응 같은걸 더 찾아보면서 학습하고, 실전에 써먹기!
'DevOps > AWS' 카테고리의 다른 글
| [DevOps] 캐시와 Redis, ElastiCache (3) | 2025.08.16 |
|---|---|
| [AWS] CloudWatch 비용 숨바꼭질 : per metric-month (0) | 2024.12.19 |
| [AWS] AWS 하나의 LB로 여러 서비스 운영하기 (0) | 2024.05.22 |
| [AWS] public & private subnet 분리로 서버 운영하기 (2) | 2024.04.07 |
| [AWS] AWS CLI 설정 및 활용하기 (0) | 2024.03.24 |