AWS 비용 점검 — 항목마다 무엇을 보고 무엇을 판단하는가

비용 체크리스트는 항목만으로는 쓰기 어렵습니다. “미사용 리소스를 정리한다”는 항목은 그것이 정말 미사용인지 판별할 방법이 함께 있어야 쓸 수 있고, “사이징을 검토한다”는 항목은 어디까지 낮춰도 안전한지의 기준이 함께 있어야 실행됩니다.

그래서 이 글은 항목마다 네 가지를 함께 적었습니다.

• 왜 중요한가 — 이 항목이 요금에 어떤 경로로 반영되는가
• 문제 시 나타나는 지표 — 무엇이 관측되면 확인이 필요한가
• 우선 조치 — 무엇부터 손대는가
• 전문가 검토가 필요한 조건 — 어디서부터는 혼자 판단하지 않는 편이 나은가

비용 점검의 목적은 줄이는 것이 아니라 지금 상태가 의도한 것인지 확인하는 것입니다. 항목에 해당한다고 해서 반드시 조치가 필요한 것은 아닙니다.

요금이 이미 크게 올랐고 그 원인을 특정하는 중이라면 이 글이 아니라 비용이 갑자기 올랐을 때의 확인 순서가 맞습니다. 그 글은 변화의 원인을 추적하고, 이 글은 급한 일이 없을 때 평상시 상태를 점검합니다.

점검 전에 정할 것 — 주기와 순서

비용 점검은 분기 단위로 잡고, 되돌리기 쉬운 항목부터 어려운 항목 순으로 진행하는 편이 안전합니다. 월 단위는 조치할 시간이 확보되지 않아 목록만 쌓이기 쉽고, 연 단위는 그사이 늘어난 것을 되짚기 어렵습니다. 신규 서비스 출시나 계정 구조 변경이 있었다면 주기와 무관하게 한 번 더 봅니다.

일반적인 점검 항목 목록은 무엇을 보는가의 나열이지만, 이 글은 무엇부터 손대는가의 순서로 배열했습니다. 그래서 약정이 가장 마지막에 옵니다.

진행 순서는 다섯 단계입니다.

1. 관측 — 어디에 얼마가 쓰이는지 나눠 본다
2. 정리 — 지금 아무 일도 하지 않는 자원을 확인한다
3. 조정 — 돌아가고는 있지만 사양이나 보존 기간이 과한 것을 본다
4. 구조 — 트래픽 경로와 가동 시간을 본다
5. 약정 — 정리된 사용량을 기준으로 마지막에 판단한다

01. 서비스별 비용 분석

Cost Explorer는 청구서 총액을 서비스별·계정별·태그별로 나눠 보는 도구이며, 비용 점검의 출발점입니다. 어느 서비스가 얼마를 쓰는지 나뉘지 않은 상태에서는 이어지는 항목 중 무엇이 우리에게 해당하는지 고를 수 없습니다.

• 왜 중요한가 — 총액은 원인을 말해주지 않습니다. 같은 금액이라도 어느 서비스와 어느 계정에 몰려 있는지에 따라 손댈 곳이 달라지고, 태그가 붙어 있어야 비용을 팀이나 서비스 단위의 책임으로 되돌릴 수 있습니다.
• 문제 시 나타나는 지표
  • 비용의 상당 부분이 어느 팀·어느 서비스의 것인지 아무도 답하지 못하는 상태
  • 태그가 없는 리소스가 그룹화 결과에서 큰 덩어리로 잡히는 상태
  • 특정 서비스만 꾸준히 우상향하는데 그 이유를 설명할 사람이 없는 상태
• 우선 조치 — 서비스별·계정별로 먼저 나눠 보고, 그다음 태그 기준으로 다시 나눠 봅니다. 태그가 없어 나뉘지 않는다면 태그 정책을 정하는 것이 실제 첫 과제이며, 신규 리소스부터 강제하고 기존 리소스는 점진 적용하는 편이 현실적입니다. 여기서 나온 결과가 나머지 항목의 순서를 정합니다 — 목록을 처음부터 훑는 대신, 비중이 큰 상위 서비스에 해당하는 항목부터 봅니다.
• 전문가 검토가 필요한 조건 — 계정이 여러 개인데 통합 결제 구조나 계정 분리 기준이 정리돼 있지 않은 경우. 계정 구조를 바꾸는 일은 청구뿐 아니라 권한과 감사 기록에 동시에 영향을 줍니다.

02. 미사용·저사용 리소스

어떤 인스턴스에도 연결되지 않은 EBS 볼륨과 어디에도 붙어 있지 않은 Elastic IP는 아무 일도 하지 않는 상태로 과금됩니다. 장애도 알림도 발생하지 않기 때문에 가장 오래 방치되는 항목입니다.

• 왜 중요한가 — EC2 인스턴스를 중지하면 실행 시간 요금은 멈추지만 연결된 볼륨 요금은 계속됩니다. Elastic IP는 연결 여부와 관계없이 과금 대상입니다. 즉 어딘가에 붙어 있는 주소는 그 요금만큼 제 역할을 하고 있지만, 어디에도 붙지 않은 주소는 같은 요금을 내면서 아무 역할도 하지 않습니다.
• 문제 시 나타나는 지표
  • available 상태로 남아 있는 EBS 볼륨
  • 연결 대상이 없는 Elastic IP
  • 오래 stopped 상태인 EC2 인스턴스
  • 대상이 등록되지 않은 로드밸런서
• 우선 조치 — 지우기 전에 태그·생성일·소유자를 먼저 확인합니다. 소유자를 특정할 수 있으면 확인을 거쳐 정리하고, 특정할 수 없으면 삭제 대신 스냅샷을 남긴 뒤 분리해 일정 기간 관찰합니다. 복구 근거로 일부러 남겨 둔 자원일 수 있으므로 일괄 삭제는 피합니다.
• 전문가 검토가 필요한 조건
  • 소유자를 특정할 수 없는 자원이 다수인 경우
  • 프로덕션과 개발이 같은 계정에 섞여 있어 잘못 지웠을 때의 영향 범위를 예측하기 어려운 경우

03. EC2·RDS 사이징

사이징 검토(Right-sizing)는 인스턴스 사양이 실제 사용량에 맞는지 확인하는 일이며, 사용률 지표 하나만으로 결론을 내리지 않습니다. 낮은 CPU 사용률이 곧 과잉 프로비저닝을 뜻하지는 않습니다. 메모리나 디스크 입출력이 병목인 워크로드, 특정 시점에만 부하가 몰리는 배치, 장애 대비 여유분은 평상시 사용률이 낮은 것이 정상입니다.

• 왜 중요한가 — 인스턴스 요금은 실제로 쓴 양이 아니라 확보한 사양과 가동 시간에 붙습니다. 도입 시점에 정한 사양이 그대로 남아 있으면 그때의 가정과 지금의 부하 사이의 차이가 매달 반복됩니다.
• 문제 시 나타나는 지표
  • 사용률이 장기간 낮게 유지되면서 피크 시점에도 여유가 큰 인스턴스
  • 도입 이후 사양을 한 번도 재검토하지 않은 인스턴스
  • 개발용인데 프로덕션과 같은 사양으로 유지되는 인스턴스
  • AWS Compute Optimizer가 과잉 프로비저닝으로 분류한 항목
• 우선 조치 — 관측 기간을 월간 피크와 배치 주기가 포함되도록 잡고 지표를 모읍니다. AWS Compute Optimizer는 사양과 사용률 지표를 분석해 권고를 내주는 서비스이지만 계정에서 옵트인(활성화)해야 동작합니다 — 켜 본 적이 없다면 화면이 비어 있는 것이 정상이고, 활성화 뒤 지표가 쌓이기를 기다려야 합니다. 낮출 때는 프로덕션이 아닌 환경부터 낮춰 보고, 프로덕션은 한 번에 여러 단계를 내리지 않습니다. 인스턴스 계열을 바꾸는 일은 사양을 낮추는 일과 성격이 다르므로 나눠서 진행합니다.
• 전문가 검토가 필요한 조건
  • 라이선스가 사양에 연동된 소프트웨어를 쓰는 경우
  • RDS의 다중 가용 영역(Multi-AZ) 구성이나 읽기 전용 복제본을 함께 조정해야 하는 경우
  • AWS Graviton 기반 인스턴스로 옮기는 것처럼 애플리케이션 재검증이 따라붙는 변경이 필요한 경우

04. EBS·스냅샷

EBS 볼륨은 실제로 쓴 용량이 아니라 프로비저닝한 용량과 성능 기준으로 과금되고, 스냅샷은 증분 방식이라 개수를 줄이는 것과 저장량을 줄이는 것이 일치하지 않습니다. 정리했는데 기대만큼 변하지 않는 이유가 대체로 이 구조에 있습니다.

• 왜 중요한가 — 스냅샷은 직전 스냅샷과 달라진 블록만 저장하지만, 체인 안의 어떤 블록을 다른 스냅샷이 여전히 참조하고 있으면 하나를 지워도 그 블록은 남습니다. 볼륨 쪽도 유형마다 요금 구조가 달라, 예전에 만든 볼륨이 지금은 필요하지 않은 성능을 계속 확보하고 있을 수 있습니다.
• 문제 시 나타나는 지표
  • 보존 정책 없이 수동으로 만들어진 스냅샷이 계속 쌓이는 상태
  • 이미 삭제된 볼륨의 스냅샷만 남아 있는 상태
  • 프로비저닝 용량 대비 실제 사용량이 오랫동안 낮게 유지되는 볼륨
• 우선 조치 — 스냅샷마다 만들어진 이유를 먼저 구분합니다. 정기 백업인지, 배포 전 안전장치인지, 일회성 검증용인지에 따라 처리가 달라집니다. 그다음 보존 기간을 정책으로 명시합니다. 스냅샷의 생성·보존·삭제 자동화는 Amazon Data Lifecycle Manager 또는 AWS Backup으로 하고, 수동 스냅샷은 소유자 확인을 거칩니다.
• 전문가 검토가 필요한 조건
  • 백업 보존 기간이 계약이나 규제로 정해져 있는 경우
  • 복구 시점 목표와 복구 시간 목표가 문서로 합의돼 있는 경우

비용 기준으로만 스냅샷을 정리하면 복구 요건을 조용히 깨뜨릴 수 있습니다.

05. NAT Gateway·데이터 전송

NAT Gateway와 데이터 전송 요금은 리소스 개수가 아니라 통과하는 트래픽의 경로와 양에 붙기 때문에, 구성도만 봐서는 예측되지 않습니다. 인스턴스를 늘린 적이 없는데 요금이 오르는 항목이 대체로 여기입니다.

• 왜 중요한가 — NAT Gateway는 시간당 요금과 처리 데이터량 요금이 함께 붙고, 프라이빗 서브넷의 인스턴스가 AWS 서비스를 인터넷 경로로 호출하면 그 트래픽이 전부 NAT를 통과합니다. 가용 영역 사이를 오가는 트래픽과 리전 밖으로 나가는 트래픽도 각각 별도의 요금 구조를 가집니다.
• 문제 시 나타나는 지표
  • 인스턴스 수는 그대로인데 NAT Gateway 처리량만 늘어나는 상태
  • 로그 전송·백업·컨테이너 이미지 내려받기가 인터넷 경로로 나가는 상태
  • 애플리케이션과 데이터베이스가 서로 다른 가용 영역에 있어 왕복 트래픽이 상시 발생하는 상태
• 우선 조치 — 어떤 트래픽이 NAT를 통과하는지부터 확인합니다. VPC 흐름 로그로 목적지 분포를 보면 어느 서비스가 큰 비중인지 드러나고, S3나 DynamoDB처럼 게이트웨이 유형 엔드포인트를 쓸 수 있는 대상이 큰 비중이면 전환 검토 대상이 됩니다.
• 전문가 검토가 필요한 조건
  • 서브넷과 라우팅 테이블을 바꿔야 하는 경우
  • 온프레미스 연결이나 여러 VPC가 얽혀 있는 경우

경로 변경은 잘못되면 비용이 아니라 통신 자체가 끊깁니다.

VPC 엔드포인트(VPC Endpoint) 전환은 검토 기준이지 정답이 아닙니다. 판단은 엔드포인트 유형에 따라 갈립니다. S3·DynamoDB에 쓰는 게이트웨이 유형은 엔드포인트 자체에 추가 요금이 붙지 않아 판단이 단순합니다. 반면 그 밖의 서비스에 쓰는 인터페이스 유형은 엔드포인트를 두는 비용과 그것이 걷어내는 NAT 처리량을 견줘 봐야 하므로, 그 서비스로 나가는 트래픽이 꾸준히 큰지를 실제 통과량으로 확인한 뒤 대상 서비스별로 따로 계산합니다. 평상시 점검이 아니라 특정 시점 이후의 급등을 쫓는 중이라면 비용이 갑자기 올랐을 때의 확인 순서가 그 경로를 다룹니다.

06. 개발·테스트 환경 시간 외 가동

개발·테스트 환경은 사람이 쓰지 않는 시간에 켜져 있어도 그 시간만큼 그대로 과금됩니다. 프로덕션과 달리 상시 가동해야 할 이유가 없는 경우가 많아, 되돌리기 쉬운 항목에 속합니다.

• 왜 중요한가 — EC2와 RDS 요금은 가동 시간 단위로 붙기 때문에, 아무도 접속하지 않는 시간대에 환경이 계속 실행되고 있으면 실제 사용 시간과 과금 시간의 차이가 매주 반복됩니다.
• 문제 시 나타나는 지표
  • 야간·주말의 접속 로그나 지표가 사실상 비어 있는데 인스턴스는 계속 실행 중인 상태
  • 검증용으로 잠깐 만든 환경이 종료 담당자 없이 남아 있는 상태
  • 개발 환경 이름이 붙은 리소스가 프로덕션과 비슷한 규모로 유지되는 상태
• 우선 조치 — 자동 중지 대상을 태그로 표시하고 일정 기반 시작·중지를 적용합니다. Instance Scheduler on AWS 같은 솔루션을 쓰거나 자체 자동화로 구성할 수 있습니다. 적용 전에 중지 후 정상 기동하는지, 중지 시간대에 실행되는 배치가 없는지 확인합니다.
• 전문가 검토가 필요한 조건
  • 야간 배치나 CI 빌드처럼 시간 외 사용이 실제로 존재하는 경우
  • 중지와 기동 순서가 서비스 간 의존성에 걸리는 경우

중지했다가 기동이 실패하면 비용 문제가 아니라 가용성 문제가 됩니다.

07. 예약 인스턴스(RI)·Savings Plans 약정

점검 항목 중 마지막에 두는 이유는 약정이 되돌리기 가장 어려운 결정이기 때문입니다. 정리되지 않은 구성 위에 약정을 걸면 지금의 낭비를 약정 기간만큼 고정하게 됩니다.

• 왜 중요한가 — 온디맨드로만 운영하면 연중 안정적으로 돌아가는 부분까지 가장 유연한 방식으로 지불하게 되고, 반대로 곧 줄이거나 바꿀 사양에 약정을 걸면 그 결정이 기간 내내 묶입니다. Savings Plans와 예약 인스턴스는 적용 범위와 유연성이 서로 다르므로, 무엇을 확약하는 것인지 먼저 확인해야 합니다.
• 문제 시 나타나는 지표
  • 연중 거의 일정하게 유지되는 최소 사용량이 뚜렷한데, Savings Plans 적용률 리포트(coverage report)에서 덮이는 비중이 낮게 나오는 상태
  • 반대로 사용률 리포트(utilization report)에서 확약분이 남아 쓰이지 않는 것으로 나오는 상태
  • 기존 약정의 만료일이 관리 대장에 없어 만료 뒤에야 요금 변화로 인지하는 상태
• 우선 조치 — 미사용 리소스 정리와 사이징을 끝낸 뒤의 사용량을 기준선으로 삼습니다. 그다음 연중 유지되는 최소 사용량 구간만 먼저 덮고, 변동분은 온디맨드로 남깁니다. 기간·선결제 방식·적용 범위는 유연성과 단가가 교환 관계이므로 조직이 감당할 수 있는 쪽을 택합니다.
• 전문가 검토가 필요한 조건
  • 약정 기간 안에 아키텍처 변경·이전·대규모 증감 계획이 있는 경우
  • 계정이 여러 개라 약정이 어느 범위까지 적용되는지 확인이 필요한 경우

08. 개선 우선순위 정리

점검의 마지막 단계는 발견한 항목을 되돌리기 난이도와 영향 범위 기준으로 배치해 실행 순서를 정하는 일입니다. 목록만 남기면 다음 분기에 같은 목록을 다시 만들게 됩니다.

• 왜 중요한가 — 발견은 그 자체로 아무것도 바꾸지 않습니다. 항목마다 되돌리기 난이도가 다르고 담당 부서도 다르기 때문에, 순서와 책임이 정해지지 않으면 처리하기 쉬운 항목조차 미뤄집니다.
• 문제 시 나타나는 지표
  • 지난 점검 목록의 항목이 이번에도 그대로 남아 있는 상태
  • 담당자와 기한이 비어 있는 상태
  • 조치 내용이 전부 “검토”로만 적혀 있어 무엇이 끝난 것인지 판별되지 않는 상태
• 우선 조치 — 되돌리기 쉽고 영향 범위가 좁은 항목(미사용 리소스 정리·태그 부여·비프로덕션 자동 중지)을 먼저 처리하고, 되돌리기 어려운 항목(약정·프로덕션 사양·경로 변경)은 근거 자료를 갖춘 뒤 별도 결정으로 올립니다. 항목마다 담당자·기한·완료 판정 기준을 함께 적습니다.
• 전문가 검토가 필요한 조건
  • 상위 항목 대부분이 아키텍처 변경이거나 서로 의존해 단독으로 실행할 수 없는 경우
  • 대규모 리소스 변경, 코드형 인프라 대규모 수정, 데이터베이스 이전처럼 실행 자체가 별도 과제가 되는 항목이 상위에 몰린 경우

점검 결과를 어떻게 남기는가

점검 결과는 항목 목록이 아니라 판단 기록으로 남겨야 다음 점검에서 처음부터 다시 보지 않습니다. 같은 항목을 매 분기 새로 발견하는 조직과, 지난번에 “이건 의도된 구성”으로 판정한 항목을 건너뛰는 조직의 차이가 여기서 갈립니다.

기록에 들어갈 것은 네 가지입니다.

• 판정 — 조치 / 유지(의도된 구성) / 보류 중 하나. 유지로 판정했다면 그 이유를 한 줄 적습니다.
• 근거 — 어느 화면, 어느 지표에서 무엇을 보고 그렇게 판단했는지.
• 담당자와 기한 — 비어 있으면 그 항목은 다음 분기에도 그대로 남습니다.
• 재검토 조건 — 어떤 상황이 되면 판정을 다시 볼 것인지. 예를 들어 “야간 배치가 종료되면 자동 중지 대상에 포함”.

여기에 상시 관측을 붙여 두면 점검과 점검 사이의 변화가 드러납니다. 예산을 정해 두고 초과를 알리는 AWS Budgets, 평소와 다른 지출 패턴을 기계학습으로 찾아 알리는 AWS Cost Anomaly Detection을 설정하는 방식입니다. 다만 알림은 알려줄 뿐 대응하지 않습니다. 받을 사람과 받은 뒤 무엇을 하는지가 정해져 있지 않으면 알림은 곧 무시되는 메일이 됩니다.

항목 단위가 아니라 우리 조직의 비용 관리 성숙도가 어느 수준인지 보고 싶다면 AWS 비용·구조 1분 자가 진단으로 현재 위치를 확인하실 수 있습니다.

점검을 마친 뒤 무엇을 할 것인가

점검 이후의 선택은 각 항목에서 전문가 검토가 필요한 조건에 몇 번 해당했는지로 갈립니다. 거의 걸리지 않았다면 내부에서 순서대로 처리해도 무리가 없고, 여러 항목에서 반복해 걸렸다면 항목별 조치보다 구성 전체를 함께 보는 편이 낫습니다.

• 내부에서 진행하는 경우 — 되돌리기 쉬운 항목부터 처리하고, 약정과 프로덕션 사양은 근거를 모은 뒤 별도 결정으로 올립니다.
• 외부 점검을 검토하는 경우 — 비용 구조 분석과 개선 우선순위 제시의 범위는 AWS 비용 구조 점검에 정리돼 있고, 금액 기준은 AWS 운영 플랜과 요금에서 확인하실 수 있습니다.
• 기준선부터 없는 경우 — AWS 무료 점검 신청으로 현황 파악부터 시작하실 수 있습니다.

점검을 반복하는 대신 운영 자체를 맡기는 선택을 검토 중이라면, 무엇이 포함되고 무엇이 포함되지 않는지를 운영을 맡긴다는 것의 범위에서 먼저 확인하십시오. 우리 환경에 어느 항목이 해당하는지 함께 보는 편이 빠르다면 상담 신청으로 연락 주십시오.

참고 자료

• AWS Cost Explorer — AWS Cost Management 사용 설명서
• Elastic IP 주소 — Amazon EC2 사용 설명서
• Amazon EBS 스냅샷 — 사용 설명서
• Amazon EBS 요금
• Amazon VPC 요금 — NAT Gateway·데이터 전송
• AWS PrivateLink — VPC 엔드포인트 개념
• AWS Savings Plans 사용 설명서
• Amazon EC2 예약 인스턴스 — 사용 설명서
• AWS Compute Optimizer 사용 설명서
• Instance Scheduler on AWS — 솔루션 문서