AWS 비용이 갑자기 올랐다면, 이 순서로 확인하십시오

청구서는 결과만 보여줍니다. 어느 자원이 왜 그만큼 썼는지는 적혀 있지 않습니다. 그래서 금액이 튄 것을 발견한 담당자는 대개 콘솔을 이곳저곳 열어 보다가 시간을 씁니다.

원인은 추측이 아니라 순서로 찾습니다. 서비스로 좁히고, 기간으로 좁히고, 그 서비스의 사용량 지표와 대조하는 순서입니다. 이 글은 그 순서와 함께, 실무에서 반복해 나오는 원인을 서비스 단위로 정리합니다.

먼저 할 일 — 증가분이 어디에 몰렸는지 확인

AWS 비용이 갑자기 올랐다면 Cost Explorer를 열어 서비스별·일별로 증가 구간을 좁히는 것이 첫 단계입니다. Cost Explorer는 Billing and Cost Management 안에 있습니다. 화면이 열리지 않는다면 결제 정보 접근 권한이 없는 것이므로 계정 관리자에게 요청해야 합니다. 원인을 짐작하기 전에 증가분이 어디에 몰렸는지부터 확정해야 나머지 확인이 짧아집니다.

확인 순서는 다음과 같습니다.

1. 기간과 세분성 — 이번 달과 지난달 같은 기간을 나란히 놓고 세분성을 일별로 바꿉니다. 월 합계만 보면 언제부터 늘었는지가 보이지 않습니다.
2. 서비스별 그룹화 — 증가분이 어느 서비스에서 나왔는지 먼저 특정합니다.
3. 사용 유형(Usage Type)으로 한 번 더 — 같은 서비스 안에서도 과금 축이 여러 개입니다. NAT Gateway가 시간당 요금에서 늘었는지 처리량 요금에서 늘었는지에 따라 조치가 달라집니다.
4. 연결 계정·태그별 — 계정을 여러 개 쓴다면 어느 계정인지 먼저 좁힙니다. 비용 할당 태그가 켜져 있다면 팀·환경 단위까지 내려갈 수 있습니다.
5. 증가 시작일 특정 — 특정 날짜부터 계단처럼 올랐다면 설정 변경이나 신규 자원이 원인일 가능성이 큽니다. 최근 1~2일 구간은 아직 채워지는 중이므로 시작일 판정에서 제외합니다. 완만하게 우상향한다면 특정 사건이 아니라 사용량 자체가 늘고 있는 것이므로, 이 글의 원인 목록보다 AWS 비용 점검 체크리스트의 정기 점검 항목이 맞는 도구입니다.

증가분이 한 서비스에 몰려 있으면 원인은 대개 하나입니다. 여러 서비스에 고르게 흩어져 있다면 개별 자원이 아니라 구조나 트래픽 총량이 바뀐 것으로 보는 편이 맞습니다.

원인 1. NAT Gateway — 처리량이 그대로 요금이 된다

NAT Gateway는 게이트웨이가 존재하는 시간과 게이트웨이를 통과한 데이터 처리량에 각각 별개로 요금이 붙습니다. 두 축이 나뉘어 있어서 인스턴스 대수가 그대로여도 통과 트래픽만 늘면 요금이 오릅니다.

갑자기 커지는 경로는 대체로 정해져 있습니다. 프라이빗 서브넷에 있는 워크로드가 S3·ECR·DynamoDB 같은 AWS 서비스를 인터넷 경로로 접근하면 그 트래픽이 전부 NAT를 통과합니다. 컨테이너 이미지를 배포마다 다시 내려받거나, 로그·백업을 대량으로 내보내거나, 배치 작업을 증설하면 처리량이 곧바로 따라 붙습니다.

확인은 세 곳에서 합니다. Cost Explorer의 사용 유형 축에서 시간당 항목(NatGateway-Hours 계열)과 바이트 처리 항목(NatGateway-Bytes 계열)을 분리해 어느 쪽이 늘었는지 봅니다. 사용 유형 이름 앞에는 리전 코드가 붙어 나오므로 목록에서는 뒷부분을 기준으로 찾는 편이 빠릅니다. CloudWatch의 NAT Gateway 지표로 처리 바이트가 증가한 시점을 잡습니다. VPC 흐름 로그(VPC 안에서 오간 통신의 출발지·목적지·양을 기록하는 기능)가 켜져 있다면 어느 자원이 NAT로 많이 내보내는지까지 좁힐 수 있습니다. 다만 이 로그는 켜는 것 자체가 수집·저장 비용을 만들므로, 조사 기간에만 켜고 끝나면 다시 끄는 편이 안전합니다.

원인 2. 데이터 전송 — 방향에 따라 과금이 갈린다

데이터 전송은 방향과 경계에 따라 과금 여부와 항목이 달라집니다. 인터넷으로 나가는 트래픽, 리전 간 트래픽, 같은 리전 안에서 가용 영역을 넘는 트래픽이 서로 다른 항목으로 붙고, 들어오는 트래픽과 나가는 트래픽의 취급도 같지 않습니다.

갑자기 커지는 경우는 대개 응답이 무거워졌거나 경로가 늘어난 때입니다. 배포 이후 이미지·파일 응답 크기가 커지면 나가는 트래픽이 함께 늘어납니다. 로그와 백업을 다른 리전으로 복제하기 시작한 경우, 캐시 적중률이 떨어져 오리진을 직접 조회하는 비율이 올라간 경우도 같습니다. 애플리케이션과 데이터베이스가 서로 다른 가용 영역에 놓인 구성에서는 평범한 내부 통신이 계속 과금됩니다.

확인은 Cost Explorer의 사용 유형 축에서 전송 관련 항목을 골라 보는 것으로 시작합니다. 인터넷으로 나간 양은 DataTransfer-Out-Bytes, 같은 리전 안의 AWS 자원 사이에서 오간 양은 DataTransfer-Regional-Bytes 계열로 잡힙니다. CloudFront·ALB·S3가 각각 별도 항목으로 잡히므로 어느 경계에서 늘었는지 구분할 수 있고, 상대 주소까지 알아야 한다면 VPC 흐름 로그를 봅니다.

원인 3. EBS 스냅샷 — 지우는 절차가 없으면 계속 쌓인다

EBS 스냅샷은 변경분만 저장하는 증분 방식이지만, 저장된 총량에 대해 계속 요금이 붙습니다. 볼륨을 지워도 그 볼륨에서 뜬 스냅샷은 남고, AMI도 뒤에 스냅샷을 가지고 있습니다.

조용히 쌓이는 이유는 만드는 절차만 있고 지우는 절차가 없기 때문입니다. 자동 백업 정책이 보존 기간 없이 돌면 스냅샷은 날마다 늘어나기만 합니다. 이관이나 릴리스 직전에 안전장치로 수동으로 뜬 스냅샷도 정리 담당이 없으면 그대로 남습니다. 여기에 삭제된 인스턴스가 남긴 미연결 볼륨까지 겹칩니다. 증가가 눈에 띌 때쯤에는 이미 상당량이 누적된 상태입니다.

확인은 EC2 콘솔의 스냅샷 목록을 소유 계정 기준으로 걸러 생성일 순으로 정렬하는 것으로 시작합니다. Cost Explorer에서는 표준 등급 스냅샷이 EBS:SnapshotUsage 사용 유형으로 별도로 나옵니다. 어떤 스냅샷이 AMI에 묶여 있는지도 함께 확인해야 삭제 판단이 가능합니다.

원인 4. CloudWatch Logs — 수집량과 보존이 둘 다 과금된다

CloudWatch Logs는 수집된 로그 양과 저장·보존되는 양에 각각 요금이 붙고, Logs Insights 같은 조회에도 별도로 붙습니다. 축이 나뉘어 있어서 로그를 덜 남기는 조치와 덜 오래 두는 조치의 효과가 서로 다릅니다.

갑자기 커지는 흔한 경우는 디버그 로그입니다. 장애를 보려고 로그 레벨을 올린 뒤 되돌리지 않으면 수집량이 그대로 유지됩니다. 트래픽이 늘면 액세스 로그는 비례해서 늘어납니다. 그리고 새로 만들어진 로그 그룹은 보존 기간이 설정되지 않으면 만료 없이 계속 쌓이므로, 함수나 서비스를 추가한 시점부터 저장량이 조용히 우상향합니다.

확인은 CloudWatch 콘솔의 로그 그룹 목록에서 저장 바이트와 보존 기간을 열로 정렬해 보는 것이 가장 빠릅니다. 보존 기간이 비어 있는 그룹과 저장량 상위 그룹이 겹치는 지점이 대개 원인입니다. Cost Explorer에서는 수집이 DataProcessing-Bytes, 표준 등급 저장이 TimedStorage-ByteHrs 사용 유형으로 나뉘어 잡힙니다. 어느 축이 늘었는지 여기서 바로 갈라 볼 수 있습니다.

원인 5. 약정 만료 — 아무것도 바꾸지 않았는데 오른다

Savings Plans와 예약 인스턴스는 약정 기간 동안 해당 사용량에 할인 요금을 적용합니다. 약정이 끝나면 자원이 그대로 돌아가고 있어도 그 시점부터 온디맨드(약정 없이 쓴 만큼 내는 기본 요금) 요금으로 청구됩니다. 우리 쪽에서 아무것도 바꾸지 않았는데 금액이 오르는 대표적인 경우입니다.

만료 외에도 할인이 덜 걸리게 되는 경로가 있습니다. 사용량이 약정 범위를 넘어서면 초과분은 온디맨드로 붙고, 인스턴스 패밀리나 리전을 바꾸면 기존 약정의 적용 대상에서 벗어날 수 있습니다. 어느 쪽이든 사용량 그래프는 평평한데 비용 그래프만 계단으로 올라가는 모양이 나옵니다.

확인은 Billing and Cost Management 콘솔의 Savings Plans·예약 인스턴스 목록에서 만료일을 보는 것으로 시작합니다. 활용률과 적용률 리포트를 함께 보면 약정이 남아 있는데도 할인이 덜 걸리고 있는지 판단할 수 있습니다. 두 리포트는 반대쪽을 봅니다. 활용률이 낮으면 사 둔 약정을 다 쓰지 못하고 있는 것이고, 적용률이 낮으면 약정 밖 사용량이 온디맨드로 새고 있는 것입니다.

원인 6. 신규 리소스 — 누가 언제 만들었는가

새로 만들어진 자원은 만들어진 시점부터 과금됩니다. 청구 데이터는 서비스와 사용 유형으로 집계되기 때문에, 누가 언제 무엇을 만들었는지는 청구서가 아니라 변경 이력에서 확인해야 합니다.

늘어나는 경위는 대체로 정리되지 않은 것들입니다. 검증용으로 띄운 환경이 그대로 남습니다. 자동 확장이 트래픽에 반응해 늘어난 뒤 축소 조건에 걸리지 않아 유지되기도 합니다. 담당자 교체 과정에서 인수인계 목록에 빠진 자원이 계속 돌아가는 경우도 있습니다. 코드로 관리하는 범위 밖에서 콘솔로 직접 만들어진 자원은 특히 추적이 늦습니다.

확인은 CloudTrail 이벤트 기록에서 증가 시작일 전후를 보는 것이 가장 정확합니다. 인스턴스·데이터베이스·로드밸런서 생성 이벤트를 그 구간으로 걸러 보면 만든 주체와 시각이 함께 나옵니다.

원인 7. 우리 손 밖의 변수 — 사용량은 그대로인데 금액이 달라진다

환경이 그대로여도 청구 금액이 달라지는 요인이 있습니다. AWS의 요금 개정, 청구 통화와 환율, 세금 항목, 프리티어 종료, 지원 플랜 구독 항목이 여기에 해당합니다.

이 요인들은 사용량 지표를 아무리 봐도 원인이 잡히지 않는다는 공통점이 있습니다. 사용량 그래프는 평평한데 금액만 달라졌다면 단가나 환산 조건이 바뀐 쪽을 봐야 합니다. 계정을 만든 지 오래되지 않았다면 프리티어 적용이 끝난 시점과 증가 시점이 겹치는지도 확인 대상입니다.

확인은 Billing 콘솔의 청구서 화면에서 합니다. 통화, 세금 줄, 지원 플랜 줄을 개별로 보면 사용량과 무관한 증가분을 분리할 수 있습니다.

어느 요인인지는 지난달 청구서와 이번 달 청구서를 같은 항목끼리 나란히 놓고 어느 줄이 달라졌는지로 가릅니다. 세금과 지원 플랜은 각각 별도 줄이라 눈에 바로 띕니다. 환율은 통화 환산 조건이 붙은 줄에서 드러납니다. 요금 개정은 사용량 수치는 그대로인데 그 줄의 금액만 달라진 모양으로 나타나므로, 청구서와 사용량 리포트를 같은 기간으로 대조하면 구분됩니다. 프리티어는 Billing and Cost Management 콘솔의 Free Tier 페이지에서 서비스별 한도 대비 사용량과 초과 여부를 볼 수 있습니다. 계정에 적용된 크레딧의 만료일은 같은 콘솔의 크레딧 페이지에서 확인합니다. 구체적인 단가와 조건은 공식 요금 페이지에서 확인하십시오.

원인을 찾은 다음 — 조치 순서

조치는 먼저 측정, 그다음 변경 순서로 합니다. 원인을 특정하기 전에 자원을 지우거나 사양을 낮추면 비용 대신 장애를 만듭니다. 원인을 찾았더라도 되돌리기 쉬운 것부터 손대는 편이 안전합니다.

• 되돌릴 수 있는 것부터 — 올려 둔 로그 레벨을 낮추고, 보존 기간이 비어 있는 로그 그룹에 기간을 설정합니다. 실수해도 되돌리기 쉽고 효과가 바로 보입니다.
• 삭제는 확인 뒤에 — 쓰지 않는 것처럼 보이는 스냅샷, 미연결 볼륨, 정지된 인스턴스는 복구 근거이거나 감사 자료일 수 있습니다. 소유 부서와 용도를 확인하고 보존 정책을 정한 다음, 그 정책에 따라 정리합니다.
• 경로 변경은 영향 범위를 확인하고 — VPC 엔드포인트 도입이나 가용 영역 배치 조정은 통신 경로 자체를 바꿉니다. 검증 환경에서 먼저 확인하고 점검 시간대를 정해 진행합니다.
• 약정은 마지막에 — 사용량이 앞으로도 유지될 것이 확인된 뒤에 검토합니다.
• 조치 후 같은 축으로 다시 측정 — 처음에 썼던 것과 동일한 그룹화 축으로 다시 확인해야 실제로 줄었는지 알 수 있습니다.

이번 건을 정리한 다음에는 같은 일이 반복되지 않게 하는 쪽으로 넘어갑니다. AWS 비용 점검 체크리스트는 이미 오른 비용의 원인을 찾는 이 글과 달리, 아직 오르지 않았을 때 무엇을 어떤 기준으로 정기 점검할지를 다룹니다.

혼자 판단하기 전에 멈출 지점

프로덕션 트래픽 경로 변경, 신규 약정 체결, 데이터베이스 사양 조정은 되돌리는 비용이 큰 결정입니다. 비용을 줄이려던 조치가 서비스 중단이나 장기 지불 의무로 돌아오는 지점이 여기입니다.

• 트래픽 경로 변경 — 라우팅과 엔드포인트 구성을 잘못 바꾸면 통신이 끊깁니다. 영향 받는 워크로드 목록이 먼저 있어야 합니다.
• 신규 약정 체결 — 지불 의무는 사용량을 줄여도 남습니다. 축소 계획이 있는 워크로드에 약정을 거는 것이 가장 흔한 실수입니다.
• 데이터베이스 사양 하향 — 재시작이 필요할 수 있고, 성능 여유가 사라지면 다음 트래픽 증가 때 장애로 나타납니다.

증가분이 한 서비스가 아니라 여러 서비스에 흩어져 있다면 단발 사고가 아니라 구조 문제일 가능성이 큽니다. 현재 상태를 항목별로 먼저 보고 싶다면 AWS 비용·구조 1분 자가 진단으로 위치를 확인하실 수 있습니다. 같은 일이 반복되는 이유가 “보는 사람이 없어서”에 가깝다면 AWS 운영을 맡긴다는 것의 범위에서 어디까지 위탁할 수 있는지 판단 기준을 정리해 두었습니다.

다음 단계

AWS 비용 증가의 원인을 특정한 뒤에도 같은 일이 반복된다면, 그때는 개별 원인이 아니라 구조를 보는 작업입니다. 청구서 한 번을 진정시키는 것과 매달 같은 일이 안 생기게 만드는 것은 다른 작업입니다.

현재 AWS 환경의 구성과 비용 구조를 함께 훑어보고 싶으시다면 AWS 무료 점검 신청에서 시작하실 수 있습니다.

원인 파악과 조치를 함께 진행할 인력이 없다면 AWS 비용 구조 점검에서 다루는 범위를 확인하십시오. 운영을 정기적으로 맡기는 방식과 조건은 AWS 운영 플랜과 요금에 정리돼 있습니다.

AWS 요금은 개정되고 리전마다 다르므로 이 글은 단가를 적지 않고 과금 구조만 설명했습니다. 실제 숫자는 아래 공식 요금 페이지에서 확인하십시오.

참고 자료

• Amazon VPC 요금 — NAT Gateway·VPC 엔드포인트
• NAT 게이트웨이 — Amazon VPC 사용 설명서
• Amazon EC2 온디맨드 요금 — 데이터 전송
• Amazon EBS 요금
• Amazon EBS 스냅샷 — 증분 저장 방식
• Amazon CloudWatch 요금
• CloudWatch Logs — 로그 그룹과 보존 기간
• AWS Cost Explorer — AWS Cost Management 사용 설명서
• AWS Cost Anomaly Detection 시작하기
• AWS Budgets — 비용 관리
• Savings Plans 사용 설명서
• AWS CloudTrail 사용 설명서