월초에 Azure 청구서를 열었는데 지난달보다 확 뛰어 있는 상황. 이때 가장 나쁜 대응은 리소스 목록을 위에서부터 훑으면서 범인을 찾는 것입니다. 구독에 리소스가 수백 개면 하루가 갑니다.
비용 급증은 대부분 단일 원인이고, Cost Analysis에서 축을 네 번 바꾸는 것만으로 대개 30분 안에 잡힙니다. 이 글은 그 네 번의 순서와, 각 단계에서 무엇을 보고 다음으로 넘어갈지를 정리한 것입니다. 마지막에는 같은 일이 반복되지 않도록 알림을 거는 방법까지 붙였습니다.
시작 전: “언제부터”를 먼저 확정한다
범인을 찾기 전에 사건 발생 시각을 특정해야 합니다. 이게 있으면 이후 모든 단계가 빨라집니다.
- 비용 관리 → 비용 분석 진입
- 기간을 지난 3개월로 넓힘
- 세분성을 일별로 (월별로 보면 계단이 안 보입니다)
- 차트를 누적 세로 막대로
여기서 그래프 모양이 두 가지 중 하나로 나옵니다. 어느 쪽이냐에 따라 원인의 성격이 완전히 다릅니다.
| 그래프 모양 | 의미 | 유력한 원인 |
|---|---|---|
| 특정 날짜부터 계단식 상승 후 유지 | 리소스가 새로 생겨 계속 돌고 있음 | VM·AKS 노드 풀 신규 배포, 티어 상향, 자동 종료 해제 |
| 하루이틀 뾰족하게 튀고 복귀 | 일회성 대량 작업 | 대량 데이터 전송(송신 트래픽), 백업 전체 실행, 배치 폭주 |
| 완만하게 우상향 | 쌓이는 자원 | 스토리지 증가, 로그 보존, 스냅샷 누적 |
계단식이면 “누가 무엇을 만들었나”를, 뾰족하면 “그날 무슨 작업을 했나”를, 우상향이면 “무엇이 안 지워지고 있나”를 쫓으면 됩니다. 질문이 달라집니다.
1차 — 서비스 이름으로 쪼갠다
그룹화를 Service name으로 바꿉니다. 이 한 번으로 범위가 수백 개 리소스에서 서비스 한두 개로 줄어듭니다.
증가분이 어디에 있는지에 따라 갈 길이 정해집니다.
- Virtual Machines → 2차로 (크기·수량 문제)
- Storage → 스냅샷·버전·로그 누적 의심. 수명 주기 정책 글 참고
- Bandwidth → 송신 트래픽. 리전 간 통신이나 외부 다운로드 급증
- Azure Monitor / Log Analytics → 진단 설정을 켠 직후 급증하는 대표적 항목
- Azure Firewall / Application Gateway → 배포만 해도 시간당 고정 요금이 붙는 서비스
경험상 예상 밖의 1위를 자주 차지하는 게 Log Analytics입니다. 문제 조사한다고 진단 설정에서 로그 카테고리를 전부 켜두고 그대로 잊으면, 수집량이 그대로 요금이 됩니다. 특히 AKS의 컨테이너 로그와 Application Gateway 액세스 로그는 양이 매우 많습니다.
2차 — 리소스 그룹으로 책임 소재를 좁힌다
서비스가 정해졌으면 그룹화를 Resource group으로 바꿉니다. 여기서 어느 팀·어느 환경의 문제인지가 드러납니다.
이 단계에서 rg-dev-*나 rg-test-*가 상위에 올라오면 거의 확정입니다. 개발 환경이 꺼지지 않고 있는 것입니다. 자동 종료가 풀렸거나, 누군가 테스트하려고 켠 뒤 잊었거나, 새 노드 풀을 만들고 안 지운 경우입니다.
반대로 이름 규칙에 안 맞는 리소스 그룹(rg-test-2, Default-... 같은)이 튀어나오면 임시로 만들고 방치된 것입니다. 태그 정책이 없는 구독에서 흔합니다.
3차 — 리소스와 미터로 확정한다
그룹화를 Resource로 바꾸면 개별 리소스가 나옵니다. 여기서 끝내지 말고 한 번 더, Meter로 바꿔서 봐야 합니다.
Meter는 같은 리소스 안에서 어떤 항목이 돈을 먹는지를 보여줍니다. 예를 들어 VM 하나가 범인으로 지목됐을 때, Meter로 보면 원인이 셋 중 하나로 갈립니다.
D8s v5 Compute가 크다 → VM 자체가 큼. 크기 축소 검토P30 Disks가 크다 → 프리미엄 디스크. 실제 IOPS 필요 여부 확인Data Transfer Out이 크다 → 송신 트래픽. 아키텍처 문제일 수 있음
세 번째가 나오면 리소스 문제가 아니라 설계 문제입니다. 리전 간 통신이 발생하고 있거나, CDN을 안 거치고 스토리지에서 직접 다운로드를 내보내고 있을 가능성이 큽니다. VM 크기를 줄여도 해결되지 않습니다.
CLI로 한 번에 뽑기
포털 클릭이 번거로우면 이렇게도 됩니다. 지난달 대비 이번달 리소스별 비용을 뽑아 정렬합니다.
#!/usr/bin/env bash
set -euo pipefail
SUB="00000000-0000-0000-0000-000000000000"
# 이번 달 리소스별 비용 상위 20건
az costmanagement query \
--type ActualCost \
--scope "/subscriptions/$SUB" \
--timeframe MonthToDate \
--dataset-aggregation '{"totalCost":{"name":"Cost","function":"Sum"}}' \
--dataset-grouping name=ResourceId type=Dimension \
--query "rows | sort_by(@, &[0]) | reverse(@) | [0:20]" \
-o tsv계단식 상승이었다면 언제 무엇이 만들어졌는지를 활동 로그에서 직접 확인하는 편이 확실합니다.
# 급증 시작일 전후로 생성된 리소스와 실행 주체 조회
az monitor activity-log list \
--start-time 2026-07-08T00:00:00Z \
--end-time 2026-07-10T00:00:00Z \
--query "[?authorization.action=='Microsoft.Resources/deployments/write' \
|| contains(authorization.action, '/write')].\
{time:eventTimestamp, who:caller, what:authorization.scope}" \
-o tablecaller 필드에 실행한 계정이 찍힙니다. 서비스 주체(Service Principal)로 나오면 파이프라인이 만든 것이므로, 사람이 아니라 CI/CD 설정을 봐야 합니다. Terraform이 destroy에 실패해 리소스가 중복 생성되는 경우가 여기서 잡힙니다.
범인이 안 잡힐 때 확인할 사각지대 4곳
위 순서를 다 밟았는데도 뚜렷한 원인이 없다면, 아래 네 곳을 보세요. 리소스 목록에 잘 안 보이거나, 보여도 대수롭지 않아 보이는 것들입니다.
1) 연결이 끊긴 관리 디스크
VM을 지워도 디스크는 남습니다. 아무 데도 안 붙어 있는데 요금은 그대로 나갑니다. 몇 달 쌓이면 무시 못 할 금액이 됩니다.
# 어디에도 붙어있지 않은 디스크 조회
az disk list \
--query "[?diskState=='Unattached'].\
{name:name, rg:resourceGroup, sizeGB:diskSizeGb, sku:sku.name}" \
-o table2) 할당만 되고 안 쓰는 공용 IP
Standard SKU 공용 IP는 연결 여부와 무관하게 시간당 요금이 붙습니다. 개당 금액은 작지만 수십 개가 쌓이면 눈에 띕니다.
az network public-ip list \
--query "[?ipConfiguration==null].{name:name, rg:resourceGroup, sku:sku.name}" \
-o table3) “중지됨”이지만 할당 해제가 아닌 VM
게스트 OS 안에서 shutdown만 하면 VM은 Stopped 상태가 되고 컴퓨팅 요금이 계속 청구됩니다. 과금이 멈추려면 Stopped (deallocated)여야 합니다. 껐다고 믿고 있는데 청구되는 사고의 대부분이 이것입니다.
# 껐는데 과금되고 있는 VM 찾기
az vm list -d \
--query "[?powerState=='VM stopped'].{name:name, rg:resourceGroup, state:powerState}" \
-o table
# 제대로 끄기
az vm deallocate --name <VM> -g <RG>4) 오래된 스냅샷과 복구 지점
백업 정책의 보존 기간이 길게 잡혀 있으면 복구 지점이 계속 쌓입니다. 수동으로 뜬 스냅샷은 아무도 안 지웁니다. 완만한 우상향 그래프의 단골 원인입니다.
az snapshot list \
--query "sort_by([].{name:name, rg:resourceGroup, \
created:timeCreated, sizeGB:diskSizeGb}, &created)" \
-o table실제로 자주 나오는 급증 패턴 4가지
조사를 몇 번 해보면 원인이 몇 가지로 수렴한다는 걸 알게 됩니다. 아래 네 가지가 대부분을 차지합니다. 그래프 모양과 함께 보시면 1차 단계에서 바로 짚을 수 있습니다.
패턴 A — 진단 설정을 켜둔 채 잊음 (계단식)
장애 조사한다고 AKS나 Application Gateway의 진단 설정에서 로그 카테고리를 전부 체크하고 Log Analytics로 보냅니다. 조사가 끝나도 설정은 남습니다. Log Analytics는 수집량 기준 과금이라 그대로 요금이 됩니다. 특히 컨테이너 stdout 로그는 양이 폭발적입니다.
확인은 워크스페이스에서 어떤 테이블이 용량을 먹는지 보면 됩니다.
// Log Analytics 워크스페이스에서 실행
Usage
| where TimeGenerated > ago(30d)
| summarize GB = sum(Quantity) / 1000 by DataType
| sort by GB desc
| take 10상위 테이블이 ContainerLogV2나 AzureDiagnostics면 확정입니다. 필요 없는 카테고리를 끄거나, 보존 기간을 줄이거나, 기본 로그(Basic Logs) 티어로 내리는 선택지가 있습니다.
패턴 B — 자동 종료가 풀린 개발 환경 (계단식)
개발 VM의 자동 종료를 누군가 임시로 껐다가 되돌리지 않은 경우입니다. 하루 10시간 켜지던 VM이 24시간 켜지면 비용이 2.4배가 됩니다. 리소스 그룹 단계에서 rg-dev-*가 튀어나오면 이걸 먼저 보세요.
패턴 C — 리전 간 트래픽을 만드는 배포 (계단식)
새 리소스를 다른 리전에 배포했는데 데이터베이스는 기존 리전에 있는 경우입니다. 애플리케이션이 매 요청마다 리전을 넘나들며 송신 트래픽 요금을 발생시킵니다. Meter에 Data Transfer Out이 뜨면 이걸 의심하세요. VM 크기를 줄여도 안 잡히는 유형입니다.
패턴 D — 파이프라인이 리소스를 중복 생성 (계단식·급격)
Terraform이나 Bicep 배포가 실패했는데 정리가 안 돼서, 재실행할 때마다 리소스가 새로 쌓이는 경우입니다. 활동 로그의 caller가 서비스 주체로 나오면 여기입니다. AKS 노드 풀이 중복 생성되면 하루 만에도 금액이 크게 뜁니다.
다음 달에 또 당하지 않으려면
원인을 찾았다면 이제 같은 일을 청구서가 아니라 알림으로 먼저 알게 만들어야 합니다. 최소 두 가지는 걸어두시길 권합니다.
첫째, 예산 알림. 실제 비용이 아니라 예측 비용에도 알림을 거는 것이 핵심입니다. 실제 비용 기준으로만 걸면 이미 다 쓴 뒤에 알림이 옵니다.
az consumption budget create \
--budget-name "monthly-guard" \
--amount 3000 \
--time-grain Monthly \
--category Cost \
--start-date 2026-08-01 \
--end-date 2027-08-01포털의 비용 관리 → 예산에서 알림 조건을 추가할 때, 실제 80%와 함께 예측 100%를 반드시 넣으세요. 예측 알림은 월 중반에 “이 속도면 예산을 넘는다”고 미리 알려줍니다.
둘째, 태그 강제. 리소스에 소유자·환경 태그가 없으면 3차 단계에서 “이게 누구 건지” 알 수 없습니다. Azure Policy로 태그 없는 리소스 생성을 막아두면 다음 조사부터 훨씬 빨라집니다. 구체적인 설정은 태그와 Policy로 거버넌스 잡기에 정리해두었습니다.
30분 안에 끝내는 순서
- 일별·3개월 그래프로 급증 시작일과 모양(계단/뾰족/우상향) 확인
- 그룹화 Service name → 어떤 서비스인지
- 그룹화 Resource group → 어느 팀·환경인지
- 그룹화 Resource → Meter → 리소스 안의 어떤 항목인지
- 안 잡히면 미연결 디스크·유휴 공용 IP·미할당해제 VM·스냅샷 확인
- 예측 기준 예산 알림을 걸어 재발 방지
축을 바꾸는 순서가 전부입니다. 넓은 축에서 좁은 축으로 내려가면 리소스를 하나씩 뒤질 일이 없습니다. 이어서 신규 구독 첫 주 점검 5가지와 Reserved·Savings Plan·Spot 선택 기준을 보시면, 사후 조사에서 사전 통제로 넘어가는 그림이 맞춰집니다.