AWS DVA 항해기 - EC2 인스턴스 스토리지 - EBS + EBS 스냅샷

에옹이다아옹·2025년 11월 9일

DVA aws

AWS-DVA

목록 보기

9/21

❓EBS(Elastic Block Store) Volume

=> 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브(실제 물리적인 연결이 있는 것은 아님)

EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터 지속 가능 => 인스턴스를 재성성하고 EBS 볼륨을 마운트하면 데이터를 다시 받을 수 있음

AZ 단위 리소스라서, EC2와 같은 AZ에 있어야 붙일 수 있음
ex) EBS 볼륨이 us-east-1a에서 생성 => us-east-1b 인스턴스에 붙일 수 ❌

하지만 스냅샷을 이용하면 다른 가용영역(AZ)로도 옮길 수 있음

CCP 레벨:
하나의 EBS는 하나의 인스턴스에만 마운트 가능 BUT 하나의 인스턴스는 여러개의 EBS를 가질 수 있다‼️

Associate 레벨:
일부 EBS 타입에 한해 여러 EC2 동시 부착 가능

EBS 볼륨이 인스턴스와 통신하기 위해서는 네트워크가 필요 => 컴포터가 다른 서버에 도달할 때 지연이 발생할 수 있음

EBS 볼륨은 네트워크 드라이브기 때문에 인스턴스에 빠르게 붙기도 떨어지기도 함

용량을 미리 결정해야 함(size: GB, IOPS(단위 초당 전송 수))
why?

블록 주소 공간 고정 필요
- OS는 디스크를 “0번 블록~N번 블록”처럼 연속된 주소 범위로 인식
  => 이 범위를 초기에 선언해야 파티션/파일시스템을 안정적으로 만들 수 있음 (중간에 맘대로 줄였다 늘리면 데이터 맵이 깨짐)
예측 가능한 성능·격리
- EBS는 멀티 테넌트 스토리지 위에 프로비저닝(예약)된 논리 디스크를 만들어 주는 구조
- 크기와 타입에 따른 성능/내구성 보장(특히 io1/io2의 IOPS 보장)을 위해 자원을 미리 예약해야 함
- gp3는 IOPS/처리량을 용량과 분리해 설정할 수 있지만, 기본이 되는 블록 공간(GB)은 여전히 정의해야 해야 함

과금 모델과 리소스 관리
- EBS는 GB-월 단위로 과금(스냅샷/프로비저닝 IOPS/Throughput은 별도)
  => 미리 크기를 정하면 AWS 입장에서도 용량 계획·파편화 관리가 가능하고, 사용자 입장에서도 비용 예측이 쉽다
스냅샷/복구·마이그레이션의 일관성
- 스냅샷은 증분 백업이지만, 복구 시엔 동일한 블록 주소 범위로 복원
- 주소 공간이 고정되어 있어야 스냅샷 → 볼륨 재생성/리전 복사/FSR 같은 기능이 안전하게 동작

ec2 인스턴스를 통해 ebs 볼륨을 생성하는 경우 "종료 시 삭제" 속성이 존재

기본적으로 root EBS 볼륨은 인스턴스 종료와 함께 삭제되도록 설정

EBS 볼륨 만들어보기

EC2 Instance에서 인스턴스 클릭 후 Storage 탭을 클릭하면 Block devices에서 지금 사용중인 EBS가 보인다

대부분의 경우 (= EBS-backed AMI사용)
EC2를 생성하면 루트 EBS 볼륨이 자동으로 함께 생성·붙음

Create volume 버튼 클릭

EC2> Instances에 Networking 탭에서 Availability zone 확인 가능

인스턴스를 선택하고 볼륨을 연결한다

다시 Instances의 내 인스턴스에서 Storage 탭을 클릭해서 스크롤한 다음 Block devices를 확인하면 방금 연결한 볼륨이 목록에 뜨는 것을 확인할 수 있다

인스턴스를 종료하면 EBS 볼륨은 어떻게 될까?

최상단의 EBS 볼륨을 보면 Delete on termiation에 Yes 표시가 되어있는데

이는 Instance를 생성할 때 우리가 Delete on termination에 Yes로 체크했기 때문이다

실제로 내가 Instance를 종료하고 다시 EBS 볼륨 목록을 조회하면

첫번째 EBS 볼륨이 사라진 것을 확인할 수 있다

EBS 스냅샷

EBS 볼륨의 특정 시점에서의 백업 /EBS의 데이터 저장 상태에 대해 사진(백업본)을 찍어둔 개념

EBS 스냅샷을 다른 가용 영역 또는 다른 리전에 복사 가능

EBS 볼륨을 한 인스턴스에서 다른 인스턴스로 전송하는 방법이라고도 할 수 있다

특징

증분 백업: 첫 스냅샷은 사용 중 블록 전체, 이후엔 변경 블록만 저장 → 비용/시간 절감

맨 왼쪽부터 스냅샷이 생성된 순서에 따라 "Snapshots A-> B-> C"로 표현하고 있으며, 볼륨에 대한 데이터가 변경될 때마다 스냅샷을 생성하는 순서를 "State"로 표현하고 있다.

State 1 부터 살펴보면, 15GiB 용량을 가진 EBS 볼륨에서 10GiB의 데이터를 가지고 있고, 해당 볼륨에 대한 첫번째 스냅샷을 생성한다면 스냅샷 A가 가진 용량은 10GiB가 됨

State 2 에서는 기존 EBS 볼륨의 10GiB 데이터에서 4GiB의 데이터가 변경(changed)되었는데, 해당 시점에서 두번째 스냅샷을 생성한다면 스냅샷 B는 변경된 4GiB의 데이터를 가지며, 변경되지 않은 6GiB에 대해서는 스냅샷 A의 부분을 참조(referenced)

(❕이 시점에서 10GiB 데이터를 가진 볼륨에 대한 스냅샷이 2개 생성되었지만 실제로 스냅샷이 가진 데이터의 크기는 A -> 10GiB + B -> 4 GiB으로 14GiB가 됨)

State 3 에서는 기존 10GiB 데이터를 가지고 있는 볼륨에 2GiB 크기의 새로운 데이터가 추가(added)되었으며, 해당 시점에서 세번째 스냅샷을 생성한다면 스냅샷 C는 새로 추가된 2GiB의 데이터를 가지며, 스냅샷 A의 6GiB, 스냅샷 B의 4GiB의 데이터를 참조(referenced)

정리하자면,

Snapshot A : 10GiB 데이터를 가짐 (EBS 볼륨이 가지고 있는 데이터 용량 : 10GiB)
Snapshot B : 4GiB 데이터를 가짐 (EBS 볼륨이 가지고 있는 데이터 용량 : 기존의 6GiB + 변경된 4GiB)
Snapshot C : 2GiB 데이터를 가짐 (EBS 볼륨이 가지고 있는 데이터 용량 : 기존의 10GIB + 추가된 2GIB 으로 12GiB)
Snapshot A + B + C 저장에 필요한 S3의 용량은 10 + 4 + 2 로 16GiB이 된다. 따라서 사용자는 16GiB에 대한 스냅샷 비용을 지불하면 됨

(❕ 스냅샷은 EBS의 데이터를 S3에 백업하는 방식으로 생성)

복원 성능: 스냅샷에서 만든 볼륨은 지연 로딩(lazy loading) → 초기 읽기 지연
- 해결: Fast Snapshot Restore(FSR) 활성화(특정 AZ 예열) 또는 수동 프리리드
  - FSR(Fast Snapshot Restore)?
  => 스냅샷을 처음 사용할 때 대기 시간이 없도록 스냅샷을 완전히 초기화하는 것
  => 스냅샷이 매우 클 때 EBS 볼륨을 초기화하거나 빠르게 인스턴스화해야하는 경우에 유리
  => 하지만 비용이 많이 든다

비용/보존: GB-월로 과금(증분 기준) + API 호출
- Snapshot Archive: 장기보관용 저렴, 대신 복원에 몇 시간
  - 스냅샷을 최대 75%% 더 저렴한 아카이브 티어로 옮길 수 있는 기능
  - 스냅샷을 아카이브 티어로 옮기면 아카이브를 복원하는 데 24시간에서 72시간 정도 걸림
- Recycle Bin: 삭제 보호(보존 규칙)
  - EBS 스냅샷을 영구적으로 삭제하는 대신 휴지통에 보관 => 실수로 삭제한 경우 복구가 가능
  - 보관 기간은 하루에서 1년까지 설정 가능!