2개의 EBS 볼륨을 연결하고 있는 EC2 인스턴스롤 AMI로 복원하면 어떻게 될까?

2개의 EBS 볼륨을 연결하고 있는 EC2 인스턴스롤 AMI로 복원하면 어떻게 되는지 확인해 봤습니다.
2026.04.17
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번 블로그에서는 2개의 EBS 볼륨을 연결하고 있는 EC2 인스턴스롤 AMI로 복원하면 어떻게 되는지 확인해 봤습니다.
 현재 환경이번 테스트는 EC2 인스턴스를 생성할 때 두 개의 EBS 볼륨을 함께 연결한 상태를 기준으로 진행합니다.
EBS 2개가 제대로 생성되어 있는 것을 확인할 수 있습니다.
 AMI 생성EC2 인스턴스에서 AMI를 생성합니다.
스냅샷도 2개가 생성된 것을 확인할 수 있습니다.
여기서 스냅샷 하나는 [1.83 GiB]이고 하나는 [0 GiB]으로 표시되어 있는데, 스냅샷은 디스크 전체 크기를 저장하는 게 아니라 실제로 데이터가 들어있는 블록만 저장합니다.
두 번째 EBS 볼륨이 [0 GiB]으로 표시되는 이유는 데이터가 없어서 일 가능성이 크며, 예를 들어
볼륨만 붙이고 포맷 안 함
마운트 안 함
파일 저장 안 함
이 경우 저장할 블록이 없어서 스냅샷 크기가 0 GiB로 표시되는 것입니다.
[1.83 GiB] 스냅샷은 보통 루트 볼륨입니다
OS (Amazon Linux 등)
기본 패키지
로그 등
실제 사용 데이터가 있어서 용량이 잡히는 상황입니다.
 AMI로 복원AMI로 복원을 시도하면 EBS 볼륨이 2개로 설정되어 있는 것을 확인할 수 있습니다.
당연하게도 EBS도 2개가 생성되며, EC2 인스턴스에 연결되어 있습니다.
 나중에 EBS 볼륨을 연결한 경우에는?처음부터 2개의 EBS 볼륨을 EC2 인스턴스에 연결한 상태로 시작했지만, 나중에 EBS 볼륨을 연결한 경우에도 AMI 복원 시 2개의 EBS 볼륨이 생성될까요?
이번에는 마운트까지 진행한 상태에서 AMI를 취득합니다.
sudo mkfs -t ext4 /dev/nvme1n1
sudo mkdir /data
sudo mount /dev/nvme1n1 /data

df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          4.0M     0  4.0M   0% /dev
tmpfs             459M     0  459M   0% /dev/shm
tmpfs             184M  440K  183M   1% /run
/dev/nvme0n1p1    8.0G  1.7G  6.3G  21% /
tmpfs             459M     0  459M   0% /tmp
/dev/nvme0n1p128   10M  1.3M  8.7M  13% /boot/efi
tmpfs              92M     0   92M   0% /run/user/0
/dev/nvme1n1       98G   24K   93G   1% /data
AMI를 취득하니 2개의 스냅샷이 생성된 것을 확인할 수 있습니다.
EC2 인스턴스 생성 시 2개의 EBS 볼륨이 설정된 것을 확인할 수 있습니다.
EC2 인스턴스를 생성해 보면, 2개의 EBS 볼륨이 생성되어 있습니다.
EC2 내부에서 확인해 보면, 루트 볼륨은 연결되어 있지만, 추가 연결한 볼륨은 마운트가 되어있지 않기 때문에 별도로 마운트 작업을 실시할 필요가 있습니다.
원인으로는 AMI는 디스크 상태는 복사하지만 마운트는 OS의 설정이며,NVMe 환경에서는 디바이스 이름이 바뀔 수 있기 때문에 자동 마운트 실패하는 것입니다.
lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0    8G  0 disk
├─nvme0n1p1   259:2    0    8G  0 part /
├─nvme0n1p127 259:3    0    1M  0 part
└─nvme0n1p128 259:4    0   10M  0 part /boot/efi
nvme1n1       259:1    0  100G  0 disk
 결론AMI를 통해 EC2를 복원하면 EBS 볼륨은 개수 그대로 생성된다
스냅샷은 실제 데이터만 저장되기 때문에 0 GiB로 표시될 수 있다
하지만 마운트 상태는 복원되지 않으며, 별도의 설정이 필요하다
즉, EBS는 복원되지만 마운트는 자동으로 복원되지 않는다 가 핵심입니다.
따라서 실무에서는 /etc/fstab을 활용한 자동 마운트 설정이 필수적입니다.
 마무리이번 블로그를 통해 EC2 인스턴스에서 여러 개의 EBS 볼륨을 사용하는 경우, AMI 생성 및 복원 과정에서 어떤 변화가 발생하는지를 확인해보았습니다.
결론적으로 AMI를 생성하면 EC2에 연결된 EBS 볼륨 개수만큼 각각 스냅샷이 생성되며, 각 볼륨은 독립적으로 관리된다는 것을 확인할 수 있었습니다. 이때 중요한 점은 스냅샷의 크기가 반드시 EBS 볼륨 전체 용량과 동일하지 않다는 점입니다. 스냅샷은 디스크 전체를 그대로 저장하는 것이 아니라, 실제로 데이터가 기록된 블록만 저장하기 때문에 사용되지 않은 영역이 있는 경우 0 GiB로 표시될 수도 있습니다.
또한 AMI를 통해 EC2 인스턴스를 복원하면 EBS 볼륨 자체는 정상적으로 생성되지만, 마운트 상태까지 자동으로 복원되지는 않는다는 점도 확인할 수 있었습니다. 이는 AMI가 디스크 이미지와 스냅샷을 기반으로 인스턴스를 복제하는 기능이지만, 운영체제 내부 설정(예: /etc/fstab)까지 동일하게 보장하는 것은 아니기 때문입니다.
특히 NVMe 기반 EC2 환경에서는 디바이스 이름이 /dev/nvme1n1과 같이 동적으로 변경될 수 있기 때문에, 단순히 디바이스 경로에 의존한 설정은 안정적이지 않을 수 있습니다. 이러한 이유로 실무에서는 UUID 기반으로 마운트를 설정하는 방식이 권장됩니다.
이번 테스트를 통해 확인할 수 있었던 핵심 내용은 다음과 같습니다.
AMI 생성 시 EBS 볼륨은 개수만큼 각각 스냅샷으로 생성됩니다
스냅샷 용량은 실제 데이터 사용량에 따라 달라질 수 있습니다
AMI 복원 시 EBS 볼륨은 자동으로 생성되지만 마운트는 자동으로 복원되지 않습니다
NVMe 환경에서는 디바이스 이름이 변경될 수 있어 추가 확인이 필요합니다
즉, AMI는 인프라를 빠르게 복제하는 데에는 매우 유용하지만, 운영 환경의 설정까지 완전히 동일하게 복원해주는 기능은 아니라는 점을 이해하는 것이 중요합니다.
따라서 실무에서는 AMI를 기반으로 인스턴스를 복원한 이후 반드시 다음과 같은 작업을 수행해야 합니다.
lsblk 및 df -h를 통한 디스크 상태 확인
필요한 경우 수동 마운트 수행
재부팅을 고려한 /etc/fstab 설정
이러한 과정을 통해 동일한 환경을 안정적으로 재현할 수 있습니다.
결론적으로 AMI는 서버를 손쉽게 복제할 수 있는 강력한 기능이지만, 운영 설정까지 자동으로 복제해주지는 않기 때문에 별도의 후처리 작업이 필요하다는 점을 이해하는 것이 중요합니다.