← 목록

EC2 복원 가이드: AMI + EBS 스냅샷 조합 복원

EC2 장애 시 AMI와 EBS 스냅샷을 조합하여 빠르게 복원하는 절차와 시나리오별 추천 방식 정리

2026-04-08AWSEC2BackupDevOps

들어가며

백업 현황을 정리하다가(AMI 갱신 계획) 빠진 게 하나 있다는 걸 알았다. 백업은 세어봤는데, 그걸로 어떻게 복구하는지는 아무 데도 적혀 있지 않았다.

복구 절차가 없는 백업은 반쪽이다. 장애가 나면 시간에 쫓기고, 그 상태에서 처음 해보는 작업은 실수가 나온다. 특히 이 작업에는 한 번 잘못하면 데이터를 날리는 단계가 섞여 있다. 그래서 순서를 적고, 위험한 지점을 따로 표시해뒀다.

개요

EC2 장애 시 AMI와 EBS 스냅샷을 조합하여 빠르게 복원하는 방법을 정리한다.

AMI는 주기적으로(주 1회), EBS 스냅샷은 자주(일 1회 또는 시간 단위) 생성해두는 것을 권장한다.

둘의 주기가 다른 이유는 되돌리려는 대상이 다르기 때문이다. OS와 앱 환경은 자주 바뀌지 않지만, 데이터는 계속 쌓인다. 바뀌는 속도가 빠른 것일수록 자주 찍어야 한다. 이 원칙 하나가 백업 주기를 정하는 기준이 된다.

백업 주기와 복구 범위

마지막 스냅샷과 장애 시점 사이의 데이터는 복구되지 않는다. 그 폭을 얼마까지 허용할지 정하는 게 스냅샷 주기를 정하는 일이다. 중요한 DB라면 스냅샷 주기를 줄이거나, MariaDB 복제 구성처럼 복제본을 따로 두는 쪽이 맞다.

전제 상황

항목설명
장애 상황EC2 인스턴스 복구 불가 (OS 커널 패닉, 인스턴스 장애 등)
AMI며칠 전 생성됨 (OS + 앱 환경 포함, 데이터는 생성 시점)
EBS 스냅샷장애 직전 시점의 데이터 볼륨 스냅샷 보유

복원 절차

Step 1. AMI로 새 인스턴스 실행

AMI에서 인스턴스를 Launch하여 OS + 앱 환경을 복원한다.

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type t3.medium \
  --key-name [my-key] \
  --security-group-ids sg-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --iam-instance-profile Name=[my-ec2-role] \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=restored-server}]'

콘솔: EC2 → AMIs → 해당 AMI 선택 → "Launch instance from AMI"

⚠️ 기존 인스턴스와 동일한 VPC, 서브넷, SG, IAM Role을 맞춰야 한다.

Step 2. EBS 스냅샷에서 최신 데이터 볼륨 생성

장애 직전 스냅샷으로부터 새 볼륨을 생성한다.

aws ec2 create-volume \
  --snapshot-id snap-xxxxxxxxxxxxxxxxx \
  --availability-zone ap-northeast-2a \
  --volume-type gp3 \
  --size 100 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=restored-data-vol}]'

⚠️ AZ는 Step 1에서 띄운 인스턴스와 반드시 동일해야 한다. 다르면 attach 불가.

Step 3. 오래된 데이터 볼륨 분리 (Detach)

AMI에 포함된 오래된 데이터 볼륨을 분리한다.

# 인스턴스에 붙어있는 볼륨 확인
aws ec2 describe-instances \
  --instance-ids i-xxxxxxxxxxxxxxxxx \
  --query 'Reservations[].Instances[].BlockDeviceMappings[]'
 
# 데이터 볼륨 분리 (예: /dev/xvdf)
aws ec2 detach-volume --volume-id vol-xxxxxxxxxxxxxxxxx

🚨 루트 볼륨(/dev/xvda)은 절대 분리하면 안 된다. 데이터 볼륨(/dev/xvdf, /dev/sdb 등)만 교체할 것.

Step 4. 최신 데이터 볼륨 연결 (Attach)

Step 2에서 생성한 볼륨을 인스턴스에 연결한다.

aws ec2 attach-volume \
  --volume-id vol-xxxxxxxxxxxxxxxxx \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --device /dev/xvdf

Step 5. 마운트 확인

SSH 접속 후 볼륨을 마운트한다.

lsblk                          # 볼륨 인식 확인
sudo mount /dev/xvdf /data     # 기존 마운트 포인트에 마운트
df -h                          # 마운트 상태 확인

🚨 이미 파일시스템이 있는 볼륨이므로 mkfs 하면 데이터가 날아간다. 바로 mount할 것.

Step 6. 네트워크 설정 복원

# Elastic IP 재연결
aws ec2 associate-address \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --allocation-id eipalloc-xxxxxxxxx
 
# ALB Target Group 등록 (ALB 뒤에 있었다면)
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:[account-id]:targetgroup/[my-tg]/xxxx \
  --targets Id=i-xxxxxxxxxxxxxxxxx

전체 흐름도

[장애 발생]
    │
    ▼
[Step 1] AMI로 새 인스턴스 Launch  ← OS + 앱 환경 복원
    │
    ▼
[Step 2] EBS 스냅샷 → 새 볼륨 생성  ← 최신 데이터 복원
    │
    ▼
[Step 3] 오래된 데이터 볼륨 Detach
    │
    ▼
[Step 4] 새 데이터 볼륨 Attach
    │
    ▼
[Step 5] 마운트 + 데이터 확인
    │
    ▼
[Step 6] 네트워크(EIP, TG) 복원
    │
    ▼
[서비스 정상화 확인]

실제로 시간을 먹는 곳

절차만 보면 명령 여섯 개다. 그런데 장애 상황에서 걸리는 시간은 명령을 치는 시간이 아니다.

단계예상보다 오래 걸리는 이유
AMI로 인스턴스 기동인스턴스 타입, AZ, SG, IAM Role을 기존과 맞추는 확인 작업
스냅샷에서 볼륨 생성볼륨 생성 자체는 빠르지만, 첫 접근 성능이 느리다
마운트와 데이터 확인정말 최신 데이터인지 확인하는 데 시간이 든다
네트워크 복원EIP, Target Group, DNS 중 하나를 빠뜨리면 다시 찾아야 한다

두 번째 항목은 알아두면 당황하지 않는다. 스냅샷에서 만든 볼륨은 데이터를 S3에서 필요할 때 가져오는 방식이라, 처음 읽는 블록은 평소보다 느리다. 복원 직후에 성능이 안 나온다고 해서 볼륨 설정이 잘못된 건 아니다. 시간이 급한 복구라면 Fast Snapshot Restore 같은 옵션을 미리 확인해두는 게 좋다.

성능 수치를 볼 때 설정값과 실제 낼 수 있는 값이 다르다는 건 EBS IOPS 8,000 설정에도 4,000만 사용되는 문제에서도 겪었다. 복구 직후의 느린 응답을 장애로 오해하지 않으려면 이런 성질을 미리 알고 있어야 한다.

복구 후에 남는 일

인스턴스가 뜨고 서비스가 응답하면 끝난 것 같지만, 복원된 서버는 새 인스턴스다. 기존 인스턴스 ID를 기준으로 걸어둔 것들이 전부 빠져 있다.

복구 직후는 정신없어서 이 부분이 잘 밀린다. 그러면 "복구는 했는데 그 서버만 알람이 안 오는" 상태로 몇 달이 간다. 체크리스트 마지막에 이 항목들을 넣어둔 이유다.

AMI vs EBS 스냅샷 사용 시나리오

상황추천 방식
인스턴스 완전 장애, 새로 띄워야 함AMI
데이터 볼륨만 손상됨EBS 스냅샷
루트 볼륨 교체 (OS 레벨 문제)EBS 스냅샷 (루트 볼륨 swap)
다른 AZ/리전으로 복구AMI (리전 간 복사 후 launch)
특정 시점 데이터 롤백EBS 스냅샷
환경 + 최신 데이터 모두 복원AMI + EBS 스냅샷 조합

주의사항 체크리스트

배운 점

복구 절차는 만들어 두는 것보다 밟아보는 게 중요하다. AZ 불일치나 루트 볼륨 분리 같은 항목은 문서로 읽으면 당연한데, 실제 상황에서는 시간에 쫓겨 빠뜨린다. 그래서 위험한 단계는 본문에서 빼서 체크리스트로 따로 만들었다. 급할 때 읽는 문서와 평소에 읽는 문서는 형태가 달라야 한다.

AMI와 스냅샷은 되돌리는 대상이 다르다. AMI는 환경을, 스냅샷은 데이터를 되돌린다. 주기가 다른 이유도 여기에 있고, 둘 중 하나만으로는 복구가 안 되는 이유도 여기에 있다. 백업을 몇 개 갖고 있느냐보다 무엇을 되돌릴 수 있느냐로 따지게 됐다.

복구는 서비스가 응답하는 순간 끝나지 않는다. 복원된 서버는 새 인스턴스라서, 알람과 백업 대상에서 빠져 있다. 이걸 다시 연결하지 않으면 다음 장애 때 같은 서버가 또 백업 없는 상태로 발견된다. 장애 대응이 원래 상태로 완전히 돌아가는 것까지라는 걸, 이 목록을 만들면서 분명히 했다.

백업이 있어도 오래됐으면 소용이 없어서 갱신 주기를 따로 다룬 글이 AMI 갱신 계획이고, 복구까지 가지 않고 끝나는 장애 범위는 EC2 StatusCheckFailed 기반 장애 감지에 정리했다.

이어 읽기