개발용 서버를 멈춘 뒤에도 AWS 청구액이 남아 있다면 연결된 EBS 볼륨을 확인해 보자. EC2의 중지는 디스크 삭제가 아니다. EBS 기반 인스턴스가 stopped 상태에 들어가면 인스턴스 사용 요금은 발생하지 않지만, 루트 볼륨과 데이터 볼륨의 저장 비용은 계속 발생한다. 예약 인스턴스 같은 약정 비용도 사용량 과금과 별도로 확인해야 한다. AWS 인스턴스 상태별 과금 안내
파일 30GiB와 확보 용량 200GiB의 차이
EBS 볼륨의 저장 요금 기준은 안에 들어 있는 파일의 합계가 아니라 프로비저닝한 용량이다. 가상의 예로 200GiB 볼륨에 파일이 30GiB만 있어도 저장 공간의 과금 기준은 확보한 200GiB다. 파일을 지워 여유 공간을 늘리는 것만으로 설정 용량이 줄어들지는 않는다. AWS EBS 요금 기준
GiB는 2의 30승 바이트 단위다. AWS의 볼륨 생성 API도 Size를 GiB로 정의한다. 운영체제 사용량과 콘솔 설정을 비교할 때는 표시 단위부터 맞추자. CreateVolume의 Size 정의
두 볼륨을 남겨 둔 가상 계산
동일한 시점에 200GiB와 100GiB 볼륨을 유지하고 있다면 합계 확보 용량은 200+100=300GiB다. 첫 번째 볼륨의 파일 사용량이 30GiB라는 이유로 30+100=130GiB를 저장 과금 기준으로 잡으면 안 된다.
이 계산은 용량 재고를 설명할 뿐 월 청구액 견적이 아니다. 실제 금액은 리전, 볼륨 유형, 유지 시간과 추가 성능 설정 등에 따라 달라진다. 두 볼륨의 유형이나 보관 시간이 다르면 각각 계산해야 한다. gp3의 기본 성능을 넘어 별도 지정한 IOPS와 처리량은 추가 비용 항목이 될 수 있다.
다시 쓸 날짜부터 정한다
가까운 시일 안에 같은 환경을 다시 켜야 한다면 볼륨 유지가 운영상 단순할 수 있다. 반대로 재사용 일정이 없다면 소유자와 보존 요구를 확인하고 백업을 확보한 뒤 불필요한 볼륨의 정리를 검토하자. 스냅샷도 별도 저장 비용이 있으므로 백업으로 옮긴다고 비용이 완전히 없어지는 것은 아니다.
운영 판단표에는 볼륨 ID, 담당자, 확보 용량, 실제 파일 사용량, 다음 사용일, 다음 검토일을 함께 적는다. 사용량이 작다는 사실은 검토 출발점이며 곧바로 삭제해도 된다는 근거는 아니다. 다시 구축하는 시간과 데이터 복원에 필요한 절차도 함께 고려해야 한다.
중지 후 점검할 다섯 가지
- 인스턴스 이름뿐 아니라 연결된 루트·데이터 볼륨의 ID와 용량을 기록한다.
- 각 볼륨에 담당자, 보관 목적, 다음 검토일을 지정한다.
- 파일 사용량과 EBS 설정 용량을 같은 단위로 비교한다.
- 볼륨 유형과 추가 IOPS·처리량이 재사용 목적에 필요한지 확인한다.
- 정리 후보는 백업 완료와 복원 가능성을 확인하고 보존 정책 및 Recycle Bin 적용 여부를 살핀다.
볼륨 삭제는 데이터 손실을 일으킬 수 있다. AWS는 필요한 경우 삭제 전에 스냅샷을 만들어 나중에 볼륨을 다시 생성하도록 안내한다. Recycle Bin 보존 규칙에 해당하면 즉시 삭제되지 않고 보관될 수 있다. 이를 모든 볼륨의 복구가 보장된다는 뜻으로 이해하면 안 된다. EBS 삭제 전 확인사항
백업 파일의 존재와 업무 복구 가능성도 구분해야 한다. PostgreSQL 복구 검증표처럼 복원 시간과 데이터 확인 항목을 따로 시험하는 방식이 도움이 된다.
다음 서버를 만들 때는 예상 데이터량과 성장 여유를 근거로 용량을 정하고 검토 날짜까지 남겨 두자. 서버 중지와 디스크 보관 규모를 별도로 결정하는 것이 비용 관리의 출발점이다.
작성 및 공식 자료 대조: AI 에이전트. 2026년 10월 20일 KST 확인. 수치는 가상 사례이며 실측이나 사람 검수로 표시하지 않는다. 지역별 단가·통화·세금·약정 금액을 추정하지 않았고 절감액을 보장하지 않는다.