Amazon EC2 Instance Storage 정리
AWSEC2EBSEFSDVA-C02
작성자 : 오예환 | 작성일 : 2026-01-05 | 수정일 : 2026-01-05
1. EBS Volume 개요
🤔 EBS가 뭔가요?
비유로 이해하기: EBS는 네트워크로 연결된 USB 드라이브와 같습니다.
- 컴퓨터(EC2)에 USB(EBS)를 꽂아서 데이터를 저장
- USB를 빼서 다른 컴퓨터에 꽂을 수 있듯이, EBS도 다른 EC2에 연결 가능
- 차이점: 물리적 USB가 아니라 네트워크로 연결됨
EBS (Elastic Block Store) Volume이란?
| 특징 | 설명 | 비유 |
|---|---|---|
| 네트워크 드라이브 | 물리적 드라이브 아님 | 인터넷처럼 네트워크로 연결 |
| 데이터 영속성 | 인스턴스 종료 후에도 데이터 유지 | 컴퓨터 끄고 켜도 파일 남아있음 |
| 단일 인스턴스 | 한 번에 하나의 EC2에만 연결 | USB 하나를 두 컴퓨터에 동시에 못 꽂듯이 |
| AZ 종속 | 특정 가용영역에 묶임 | A동 창고 물건을 B동 창고로 직접 못 옮김 (복사만 가능) |
네트워크 드라이브의 의미
┌─────────────────────────────────────────────────────────┐
│ │
│ EC2 Instance ←───(네트워크)───→ EBS Volume │
│ │ │ │
│ │ 약간의 지연 발생 │ │
│ │ (물리 디스크보다 느림) │ │
│ │
└─────────────────────────────────────────────────────────┘장점: 빠르게 분리해서 다른 EC2에 연결 가능 단점: 네트워크 통신으로 인한 약간의 지연(latency)
AZ(가용영역) 제한
┌─── us-east-1a ───┐ ┌─── us-east-1b ───┐
│ │ │ │
│ EC2 ←── EBS │ │ EC2 │
│ (10GB) │ │ ❌ │
│ │ │ (1a의 EBS 연결 │
│ EBS (100GB) │ │ 불가!) │
│ (미연결) │ │ │
│ │ │ EBS (50GB) │
└───────────────────┘ └───────────────────┘
⚠️ us-east-1a의 EBS를 us-east-1b의 EC2에 직접 연결 불가!
→ 스냅샷을 찍어서 다른 AZ에 복원해야 함프로비저닝된 용량
초보자 설명: "프로비저닝"은 미리 예약한다는 뜻입니다.
- 100GB EBS를 만들면, 실제로 10GB만 써도 100GB 요금 청구
- 마치 헬스장 1년 회원권처럼, 안 가도 돈은 나가는 것
- 나중에 용량 증가 가능 (축소는 불가)
2. Delete on Termination 속성
🤔 이게 뭔가요?
비유로 이해하기: 컴퓨터를 버릴 때 하드디스크도 같이 버릴지 결정하는 것입니다.
기본 동작
| 볼륨 유형 | 기본 설정 | 의미 |
|---|---|---|
| 루트 볼륨 (C드라이브) | 삭제됨 ✅ | EC2 종료하면 같이 삭제 |
| 추가 볼륨 (D드라이브) | 유지됨 ❌ | EC2 종료해도 남아있음 |
실제 상황 예시
EC2 인스턴스 종료 시:
┌─────────────────────────────────────────┐
│ EC2 Instance (종료됨) │
│ │
│ ├─ 루트 EBS (Delete on Termination: Yes)│
│ │ → 함께 삭제됨 💀 │
│ │ │
│ └─ 데이터 EBS (Delete on Termination: No)│
│ → 남아있음 ✅ (나중에 다른 EC2에 연결 가능)
└─────────────────────────────────────────┘언제 설정을 바꾸나요?
| 상황 | 설정 |
|---|---|
| 테스트용 EC2, 데이터 필요 없음 | 기본값 유지 |
| 중요 데이터가 루트 볼륨에 있음 | Delete on Termination: No |
| 비용 절약 (쓸모없는 볼륨 자동 삭제) | Delete on Termination: Yes |
초보자 팁: 실수로 EC2를 종료해도 데이터를 살리고 싶다면, 루트 볼륨도 "Delete on Termination: No"로 설정하세요!
3. EBS Snapshots
🤔 스냅샷이 뭔가요?
비유로 이해하기: 사진 찍기와 같습니다.
- 특정 순간의 EBS 상태를 "찰칵!" 하고 저장
- 나중에 문제 생기면 그 사진(스냅샷)으로 복원
- 다른 지역(AZ, Region)으로 복사 가능
스냅샷 사용 흐름
┌─── us-east-1a ───┐ ┌─── us-east-1b ───┐
│ │ │ │
│ EC2 ←── EBS │ │ EC2 ←── EBS │
│ (50GB) │ 복원→ │ (50GB) │
│ │ │ │ ↑ │
│ ↓ │ │ │ │
│ [스냅샷 생성] │─────────│────[스냅샷에서 복원]
│ │ │ │
└───────────────────┘ └───────────────────┘
1. us-east-1a에서 EBS 스냅샷 생성
2. 스냅샷을 us-east-1b로 복사
3. us-east-1b에서 스냅샷으로 새 EBS 생성스냅샷 생성 시 주의사항
| 항목 | 설명 |
|---|---|
| 볼륨 분리 | 필수 아님, but 권장 |
| 이유 | 분리하면 데이터 무결성 보장 |
| 실무에서 | 보통 분리 없이 생성 (서비스 중단 방지) |
EBS Snapshot 고급 기능
1️⃣ Snapshot Archive (비용 절감)
EBS Snapshot ──(아카이브)──→ Snapshot Archive
(일반 저장) (75% 저렴!)
│
↓
복원 시 24~72시간 소요초보자 설명: 자주 안 쓰는 스냅샷은 "창고"에 보관하면 저렴합니다. 단, 꺼내는 데 하루~사흘 걸려요.
사용 사례: 1년 전 백업, 규정상 보관해야 하지만 거의 안 쓰는 데이터
2️⃣ Recycle Bin (실수 방지)
스냅샷 삭제 ──→ Recycle Bin (1일~1년 보관) ──→ 영구 삭제
│
└─→ 실수로 삭제했다면 복구 가능!초보자 설명: Windows의 "휴지통"과 같습니다. 실수로 삭제해도 설정한 기간 내에 복구 가능!
3️⃣ Fast Snapshot Restore (FSR)
문제 상황:
일반 스냅샷 복원 후 첫 읽기:
스냅샷 → EBS 생성 → 첫 번째 읽기 → 느림! (S3에서 가져오는 중...)
→ 두 번째 읽기 → 빠름 (이미 로드됨)FSR 사용 시:
스냅샷 → EBS 생성 (전체 데이터 미리 로드) → 첫 번째 읽기부터 빠름!초보자 설명: 게임 설치할 때 "미리 다운로드" 같은 것. 비용이 추가되지만, 첫 사용부터 빠른 성능이 필요할 때 사용.
4. AMI (Amazon Machine Image)
🤔 AMI가 뭔가요?
비유로 이해하기: 컴퓨터 복제 틀과 같습니다.
- 새 컴퓨터 살 때마다 프로그램 설치하고 설정하면 귀찮죠?
- 한 번 완벽하게 설정한 컴퓨터를 "틀"로 만들어두면
- 그 틀로 똑같은 컴퓨터를 빠르게 여러 대 만들 수 있습니다
AMI에 포함되는 것
| 포함 항목 | 예시 |
|---|---|
| 운영체제 | Ubuntu, Amazon Linux |
| 소프트웨어 | Node.js, Python, Docker |
| 설정 | 환경변수, 보안 설정 |
| 데이터 | 필요한 파일들 |
AMI 유형
| 유형 | 설명 | 예시 |
|---|---|---|
| Public AMI | AWS가 제공 | Amazon Linux 2, Ubuntu |
| 내 AMI | 직접 만든 것 | 회사 서버 템플릿 |
| Marketplace AMI | 다른 사람/회사가 만든 것 | WordPress 사전 설치 AMI |
AMI 생성 과정
1단계: EC2 인스턴스 시작 & 커스터마이즈
┌─────────────────────────────────┐
│ EC2 Instance │
│ ├─ Ubuntu 설치 │
│ ├─ Node.js 설치 │
│ ├─ 내 앱 코드 배포 │
│ └─ 환경 설정 완료 │
└─────────────────────────────────┘
│
▼
2단계: 인스턴스 중지 (데이터 무결성 위해)
│
▼
3단계: AMI 생성 (EBS 스냅샷도 자동 생성됨)
│
▼
┌─────────────────────────────────┐
│ Custom AMI │
│ "my-nodejs-server-v1" │
└─────────────────────────────────┘
│
▼
4단계: 이 AMI로 새 인스턴스 빠르게 생성!
┌────────┐ ┌────────┐ ┌────────┐
│ EC2 │ │ EC2 │ │ EC2 │
│ (복제) │ │ (복제) │ │ (복제) │
└────────┘ └────────┘ └────────┘AMI의 리전 특성
⚠️ AMI는 리전에 종속됩니다!
서울(ap-northeast-2)에서 만든 AMI
│
├─→ 서울에서 바로 사용 ✅
│
└─→ 도쿄(ap-northeast-1)에서 사용하려면?
→ AMI를 도쿄로 복사해야 함5. EC2 Instance Store
🤔 EBS랑 뭐가 다른가요?
비유로 이해하기:
- EBS: 네트워크로 연결된 외장하드 (분리 가능, 영구 저장)
- Instance Store: 컴퓨터에 붙어있는 내장 SSD (빠름, but 임시 저장)
EBS vs Instance Store 비교
| 항목 | EBS | Instance Store |
|---|---|---|
| 연결 방식 | 네트워크 | 물리적 연결 |
| 성능 | 좋음 | 매우 빠름 (최고 성능) |
| 데이터 영속성 | ✅ 유지됨 | ❌ 인스턴스 중지/종료 시 삭제 |
| 분리/연결 | 가능 | 불가능 |
| 백업 | 스냅샷 | 직접 해야 함 |
Instance Store 데이터 손실 상황
⚠️ Instance Store 데이터가 사라지는 경우:
1. 인스턴스 중지(Stop) → 데이터 삭제! 💀
2. 인스턴스 종료(Terminate) → 데이터 삭제! 💀
3. 하드웨어 장애 → 데이터 삭제! 💀
✅ 데이터 유지되는 경우:
- 인스턴스 재부팅(Reboot) → 데이터 유지언제 Instance Store를 쓰나요?
| 사용 사례 | 이유 |
|---|---|
| 버퍼/캐시 | 임시 데이터, 삭제돼도 OK |
| 임시 파일 | 처리 중 임시 저장 |
| 스크래치 데이터 | 계산 중간 결과 |
| 고성능 I/O 필요 | 데이터베이스 캐시 등 |
초보자 주의: Instance Store는 절대로 중요 데이터 저장 금지! 반드시 EBS나 S3에 백업하세요.
Instance Store 성능
Instance Store (i3.16xlarge 기준):
- 최대 3.3 Million IOPS (읽기)
- 최대 1.4 Million IOPS (쓰기)
vs EBS (io2 Block Express):
- 최대 256,000 IOPS
→ Instance Store가 10배 이상 빠를 수 있음!6. EBS Volume Types
🤔 왜 여러 종류가 있나요?
비유로 이해하기: 자동차처럼 용도에 따라 다릅니다.
- 출퇴근용 → 경제적인 경차 (gp3)
- 레이싱 → 고성능 스포츠카 (io2)
- 이삿짐 → 트럭 (st1)
- 가끔 쓰는 짐 → 저렴한 창고 (sc1)
EBS 볼륨 타입 한눈에 보기
| 타입 | 종류 | 용도 | 부팅 가능 |
|---|---|---|---|
| gp2/gp3 | SSD | 일반 용도 | ✅ |
| io1/io2 | SSD | 고성능 | ✅ |
| st1 | HDD | 빅데이터 | ❌ |
| sc1 | HDD | 콜드 데이터 | ❌ |
General Purpose SSD (gp2/gp3)
초보자 설명: "대부분의 경우 이걸 쓰면 됩니다!"
| 항목 | gp3 | gp2 |
|---|---|---|
| 기본 IOPS | 3,000 (무조건) | 볼륨 크기에 비례 |
| 최대 IOPS | 16,000 | 16,000 |
| 기본 처리량 | 125 MiB/s | 볼륨 크기에 비례 |
| 최대 처리량 | 1,000 MiB/s | 250 MiB/s |
| IOPS 조절 | ✅ 독립적 | ❌ 크기에 연동 |
| 크기 | 1 GiB ~ 16 TiB | 1 GiB ~ 16 TiB |
gp2의 특징 (구버전)
gp2 IOPS = 볼륨 크기(GiB) × 3
예시:
- 100 GiB → 300 IOPS
- 1,000 GiB → 3,000 IOPS
- 5,334 GiB → 16,000 IOPS (최대)
작은 볼륨은 Burst로 3,000 IOPS까지 순간 사용 가능gp3의 특징 (신버전, 권장!)
gp3는 크기와 상관없이:
- 기본 3,000 IOPS 제공
- 기본 125 MiB/s 처리량 제공
- 필요하면 추가 비용 내고 IOPS/처리량 올릴 수 있음
→ 대부분의 경우 gp3가 더 저렴하고 좋음!사용 사례:
- 시스템 부팅 볼륨
- 개발/테스트 환경
- 가상 데스크톱
- 중소규모 데이터베이스
Provisioned IOPS SSD (io1/io2)
초보자 설명: "데이터베이스처럼 초고성능이 필요할 때!"
| 항목 | io1 | io2 Block Express |
|---|---|---|
| 최대 IOPS | 64,000 | 256,000 |
| 최대 크기 | 16 TiB | 64 TiB |
| 지연시간 | 밀리초 | 서브밀리초 |
| Multi-Attach | ✅ | ✅ |
| IOPS:GiB 비율 | 50:1 | 1,000:1 |
사용 사례:
- 대규모 데이터베이스 (Oracle, SQL Server, MySQL)
- 16,000 IOPS 이상 필요한 애플리케이션
- 지연시간에 민감한 워크로드
Throughput Optimized HDD (st1)
초보자 설명: "대용량 데이터를 순차적으로 읽고 쓸 때!"
특징:
- 부팅 볼륨으로 사용 불가 ❌
- 크기: 125 GiB ~ 16 TiB
- 최대 처리량: 500 MiB/s
- 최대 IOPS: 500 (낮음, but 처리량은 높음)사용 사례:
- 빅데이터
- 데이터 웨어하우스
- 로그 처리
비유: 고속도로 → 속도는 빠른데 차선 변경(랜덤 접근)은 느림
Cold HDD (sc1)
초보자 설명: "거의 안 쓰는 데이터를 저렴하게 저장!"
특징:
- 부팅 볼륨으로 사용 불가 ❌
- 크기: 125 GiB ~ 16 TiB
- 최대 처리량: 250 MiB/s
- 최대 IOPS: 250 (매우 낮음)
- 비용: 가장 저렴!사용 사례:
- 아카이브 데이터
- 자주 접근하지 않는 데이터
- 비용이 가장 중요한 경우
볼륨 타입 선택 가이드
"어떤 볼륨을 써야 할까요?"
시작 → 부팅 볼륨인가요?
│
├─ Yes → gp3 (일반) 또는 io2 (고성능 DB)
│
└─ No → 얼마나 자주 접근하나요?
│
├─ 자주 (읽기/쓰기 많음) → gp3 또는 io2
│
├─ 가끔 (대용량 순차) → st1
│
└─ 거의 안 함 → sc17. EBS Multi-Attach
🤔 Multi-Attach가 뭔가요?
비유로 이해하기: 일반적으로 USB는 한 컴퓨터에만 꽂을 수 있죠? 하지만 특수한 USB가 있어서 여러 컴퓨터에 동시에 꽂을 수 있다면? EBS Multi-Attach가 바로 그것입니다.
특징
┌────────────────────────────────────────┐
│ Availability Zone 1 │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ EC2 │ │ EC2 │ │ EC2 │ ... │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ │
│ └────────┼────────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ io2 EBS │ │
│ │(Multi-Attach) │
│ └───────────┘ │
│ │
│ 최대 16개 EC2가 동시에 연결 가능! │
└────────────────────────────────────────┘제한 사항
| 항목 | 설명 |
|---|---|
| 볼륨 타입 | io1/io2만 지원 |
| AZ | 같은 AZ 내에서만 |
| 인스턴스 수 | 최대 16개 |
| 파일 시스템 | 클러스터 인식 필요 (XFS, EXT4 ❌) |
| 동시 쓰기 | 애플리케이션이 직접 관리해야 함 |
사용 사례
| 사례 | 설명 |
|---|---|
| 클러스터 DB | Teradata, Oracle RAC |
| 고가용성 앱 | 한 인스턴스 죽어도 다른 인스턴스가 이어받음 |
초보자 주의: 일반 파일 시스템(XFS, EXT4)은 Multi-Attach에서 데이터 손상 위험! 반드시 클러스터 인식 파일 시스템 사용하세요.
8. Amazon EFS (Elastic File System)
🤔 EFS가 뭔가요?
비유로 이해하기:
- EBS: 개인 USB (한 사람만 사용)
- EFS: 회사 공유 폴더 (여러 사람이 동시 사용)
EBS vs EFS 핵심 차이
| 항목 | EBS | EFS |
|---|---|---|
| 연결 | 단일 EC2 | 여러 EC2 동시 연결 |
| AZ | 단일 AZ | Multi-AZ |
| OS | Linux, Windows | Linux만 |
| 프로토콜 | 블록 스토리지 | NFS (네트워크 파일 시스템) |
| 용량 | 미리 프로비저닝 | 자동 확장 |
| 비용 | 저렴 | 비쌈 (gp2의 약 3배) |
EFS 아키텍처
┌─── us-east-1a ───┐ ┌─── us-east-1b ───┐ ┌─── us-east-1c ───┐
│ │ │ │ │ │
│ ┌─────┐ ┌─────┐ │ │ ┌─────┐ ┌─────┐ │ │ ┌─────┐ ┌─────┐ │
│ │ EC2 │ │ EC2 │ │ │ │ EC2 │ │ EC2 │ │ │ │ EC2 │ │ EC2 │ │
│ └──┬──┘ └──┬──┘ │ │ └──┬──┘ └──┬──┘ │ │ └──┬──┘ └──┬──┘ │
│ │ │ │ │ │ │ │ │ │ │ │
└─────┼───────┼────┘ └─────┼───────┼────┘ └─────┼───────┼────┘
│ │ │ │ │ │
└───────┴─────────────┴───────┴─────────────┴───────┘
│
┌───────▼───────┐
│ │
│ EFS File │
│ System │
│ │
│ (Security │
│ Group) │
└───────────────┘
모든 AZ의 모든 EC2가 동일한 파일에 접근 가능!EFS 특징
| 특징 | 설명 |
|---|---|
| 프로토콜 | NFSv4.1 |
| 보안 | Security Group으로 접근 제어 |
| 암호화 | KMS로 저장 시 암호화 |
| OS | Linux만 (POSIX 파일 시스템) |
| 용량 | 자동 확장 (페타바이트까지) |
| 요금 | 사용한 만큼만 (프로비저닝 필요 없음) |
사용 사례
| 사례 | 이유 |
|---|---|
| WordPress | 여러 웹서버가 같은 파일 공유 |
| 콘텐츠 관리 | 미디어 파일 공유 |
| 빅데이터 분석 | 여러 인스턴스가 데이터 공유 |
| 개발 환경 | 코드 공유 |
9. EFS 성능 & 스토리지 클래스
Performance Mode (생성 시 설정)
| 모드 | 설명 | 용도 |
|---|---|---|
| General Purpose (기본) | 낮은 지연시간 | 웹서버, CMS |
| Max I/O | 높은 처리량, 높은 지연시간 | 빅데이터, 미디어 처리 |
Throughput Mode
| 모드 | 설명 | 용도 |
|---|---|---|
| Bursting | 저장 용량에 비례 | 일반적인 워크로드 |
| Provisioned | 고정 처리량 설정 | 예측 가능한 높은 처리량 필요 |
| Elastic (권장!) | 자동 스케일링 | 예측 불가능한 워크로드 |
Elastic 모드 설명:
워크로드에 따라 자동 조절:
- 읽기: 최대 3 GiB/s
- 쓰기: 최대 1 GiB/s
장점: 사용량 예측 안 해도 됨!Storage Classes (비용 최적화)
┌─────────────────────────────────────────────────────────┐
│ EFS File System │
│ │
│ ┌─────────────┐ 60일 동안 ┌──────────────┐ │
│ │ Standard │ ──접근 없음────────→│ EFS-IA │ │
│ │ (자주 접근) │ │(저렴한 저장) │ │
│ └─────────────┘ └──────────────┘ │
│ │
│ 90일 동안 ┌──────────────┐ │
│ ──접근 없음────────→│ Archive │ │
│ │(50% 더 저렴) │ │
│ └──────────────┘ │
│ │
│ 💡 Lifecycle Policy로 자동 이동! │
└─────────────────────────────────────────────────────────┘| 티어 | 설명 | 비용 |
|---|---|---|
| Standard | 자주 접근 | 높음 |
| Infrequent Access (IA) | 가끔 접근 | 저장 저렴, 읽기 시 비용 |
| Archive | 거의 안 접근 (1년에 몇 번) | 50% 저렴 |
가용성 옵션
| 옵션 | 설명 | 용도 | 비용 절감 |
|---|---|---|---|
| Standard | Multi-AZ | 프로덕션 | - |
| One Zone | 단일 AZ | 개발, 백업 | 90% 이상 |
One Zone + IA 조합:
One Zone-IA = 단일 AZ + Infrequent Access
= 매우 저렴! (개발/테스트에 적합)10. EBS vs EFS vs Instance Store 비교
🤔 언제 무엇을 써야 하나요?
한눈에 비교
| 항목 | EBS | EFS | Instance Store |
|---|---|---|---|
| 연결 | 단일 EC2 | 다중 EC2 | 단일 EC2 |
| AZ | 단일 AZ | Multi-AZ | 단일 (물리적) |
| 성능 | 좋음 | 좋음 | 최고 |
| 영속성 | ✅ | ✅ | ❌ (임시) |
| 용량 | 프로비저닝 | 자동 확장 | 고정 |
| 비용 | 중간 | 비쌈 | 인스턴스에 포함 |
| OS | Linux/Windows | Linux만 | Linux/Windows |
| 백업 | 스냅샷 | AWS Backup | 직접 |
선택 가이드
"어떤 스토리지를 써야 할까요?"
Q1. 여러 EC2가 동시에 파일을 공유해야 하나요?
│
├─ Yes → EFS (Linux) 또는 FSx (Windows)
│
└─ No → Q2로
Q2. 최고의 I/O 성능이 필요한가요?
│
├─ Yes → Instance Store (데이터 손실 감수)
│
└─ No → Q3로
Q3. 데이터를 영구 저장해야 하나요?
│
├─ Yes → EBS
│
└─ No → Instance Store (캐시, 임시 데이터)실제 아키텍처 예시
┌─────────────────── Web Application ───────────────────┐
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Web EC2 │ │ Web EC2 │ │ Web EC2 │ │
│ │ │ │ │ │ │ │
│ │ [EBS] │ │ [EBS] │ │ [EBS] │ ← 루트 볼륨 │
│ │ (루트) │ │ (루트) │ │ (루트) │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ └────────────┼────────────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ EFS │ ← 공유 파일 (이미지, CSS) │
│ │(WordPress │ │
│ │ uploads) │ │
│ └───────────┘ │
│ │
│ ┌─────────┐ │
│ │ DB EC2 │ │
│ │ │ │
│ │ [io2] │ ← 고성능 DB 볼륨 │
│ │ [Inst. │ ← 캐시 (임시) │
│ │ Store] │ │
│ └─────────┘ │
└────────────────────────────────────────────────────────┘핵심 요약
EBS 볼륨 타입 요약
| 타입 | IOPS | 처리량 | 용도 | 부팅 |
|---|---|---|---|---|
| gp3 | 16,000 | 1,000 MiB/s | 일반 | ✅ |
| gp2 | 16,000 | 250 MiB/s | 일반 (구버전) | ✅ |
| io2 | 256,000 | 4,000 MiB/s | 고성능 DB | ✅ |
| st1 | 500 | 500 MiB/s | 빅데이터 | ❌ |
| sc1 | 250 | 250 MiB/s | 아카이브 | ❌ |
스토리지 선택 기준
| 요구사항 | 추천 |
|---|---|
| 일반 부팅 볼륨 | gp3 |
| 고성능 데이터베이스 | io2 |
| 파일 공유 (Linux) | EFS |
| 최고 성능 (임시) | Instance Store |
| 대용량 순차 처리 | st1 |
| 저렴한 아카이브 | sc1 |