Day 3 - EC2의 디스크 layer: EBS, Instance Store, 그리고 그 위의 EFS·FSx

처음 EC2를 만들 때 "Add storage" 화면을 보면 막막하다. gp3? io2? Block Express? 16TB까지 늘릴 수 있다는데 왜 io2는 비싸고 sc1은 싼지, 왜 인스턴스 스토어는 "이 인스턴스가 죽으면 데이터도 죽는다"고 경고가 뜨는지. 그 답은 EBS가 네트워크 위에 얹힌 분산 블록 스토리지라는 사실에서 시작한다. 같은 "디스크"라는 단어 안에 IOPS, throughput, latency, durability, replication 모델이 모두 다르고, 그 trade-off가 시험의 핵심이다.

오늘은 EBS의 내부 아키텍처(왜 AZ 종속인지, 왜 io2 Block Express만 256K IOPS인지)부터 인스턴스 스토어의 물리적 NVMe까지 따라가 본다. 그 위에서 EFS·FSx가 어떤 위치를 차지하는지, EBS 스냅샷이 S3에 정확히 어떻게 저장되는지를 본다. 개발자가 시험에서 만나는 "왜 우리 EBS는 IOPS가 안 나오지?", "왜 인스턴스 stop했더니 데이터가 다 날아갔지?" 같은 시나리오는 결국 이 layer를 끝까지 본 사람만 풀 수 있다.

EBS는 네트워크 디스크다 — AZ 종속의 이유

EBS는 "EC2에 attach되는 디스크"라고 단순히 이해하면 절반만 본 거다. 실제로 EBS는 AZ 안의 별도 분산 스토리지 fleet에 데이터를 저장하고, EC2 인스턴스는 그 fleet에 iSCSI 비슷한 프로토콜로 네트워크 너머 접근한다. 그래서 EBS volume은 AZ에 종속적이고, EC2를 다른 AZ로 옮기려면 ① snapshot 생성(S3에 저장) → ② 새 AZ에서 snapshot으로 volume 생성 → ③ attach라는 3단계가 필요하다.

[EC2 in AZ-a]
       |
       | iSCSI-like protocol over Nitro EBS Card
       |
[EBS Volume in AZ-a fleet]
       |
       | 3-way replicated within AZ
       |
[Storage Server 1] [Storage Server 2] [Storage Server 3]
   (같은 AZ 안에서 3-way replication)

EBS는 한 AZ 안에서 자동으로 3-way replication을 한다. 그래서 단일 storage server 장애로는 데이터를 잃지 않지만, AZ 전체가 죽으면 그 AZ에 있던 모든 EBS volume이 같이 죽는다. 이게 RDS Multi-AZ가 EBS를 그대로 다른 AZ에 두는 게 아니라, Primary와 Standby를 각각 다른 AZ의 EBS volume에 두고 synchronous replication을 추가로 하는 이유다.

Nitro 인스턴스의 경우 EBS는 Nitro EBS Card라는 전용 PCIe 카드를 통해 액세스된다. 호스트 OS의 CPU를 거의 안 거치고 카드가 직접 네트워크 패킷을 처리하므로, 같은 인스턴스 타입에서 non-Nitro 대비 약 2배의 EBS throughput이 나온다. 또 EBS-Optimized 옵션이 무료로 기본 활성화돼 있어, EC2의 일반 네트워크 대역과 EBS 대역이 분리된다(예전엔 옵션이었고 추가 요금).

io2 Block Express의 설계 내구성은 99.999%(five nines, 연간 고장률 0.001% 이하)다. S3의 11 nines(99.999999999%)와 혼동하지 않는다. 내부 복제 방식은 AWS가 세부를 공개하지 않는다. gp3·gp2·io1은 99.8-99.9% durability(연간 고장률 0.2% 이하, 1,000개 볼륨 중 연간 최대 2개 고장)다. 그래서 critical workload에는 gp3보다 io2가 권장된다. 다만 실무에선 어떤 EBS 타입이든 application-level backup(snapshot, RDS automated backup, Aurora continuous backup)이 항상 권장된다.

EBS volume type 깊이 분석

볼륨 타입을 외우기 전에 각 타입의 용도부터 구분한다.

gp3가 gp2를 대체하는 이유: gp2는 IOPS가 볼륨 크기에 묶여 있어(1GB당 3 IOPS, 최대 16,000) 100GB 볼륨에 5,000 IOPS가 필요하면 1,667GB까지 키워야 했다. gp3는 IOPS와 throughput을 크기와 독립적으로 설정 가능하다(추가 비용 있음). 같은 100GB 볼륨에 5,000 IOPS와 250 MB/s를 설정해도 gp2보다 약 20% 저렴하다.

io1 vs io2의 차이: 2025년 4월 30일부터 새로 만들든 기존이든 모든 io2 볼륨은 io2 Block Express다. ① durability가 io1의 99.8-99.9%에서 io2는 99.999%(five nines)로 높다. ② GiB당 프로비저닝 가능한 IOPS가 io1은 최대 50, io2는 최대 1,000이다. 즉 100GiB io1은 최대 5,000 IOPS, 100GiB io2는 최대 100,000 IOPS까지 설정한다. 그래서 새 워크로드에 io1을 쓰는 것은 오답 보기로 쓰이기 쉽다.

io2 Block Express: 2021년 정식 출시. 차세대 EBS 스토리지 서버 구조 위에서 Nitro 카드와 SRD(Scalable Reliable Datagram) 네트워크 프로토콜로 통신한다. 최대 256,000 IOPS, 4,000 MiB/s throughput, 16KiB I/O 기준 평균 500마이크로초 미만 latency, 64TiB까지 확장한다. SAP HANA 같은 인메모리 DB의 영구 스토리지 layer에 쓰인다. 256,000 IOPS는 Nitro 기반 인스턴스에서 나오고, 그 밖의 인스턴스는 최대 32,000 IOPS까지 낸다.

⚠️ 함정: 시험에서 "데이터베이스에 가장 적합한 EBS 타입"이 보이면 io2 또는 io2 Block Express가 답이다. gp3도 "일반 DB"엔 충분하지만, "지연 시간 민감"이나 "미션 크리티컬"이라는 키워드가 붙으면 io2 답. 또 "HDD를 부팅 볼륨으로"라는 보기는 오답이다. st1과 sc1은 부팅 불가.

gp3의 baseline 3,000 IOPS는 1GB든 1TB든 동일하다. 그 위에 추가 IOPS는 1 IOPS당 월 $0.005, throughput은 1MB/s당 월 $0.04(125 MB/s 위에서). 그래서 80GB 부팅 볼륨에 5,000 IOPS가 필요하면 추가 2,000 IOPS × $0.005 = 월 $10이 추가된다. 비교적 저렴한 옵션이라 production 부팅 볼륨도 gp3로 통일하는 게 표준이 되어가는 중.

EBS Multi-Attach: 같은 볼륨을 여러 인스턴스에서

기본적으로 EBS volume은 한 EC2 인스턴스에만 attach된다. 그런데 io1/io2 + Nitro 인스턴스 + 같은 AZ 조합에서만 가능한 예외가 EBS Multi-Attach다. 최대 16개 인스턴스가 같은 volume에 동시 attach된다.

그런데 여기에 함정이 있다: Multi-Attach만 켠다고 끝이 아니다. 일반 파일시스템(ext4, xfs)은 cluster-aware하지 않아서 여러 노드가 동시 write하면 파일시스템이 깨진다. GFS2, OCFS2, VxFS 같은 cluster file system이 필요하고, 그 위에서 distributed lock manager가 동시 access를 조율해야 한다. 즉 Multi-Attach는 application/middleware가 이미 클러스터링을 알고 있을 때(Oracle RAC, SAP ASCS·ERS 같은 경우)만 의미가 있다.

# Multi-Attach 가능한 io2 volume 생성
volume = ec2.create_volume(
    AvailabilityZone='ap-northeast-2a',
    Size=100,
    VolumeType='io2',
    Iops=5000,
    MultiAttachEnabled=True
)

시험에 "여러 EC2가 같은 디스크 공유"라는 시나리오의 답은 EFS(NFS 기반 파일 공유)지 EBS Multi-Attach가 아니다. Multi-Attach는 cluster-aware 워크로드의 특수 케이스일 뿐.

Instance Store: 물리적 NVMe

인스턴스 스토어(ephemeral storage, instance-store)는 EC2 호스트의 물리 디스크에 직접 연결된 스토리지다. EBS와 달리 네트워크를 거치지 않으므로 latency는 microsecond 수준, IOPS는 수백만에 달한다. 단점은 호스트가 죽으면 데이터도 죽는다는 것.

[EC2 instance on host server]
       |
       | PCIe direct attached
       |
[NVMe SSD physically on host]
   (호스트 서버에 물리적으로 박혀 있음)

i3·i4i·im4gn·is4gen 같은 storage-optimized 인스턴스 패밀리는 NVMe instance store가 큰 용량(수 TB까지)으로 제공된다. d2·d3 패밀리는 dense HDD instance store로 데이터 웨어하우스용. 단 instance store는 시작 시점에 fixed size로 할당되고 크기 변경이 불가하며, attach·detach 개념도 없다(인스턴스 자체와 한 몸).

인스턴스 stop은 인스턴스가 다른 호스트로 옮겨갈 수 있는 작업이다(start 시 새 호스트 할당). 그래서 호스트 종속인 instance store는 stop으로 데이터가 사라진다. 반대로 reboot은 같은 호스트에서 OS만 재시작하므로 데이터가 유지된다. Hibernate는 RAM 내용을 EBS 루트 볼륨에 dump하고 stop하는 것이라 instance store는 마찬가지로 소멸된다. 그래서 hibernate는 EBS 루트 볼륨이 암호화돼 있어야 하고, 일부 인스턴스 타입(주로 m·c·r 계열)만 지원한다.

EBS Snapshot: S3 위의 incremental backup

EBS snapshot은 volume의 특정 시점 백업이다. S3에 저장된다고 적혀 있지만 실제로는 AWS가 관리하는 S3 버킷에 저장되고 사용자가 직접 접근할 수 없다.

핵심 메커니즘은 block-level incremental backup이다. 첫 snapshot은 모든 used block을 S3에 저장. 두 번째 snapshot부터는 첫 snapshot 이후 변경된 block만 저장하고, 변경 안 된 block은 첫 snapshot을 reference한다. 그래서 100GB 볼륨의 10번째 snapshot이라도 차지하는 추가 공간은 그 사이 변경된 분량만이다.

Snapshot 1 (Day 1):  [Block A][Block B][Block C][Block D]  → S3 full
Snapshot 2 (Day 2):  [        ][Block B'][        ][        ]  → S3 with reference
                     (실제 저장은 B'만, 나머지는 Snapshot 1을 가리킴)
Snapshot 3 (Day 3):  [        ][        ][Block C'][        ]  → S3 with reference
                     (C'만 저장)

이 구조 때문에 ① snapshot 1개당 비용은 변경량 비례(저렴), ② 중간 snapshot 삭제 시 다른 snapshot들이 reference하던 block은 유지(automatic dependency management), ③ snapshot에서 volume 복원 시 모든 block reference를 따라가 재구성한다.

Lazy load의 함정: snapshot에서 volume을 만들면 "Available" 상태가 즉시 되지만, 그 안의 block은 처음 접근될 때 S3에서 fetch된다. 그래서 새 volume의 첫 fsck나 부팅 시 latency가 크게 튄다. 미리 모든 block을 채워두려면 ① dd if=/dev/xvdf of=/dev/null bs=1M 같은 명령으로 full scan, 또는 ② Fast Snapshot Restore(유료)를 켠다.

# Snapshot 생성과 cross-region copy + encryption
snap = ec2.create_snapshot(
    VolumeId='vol-0abc1234',
    Description='Daily backup before deploy',
    TagSpecifications=[{
        'ResourceType': 'snapshot',
        'Tags': [{'Key': 'Backup', 'Value': '2026-05-26'}]
    }]
)
 
# 다른 리전으로 복사 + KMS 재암호화 + Archive tier (75% 절감)
target_ec2 = boto3.client('ec2', region_name='us-east-1')
copy = target_ec2.copy_snapshot(
    SourceRegion='ap-northeast-2',
    SourceSnapshotId=snap['SnapshotId'],
    Encrypted=True,
    KmsKeyId='arn:aws:kms:us-east-1:123:key/abc'
)
 
# 90일 이상 보관할 거면 Archive tier로 이동
ec2.modify_snapshot_tier(
    SnapshotId=snap['SnapshotId'],
    StorageTier='archive'
)

⚠️ 함정: 시험에 "snapshot으로 만든 새 volume이 production보다 느리다"는 시나리오가 나오면 답은 Fast Snapshot Restore. lazy load 때문이다. 또 "snapshot을 다른 리전에 복사할 때 자동으로 암호화"는 가능하지만(Encrypted=True) 같은 KMS 키를 두 리전에서 쓸 수 없으므로 대상 리전의 KMS 키를 새로 지정해야 한다. Multi-Region KMS Key를 쓰면 두 리전이 같은 키 머티리얼을 공유 가능.

EBS 암호화: KMS envelope encryption의 내부

EBS encryption은 사용자가 보기엔 토글 하나지만 내부적으로는 KMS의 envelope encryption을 쓴다.

1. EBS volume 생성 시 KMS에 "GenerateDataKey" 요청
2. KMS가 plaintext data key(DEK) + encrypted DEK를 반환
3. EC2 호스트의 Nitro Card가 plaintext DEK를 메모리에 보관 (memory only)
4. volume의 모든 block을 AES-256-XTS로 DEK로 암호화 후 디스크에 기록
5. encrypted DEK는 volume metadata에 함께 저장
6. 인스턴스 재부팅·옮겨갈 때마다 encrypted DEK를 다시 KMS Decrypt 호출로 복호화

핵심은 ① plaintext DEK는 KMS 안과 EC2 host 메모리에만 존재(디스크에 절대 안 적힘), ② 모든 IO는 transparent encrypt/decrypt(애플리케이션 입장에선 보이지 않음), ③ 성능 영향은 < 1% (AES-NI 하드웨어 가속 활용).

KMS Multi-Region Key는 2021년 출시. 같은 key material을 여러 리전에서 사용 가능하므로 EBS snapshot을 cross-region copy해도 같은 키로 복호화 가능. 이전엔 각 리전마다 새 키를 만들어 snapshot copy 시 re-encrypt해야 했다. 단 Multi-Region Key는 KMS의 fully-managed CMK가 아닌 customer-managed CMK(CMK)에서만 가능하다.

미암호화 volume을 암호화하는 5단계: ① snapshot 생성(미암호화) → ② copy-snapshot --encrypted --kms-key-id 로 암호화 복사 → ③ 암호화된 snapshot에서 새 volume 생성 → ④ 원래 volume detach, 새 volume attach → ⑤ 검증 후 원본 삭제. 이 순서가 암호화 전환 절차다.

EFS, FSx: EBS 너머의 파일 공유

EBS가 "한 인스턴스가 단독 사용하는 블록 디스크"라면, EFS는 "여러 인스턴스가 NFS로 공유하는 파일 시스템"이다. EFS는 multi-AZ에 자동 복제되고, 사용량 기반 과금(쓴 만큼 GB-월)이며, 인스턴스 수에 관계없이 throughput이 자동 확장된다.

EFS의 두 가지 throughput 모드:

• Bursting: 기본. 1TB 미만에서는 baseline 50 MB/s에 burst credit으로 100 MB/s 까지. 큰 워크로드엔 부족.
• Provisioned: 명시적으로 throughput 구매. baseline 무시.
• Elastic (2023): 자동 확장, 사용량 기반 과금. 새 워크로드의 기본값.

EFS storage classes:

• Standard: 자주 접근, $0.33/GB·월
• Infrequent Access (IA): 30일 미접근 자동 이동, $0.025/GB·월 + 접근 시 GB당 $0.01
• Archive: 90일 미접근, $0.008/GB·월 + 접근 시 GB당 $0.03

Lambda는 EFS를 마운트할 수 있다. Lambda는 boot 시 EFS access point를 통해 mount하고, 함수 안에서 일반 파일 IO처럼 read/write 가능. 큰 ML 모델(GB 단위)을 Lambda layer 한도(250MB) 안에 못 넣을 때 EFS에 둔다. 단 Lambda → EFS는 같은 VPC + 같은 subnet 또는 access point가 필요하고, 콜드 스타트 latency가 EFS mount 시간만큼 추가된다.

CLI 종합

# gp3 볼륨 생성 (independent IOPS/throughput)
aws ec2 create-volume \
  --volume-type gp3 \
  --size 500 \
  --iops 6000 \
  --throughput 250 \
  --availability-zone ap-northeast-2a \
  --encrypted \
  --kms-key-id alias/aws/ebs
 
# 볼륨을 인스턴스에 attach (Linux는 보통 /dev/xvdf 이후)
aws ec2 attach-volume \
  --volume-id vol-0abc \
  --instance-id i-0xyz \
  --device /dev/sdf
 
# Linux 안에서 파일시스템 생성 (XFS 권장)
sudo mkfs -t xfs /dev/nvme1n1  # Nitro는 /dev/nvme1n1 형태
sudo mkdir /data
sudo mount /dev/nvme1n1 /data
 
# /etc/fstab에 추가 (재부팅 시 자동 마운트, nofail로 부팅 실패 방지)
echo 'UUID=$(blkid -s UUID -o value /dev/nvme1n1) /data xfs defaults,nofail 0 2' \
  | sudo tee -a /etc/fstab
 
# 실시간 볼륨 수정 (downtime 없이 size/IOPS/throughput/type 변경)
aws ec2 modify-volume \
  --volume-id vol-0abc \
  --size 1000 \
  --iops 10000
 
# 자동화된 snapshot — Data Lifecycle Manager
aws dlm create-lifecycle-policy \
  --execution-role-arn arn:aws:iam::123:role/DLMRole \
  --description "Daily backup, retain 7 days" \
  --state ENABLED \
  --policy-details '{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "Backup", "Value": "Daily"}],
    "Schedules": [{
      "Name": "DailySchedule",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["03:00"]},
      "RetainRule": {"Count": 7}
    }]
  }'

정리

오늘 본 그림은 세 가지다. 첫째, EBS는 AZ 안의 분산 스토리지 fleet에 네트워크 너머 접근하는 block storage이고, gp3가 새 워크로드의 default이며 io2 Block Express가 인메모리 DB용 최상위 옵션이다. 둘째, Instance Store는 호스트 NVMe 직결이라 microsecond latency지만 stop·terminate·호스트 장애로 데이터가 사라지므로 영구 저장에 쓰지 않는다. 셋째, 여러 인스턴스가 같은 데이터를 본다면 EBS Multi-Attach가 아니라 EFS(또는 워크로드에 따라 FSx)가 정답이다.

다음 글에서는 그 위에 트래픽을 분산하는 layer — ALB·NLB·GWLB와 Auto Scaling Group을 본다. EBS가 한 인스턴스의 디스크 layer였다면, ELB·ASG는 여러 인스턴스 위의 가용성·확장성 layer다.

📌 오늘의 요약

1. EBS는 AZ 종속 분산 블록 스토리지. gp3가 새 워크로드의 default, io2/io2 Block Express는 미션 크리티컬 DB용. HDD(st1·sc1)는 부팅 불가.
2. Snapshot은 S3 위의 block-level incremental backup. lazy load 함정 → Fast Snapshot Restore. 장기 보관은 Snapshot Archive(75% 절감).
3. EBS 암호화는 KMS envelope encryption + AES-256-XTS. 미암호화 → 암호화 전환은 snapshot copy 경유 5단계.
4. Instance store는 호스트 NVMe 직결 microsecond latency지만 stop/terminate/호스트 장애로 데이터 소멸. 절대 영구 저장에 사용 금지.
5. 여러 인스턴스 공유는 EFS(NFS, multi-AZ), Windows 공유는 FSx for Windows, HPC는 FSx for Lustre. EBS Multi-Attach는 cluster-aware 워크로드 한정.