기본개념 · 6장

EBS와 블록 스토리지

블록 스토리지 문항은 대개 두 갈래로 갈립니다. 어느 볼륨 타입을 고를 것인가와 이 데이터가 인스턴스보다 오래 살아남아야 하는가입니다. 전자는 IOPS와 처리량 요구가, 후자는 인스턴스 스토어의 휘발성이 답을 정합니다. 그리고 볼륨 타입 판단에는 2025년에 바뀐 숫자가 걸려 있습니다.

이 장은 고성능 아키텍처 설계(24%)와 비용 최적화 아키텍처 설계(20%)에 걸칩니다. 18장 중 가장 짧지만, 여기서 다루는 gp3 상한은 시중 자료가 가장 자주 틀리는 항목입니다.

학습 목표

Amazon EBS가 네트워크로 연결된 블록 스토리지라는 성격에서 따라 나오는 제약을 설명할 수 있습니다.
EBS와 인스턴스 스토어의 수명 차이를 근거로 어떤 데이터를 어디에 둘지 판단할 수 있습니다.
볼륨 타입 여섯 가지를 SSD와 HDD로 나누고, IOPS 요구와 처리량 요구에 맞는 타입을 고를 수 있습니다.
gp3의 현행 상한을 말하고, 시중 자료에 남아 있는 옛 값과 구분할 수 있습니다.
증분 스냅샷의 과금·삭제 동작과 스냅샷·AMI·볼륨의 관계를 설명할 수 있습니다.
EBS 암호화가 스냅샷과 AMI로 전파되는 경로를 따라가고, 미암호화 볼륨을 암호화로 바꾸는 절차를 설명할 수 있습니다.

EBS는 네트워크 너머에 있는 디스크다

Amazon EBS 볼륨은 인스턴스에 물리적으로 꽂혀 있지 않습니다. 네트워크로 연결된 블록 디바이스이고, 인스턴스와는 별개의 수명을 가집니다. 이 한 가지 사실에서 실무와 시험의 결론이 대부분 따라 나옵니다.

인스턴스를 종료해도 볼륨은 남길 수 있고, 다른 인스턴스에 다시 붙일 수 있습니다.
볼륨은 특정 가용 영역에 속합니다. 다른 가용 영역의 인스턴스에는 붙일 수 없습니다.
가용 영역이나 리전을 넘기려면 스냅샷을 거쳐야 합니다.
인스턴스가 중지되어 있어도 볼륨 요금은 계속 발생합니다.

인스턴스 스토어 · Amazon EBS · Amazon EFS의 연결 위치 비교 — 인스턴스 스토어는 호스트에 물리적으로 붙어 있고, EBS는 네트워크 너머의 블록 볼륨이며, EFS는 여러 가용 영역의 여러 인스턴스가 동시에 공유하는 파일 시스템입니다

EBS와 인스턴스 스토어 — 무엇을 잃는가 SAA 빈출

인스턴스 스토어(instance store)는 호스트 컴퓨터에 물리적으로 붙어 있는 디스크입니다. 네트워크를 거치지 않으므로 지연이 매우 낮지만, 그 대가로 데이터가 인스턴스의 수명 동안만 유지됩니다.

Amazon EBS와 인스턴스 스토어 비교
항목	Amazon EBS	인스턴스 스토어
연결 방식	네트워크로 연결된 블록 디바이스	호스트에 물리적으로 부착된 디스크
인스턴스 재부팅	데이터 유지	데이터 유지
인스턴스 중지 · 최대 절전	데이터 유지	데이터 소실
인스턴스 종료	기본 동작은 루트 볼륨 삭제이며 설정으로 보존 가능	데이터 소실
기반 디스크 장애	인스턴스 수명과 독립적으로 유지되도록 설계되었고, 스냅샷으로 추가 보호한다	데이터 소실 — 문서가 명시하는 소실 조건이다
분리 후 재연결	가능 — 같은 가용 영역 안에서	불가 — 시작 시에만 지정할 수 있다
스냅샷	가능	불가 — AMI에도 보존되지 않는다
적합한 데이터	운영체제, 데이터베이스 파일, 유지해야 하는 애플리케이션 데이터	버퍼, 캐시, 스크래치 데이터, 여러 인스턴스에 복제해 둔 임시 데이터

표에서 가장 자주 출제되는 줄은 인스턴스 중지입니다. 중지했다 시작하면 인스턴스가 다른 호스트로 옮겨질 수 있고, 그 순간 이전 호스트의 인스턴스 스토어 데이터는 접근할 수 없게 됩니다. 재부팅은 다릅니다 — 인스턴스는 계속 같은 호스트에서 running 상태이므로 데이터가 남습니다 (5장 인스턴스 수명주기).

인스턴스 스토어를 포함하는 인스턴스 타입은 이름에 d가 붙습니다. 인스턴스 스토어가 정답이 되는 경우는 "매우 낮은 지연이 필요하고, 데이터가 사라져도 되거나 다른 곳에 복제본이 있다"는 조건이 모두 성립할 때입니다.

볼륨 타입 — SSD 넷과 HDD 둘

EBS 볼륨 타입은 API 열거값 기준으로 gp3 · gp2 · io1 · io2 · st1 · sc1 · standard입니다. 앞의 넷이 SSD, 다음 둘이 HDD이고, standard는 구세대 마그네틱 볼륨입니다. 볼륨 타입을 지정하지 않으면 기본값은 gp2입니다.

EBS 볼륨 타입별 분류 · 크기 범위 · 프로비저닝 가능한 성능
타입	분류	크기 범위	IOPS	처리량	부트 볼륨
`gp3`	범용 SSD	1 – 65,536 GiB (64 TiB)	3,000(기본) – 80,000	125(기본) – 2,000 MiB/s	가능
`gp2`	범용 SSD	1 – 16,384 GiB (16 TiB)	별도로 지정할 수 없음 — 크기가 성능을 결정	별도로 지정할 수 없음	가능
`io1`	프로비저닝된 IOPS SSD	4 – 16,384 GiB (16 TiB)	100 – 64,000	지정 파라미터 없음	가능
`io2`	프로비저닝된 IOPS SSD	4 – 65,536 GiB (64 TiB)	100 – 256,000	지정 파라미터 없음	가능
`st1`	처리량 최적화 HDD	125 – 16,384 GiB	지정 파라미터 없음	지정 파라미터 없음	불가
`sc1`	콜드 HDD	125 – 16,384 GiB	지정 파라미터 없음	지정 파라미터 없음	불가
`standard`	마그네틱(구세대)	1 – 1,024 GiB	지정 파라미터 없음	지정 파라미터 없음	구세대이므로 새로 쓰지 않는다

프로비저닝할 수 있는 최대 IOPS 비교. io2가 압도적으로 높고, gp3가 io1보다 높다는 것이 이 그림의 결론입니다 — "IOPS가 필요하면 무조건 프로비저닝된 IOPS 타입"이라는 옛 상식이 더 이상 성립하지 않습니다. gp2는 확인된 값이 없어 제외했습니다

볼륨 타입별 크기 범위. gp3와 io2만 64 TiB까지 올라가고, HDD 두 타입은 125 GiB부터 시작한다는 점이 선택을 가릅니다

gp3 상한은 2025년 9월에 올라갔다 SAA 빈출

2025년 9월, gp3의 최대 크기와 최대 프로비저닝 성능이 상향되었습니다.

`gp3` 상한의 변경 전후 비교
항목	이전 값 (시중 자료 다수)	현행 값
최대 크기	16 TiB	64 TiB (65,536 GiB)
최대 IOPS	16,000	80,000
최대 처리량	1,000 MiB/s	2,000 MiB/s
기준값	3,000 IOPS / 125 MiB/s	3,000 IOPS / 125 MiB/s 변경 없음

한국어 SAA 자료 상당수와 여러 블로그가 아직 "gp3는 최대 16,000 IOPS, 1,000 MiB/s"로 적고 있습니다. 그 서술로 공부하면 "gp3로는 부족하니 io1으로 가야 한다"는 잘못된 결론에 이릅니다. 현행 기준으로는 gp3의 최대 IOPS가 io1보다 높습니다.

바뀐 것은 상한이고 기준값은 그대로입니다. gp3는 크기와 무관하게 3,000 IOPS와 125 MiB/s를 기본으로 제공하며, 더 필요한 만큼만 따로 프로비저닝합니다. 성능과 용량이 분리되어 있다는 것이 gp3의 핵심 성질입니다.

gp3의 옛 값과 현행 값 비교. 세 항목이 모두 상향되었고 기준값만 그대로입니다. 이 차이를 모르면 볼륨 타입 선택 문항에서 불필요하게 비싼 답을 고르게 됩니다

SSD와 HDD — IOPS인가 처리량인가

SSD 계열은 작은 I/O가 자주 일어나는 트랜잭션 워크로드에, HDD 계열은 큰 블록을 순차적으로 읽고 쓰는 스트리밍 워크로드에 맞습니다. 판단 기준은 "빠른가"가 아니라 지배적인 성능 지표가 IOPS인가 처리량인가입니다.

HDD 두 타입에는 결정적인 제약이 하나 더 있습니다 — st1과 sc1은 부트 볼륨으로 쓸 수 없습니다. "운영체제를 sc1에 올려 비용을 줄인다"는 선택지는 그 자리에서 소거됩니다.

볼륨 타입 선택 기준

요구사항에 따른 EBS 볼륨 타입 배정
요구사항	선택	근거
대부분의 범용 워크로드, 부트 볼륨	`gp3`	기준 성능이 크기와 무관하고, 필요한 만큼만 성능을 따로 올릴 수 있다
매우 높은 IOPS가 지속적으로 필요한 데이터베이스	`io2`	프로비저닝 가능한 IOPS 상한이 가장 높다
여러 인스턴스가 한 볼륨을 동시에 붙여야 함	`io1` 또는 `io2`	멀티 어태치는 이 두 타입에서만 지원된다
큰 파일을 순차적으로 읽는 빅데이터 · 로그 처리	`st1`	처리량 중심 워크로드에 맞고 SSD보다 저렴하다. 단 부트 볼륨 불가
접근 빈도가 매우 낮은 아카이브성 데이터	`sc1`	EBS 계열에서 가장 저렴하다. 단 부트 볼륨 불가
지연이 극도로 낮아야 하고 데이터는 휘발성이어도 됨	인스턴스 스토어	네트워크를 거치지 않는다. 대신 중지·종료 시 소실된다

비용 관점의 기본 판단은 gp2를 쓰고 있다면 gp3로 옮기는 것입니다. gp2는 성능이 크기에 묶여 있어서, 성능이 필요하면 필요 없는 용량까지 사야 합니다. gp3는 용량과 성능을 따로 정하므로 같은 성능을 더 작은 용량으로 얻을 수 있습니다.

볼륨 타입 문항의 판단 순서입니다.

부트 볼륨인가 — 그렇다면 HDD 두 타입은 즉시 소거합니다.
지배 지표가 IOPS인가 처리량인가 — IOPS면 SSD, 처리량이면 HDD입니다.
여러 인스턴스가 동시에 붙어야 하는가 — io1 · io2만 가능합니다. 다만 동시 접근이 파일 공유를 뜻한다면 답은 Amazon EFS일 가능성이 더 높습니다.
비용 한정어가 붙었는가 — 같은 성능을 gp3로 얻을 수 있다면 gp3입니다.

"IOPS 요구가 크면 자동으로 프로비저닝된 IOPS 타입"이라고 외우지 않습니다. 현행 gp3의 상한이 io1보다 높으므로, 요구 수치를 먼저 보고 판단해야 합니다.

인스턴스 쪽 한계도 함께 본다

볼륨에 IOPS를 아무리 프로비저닝해도 인스턴스가 받아 주지 못하면 소용이 없습니다. API 문서는 Nitro 시스템 기반 인스턴스는 최대 256,000 IOPS를, 그 외 인스턴스는 최대 32,000 IOPS를 지원한다고 명시합니다. 또한 인스턴스에 붙일 수 있는 EBS 볼륨 개수는 인스턴스 타입에 따라 다르고, 한도를 넘기면 연결 요청이 실패합니다. 스토리지 성능은 볼륨과 인스턴스 두 쪽의 최솟값이라는 점을 기억합니다.

볼륨 변경 — 대체로 무중단

현재 세대 인스턴스에 붙어 있는 볼륨이라면 크기 · 볼륨 타입 · IOPS를 인스턴스를 멈추지 않고 변경할 수 있습니다. 변경이 끝난 뒤에는 운영체제에서 파일 시스템을 확장해야 늘어난 공간을 쓸 수 있습니다. 하나의 볼륨은 24시간 이동 구간 안에서 최대 4회까지 변경할 수 있고, 이전 변경이 완료되기 전에는 다음 변경을 시작할 수 없습니다.

modify-volume.sh — gp2 볼륨을 gp3로 전환하며 성능을 지정 (리소스 ID는 예시입니다)

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 250

# 변경 진행 상황 확인
aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[].[ModificationState,Progress,TargetVolumeType]' \
  --output table

스냅샷 — 증분으로 저장되고 복원은 즉시 시작된다

EBS 스냅샷은 볼륨의 데이터를 Amazon S3에 백업하는 시점 복사본입니다. 여기서 "S3에 저장된다"는 것은 AWS가 관리하는 영역이라는 뜻이고, 우리 계정의 S3 버킷에 객체로 보이지는 않습니다.

증분 스냅샷의 실제 동작

볼륨의 첫 스냅샷은 전체 스냅샷이고, 이후 스냅샷은 직전 스냅샷 이후 변경되거나 추가된 블록만 담습니다. 전체 스냅샷의 크기도 볼륨 크기가 아니라 실제로 쓰인 데이터 크기로 정해집니다. 200 GiB 볼륨에 50 GiB만 쓰여 있다면 첫 스냅샷은 50 GiB입니다.

여기서 자주 놓치는 지점이 삭제 동작입니다. 스냅샷을 지우면 그 스냅샷만 참조하던 데이터만 제거되고, 다른 스냅샷도 참조하는 블록은 남습니다. 그래서 스냅샷을 하나 지웠다고 저장 비용이 그만큼 줄지 않습니다.

복원은 반대 방향입니다. 스냅샷으로 볼륨을 만들면 데이터가 백그라운드에서 로드되는 동안에도 볼륨을 바로 쓸 수 있고, 아직 로드되지 않은 블록에 접근하면 그 블록을 즉시 내려받습니다. "복원이 끝날 때까지 기다려야 한다"는 서술은 사실이 아닙니다.

사용 중인 볼륨의 스냅샷도 찍을 수 있지만, 스냅샷은 명령을 낸 시점까지 볼륨에 기록된 데이터만 담습니다. 애플리케이션이나 운영체제가 캐시에 들고 있던 데이터는 빠질 수 있으므로, 일관성이 중요하면 파일 시스템 쓰기를 잠깐 멈추거나 볼륨을 언마운트한 뒤 찍습니다. 여러 볼륨에 걸친 다중 볼륨 스냅샷을 쓰면 인스턴스에 붙은 볼륨들의 시점을 맞춰 한 번에 찍을 수 있습니다.

스냅샷 · AMI · 볼륨의 관계

볼륨에서 스냅샷으로, 스냅샷에서 AMI와 새 볼륨으로 이어지는 관계 — AMI는 스냅샷에 시작 메타데이터와 블록 디바이스 매핑을 더한 것이고, 리전 간 이동은 스냅샷 또는 AMI 복사로 일어납니다

AMI는 스냅샷 + 시작 메타데이터라고 이해하면 관계가 정리됩니다. EBS 기반 인스턴스에서 AMI를 만들면 연결된 볼륨의 스냅샷이 함께 생성되고, AMI에는 그 스냅샷을 어떤 디바이스에 붙일지 적은 블록 디바이스 매핑이 들어갑니다. 루트 볼륨 스냅샷 하나만 가지고 RegisterImage로 AMI를 만들 수도 있습니다.

스냅샷 · AMI · 볼륨의 범위와 이동 방법
리소스	범위	다른 위치로 옮기는 방법
EBS 볼륨	가용 영역 단위	스냅샷을 찍고 다른 가용 영역에서 볼륨을 새로 만든다
스냅샷	리전 단위	`CopySnapshot`으로 다른 리전에 복사한다
AMI	리전 단위	`CopyImage`로 복사하며, 복사는 대상 리전에서 시작한다

재해 복구 설계에서 이 표가 그대로 쓰입니다. 다른 리전으로 워크로드를 옮길 수 있게 하려면 스냅샷이나 AMI를 미리 복사해 두어야 하고, 그 복사 작업 자체를 자동화하는 것이 Amazon Data Lifecycle Manager나 AWS Backup의 역할입니다 (18장 비용 최적화·마이그레이션·재해 복구).

snapshot-and-copy.sh — 스냅샷 생성과 리전 간 복사 (리소스 ID와 리전은 예시입니다)

SNAP_ID=$(aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "nightly backup" \
  --query 'SnapshotId' --output text)

aws ec2 wait snapshot-completed --snapshot-ids "$SNAP_ID"

# 복사 명령은 대상 리전에서 실행합니다.
aws ec2 copy-snapshot \
  --source-region ap-northeast-2 \
  --source-snapshot-id "$SNAP_ID" \
  --description "DR copy" \
  --encrypted \
  --region us-west-2

암호화 — 한 번 켜지면 따라다닌다

EBS 암호화는 AWS KMS 키를 써서 봉투 암호화(envelope encryption) 방식으로 동작합니다. KMS가 데이터 키를 만들고 그 데이터 키를 우리가 지정한 KMS 키로 암호화해서 볼륨 메타데이터와 함께 저장합니다. 실제 디스크 I/O는 AES-256 데이터 키로 하이퍼바이저에서 암호화되며, 평문 데이터 키는 볼륨이 인스턴스에 붙어 있는 동안 메모리에만 존재합니다.

암호화된 볼륨을 쓰면 다음 네 가지가 함께 암호화됩니다.

볼륨 안에 저장된 데이터
볼륨과 인스턴스 사이를 오가는 데이터
그 볼륨에서 만든 모든 스냅샷
그 스냅샷에서 만든 모든 볼륨

암호화와 복호화는 투명하게 처리되어 애플리케이션이 따로 할 일이 없고, 모든 볼륨 타입에서 암호화를 지원하며 IOPS 성능도 사실상 동일합니다. "암호화하면 느려지니 성능이 중요한 볼륨은 끈다"는 판단은 근거가 없습니다.

EBS 암호화의 전파 경로 — KMS 키로 만든 볼륨에서 나온 스냅샷과 그 스냅샷에서 만든 볼륨·AMI가 암호화를 상속하며, 미암호화 볼륨을 암호화하려면 스냅샷을 암호화 옵션으로 복사하는 단계를 거쳐야 합니다

계정 수준 기본 암호화

계정과 리전 단위로 EBS 기본 암호화를 켤 수 있습니다. 켜면 그 이후에 만드는 볼륨이 항상 암호화되며, 키를 따로 지정하지 않으면 EBS용 기본 KMS 키가 쓰입니다. 중요한 제약이 둘 있습니다.

기존 볼륨의 암호화 상태는 바뀌지 않습니다. 앞으로 만드는 볼륨에만 적용됩니다.
기본 암호화를 켠 뒤에는 암호화를 지원하지 않는 인스턴스 타입으로 시작할 수 없습니다.

이미 만든 미암호화 볼륨을 암호화하려면

볼륨의 암호화 상태는 제자리에서 바꿀 수 없습니다. 스냅샷을 거치는 우회 경로를 써야 합니다.

미암호화 볼륨의 스냅샷을 만듭니다.
그 스냅샷을 암호화 옵션을 켜서 복사합니다.
복사된 암호화 스냅샷에서 새 볼륨을 만듭니다.
인스턴스를 중지하고 기존 볼륨을 떼어 낸 뒤 새 볼륨을 붙입니다.

같은 이유로 암호화된 AMI를 만들려면 스냅샷 복사 단계에서 암호화를 지정하고 그 스냅샷으로 AMI를 등록합니다. 암호화된 스냅샷에서 만든 볼륨은 자동으로 암호화됩니다.

encrypt-existing-volume.sh — 미암호화 볼륨을 암호화 볼륨으로 전환 (리소스 ID는 예시입니다)

SNAP_ID=$(aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --query 'SnapshotId' --output text)
aws ec2 wait snapshot-completed --snapshot-ids "$SNAP_ID"

# 복사 단계에서 암호화를 켭니다. 고객 관리형 키를 지정할 수 있습니다.
ENC_SNAP=$(aws ec2 copy-snapshot \
  --source-region ap-northeast-2 \
  --source-snapshot-id "$SNAP_ID" \
  --encrypted \
  --kms-key-id alias/ebs-app-key \
  --query 'SnapshotId' --output text)

aws ec2 create-volume \
  --snapshot-id "$ENC_SNAP" \
  --availability-zone ap-northeast-2a \
  --volume-type gp3

멀티 어태치 — 공유 파일 시스템이 아니다

EBS 멀티 어태치(Multi-Attach)는 볼륨 하나를 여러 인스턴스에 동시에 붙이는 기능입니다. 조건이 상당히 엄격합니다.

멀티 어태치의 조건과 제약
항목	내용
지원 볼륨 타입	`io1`과 `io2`만 지원한다
연결 가능 인스턴스	같은 가용 영역의 Nitro 시스템 기반 인스턴스 최대 16대
기본값	비활성. 볼륨 생성 시 명시적으로 켜야 한다
부트 볼륨	불가
파일 시스템	XFS·EXT4 같은 일반 파일 시스템은 쓸 수 없다. 클러스터 파일 시스템이 필요하다
I/O 펜싱	지원하지 않는다. 쓰기 순서 제어는 애플리케이션의 책임이다
성능	연결된 인스턴스들의 합산 성능이 볼륨의 프로비저닝된 성능을 넘지 못한다

흔한 오해

시험 포인트 정리

6장 핵심 암기 항목과 함정
항목	사실	함정
EBS의 범위	가용 영역 단위. 다른 가용 영역의 인스턴스에는 붙일 수 없다	볼륨을 다른 가용 영역으로 직접 옮기려 함
기본 볼륨 타입	타입을 지정하지 않으면 `gp2`	기본이 `gp3`라고 가정
`gp3` 상한 (2025-09)	64 TiB · 80,000 IOPS · 2,000 MiB/s. 기준값은 3,000 IOPS · 125 MiB/s	옛 값(16 TiB · 16,000 · 1,000)으로 판단해 불필요하게 `io1`을 고름
`io1`과 `io2`	`io1`은 최대 64,000 IOPS · 16 TiB, `io2`는 최대 256,000 IOPS · 64 TiB	두 타입의 상한을 같다고 봄
`gp2`의 성능	`Iops` 파라미터를 받지 않는다 — 크기가 성능을 결정한다	`gp2`에 IOPS를 따로 지정할 수 있다고 답함
HDD 부트 볼륨	`st1`과 `sc1`은 부트 볼륨으로 쓸 수 없다	비용 절감을 이유로 운영체제를 `sc1`에 두는 선택지를 고름
인스턴스 쪽 IOPS 한계	Nitro 기반은 최대 256,000, 그 외는 최대 32,000 IOPS	볼륨만 보고 성능을 계산
인스턴스 스토어의 휘발성	중지 · 최대 절전 · 종료 · 디스크 장애 시 소실. 재부팅은 유지	중지와 재부팅을 같은 것으로 취급
인스턴스 스토어와 AMI	인스턴스 스토어 데이터는 AMI에 보존되지 않는다	AMI로 데이터까지 옮길 수 있다고 가정
증분 스냅샷	첫 스냅샷만 전체이고 이후는 변경 블록만. 크기는 볼륨 크기가 아니라 데이터 크기	스냅샷마다 볼륨 전체가 복사된다고 생각
스냅샷 삭제	그 스냅샷만 참조하던 블록만 제거된다	스냅샷 하나를 지우면 그 크기만큼 절약된다고 답함
스냅샷 복원	백그라운드 로드 중에도 볼륨을 즉시 사용할 수 있다	복원 완료까지 기다려야 한다고 답함
AMI의 정체	스냅샷 + 블록 디바이스 매핑 + 시작 메타데이터. 리전 단위 리소스	AMI를 다른 리전에서 그대로 참조하려 함
암호화 전파	암호화 볼륨의 스냅샷과 그 스냅샷에서 만든 볼륨은 모두 암호화된다	스냅샷을 거치면 암호화가 풀린다고 생각
기존 볼륨 암호화	제자리 변경 불가. 스냅샷 → 암호화 복사 → 새 볼륨	"볼륨 설정에서 암호화를 켠다"는 선택지를 고름
기본 암호화	계정·리전 단위로 켜며 기존 볼륨에는 영향이 없다	켜면 기존 볼륨도 암호화된다고 답함
암호화 성능	모든 볼륨 타입에서 지원되고 IOPS 성능은 사실상 동일하다	성능을 이유로 암호화를 끄는 선택지를 고름
멀티 어태치	`io1`·`io2`만, 같은 가용 영역의 Nitro 인스턴스 최대 16대	다중 가용 영역 파일 공유 요구에 멀티 어태치를 고름
공유 파일 시스템	다중 가용 영역 공유는 Amazon EFS(또는 FSx)의 영역이다	EBS로 공유 스토리지를 만들려 함
볼륨 변경	크기·타입·IOPS를 대체로 무중단 변경. 24시간 안에 최대 4회, 이후 파일 시스템 확장 필요	볼륨을 키우면 파일 시스템도 자동으로 커진다고 가정

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

이어서 볼 곳

공식 문서 출처

이 장의 수치 · 기본값 · 동작은 모두 아래 문서에서 확인했습니다.

Amazon EC2 API 레퍼런스 — CreateVolume — 볼륨 타입별 크기 범위, gp3 3,000–80,000 IOPS와 125–2,000 MiB/s, io1 100–64,000 IOPS, io2 100–256,000 IOPS, Nitro 기반 인스턴스의 256,000 IOPS 한계, 기본 타입 gp2, st1·sc1의 부트 볼륨 사용 불가, 멀티 어태치 최대 16대
Amazon EBS 사용 설명서 — 볼륨 유형 — SSD와 HDD 분류, 각 타입의 대표 워크로드
Amazon EC2 사용 설명서 — 인스턴스 스토어 — 인스턴스 스토어 데이터가 디스크 장애 · 중지 · 최대 절전 · 종료 시 소실되고 재부팅에는 유지된다는 서술, AMI에 보존되지 않는다는 점, 시작 시에만 지정할 수 있다는 제약
Amazon EC2 사용 설명서 — EBS 스냅샷 — 증분 백업의 정의, 첫 스냅샷이 전체이고 이후가 증분이라는 점, 크기가 데이터 크기로 결정된다는 점, 삭제 시 해당 스냅샷만 참조하는 데이터가 제거된다는 점, 복원 중에도 볼륨을 즉시 사용할 수 있다는 점, 다중 볼륨 스냅샷
Amazon EC2 API 레퍼런스 — CreateSnapshot — 사용 중인 볼륨의 스냅샷이 명령 시점까지 기록된 데이터만 담는다는 서술
Amazon EC2 API 레퍼런스 — CopySnapshot — 리전 간 스냅샷 복사와 복사 시 암호화 결과가 결정되는 방식
Amazon EC2 API 레퍼런스 — CreateImage — AMI 생성 시 추가 볼륨의 블록 디바이스 매핑이 함께 담긴다는 서술
Amazon EC2 API 레퍼런스 — RegisterImage — 루트 볼륨 스냅샷으로 AMI를 등록할 수 있고, 스냅샷이 암호화되어 있으면 인스턴스 루트 볼륨도 암호화된다는 서술
Amazon EC2 사용 설명서 — Amazon EBS 암호화 — AES-256 데이터 키와 KMS 키의 관계, 저장 데이터·전송 데이터·스냅샷·파생 볼륨이 함께 암호화된다는 점, 모든 볼륨 타입에서 지원되며 성능 영향이 미미하다는 점
Amazon EC2 API 레퍼런스 — EnableEbsEncryptionByDefault — 계정·리전 단위 기본 암호화이며 기존 볼륨의 암호화 상태에는 영향이 없다는 서술
Amazon EBS 사용 설명서 — 멀티 어태치 — io1·io2 한정, 같은 가용 영역의 Nitro 인스턴스 최대 16대, 부트 볼륨 불가, 일반 파일 시스템 사용 시 데이터 손상 위험, I/O 펜싱 미지원
Amazon EC2 API 레퍼런스 — ModifyVolume — 크기·타입·IOPS의 무중단 변경, 24시간 이동 구간 안에서 최대 4회 제한, 변경 후 파일 시스템 확장 필요
Amazon EC2 API 레퍼런스 — AttachVolume — 인스턴스에 붙일 수 있는 볼륨 수가 인스턴스 타입에 따라 다르다는 서술