beautifulsoups.dev
Published on

AWS EC2 인스턴스 비용 폭탄 피하기 탄력적 IP 해제와 예약 인스턴스 활용 팁

Authors

서버를 잠깐 테스트하려고 EC2를 하나 띄웠다가, 다음 달 카드 명세서에서 예상치 못한 금액을 보고 놀라는 경우가 의외로 많습니다. 특히 **“인스턴스는 중지했는데 왜 돈이 나오지?”**라는 질문의 대부분은 인스턴스 자체가 아니라 탄력적 IP(EIP), EBS 볼륨/스냅샷, 로드밸런서, 데이터 전송 같은 ‘주변 리소스’에서 발생합니다.

이번 글에서는 비용 폭탄의 단골 원인인 EIP 해제(Release) 포인트를 확실히 짚고, 장기 운영에서 효과가 큰 예약 인스턴스(Reserved Instances)와 Savings Plans를 어떻게 선택/적용하면 좋은지, 그리고 실무에서 바로 써먹을 수 있는 점검 스크립트와 트러블슈팅까지 정리합니다.

운영체제/네트워크 기본 개념이 헷갈린다면, 리소스가 어떻게 붙고 떨어지는지 이해하는 데 도움이 되는 글도 함께 보세요: 리눅스란 무엇인가? 자유로운 운영체제의 세계

EC2 비용 폭탄이 터지는 대표 시나리오

1) 인스턴스를 “중지(Stop)”했는데도 과금이 된다

  • EC2 컴퓨팅 비용: 중지하면 대부분 멈춥니다.
  • 하지만 아래는 계속 과금될 수 있습니다.
    • EBS 볼륨(루트/데이터 디스크): 인스턴스를 중지해도 디스크는 남아 과금
    • EIP(탄력적 IP): 특정 조건에서 과금
    • 스냅샷: 백업 파일도 저장 비용 발생
    • 로드 밸런서(ALB/NLB): 인스턴스가 없어도 리소스 자체 과금

즉, “인스턴스 중지 = 비용 0”이 아닙니다.

2) EIP를 붙여놓고 인스턴스를 내려버렸다

EIP는 ‘고정 공인 IP’라 편하지만, **연결되지 않은 상태(또는 특정 조건)**에서는 과금이 발생합니다. 테스트 서버를 지우고도 EIP를 남겨두면 월말에 조용히 비용이 쌓입니다.

3) 장기 운영인데 온디맨드로 계속 결제한다

24/7로 돌아가는 워크로드를 온디맨드로만 쓰면 비용이 예측 불가능해지고, 장기적으로 손해가 커집니다. 이때 예약 인스턴스(RI) 또는 Savings Plans가 큰 차이를 만듭니다.

탄력적 IP(EIP) 과금 구조와 “해제” 체크리스트

EIP는 언제 과금되는가?

AWS 정책은 시기별로 조금씩 변동이 있을 수 있지만, 실무적으로는 아래 원칙을 기억하면 안전합니다.

  • EIP가 인스턴스(또는 지원 리소스)에 정상적으로 연결(associate)된 상태: 보통 과금이 최소화되거나 조건부(정책에 따라 다름)
  • EIP가 연결되지 않은 상태(Disassociated): 과금되는 경우가 많음
  • EIP를 여러 개 보유하거나, 특정 구성(예: IPv4 고정 할당 관련 정책)에 따라 과금이 발생할 수 있음

따라서 가장 안전한 운영 습관은:

  1. 테스트/임시 서버 종료 시 EIP 연결 해제(Disassociate)
  2. 다시 쓸 계획이 없다면 **EIP 해제(Release)**까지 진행

“연결 해제”와 “해제”는 다르다

  • Disassociate(연결 해제): 인스턴스에서 IP를 떼어냄. EIP는 계정에 남아 있음.
  • Release(해제): EIP 자체를 계정에서 반환. 더 이상 내 것이 아님.

실수 포인트:

  • 인스턴스를 종료(Terminate)하면 EIP가 자동으로 사라질 거라 생각하는데, EIP는 남아 있는 경우가 많습니다.

콘솔에서 EIP 해제 절차

  1. EC2 콘솔 → Elastic IPs
  2. 해당 EIP 선택
  3. 연결되어 있으면 Disassociate Elastic IP address
  4. 이어서 Release Elastic IP address

AWS CLI로 EIP “연결 해제 → 해제”하기

아래는 가장 흔한 흐름입니다.

# 1) EIP 목록 확인
aws ec2 describe-addresses \
  --query 'Addresses[].{PublicIp:PublicIp,AllocationId:AllocationId,AssociationId:AssociationId,InstanceId:InstanceId}' \
  --output table

# 2) 연결되어 있다면 연결 해제
aws ec2 disassociate-address --association-id eipassoc-0123456789abcdef0

# 3) EIP 해제(반환)
aws ec2 release-address --allocation-id eipalloc-0123456789abcdef0

트러블슈팅: Release가 안 될 때

  • "InvalidAllocationID.NotFound": 리전이 다르거나 ID가 틀렸을 가능성
  • "DependencyViolation": NAT Gateway, Network Interface(ENI) 등에 물려 있을 수 있음
    • describe-addresses 결과에서 NetworkInterfaceId가 보이면 해당 ENI/서비스 연결을 먼저 정리해야 합니다.

EIP만 지우면 끝이 아니다: 함께 점검해야 할 비용 리소스

1) EBS 볼륨: 중지해도 계속 과금

인스턴스를 중지해도 루트 볼륨은 남습니다. 종료 시 자동 삭제 여부는 DeleteOnTermination 설정에 좌우됩니다.

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].BlockDeviceMappings[].Ebs.{VolumeId:VolumeId,DeleteOnTermination:DeleteOnTermination}' \
  --output table
  • 테스트 인스턴스라면 DeleteOnTermination=true를 권장
  • 데이터 볼륨은 별도 정책(백업/보관)과 함께 관리

2) 스냅샷: “백업이니까 공짜”가 아니다

EBS Snapshot은 S3 기반 저장 비용이 발생합니다. 오래된 스냅샷이 쌓이면 비용이 커질 수 있습니다.

aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[].{SnapshotId:SnapshotId,StartTime:StartTime,VolumeSize:VolumeSize,State:State}' \
  --output table

3) 로드 밸런서/데이터 전송

  • ALB/NLB는 인스턴스가 없어도 리소스 자체 과금
  • 외부로 나가는 트래픽(egress)은 비용이 빠르게 증가

Best Practice

  • 개발/스테이징 환경은 필요할 때만 ALB 생성하거나, 대체 경량 구성(예: 단일 인스턴스 + 보안그룹 제한)을 고려
  • CloudFront/캐시로 외부 트래픽 비용 완화

비용 폭탄을 막는 운영 루틴: “종료 전 체크리스트” 자동화

사람이 매번 콘솔에서 확인하면 놓치기 쉽습니다. 최소한 아래 3가지는 자동 점검을 추천합니다.

1) 연결되지 않은 EIP 탐지

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].{PublicIp:PublicIp,AllocationId:AllocationId}' \
  --output table

출력된 항목이 있다면 “정말 보관할 EIP인지” 재검토 후 해제하세요.

2) 사용하지 않는(Detached) EBS 볼륨 탐지

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

available은 인스턴스에 붙지 않은 상태입니다. 필요 없다면 삭제 후보입니다.

3) Cost Explorer + Budgets로 “사전 경보” 걸기

  • AWS Budgets: 월 비용/일 비용 임계치 알림
  • Cost Anomaly Detection: 이상 지출 탐지

현실적인 추천값

  • 개인/사이드 프로젝트: 월 예산 20~50달러로 알림
  • 팀/서비스: 서비스별 태그 기반 예산 + 80%/100% 알림

예약 인스턴스(RI)로 장기 비용 줄이기

RI가 잘 맞는 경우

  • 1년/3년 단위로 항상 켜져 있는 서버
  • 인스턴스 타입/리전이 크게 변하지 않음
  • 예: API 서버, 배치 서버, 내부 서비스 등

RI의 핵심 포인트

  • 할인: 온디맨드 대비 큰 폭 절감(조건에 따라 다름)
  • 약정: 기간 동안 비용 약정이 생김
  • 유연성: Standard RI는 변경 제한이 더 크고, Convertible RI는 유연하지만 할인폭이 작을 수 있음

결제 옵션 선택 팁

  • All Upfront: 가장 싸지만 현금 부담 큼
  • Partial Upfront: 절충안
  • No Upfront: 초기 부담 낮지만 상대적으로 비쌀 수 있음

실무 팁

  • 처음부터 3년을 박기보다, 트래픽/구성이 안정화되기 전에는 1년 + Partial Upfront 같은 보수적 선택이 안전합니다.

Savings Plans가 더 나은 선택인 경우

RI가 “특정 인스턴스” 중심이라면, Savings Plans는 “컴퓨팅 사용량” 중심으로 더 유연한 편입니다.

Compute Savings Plans 추천 케이스

  • 오토스케일링으로 인스턴스 수가 변함
  • ECS/EKS, Lambda까지 컴퓨팅 전반을 묶어 절감하고 싶음

EC2 Instance Savings Plans 추천 케이스

  • 특정 인스턴스 패밀리/리전에 집중
  • RI와 비슷한 성격이지만 관리가 간단한 편

선택 기준(간단 요약)

  • 워크로드가 자주 바뀌면: Compute Savings Plans
  • EC2 중심으로 비교적 고정이면: RI 또는 EC2 Instance Savings Plans

태그 전략이 곧 비용 통제다

비용 폭탄은 “어디서 새는지 모를 때” 커집니다. 태그가 없으면 Cost Explorer에서 분석이 어려워지고, 팀이 커질수록 책임 소재도 불명확해집니다.

권장 태그 예시

  • Project: 서비스/프로젝트명
  • Env: dev/stage/prod
  • Owner: 담당자
  • CostCenter: 비용 귀속
  • TTL: 만료일(임시 리소스)

Best Practice

  • IaC(Terraform/CloudFormation)로 태그 강제
  • TTL이 지난 리소스를 주기적으로 탐지해 정리(람다/스케줄러)

자주 겪는 문제와 해결

Q1. 인스턴스를 종료했는데도 EBS 비용이 남는다

  • 루트 볼륨이 삭제되지 않았거나, 데이터 볼륨이 별도로 남았을 가능성
  • 해결: describe-volumes로 available 볼륨 확인 후 삭제

Q2. EIP를 해제했는데도 청구가 계속된다

  • 청구 반영은 시차가 있을 수 있음
  • 동일 리전에 다른 EIP가 남아 있거나, NAT Gateway 등에서 공인 IP 비용이 발생할 수 있음
  • 해결: Cost Explorer에서 서비스별(EC2-Other, VPC 등)로 분해해 원인 추적

Q3. RI를 샀는데 할인이 적용되지 않는 것 같다

  • RI는 “매칭 규칙”이 있습니다(리전/인스턴스 패밀리/OS/테넌시 등)
  • 해결: RI 적용 리포트 확인, 인스턴스 속성 불일치 여부 점검

결론: 비용 폭탄을 막는 가장 현실적인 3단계

  1. 종료/중지 전에 EIP를 점검하고, 안 쓰면 Release까지 진행한다.
  2. EBS 볼륨/스냅샷/로드밸런서/데이터 전송 같은 “주변 리소스”를 함께 정리한다.
  3. 24/7 워크로드는 온디맨드로 방치하지 말고, 안정화되면 예약 인스턴스 또는 Savings Plans로 비용을 고정/절감한다.

이 3가지만 습관화해도 “EC2 껐는데 왜 돈이 나오지?” 같은 상황을 대부분 예방할 수 있습니다.

Discuss on Twitter • View on GitHub