EC2 인스턴스 중지(Stop) vs 종료(Terminate): EBS 데이터는 살아남는가

EC2 인스턴스를 중지했는데 재시작하니 데이터가 사라졌다는 제보가 팀 슬랙에 올라오는 순간, 모두가 멈춘다. 실제로 EC2 인스턴스 중지와 종료의 차이를 정확히 이해하지 못한 채 비용 절감을 위해 인스턴스를 껐다가 데이터를 잃는 사고는 생각보다 자주 발생한다. Stop과 Terminate는 콘솔에서 불과 몇 픽셀 차이지만, 결과는 완전히 다르다.

TL;DR — EC2 중지 vs 종료 핵심 비교

항목 Stop (중지) Terminate (종료)
인스턴스 상태 stopped → 재시작 가능 shutting-down → terminated (영구)
루트 EBS 볼륨 기본 유지 기본 삭제 (DeleteOnTermination=true)
추가 EBS 볼륨 유지 기본 유지 (DeleteOnTermination=false)
인스턴스 스토어 데이터 소멸 데이터 소멸
퍼블릭 IP (동적) 중지 시 반환, 재시작 시 새 IP 할당 즉시 반환
Elastic IP 유지 (연결 상태 유지) 연결 해제 (IP 자체는 계정에 남음)
과금 인스턴스 요금 없음, EBS 요금 발생 인스턴스 요금 없음, 잔존 EBS 요금 발생
복구 가능성 가능 불가능

EC2 인스턴스 중지와 종료의 동작 원리

Stop과 Terminate를 단순히 '켜고 끄는 것'으로 이해하면 반드시 사고가 난다. 두 작업은 인스턴스 수명 주기(lifecycle)의 완전히 다른 상태 전이를 트리거한다.

Stop은 인스턴스를 running → stopping → stopped 상태로 전환한다. 이 시점에 AWS는 해당 인스턴스가 실행되던 물리 호스트와의 연결을 끊는다. 재시작하면 동일한 물리 호스트에 배치된다는 보장이 없다. 그래서 인스턴스 스토어(NVMe SSD 등 호스트에 직접 붙은 스토리지)의 데이터는 Stop 이후 복구할 수 없다. EBS는 네트워크 연결 블록 스토리지이기 때문에 인스턴스와 분리된 상태로 존재하며, 중지 중에도 데이터가 보존된다.

Terminate는 running → shutting-down → terminated로 전환되며, 이 과정은 되돌릴 수 없다. 인스턴스 리소스가 해제되고, 루트 볼륨의 DeleteOnTermination 플래그에 따라 EBS 볼륨 삭제 여부가 결정된다.

stateDiagram-v2 [*] --> running : 인스턴스 시작 running --> stopping : Stop 명령 stopping --> stopped : OS shutdown 완료 stopped --> running : Start 명령 stopped --> [*] : (재사용 가능 상태) running --> shutting_down : Terminate 명령 shutting_down --> terminated : 리소스 해제 terminated --> [*] : 복구 불가 note right of stopped : EBS 볼륨 보존 인스턴스 스토어 소멸 퍼블릭 IP 반환 note right of terminated : DeleteOnTermination=true → 루트 EBS 삭제 DeleteOnTermination=false → EBS 보존
  1. running → stopping: Stop 명령 수신 후 OS shutdown 시퀀스 시작
  2. stopped: 물리 호스트 연결 해제, EBS 볼륨은 분리되지 않고 연결 상태 유지
  3. running → shutting-down: Terminate 명령 수신, 복구 불가 지점
  4. terminated: 인스턴스 리소스 해제, DeleteOnTermination 플래그에 따라 EBS 처리

EBS 볼륨의 DeleteOnTermination 플래그 — 가장 많이 놓치는 설정

Terminate 시 EBS 데이터 생존 여부는 전적으로 DeleteOnTermination 속성에 달려 있다. AWS 기본값은 다음과 같다.

  • 루트 볼륨 (/dev/xvda 또는 /dev/sda1): DeleteOnTermination=true (기본값)
  • 추가로 연결한 EBS 볼륨: DeleteOnTermination=false (기본값)

즉, 인스턴스를 Terminate하면 루트 볼륨은 기본적으로 함께 삭제된다. 이 기본값을 모르고 Terminate를 누른 뒤 루트 볼륨의 데이터를 찾는 경우가 실제 운영에서 반복된다.

EBS를 네트워크 연결 외장 하드로 생각하면 이해가 쉽다. Stop은 컴퓨터를 끄는 것이고 외장 하드는 그대로 꽂혀 있다. Terminate는 컴퓨터를 폐기하는 것인데, 내장 드라이브(루트 볼륨)는 폐기 시 같이 버려지고, 별도로 연결한 외장 하드(추가 EBS)는 그대로 남는다.

현재 인스턴스의 DeleteOnTermination 설정 확인

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].BlockDeviceMappings[*].{Device:DeviceName,DeleteOnTermination:Ebs.DeleteOnTermination}' \
  --output table

실행 중인 인스턴스의 루트 볼륨 DeleteOnTermination 변경

aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"DeleteOnTermination":false}}]'

이 명령은 인스턴스가 running 또는 stopped 상태일 때 모두 적용 가능하다. 변경 후 반드시 위의 describe-instances 명령으로 적용 여부를 재확인해야 한다.

인스턴스 스토어 — Stop으로도 데이터가 사라지는 스토리지

인스턴스 스토어(Instance Store)는 물리 호스트에 직접 연결된 임시 스토리지다. EBS와 달리 네트워크를 경유하지 않아 I/O 지연이 낮지만, 인스턴스가 중지(Stop)되거나 종료(Terminate)되면 데이터가 소멸한다. 하이버네이션(Hibernation)도 인스턴스 스토어 데이터를 보존하지 않는다.

인스턴스 스토어를 제공하는 인스턴스 패밀리(예: i3, d2, h1 계열)를 사용할 때는 이 스토리지를 영구 데이터 저장소로 사용해서는 안 된다. 캐시, 임시 버퍼, 스크래치 공간 용도로만 사용하고, 중요한 데이터는 EBS나 S3에 유지해야 한다.

graph TD A[EC2 인스턴스] --> B[EBS 루트 볼륨] A --> C[EBS 추가 볼륨] A --> D[인스턴스 스토어] B --> B1{DeleteOnTermination} B1 -->|true 기본값| B2[Terminate 시 삭제] B1 -->|false 변경 후| B3[Terminate 후 보존] B --> B4[Stop 시 항상 보존] C --> C1[Stop 시 보존] C --> C2[Terminate 시 기본 보존
DeleteOnTermination=false] D --> D1[Stop 시 데이터 소멸] D --> D2[Terminate 시 데이터 소멸] style D1 fill:#ff6b6b,color:#fff style D2 fill:#ff6b6b,color:#fff style B2 fill:#ff6b6b,color:#fff style B3 fill:#51cf66,color:#fff style B4 fill:#51cf66,color:#fff style C1 fill:#51cf66,color:#fff style C2 fill:#51cf66,color:#fff
  1. EBS 루트 볼륨: Stop 시 보존, Terminate 시 DeleteOnTermination 플래그에 따라 결정
  2. EBS 추가 볼륨: Stop/Terminate 모두 기본 보존 (DeleteOnTermination=false)
  3. 인스턴스 스토어: Stop과 Terminate 모두에서 데이터 소멸

Stop 후 재시작 시 달라지는 것들

Stop 후 Start를 하면 데이터는 살아있지만, 몇 가지 네트워크 속성이 바뀐다. 이를 모르면 재시작 후 연결이 안 된다고 혼란스러워진다.

  • 퍼블릭 IPv4 주소: 동적 퍼블릭 IP는 중지 시 반환되고 재시작 시 새 IP가 할당된다. Elastic IP를 사용하면 이 문제를 피할 수 있다.
  • 물리 호스트: 재시작 시 다른 물리 호스트에 배치될 수 있다. 이 때문에 인스턴스 스토어 데이터가 소멸한다.
  • 프라이빗 IP: VPC 내 프라이빗 IP는 유지된다.
  • DNS 호스트명: 퍼블릭 DNS는 새 퍼블릭 IP를 반영하여 변경된다.

실수로 Terminate를 눌렀을 때 — 종료 방지 설정

콘솔에서 Stop과 Terminate는 드롭다운 메뉴에 나란히 있다. 프로덕션 인스턴스에는 반드시 종료 방지(Termination Protection)를 활성화해야 한다. 이 설정이 활성화된 상태에서 Terminate를 시도하면 API 호출이 거부된다.

종료 방지 활성화

aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --disable-api-termination

종료 방지 상태 확인

aws ec2 describe-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --attribute disableApiTermination \
  --query 'DisableApiTermination.Value'

종료 방지를 활성화해도 Stop은 막지 않는다. Stop만 막으려면 IAM 정책에서 ec2:StopInstances 액션을 제한해야 한다.

Stop 방지 IAM 정책 예시

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:StopInstances",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-0123456789abcdef0"
    }
  ]
}

실제 사고 패턴 — 잘못된 가정이 데이터를 지운다

팀에서 비용 절감을 위해 개발 환경 인스턴스를 야간에 자동으로 Terminate하는 Lambda를 배포했다. 개발자들은 '어차피 Stop이겠지'라고 생각하고 인스턴스 스토어에 작업 중인 데이터를 두었다. 다음 날 아침, 인스턴스는 새로 생성되어 있었고 전날 작업한 내용은 사라졌다.

원인은 두 가지였다. 첫째, Lambda가 stop-instances가 아닌 terminate-instances를 호출하고 있었다. 둘째, 루트 볼륨의 DeleteOnTermination이 기본값인 true였다. 콘솔에서 인스턴스 상태를 보면 'terminated'로 표시되는데, 이를 'stopped'로 착각한 것이 출발점이었다.

올바른 진단 순서는 다음과 같다.

1단계: 인스턴스 현재 상태 확인

인스턴스가 stopped인지 terminated인지 먼저 확인한다. Terminated 인스턴스는 콘솔에서 약 1시간 후 목록에서 사라지므로, 사라지기 전에 상태를 확인해야 한다.

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,State:State.Name}' \
  --output table

2단계: CloudTrail에서 Terminate 호출 주체 확인

인스턴스가 예상치 않게 종료되었다면, 누가 언제 Terminate를 호출했는지 CloudTrail에서 추적한다. Stop과 Terminate는 서로 다른 이벤트 이름으로 기록된다.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=TerminateInstances \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --query 'Events[*].{Time:EventTime,User:Username,Event:EventName}' \
  --output table

3단계: 잔존 EBS 볼륨 확인

Terminate 이후에도 DeleteOnTermination=false였던 볼륨은 'available' 상태로 남아 있다. 이 볼륨에서 데이터를 복구할 수 있다.

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

비용 절감 목적의 올바른 접근

비용 절감이 목적이라면 Stop이 맞다. 단, Stop 상태에서도 EBS 볼륨 요금은 계속 발생한다. EBS 비용까지 절감하려면 스냅샷을 찍고 볼륨을 삭제한 뒤, 필요할 때 스냅샷에서 볼륨을 복원하는 방식을 사용할 수 있다. 다만 이 방식은 복원 시간이 필요하고 운영 복잡도가 올라간다.

개발 환경의 야간 자동화라면 AWS Instance Scheduler나 EventBridge + Lambda 조합으로 stop-instances를 호출하는 것이 표준 패턴이다. Terminate 자동화는 불변 인프라(Immutable Infrastructure) 패턴을 명확히 이해하고 적용하는 경우에만 사용해야 한다.

인스턴스 Stop 자동화 CLI 예시

aws ec2 stop-instances \
  --instance-ids i-0123456789abcdef0

EC2 중지와 종료 차이 — 마무리 및 다음 단계

EC2 인스턴스 중지와 종료의 차이를 한 문장으로 정리하면: Stop은 인스턴스를 재사용 가능한 상태로 보존하고, Terminate는 인스턴스를 영구적으로 폐기한다. EBS 데이터 생존 여부는 Stop이냐 Terminate냐보다 DeleteOnTermination 플래그와 스토리지 유형(EBS vs 인스턴스 스토어)에 달려 있다.

프로덕션 환경에서 반드시 적용해야 할 조치는 세 가지다.

  1. 중요 인스턴스에 Termination Protection 활성화
  2. 루트 볼륨의 DeleteOnTermination 기본값 검토 및 필요 시 변경
  3. 인스턴스 스토어를 영구 데이터 저장소로 사용하지 않도록 아키텍처 검토

관련하여 EBS 스냅샷 자동화와 Data Lifecycle Manager(DLM) 설정도 함께 검토하면 데이터 보호 체계를 완성할 수 있다.

핵심 용어 정리

용어 설명
DeleteOnTermination 인스턴스 종료 시 EBS 볼륨 자동 삭제 여부를 결정하는 블록 디바이스 매핑 속성. 루트 볼륨 기본값은 true.
인스턴스 스토어 (Instance Store) 물리 호스트에 직접 연결된 임시 스토리지. Stop 및 Terminate 시 데이터 소멸.
Termination Protection API 및 콘솔을 통한 Terminate 호출을 차단하는 인스턴스 속성.
Elastic IP 계정에 할당된 정적 퍼블릭 IPv4 주소. 인스턴스 Stop/Start 후에도 동일 IP 유지 가능.
인스턴스 수명 주기 (Instance Lifecycle) pending → running → stopping → stopped → terminated 등 EC2 인스턴스가 거치는 상태 전이 흐름.

Related Posts

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

S3 정적 웹사이트 호스팅 완전 가이드: HTML/CSS 사이트를 무료로 배포하는 법

간단한 HTML/CSS 포트폴리오나 랜딩 페이지를 만들었는데, 서버 없이 배포할 방법을 찾고 있다면 S3 정적 웹사이트 호스팅이 가장 현실적인 선택이다. EC2 인스턴스를 띄울 필요도 없고, Nginx 설정을 건드릴 필요도 없다. S3 버킷 하나로 수백만 요청을 처리할 수 있다. TL;DR — S3 정적 웹사이트 호스팅 핵심 요약 단계 작업 주의사항 1 S3 버킷 생성 (퍼블릭 액세스 차단 해제) 버킷 이름은 변경 불가 2 정적 웹사이트 호스팅 활성화 인덱스/에러 문서 지정 필수 3 버킷 정책으로 퍼블릭 읽기 허용 ACL 방식은 권장하지 않음 4 파일 업로드 Content-Type 자동 감지 확인 5 S3 웹사이트 엔드포인트로 접근 HTTPS는 CloudFront 필요 S3 정적 웹사이트 호스팅의 동작 원리 S3에는 두 가지 엔드포인트가 존재한다. 하나는 REST API 엔드포인트( s3.amazonaws.com ), 다른 하나는 웹사이트 엔드포인트( s3-website-{region}.amazonaws.com )다. 정적 웹사이트 호스팅을 활성화하면 웹사이트 엔드포인트가 활성화되고, 이 엔드포인트는 HTTP GET 요청에 대해 인덱스 문서를 반환하거나 404 시 커스텀 에러 페이지를 반환하는 웹 서버처럼 동작한다. REST 엔드포인트와 웹사이트 엔드포인트의 결정적 차이는 루트 경로 처리 방식이다. REST 엔드포인트에서 / 를 요청하면 버킷 목록 XML이 반환되거나 403이 뜬다. 웹사이트 엔드포인트는 설정된 인덱스 문서( index.html )를 자동으로 반환한다. 중요한 제약이 하나 있다. S3 웹사이트 엔드포인트는 HTTP만 지원한다. HTTPS가 필요하다면 CloudFront를 앞단에 배치해야 한다. 이 포스트에서는 S3 단독 설정에 집중하고, CloudFront 연동은 별도로 다룬...
자세한 내용 보기