돈이 새기 쉬운 AWS 서비스와 설정: 상시 점검 목록

인프라 AWS 비용
5 분 소요

전편이 “갑자기 튄” 요금의 범인 찾기였다면, 이번에는 반대쪽입니다. 그래프에 계단을 만들지 않고 베이스라인을 조용히 밀어 올리는 낭비들입니다. 급증은 눈에 띄어서 잡히지만, 이쪽은 “원래 이 정도 나왔던 것 같은데"라는 감각 뒤에 숨어서 몇 달, 몇 년을 갑니다. 분기에 한 번씩 훑을 점검 목록으로 정리했습니다. 금액은 us-east-1 기준이고 리전마다 다릅니다.

스토리지: 가장 확실하고 가장 방치되는 곳 #

gp2 볼륨 잔존: gp3는 gp2보다 GB당 약 20% 저렴하고(약 $0.08 vs $0.10/GB·월), 기본 성능(3,000 IOPS, 125MiB/s)이 크기와 무관하게 보장됩니다. gp2에서 gp3로의 변경은 Elastic Volumes로 무중단 온라인으로 되므로, 남겨 둘 이유가 사실상 없습니다. 콘솔이나 CLI에서 볼륨 타입 필터로 gp2를 나열해 일괄 전환합니다. gp3와 io2의 선택 기준은 별도 글에서 다룹니다.

고아 볼륨과 스냅샷: 인스턴스 종료 시 “delete on termination"이 꺼져 있던 볼륨들이 available 상태로 남아 과금됩니다. 스냅샷은 전편 #3에서 다뤘듯 수명 주기 정책이 답입니다.

S3 스토리지 클래스 미활용: 접근 패턴이 불확실한 버킷은 Intelligent-Tiering으로 옮기는 것만으로 자동 절감이 시작됩니다(모니터링 비용은 객체당 소액). 로그·백업처럼 접근이 뜸한 데이터가 Standard에 그대로 있다면 수명 주기 규칙으로 Standard-IA나 Glacier 계열로 내립니다. 단, 최소 보존 기간(IA 30일, Glacier 90일 등)과 검색 비용이 있으므로 자주 꺼내는 데이터는 내리지 않습니다.

네트워크: 구조가 만든 고정비 #

퍼블릭 IPv4 주소: 주소당 월 약 $3.6이 사용 여부와 무관하게 나갑니다. 미연결 Elastic IP는 즉시 해제하고, 인스턴스마다 퍼블릭 IP를 주던 구성은 NAT나 로드밸런서 뒤에 두는 쪽으로 정리합니다. Public IP Insights에서 계정 전체의 주소 수를 볼 수 있습니다. 주소가 수십 개면 그것만으로 월 세 자릿수 달러입니다.

NAT Gateway 상시 경유: 전편에서 급증 원인으로 다뤘지만, 급증이 아니어도 구조적 고정비가 됩니다. S3·DynamoDB 게이트웨이 엔드포인트는 무료인데도 안 쓰는 계정이 많습니다. 프라이빗 서브넷에서 AWS 서비스로 가는 트래픽이 있다면 엔드포인트부터 확인합니다. 개발 VPC라면 NAT Gateway 자체(월 약 $33 + 처리량)를 없애고 퍼블릭 서브넷 구성이나 NAT 인스턴스로 대체하는 선택지도 있습니다.

방치된 로드밸런서: ALB는 트래픽이 0이어도 시간당 요금으로 월 $16 이상이 나갑니다. 실험하고 남은 ALB, 서비스 내렸는데 남은 ALB를 타겟 그룹의 healthy 타겟 수 0 기준으로 찾아 정리합니다.

컴퓨팅: 단가와 가동 시간 양쪽 #

구세대 인스턴스: 같은 사양이라도 신세대가 대체로 더 싸고 빠릅니다. m4, m5를 그대로 쓰고 있다면 m7g·m8g(Graviton) 또는 m7i 계열로의 교체가 단가와 성능을 동시에 개선합니다. Graviton 전환은 다음 글에서 체크리스트로 다룹니다.

RI·Savings Plans 미적용 온디맨드: 1년 이상 꾸준히 돌 것이 확실한 베이스라인 용량이 온디맨드로 돌고 있다면, Compute Savings Plans만 걸어도 그 부분에서 수십 퍼센트가 내려갑니다. Cost Explorer의 권고(Recommendations)가 계정의 실사용 기반으로 약정 규모를 제안해 주므로, 감으로 정할 필요가 없습니다. 가격 모델 비교는 SAA Domain 4-1에서 다뤘습니다.

개발 환경의 24시간 가동: 평일 9〜19시만 쓰는 환경을 계속 켜 두면 시간의 70%를 버리는 셈입니다. Instance Scheduler나 간단한 Lambda + EventBridge로 야간·주말 정지를 자동화합니다. RDS도 dev 환경이라면 정지 대상입니다(7일 후 자동 재시작되는 제약은 스케줄러로 다시 정지시키는 방식으로 우회합니다).

dev 환경의 Multi-AZ와 과사양: 프로덕션 템플릿을 복사해 만든 개발 RDS가 Multi-AZ·프로비저닝드 IOPS까지 그대로인 경우가 많습니다. 개발 환경은 싱글 AZ, 버스터블 인스턴스, gp3로 충분한 경우가 대부분입니다.

관측·로그: 기본값이 낭비인 곳 #

CloudWatch Logs 무기한 보존: 로그 그룹의 보존 기간 기본값이 “무기한"입니다. 수집 비용(전편 #2)과 별개로 저장 비용이 무한히 자랍니다. 전 로그 그룹에 보존 기간(예: 30〜90일)을 일괄 설정하고, 장기 보관이 필요한 것만 S3로 내보내 Glacier로 내립니다. S3 저장은 CloudWatch Logs 저장보다 GB당 몇 배 쌉니다.

고카디널리티 커스텀 지표와 과잉 대시보드: 지표당 월 $0.30은 작아 보이지만 인스턴스별 × 항목별로 곱해지면 큽니다. 안 보는 대시보드, 안 울리는 알람에 딸린 지표를 분기마다 정리합니다.

점검 루틴 만들기 #

이 목록의 항목들은 한 번 고치면 끝나는 것(gp2 전환, 보존 기간 설정)과 되돌아오는 것(고아 리소스, 개발 환경 사양)으로 나뉩니다. 후자를 위해 다음 둘을 권합니다.

  • Trusted Advisor / Compute Optimizer: 미사용 리소스와 다운사이징 권고를 자동으로 뽑아 줍니다. 분기 점검의 출발점으로 삼습니다.
  • 태그 기반 소유자 지정: 리소스마다 팀·환경 태그를 강제하면 “누구 건지 몰라서 못 지우는” 리소스가 사라집니다. 지우지 못하는 리소스가 낭비의 최종 형태입니다.

정리 #

  • 베이스라인 낭비는 급증과 달리 그래프에 안 보입니다. 분기 1회 점검 루틴으로만 잡힙니다.
  • 스토리지부터 봅니다. gp2 → gp3 전환은 무중단에 즉시 약 20% 절감이라 가장 손쉬운 성과입니다.
  • 퍼블릭 IPv4, 방치 ALB, NAT 상시 경유는 트래픽과 무관하게 나가는 구조적 고정비입니다.
  • 확실한 베이스라인 용량에는 Savings Plans를, 개발 환경에는 스케줄 정지를 겁니다.
  • CloudWatch Logs 보존 기간은 기본값이 무기한입니다. 전 로그 그룹에 기간을 설정하는 것부터 시작합니다.
X