백업의 가장 순진한 정의는 "데이터를 통째로 한 번 더 복사하는 것"이다. 그런데 1TB 볼륨을 매시간 통째로 복사하면 하루에 24TB, 한 달이면 720TB가 쌓인다. 이건 백업이 아니라 비용 폭탄이다. EBS Snapshot이 영리한 건 이 순진한 정의를 버리고 "지난번 백업 이후 바뀐 블록만 기록한다"는 증분(incremental) 모델을 택했기 때문이다. 첫 스냅샷만 전체 크기고, 그 다음부터는 변경분만 쌓인다. 1TB 볼륨이라도 하루에 10GB만 바뀌면 두 번째 스냅샷은 10GB어치만 차지한다.
이 한 가지 설계 결정에서 EBS Snapshot의 모든 특성이 파생된다. 왜 스냅샷을 지워도 다른 스냅샷이 멀쩡한지, 왜 AMI를 지워도 스냅샷이 남는지, 왜 새 볼륨의 첫 IO가 느린지, 왜 비용이 직관과 다르게 나오는지 — 전부 "변경된 블록만 기억한다"는 원리를 따라가면 설명된다. 이 글은 그 내부 구조를 파고든다.
EBS Snapshot이 "S3에 저장된다"는 말은 맞지만 오해를 부른다. 사용자가 보는 S3 버킷에 snapshot.img 파일이 놓이는 게 아니다. EBS는 볼륨을 고정 크기 블록(보통 512KiB 단위)으로 쪼개 관리하고, 스냅샷은 그 블록들을 가리키는 **포인터의 집합 + 메타데이터(매니페스트)**로 존재한다