CloudWatch, 비용이 늘어나는 5가지 패턴

CloudWatch는 눈에 보이지 않는 영역에서 비용이 빠르게 누적될 수 있는 구조를 갖고 있습니다. 특히 실무 환경에서는 무심코 켜놓은 로그 수집, 디버깅용 고해상도 지표, 불필요한 알람, 오래된 로그 등으로 인해 매달 수십~수백 달러의 불필요한 요금이 발생하는 경우가 흔합니다.

이 글에서는 CloudWatch에서 가장 자주 발생하는 6가지 비용 증가 요인을 살펴보고, 각 항목별 실무 대응 전략을 함께 소개합니다. 비용은 ‘기능을 얼마나 썼냐’보다, ‘어떻게 설계했냐’에 따라 크게 달라집니다.

로그 수집 과다: 무심코 켜두면 폭증하는 로그 요금

CloudWatch 비용이 갑자기 급증하는 가장 흔한 원인 중 하나는 과도한 로그 수집 설정입니다. 특히 VPC Flow Logs, AWS Lambda 로그, ECS/ALB 로그, Custom 애플리케이션 로그 등은 초기 설정만 해두고 관리하지 않으면 GB 단위 로그가 시간당 생성되며, 저장 비용뿐 아니라 처리 비용까지 중복 과금될 수 있습니다.

로그 수집으로 인해 비용이 증가하는 주요 시나리오 몇가지를 살펴보겠습니다.

VPC Flow Logs를 전체 서브넷에 “All Traffic” + “Both Direction”으로 설정한 경우입니다. VPC Flow Logs는 VPC 내에서 발생하는 모든 트래픽의 로그를 수집합니다. 초당 수백 건의 네트워크 흐름 로그가 생성될 수 있고, 시간당 수 GB 이상의 로그가 발생할 수 있습니다. VPC Flow Logs는 APN2-DataProcessing-Bytes, APN2-VendedLog-Bytes, APN2-TimedStorage-ByteHrs 항목으로 중복 비용을 유발할 수 있습니다. 이는 VPC Flow Logs 수집 자체 비용 발생과 더불어 클라우드와치의 수집, 처리 및 저장 비용이 동시에 발생하기 때문입니다.

Lambda 함수의 로그가 과도하게 남는 경우에도 주의해야 합니다. 오류가 반복되거나 디버그 로그가 계속 출력될 경우, 함수 호출보다 로그 요금이 더 높게 나올 수 있습니다. 특히 단기 트래픽 급증 시 로그 볼륨이 예상 이상으로 폭증할 수 있습니다.

마찬가지로 Application Log를 무차별적으로 CloudWatch Logs로 전송하고 있는지도 주의깊게 확인해야 합니다. 특히 JSON 전체나 디버깅 메시지, Stack trace 전체 등을 실시간 전송하는 경우 확인이 필요합니다. 필요 이상의 verbose logging이 쌓이면 저장 및 처리 요금이 급증할 수 있습니다.

로그 그룹의 Retention(보관기간) 설정이 ‘무제한’으로 유지했다면 적절한 보관기간 설정이 필요합니다. 과거 로그가 계속 쌓여 ByteHrs 저장 비용이 누적됩니다. 수 GB가 쌓여서 수 TB 단위로 변할 수 있으며, 오래된 로그일수록 활용도가 낮으므로 주기적인 관리가 필요합니다.

다수의 마이크로서비스에서 유사 로그를 중복 수집하는 경우 같은 요청 로그가 여러 로그 그룹에 중복 기록될 수 있습니다. 서비스 간 흐름을 파악하기 위한 의미로 유의미할 수 있으나 불필요하게 과다 수집하는 것은 지양해야 합니다. 공통 요청 ID(Trace ID) 기준으로 추적해 서비스 간 요청 흐름만 파악하고, 로그는 한 그룹만 상세하게 기록합니다. CloudWatch Metric Filter/Subscription Filter를 최소화하여 필터링 단계에서 필요한 로그만 추출하는 것이 좋습니다.

로그 분류를 세분화하지 않고 하나의 로그 그룹에 전부 몰아넣는 경우에도 비용이 증가할 수 있습니다. CloudWatch Logs는 단순히 로그를 저장하는 역할을 넘어서 수집 → 처리(파싱, 색인화) → 저장 → 검색 및 분석 → 보관 → 수명주기 관리까지 담당합니다. 로그를 수집하면 내부적으로 색인화 및 포맷 정규화 작업을 수행하는데 서로 다른 형식의 로그가 섞여 있으면 색인 및 처리량이 늘어나 DataProcessing-Bytes 과금이 크게 증가합니다.

또한 쿼리를 사용할 때도 로그 그룹 내 데이터량이 많고, 서로 다른 유형의 로그가 혼재하면 필요한 로그만 필터링하려고 복잡한 조건식을 추가해야 하며 이는 스캔 데이터량(DataScanned-Bytes)이 불필요하게 증가시킬 수 있습니다.

고해상도 지표 과도 사용

CloudWatch Metrics는 기본적으로 1분 단위(Standard)로 제공되며, 대부분의 AWS 서비스는 이를 무료 범위 내에서 수집할 수 있습니다. 하지만 사용자가 직접 고해상도(High-Resolution) 지표를 설정하면 1초 단위로 지표가 수집되고, 이로 인해 예상치 못한 비용 증가가 발생할 수 있습니다.

비용이 증가하는 주요 시나리오

초 단위 사용자 정의 지표의 과도한 전송

여러 인스턴스에서 1초 단위로 사용자 정의 지표(Custom Metric)를 동시에 전송할 경우 비용이 급격히 증가할 수 있습니다. 예를 들어, PutMetricData API를 사용하여 애플리케이션 상태, 사용자 수, 응답 시간 등을 실시간으로 수집할 때, 단 하나의 지표만 1초 단위로 전송해도 하루에 86,400개, 한 달이면 약 260만 개의 데이터 포인트가 발생합니다. 이렇게 많은 데이터 포인트를 전송하면 CloudWatch 요금이 크게 늘어납니다.

고해상도 지표와 CloudWatch Alarms의 과도한 연동

고해상도 지표를 CloudWatch Alarms와 과도하게 연동하는 것도 비용 증가의 원인이 됩니다. 알람의 평가 주기가 짧아질수록 지표 모니터링 비용뿐만 아니라 알람 평가 비용도 함께 증가합니다. 즉, 짧은 주기로 자주 지표를 확인하고 알람을 평가하게 되면 그만큼 더 많은 비용이 발생하게 됩니다.

필요 이상의 고해상도 지표 설정

필요 이상의 지표를 고해상도(1초 단위)로 설정하는 경우에도 비용이 증가합니다. 예를 들어, CPU, 메모리, 디스크 사용량과 같은 기본적인 지표 외에도 트랜잭션 수, API 호출 수, 내부 큐 상태 등 다양한 사용자 정의 지표를 모두 1초 단위로 설정하면 불필요한 비용이 발생할 수 있습니다. 모든 지표가 1초 단위의 정밀도를 요구하는 것은 아니므로, 모니터링 목적에 맞는 적절한 해상도를 설정하는 것이 중요합니다.

임시 진단용 지표의 지속적인 유지

디버깅이나 임시 진단 목적으로 설정한 고해상도 지표를 사용 후 해제하지 않고 계속 유지하는 것은 '요금 폭탄'의 원인이 될 수 있습니다. 몇 주간 이러한 지표를 그대로 운영하게 되면 예상치 못한 높은 요금이 부과될 수 있으므로, 진단이 완료되면 관련 지표 설정을 반드시 해제하거나 해상도를 조정해야 합니다.

1초 vs 1분 vs 5분 : 얼마나 차이 날까?

1초 해상도 지표는 1개 지표만 수집해도 한 달에 약 260만 개 데이터 포인트를 생성합니다. 1분 해상도 지표는 같은 조건에서 월 4만 3천 개 수준입니다. 데이터 포인트 수(data points)는 조회·모니터링 등 후속 활동 시 비용을 증가시킬 수 있는 간접 요인이 됩니다.

이 많은 데이터 포인트를 시각화하는 경우, 또는 Alarm이 더 자주 조건을 평가해야 하는 경우 비용이 늘어납니다. 또한, Grafana와 같은 외부 도구에서 GetMetricData API 호출을 자주 하게 되면, 해당 API 호출에 대한 과금이 급증하여 전체 GMD-Metrics/API 호출 비용이 크게 늘어날 수 있습니다. 결국, 데이터 포인트가 많아질수록 이를 처리하고 조회하는 데 드는 비용이 전반적으로 증가하게 됩니다.

알람 과다 설정 및 불필요한 리전 중복

알람 과다 설정

CloudWatch Alarm은 모든 설정된 지표에 대해 정해진 주기로 조건을 평가합니다. 알람 하나당 월 $0.10~$0.30(표준/고해상도 기준)의 비용이 발생하며, 수십~수백 개를 설정해두면 누적 비용이 상당합니다.

동일한 지표에 대해 여러 개의 알람을 설정한 경우에 개별 비용이 발생합니다. 예로 CPUUtilization에 대해 Warning, Alert, Critical로 3중 알람 구성하는 경우입니다. 또한 Auto Scaling용 알람이 과도하게 중복되어 있을 경우, 지표 하나에 대해 각 인스턴스, 리전, AZ 단위로 알람을 생성한 경우에도 비용 증가의 요인이 됩니다.

불필요한 리전 중복

AWS CloudWatch는 리전 단위로 운영되며, 서로 다른 리전에서 동일한 로그/지표를 수집하거나 알람을 구성할 경우 중복 과금이 발생할 수 있습니다. 멀티 리전 운영 시 동일 지표를 여러 리전에서 수집하게 됩니다. 같은 분석 목적의 로그가 여러 리전에 저장된 CloudWatch Logs 그룹에 중복 기록될 수 있습니다. 대시보드/알람이 모든 리전에서 별도로 구성된 경우에도 마찬가지로 중복 비용이 발생합니다.

오래된 로그 장기 보관

CloudWatch Logs는 수집된 로그를 저장하는 데 비용이 발생하며, 저장 기간이 길어질수록 누적 비용은 점차 증가합니다. 특히 오랫동안 운영된 시스템의 경우, 사용하지 않는 과거 로그가 수년 단위로 쌓여 상당한 비용 부담으로 이어질 수 있는데, 이는 로그를 비용 관점에서 제대로 관리하지 않고 방치했을 때 흔히 발생하는 문제입니다.

몇 가지 대표적인 예시를 살펴보면 다음과 같습니다.

기본 설정으로 인한 무제한 저장: 많은 경우 로그 그룹이 기본 설정(무제한 보관)으로 되어 있어 로그가 자동으로 영구 저장되는 상황이 발생합니다.

지속적으로 발생하는 로그 방치: Lambda, ECS, VPC Flow Logs, API Gateway 로그와 같이 꾸준히 생성되는 로그들을 별다른 관리 없이 방치할 경우 저장 공간이 계속 늘어납니다.

오래된 테스트/디버깅 로그 유지: 기능 테스트나 디버깅 목적으로 생성된 로그가 수년 동안 삭제되지 않고 유지되는 사례도 많습니다.

종료된 서비스의 로그 그룹 잔존: 특정 서비스는 이미 종료되었는데도 해당 서비스의 로그 그룹이 그대로 남아 계속해서 과금이 발생하는 경우도 있습니다.

CloudWatch Logs의 저장 요금은 ByteHrs 단위로 과금됩니다. 예를 들어, 1GB의 로그를 하루(24시간) 동안 저장하면 24GB-시간(byte-hours)으로 계산되며, 이를 월간 요금으로 환산합니다. 일반 저장 기준으로 월 약 $0.03~$0.06/GB (리전별 상이)의 요금이 부과되는데, 이 금액이 작아 보일 수 있지만 수백 GB 단위의 로그가 장기간 보관될 경우 매달 수십에서 수백 달러까지 늘어날 수 있다는 점을 명심해야 합니다.

지표 통합 없이 서비스별 무차별 수집

CloudWatch Metrics는 기본 제공되는 지표 외에도 사용자 정의 지표(Custom Metrics)나 고해상도 지표(High-Resolution Metrics)에 대해 추가 요금을 부과합니다. 이 과정에서 가장 흔히 발생하는 실수는 서비스나 모듈 단위로 지표를 너무 세분화하여 무분별하게 생성하는 것입니다.

예를 들어 다음과 같은 경우에 비용이 증가할 수 있습니다.

동일한 성격의 지표를 서비스별로 분리 생성: 처리량이나 응답 시간과 같은 동일한 지표 성격을 api.serviceA.latency, api.serviceB.latency처럼 각 서비스별로 따로 생성하는 경우가 있습니다.

태그 없이 인스턴스/환경별 지표 생성: 태그를 사용하여 그룹화하지 않고 각 인스턴스, 리전, 또는 개발/스테이징/운영(dev/staging/prod) 환경별로 별도의 지표를 생성하는 경우입니다.

분산된 고빈도 지표 생성: Grafana, Prometheus, 또는 애플리케이션 내부 코드 등에서 매 초마다 수십, 수백 개의 지표를 분산적으로 생성하는 상황도 있습니다.

이러한 방식은 지표를 통합 관리하기 어렵게 만들 뿐만 아니라, 지표 수가 수천 개 단위로 누적되면서 월간 고정 비용이 급증하는 원인이 됩니다. 구체적으로, 사용자 정의 지표는 10개 단위당 월 $0.30가 과금될 수 있으며, 고해상도 지표는 개당 월 $0.30와 더불어 데이터 포인트당 별도 요금까지 부과될 수 있습니다. 또한, 지표 개수가 많아질수록 해당 지표에 연결된 알람(Alarm) 및 대시보드 비용까지 연쇄적으로 증가하게 됩니다.

결론

CloudWatch는 ‘보안’과 ‘관측’의 필수 도구지만, 관리하지 않으면 곧 비용 덩어리가 될 수 있습니다. 이 글에서 소개한 5가지 패턴은 모두 아래와 같은 특징을 가집니다.

초기 설정 이후 ‘방치’되어 유지됨

알람/로그/지표의 기본값이 그대로 유지됨

단기 대응 목적이 장기 운영으로 이어짐

수요보다 공급(모니터링 리소스)이 더 많음

CloudWatch의 진짜 절감 전략은 “기능을 끄는 것”이 아니라, 목적에 맞게 구조를 단순화하고, 유지 가능한 수준으로 통제하는 것입니다.

지표는 통합하고, 알람은 정비하며, 로그는 선별적으로 보관하는 것만으로도 비용은 절반 이하로 줄고, 관측 체계는 더 명확해질 수 있습니다.