AWS EBS 완전 정복: EC2의 '하드디스크'를 제대로 이해하는 법

들어가며: EC2 인스턴스를 켰는데, 데이터는 어디에 저장되나?

EC2 글에서 "EC2 인스턴스는 가상 컴퓨터"라고 설명했다. CPU와 RAM은 인스턴스 타입으로 정해진다. 그런데 하드디스크는?

노트북을 사면 "SSD 512GB"처럼 내장 저장소가 있다. EC2에도 비슷한 것이 필요하다. 운영체제(Linux, Windows)를 설치할 곳, 애플리케이션 코드를 저장할 곳, 데이터베이스 파일을 쓸 곳.

이때 사용하는 것이 EBS(Elastic Block Store)다. EC2 인스턴스에 네트워크로 연결되는 가상 하드디스크.

하지만 EBS를 처음 접하면 당황스러운 선택지가 쏟아진다:

• gp2? gp3? io1? io2? st1? sc1? — 볼륨 타입이 6가지
• ext4? XFS? — 파일 시스템은 뭘 선택하지?
• IOPS? 처리량? 지연 시간? — 성능 지표가 3가지
• 스냅샷? 암호화? 멀티 어태치? — 기능이 또 여러 개

이 글에서는 이 모든 것을 비유와 실전 사례로 쉽게 풀어보겠다.

1. 블록 스토리지란 무엇인가

S3와 EBS는 근본적으로 다르다

이전 S3 글에서 오브젝트 스토리지를 다뤘다. S3와 EBS는 완전히 다른 종류의 스토리지다.

S3는 파일을 "통째로" 저장하고 꺼내는 창고다. EBS는 운영체제가 직접 사용하는 디스크다. 데이터베이스는 디스크에 바이트 단위로 읽고 써야 하므로 S3가 아닌 EBS가 필요하다.

블록 스토리지의 "블록"이란

EBS가 데이터를 저장하는 방식은 블록(Block) 단위다. 디스크를 일정한 크기(보통 4KB~512KB)의 조각으로 나누고, 각 조각에 번호를 붙여 관리한다.

노트북의 SSD도 같은 방식이다. 하지만 노트북의 SSD는 물리적으로 연결되어 있고, EBS는 네트워크를 통해 연결된다.

2. 파일 시스템: ext4 vs XFS — 두려워할 필요 없다

파일 시스템이란

EBS 볼륨을 EC2에 연결하면, 처음에는 빈 디스크다. 아무것도 저장할 수 없다. 마치 새 하드디스크를 사서 꽂은 것과 같다 — 포맷해야 사용할 수 있다.

이 "포맷"이 바로 파일 시스템을 만드는 것이다. 파일 시스템은 디스크의 블록들을 파일과 폴더라는 논리적 구조로 조직하는 규칙이다.

비유하면: EBS 볼륨 = 빈 노트, 파일 시스템 = 노트에 줄을 긋고 목차를 만드는 것.

Linux의 두 가지 표준 파일 시스템

# EBS 볼륨을 ext4로 포맷
sudo mkfs.ext4 /dev/xvdf

# EBS 볼륨을 XFS로 포맷
sudo mkfs.xfs /dev/xvdf

# 마운트
sudo mount /dev/xvdf /data

3. EBS 볼륨 타입: gp2, gp3, io2 — 진짜 쉽게

성능 지표부터 이해하기

EBS 볼륨 타입을 고르기 전에, 세 가지 성능 지표를 먼저 알아야 한다. 비유로 풀어보자.

EBS 볼륨 = 고속도로라고 생각하면:

IOPS가 중요한 워크로드: 데이터베이스. 작은 데이터를 아주 빈번하게 읽고 쓴다. (차 수가 많지만 짐은 적은 고속도로)

처리량이 중요한 워크로드: 빅데이터 분석, 미디어 처리. 큰 파일을 순차적으로 읽는다. (차 수는 적지만 큰 트럭이 다니는 고속도로)

EBS 볼륨 타입 비교

gp2 vs gp3: 왜 gp3로 바꿔야 하는가

gp2는 2014년 출시된 범용 SSD다. gp3는 2020년에 나온 후속이다. gp3가 모든 면에서 낫다:

gp2에서 gp3로 바꾸면: 같은 크기에서 20% 저렴하고, 성능은 같거나 더 높다. gp2를 계속 쓸 이유가 없다.

io2: 데이터베이스가 정말 빨라야 할 때

gp3의 최대 16,000 IOPS로 부족하면 io2(Provisioned IOPS SSD) 를 쓴다. 최대 256,000 IOPS, 지연시간 한 자릿수 밀리초 미만.

Oracle, SQL Server 같은 고성능 상용 DB나, 금융 거래 시스템처럼 극도의 I/O 성능이 필요한 경우에 사용한다.

비용도 높다: 볼륨 비용($0.125/GB) + IOPS 비용($0.065/IOPS/월). 정말 필요한 경우에만 쓰라.

4. EBS가 EC2 및 다른 서비스에서 사용되는 방식

EC2의 루트 볼륨

EC2 인스턴스를 시작하면 루트 볼륨이 자동으로 연결된다. 운영체제가 설치되는 디스크다.

• Amazon Linux 2023 기본: 8GB gp3 (XFS)
• Ubuntu 기본: 8GB gp3 (ext4)

RDS의 숨겨진 EBS

이전 RDS 글에서 다루지 않은 것: RDS 인스턴스의 저장소도 EBS다. RDS 콘솔에서 "Storage" 설정을 보면 gp3, io1, io2 중 선택할 수 있다.

• 일반 웹 서비스 DB: gp3로 충분
• 대규모 트랜잭션 DB: io2로 IOPS 확보

EKS/ECS에서의 EBS

쿠버네티스(EKS)에서 PersistentVolume으로 EBS를 사용할 수 있다. EBS CSI Driver가 K8s의 볼륨 요청을 EBS API로 변환한다.

# K8s PersistentVolumeClaim → EBS 자동 생성
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-storage
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: gp3
  resources:
    requests:
      storage: 100Gi

다른 클라우드와의 비교

5. EBS 스냅샷: 디스크의 "타임머신"

스냅샷이란

EBS 스냅샷은 볼륨의 특정 시점 복사본이다. S3에 저장되며 리전 내/리전 간 복사가 가능하다.

핵심 특성:

• 증분식(Incremental): 첫 스냅샷은 전체 볼륨을 복사하지만, 이후 스냅샷은 변경된 블록만 저장. 100GB 볼륨에서 1GB만 바뀌었으면 1GB만 저장
• 즉시 사용 가능: 스냅샷에서 새 볼륨을 만들면 즉시 사용 가능 (백그라운드에서 데이터 로드)
• 리전 간 복사: DR(재해복구)을 위해 다른 리전에 스냅샷 복사

실전 활용

# 스냅샷 생성
aws ec2 create-snapshot --volume-id vol-abc123 --description "Before deployment"

# 스냅샷에서 새 볼륨 생성
aws ec2 create-volume --snapshot-id snap-xyz789 --availability-zone ap-northeast-2a

# 스냅샷을 다른 리전으로 복사 (DR)
aws ec2 copy-snapshot --source-region ap-northeast-2 \
  --source-snapshot-id snap-xyz789 --destination-region us-east-1

6. EBS 보안

암호화

2024년부터 AWS는 새로 생성되는 EBS 볼륨에 기본 암호화를 적용할 수 있게 됐다. 계정 설정에서 "EBS encryption by default"를 활성화하면, 이후 생성되는 모든 볼륨이 자동 암호화된다.

암호화 대상:

• 볼륨 내 데이터 (저장 시)
• 볼륨과 인스턴스 간 전송 데이터
• 스냅샷
• 스냅샷에서 생성된 볼륨

성능 영향: 거의 없다. Nitro 시스템이 하드웨어 수준에서 암호화를 처리하므로 CPU 부담이 없다.

보안 사고: 스냅샷 공유의 위험

7. EBS 비용 최적화

비용 구성

비용 절감 핵심 전략

1. gp2 → gp3 전환 (즉시 20% 절감)

다운타임 없이 온라인 변경. 가장 쉽고 효과적인 비용 절감.

2. 사용하지 않는 볼륨 삭제

EC2를 종료해도 EBS 볼륨은 남아 있을 수 있다 ("Delete on Termination" 비활성화 시). 사용하지 않는 볼륨이 방치되어 매달 과금되는 경우가 흔하다.

# 사용하지 않는(available 상태) 볼륨 찾기
aws ec2 describe-volumes --filters "Name=status,Values=available" \
  --query "Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}"

3. 오래된 스냅샷 정리

스냅샷도 비용이다. Data Lifecycle Manager(DLM)로 자동 정리 정책을 설정하라.

4. 적정 사이즈

CloudWatch에서 VolumeReadOps, VolumeWriteOps를 확인하여 실제 IOPS 사용량을 측정. 과도하게 프로비저닝된 io2를 gp3로 다운그레이드할 수 있다.

8. 실제 사례

Netflix: 수천 개의 EBS 볼륨 관리

Netflix는 수천 대의 EC2 인스턴스에서 동영상 인코딩, 마이크로서비스, 데이터 분석을 수행한다. 각 인스턴스에 연결된 EBS 볼륨은 수천 개에 달하며, 볼륨 타입을 워크로드에 맞게 세밀하게 조정한다:

• 인코딩 서버: gp3 (높은 처리량)
• 캐시 서버: 인스턴스 스토어 (휘발성이지만 초고속)
• 분석 DB: io2 (높은 IOPS)

Instagram: EBS 스냅샷으로 글로벌 배포

Instagram은 미국에서 운영 중인 서비스를 유럽으로 확장할 때, EBS 스냅샷을 리전 간 복사하여 데이터를 이전했다. 스냅샷의 증분 복사 기능으로 초기 대용량 전송 후 변경분만 동기화했다.

한국 기업 사례

• 쿠팡: RDS Aurora의 스토리지로 io2를 사용. 초당 수만 건의 주문 트랜잭션 처리
• 토스: 금융 DB에 io2 Block Express. 최저 지연시간 요구
• 당근마켓: 대부분의 서비스에 gp3. gp2에서 전환하며 비용 절감

9. EBS의 진화: 무엇이 바뀌고 있나

io2 Block Express

2021년 출시. 기존 io2를 Nitro System 위에서 대폭 강화:

• 256,000 IOPS (기존 io2의 4배)
• 4,000 MB/s 처리량
• 서브밀리초 지연시간
• 64TB까지 확장

Elastic Volumes: 다운타임 없는 변경

실행 중인 볼륨의 크기, 타입, IOPS, 처리량을 다운타임 없이 변경할 수 있다. 100GB gp3를 200GB로 늘리면서 IOPS를 3,000에서 10,000으로 올리는 것이 인스턴스 재시작 없이 가능하다.

EBS Fast Snapshot Restore

스냅샷에서 볼륨을 생성할 때 초기 성능 저하 없이 즉시 최대 성능을 발휘하는 기능. DB 복원이나 오토스케일링에서 새 인스턴스가 빠르게 시작해야 할 때 유용하다.

마치며: 보이지 않지만 모든 것의 기반

EBS는 화려한 서비스가 아니다. Lambda의 서버리스 마법도 아니고, DynamoDB의 밀리초 응답도 아니다. 하지만 EC2 인스턴스가 동작하려면 EBS가 있어야 하고, RDS가 데이터를 저장하려면 EBS가 있어야 하고, EKS의 Pod이 영구 데이터를 쓰려면 EBS가 있어야 한다.

이 시리즈에서 다룬 스토리지를 정리하면:

각 스토리지는 다른 물리적 특성과 다른 접근 방식을 가진다. EBS는 그중에서 가장 기본적이면서 가장 보편적인 것 — 운영체제, 데이터베이스, 애플리케이션이 직접 사용하는 디스크다.

코어닷투데이의 AI 서비스에서도 EBS는 곳곳에 있다. 추론 서버의 모델 파일 저장, 학습 데이터의 고속 접근, 데이터베이스의 영구 저장소 — 이 모든 것이 gp3와 io2 위에서 돌아간다.

gp2를 쓰고 있다면, 지금 당장 gp3로 바꾸라. 그것이 이 글에서 가져갈 수 있는 가장 즉각적인 실천이다.