CloudWatch 메트릭·알람 요금: 로그 다음으로 새는 곳
CloudWatch 요금의 본체가 Logs 수집이라는 것은 앞 편에서 다뤘습니다. 그런데 Logs를 잡고 나면 두 번째 항목이 보이기 시작합니다. 결론을 먼저 적으면, 커스텀 메트릭은 개당 월 약 $0.30이라 “메트릭 하나"는 싸지만, 디멘션 조합마다 별도 메트릭으로 세어지기 때문에 코드 한 줄이 수천 개의 메트릭을 만들 수 있고, 여기에 알람·대시보드·조회 API가 얹혀 Logs 없이도 월 수백 달러가 나올 수 있습니다. AWS 기본 메트릭은 무료이므로, 점검 대상은 직접 넣는 커스텀 메트릭과 그것을 읽는 쪽입니다. 요금은 us-east-1 기준입니다.
한눈에 보는 요금 구조 #
| 항목 | 단가 | 비고 |
|---|---|---|
| 기본 메트릭 (AWS 서비스 제공) | 무료 | EC2 CPU, ALB 요청 수 등 |
| 커스텀 메트릭 | 개당 월 약 $0.30 (첫 1만 개 구간) | 볼륨 구간별 인하, 디멘션 조합마다 1개 |
| 상세 모니터링 (EC2 1분 단위) | 인스턴스당 메트릭 묶음 과금 | 대수가 많으면 합산 주의 |
| 표준 알람 | 개당 월 약 $0.10 | 고해상도 약 $0.30, 복합 약 $0.50 |
| 대시보드 | 3개 초과분 개당 월 약 $3 | |
| API 호출 | GetMetricData 등 1,000건당 약 $0.01 | 무료 티어 제외 대상 |
커스텀 메트릭: 개수를 만드는 것은 디멘션입니다 #
과금 단위는 메트릭 이름이 아니라 이름 × 디멘션 조합입니다. request_latency라는 메트릭 하나에 엔드포인트 50개 × 상태 코드 5개를 디멘션으로 붙이면 250개 메트릭이고, 월 약 $75입니다. 여기에 인스턴스 ID나 고객 ID처럼 카디널리티가 높은 값을 디멘션으로 넣는 순간 개수가 폭발합니다. 고객 1만 명을 디멘션으로 넣은 메트릭 하나가 월 약 $3,000이 되는 구조라, 이 항목의 사고는 대부분 “무심코 넣은 디멘션 하나"에서 나옵니다.
줄이는 방향은 두 가지입니다. 첫째, 디멘션 설계 원칙을 세웁니다. 알람과 대시보드에서 실제로 갈라 보는 축만 디멘션으로 남기고, 개별 식별자(인스턴스·요청·고객)는 디멘션이 아니라 로그의 일입니다. 둘째, 임베디드 메트릭 포맷(EMF)을 검토합니다. 로그로 구조화 데이터를 보내고 그중 메트릭으로 승격할 값만 지정하는 방식이라, 상세 데이터는 로그 요금으로(스캔할 때만 조회 비용), 집계 축만 메트릭 요금으로 나뉩니다. 고카디널리티 분석이 필요한 데이터의 정석 경로입니다.
EC2 상세 모니터링(1분 단위)도 같은 계열의 조용한 항목입니다. 인스턴스당 메트릭 묶음에 과금되므로, 수백 대 규모에서 전체 켜 두면 눈에 띄는 금액이 됩니다. 1분 해상도가 실제로 필요한 그룹(오토스케일링 판단 대상 등)에만 켜는 것이 기본입니다.
알람·대시보드: 단가는 작지만 곱셈이 됩니다 #
표준 알람은 개당 월 약 $0.10이라 알람 100개도 $10입니다. 문제는 패턴입니다. 인프라를 코드로 관리하며 “인스턴스마다 알람 4종"을 자동 생성하는 구성은 인스턴스 수에 비례해 알람이 늘고, 지워지지 않은 채 남습니다. 고해상도 알람(약 $0.30)과 복합 알람(약 $0.50)은 단가가 다르므로, 복합 알람으로 묶어 표준 알람 수를 줄이는 것이 정리 방향이 되기도 합니다. 대시보드는 3개까지 무료, 초과분은 개당 월 약 $3입니다. 실험하다 남긴 대시보드가 수십 개 쌓이는 것이 전형적인 잔재입니다.
이 항목들의 점검은 기술이 아니라 목록 관리입니다. 상시 점검 목록에 “울리지 않는 알람, 보지 않는 대시보드” 항목을 넣어 두고 분기마다 지우는 것으로 충분합니다.
조회 API: 서드파티 도구가 만드는 요금 #
놓치기 쉬운 항목이 메트릭을 읽는 쪽입니다. GetMetricData는 무료 티어에서 제외되는 항시 과금 API로, 1,000건당 약 $0.01입니다. 사람이 콘솔에서 보는 수준으로는 무시할 금액이지만, 서드파티 관측 도구(Datadog, Grafana 등)가 계정 전체 메트릭을 몇 분 간격으로 긁어 가는 구성에서는 이 항목이 월 수백 달러 단위로 자랍니다. 메트릭 수 × 폴링 주기가 곱해지는 구조이기 때문입니다.
서드파티 연동이 있다면 두 가지를 확인합니다. 폴링 대상을 네임스페이스 단위로 필터링해 실제로 쓰는 메트릭만 가져가게 하는 것, 그리고 도구가 메트릭 스트림(CloudWatch Metric Streams, Firehose 경유 푸시 방식) 연동을 지원하면 폴링 대신 스트림으로 바꾸는 것입니다. 스트림은 폴링형 API 요금 대신 스트림 단가로 과금되어 대량 연동에서 대체로 쌉니다.
점검 순서 #
- 청구서에서 CloudWatch 항목을 분해합니다: 사용 유형에서 MetricMonitorUsage(커스텀 메트릭), CW:GMD-Metrics(GetMetricData), AlarmMonitorUsage를 나눠 보면 어느 축이 큰지 바로 보입니다.
- 커스텀 메트릭 목록에서 디멘션 폭발을 찾습니다: 메트릭 수가 예상보다 크면 범인은 거의 항상 고카디널리티 디멘션입니다. 해당 축을 로그·EMF로 내립니다.
- 울리지 않는 알람과 안 보는 대시보드를 지웁니다: 분기 단위 목록 정리로 충분한 항목입니다.
- 서드파티 폴링을 필터링하거나 스트림으로 바꿉니다: GetMetricData가 큰 계정은 대부분 여기가 원인입니다.
- 상세 모니터링 적용 범위를 좁힙니다: 1분 해상도가 필요한 그룹만 남깁니다.
정리 #
- 커스텀 메트릭 과금 단위는 이름 × 디멘션 조합입니다. 고카디널리티 디멘션 하나가 월 수천 달러를 만들 수 있습니다.
- 개별 식별자는 메트릭이 아니라 로그의 일입니다. EMF로 로그와 메트릭의 역할을 나누는 것이 고카디널리티 데이터의 정석입니다.
- 알람(약 $0.10)·대시보드(3개 초과 약 $3)는 단가가 아니라 방치된 개수가 문제입니다. 분기 정리 목록에 넣습니다.
- GetMetricData는 항시 과금이고, 서드파티 도구의 전체 폴링이 이 항목을 키웁니다. 필터링 또는 메트릭 스트림 전환이 대책입니다.
- AWS 기본 메트릭은 무료이므로, 점검은 직접 넣는 것(커스텀·상세 모니터링)과 읽어 가는 것(API·도구)에 집중합니다.