🔥 CloudWatch란 무엇인가: AWS 모니터링의 중심 도구

CloudWatch 콘솔을 처음 열었을 때 사이드바가 Metrics와 Logs를 따로 보여 줬다. 같은 서비스 안에서 왜 Alarms가 또 별도 메뉴를 차지하는지 따라가 보니 다루는 데이터의 형태가 달랐다. 숫자, 텍스트, 임계값 판정, 상태 변화. CloudWatch는 형태가 다른 네 가지를 한 이름 아래에 같이 둔다.

VPC 설계 패턴: 3-tier, Hub-and-Spoke, 그 외의 마지막 줄에서, 부품을 다 그어 놓은 다음 그 부품이 지금 어디에 있는지를 보는 단계로 넘어가겠다고 적어 두었다. 그 단계가 CloudWatch다. 한 가지를 미리 짚고 시작하면, CloudWatch는 자동 수집 범위와 직접 설정해야 하는 범위 사이의 분기점이다. 네 축에 닿는 데이터는 콘솔 한 화면에서 보이고, 닿지 않는 데이터는 보이지 않는다.

네 축: Metric, Log, Alarm, Event

네 가지를 한 줄씩 보면 형태가 다르다.

Metric은 시간순으로 찍히는 숫자다. CPU 사용률, 네트워크 처리량, 요청 수처럼 한 시점에 한 숫자가 찍히고, AWS는 그 숫자를 namespace(예: AWS/EC2)와 dimension(예: InstanceId=i-0abc…) 한 묶음으로 묶는다. AWS 서비스가 푸시하는 기본 메트릭은 무료지만 간격은 서비스마다 다르다. EC2는 인스턴스 메트릭(CPU, 네트워크, 디스크)을 5분 간격으로 기본 제공하고 status check만 따로 1분 간격이며, detailed monitoring을 켜면 인스턴스 메트릭도 1분 간격으로 보낸다. Lambda나 ELB처럼 처음부터 1분 단위로 찍는 서비스도 있다. 사용자가 직접 쓴 커스텀 메트릭은 메트릭 1개당 월 $0.30이다(첫 1만 개 기준).

Log는 텍스트다. JSON이든 평문이든, AWS는 한 줄 한 줄을 timestamp와 함께 log group 아래의 log stream에 기록한다. 메트릭과 다른 점은 형태가 자유롭다는 것. 그래서 검색, 필터, 집계를 쿼리(Logs Insights)로 따로 처리한다. 같은 데이터가 메트릭에 찍히기도 하고 로그에 기록되기도 하는 게 아니라, 형태 자체가 다르다.

Alarm은 메트릭 위에 얹는 규칙이다. 어떤 메트릭이 어떤 임계값을 어떤 기간 동안 넘으면, 그 순간 상태가 OK에서 ALARM으로 넘어간다. 상태는 셋이다. OK, ALARM, INSUFFICIENT_DATA. 마지막 상태가 가장 자주 사람을 헷갈리게 한다. 데이터가 충분하지 않아 판단을 미뤘다는 뜻인데, period가 메트릭 푸시 간격보다 짧으면 평가할 데이터 포인트가 없어 그 상태에 머문다. evaluation period와 datapoints to alarm 두 단위를 따로 둔 이유는 뒤에서 다시 짚는다.

Event는 상태 변화다. EC2 인스턴스가 시작하는 순간, S3가 객체를 새로 받는 순간, Auto Scaling이 인스턴스를 줄이는 순간 같은 이벤트 한 줄. 처음에는 "CloudWatch Events"라는 이름으로 CloudWatch 안에 있다가, 2019년 7월 Amazon EventBridge로 분리되어 나갔다. API는 그대로 유지되었고, 그래서 CloudWatch Events에서 EventBridge로의 전환 안내(AWS 공식)가 별도 글로 남아 있다. 즉 지금 CloudWatch 콘솔에는 Events 메뉴가 없다. EventBridge라는 형제 서비스가 그 역할을 가져갔다.

네 축을 잇는 두 줄이 알람과 이벤트다. 알람은 메트릭이 임계값을 넘는 순간 상태가 변하는데, 그 상태 변화 자체를 EventBridge가 받는다. 그 다음에 SNS 알림을 보내든 Lambda를 깨우든, 그건 EventBridge가 받은 후의 이야기다. CloudWatch는 네 축을 다 안고 있되, 한 축(이벤트)은 형제 서비스가 들고 있는 구조다.

데이터가 들어오는 길: 다른 서비스가 CW로 보낸다

이 지점에서 허브라는 단어가 들어맞는다. CloudWatch에 데이터를 넣는 주체는 사용자가 아니다. 다른 AWS 서비스가 자기 동작 통계를 기본으로 CloudWatch에 푸시한다.

EC2: 가상 서버는 5분마다 CPU, 네트워크, 디스크 메트릭을 찍는다. Lambda는 invocation 수, duration, error rate를 함수마다 찍는다. RDS는 DB 연결 수, 스토리지 사용량, 리플리카 지연을 찍는다. VPC Flow Logs를 켜면 Subnet: Public과 Private의 첫 갈림 단위로 패킷의 출발지, 목적지, 허용·거부를 텍스트 로그로 보낸다. 사용자가 한 일은 콘솔에서 토글 한 번이거나, 아예 그것조차 없는 경우(EC2 기본 메트릭은 항상 켜져 있다)도 많다.

이 fan-in 구조가 두 가지를 의미한다. 첫째, AWS 안에서 무언가를 켜기만 하면 기본 모니터링이 자동으로 따라온다. 둘째, 그래서 청구서도 자동으로 따라온다. 어느 항목이 무료이고 어느 항목부터 돈이 붙는지를 모르고 켜 두면 다음 달에 알게 된다.

'관리형'이 감추는 비용

CloudWatch 가격 페이지를 내가 처음 열어 봤을 때 무료 한도 줄이 길게 나열돼 있었다. 매월 커스텀 메트릭과 detailed monitoring 메트릭을 합산한 10개, 로그 5GB(ingestion, archive storage, Logs Insights 스캔 합산), 표준 해상도 알람 10개, 사용자 대시보드 3개, API 요청 100만 건. 작은 사이드 프로젝트는 무료 한도 안에서 거의 끝난다.

문제는 기본을 넘어서기 시작할 때부터다. 비용이 자주 새는 항목 셋을 짚어 둔다.

첫째, dimension 폭발. 커스텀 메트릭은 namespace, 메트릭 이름, dimension 값의 조합 하나를 메트릭 한 개로 친다. request_count 메트릭에 endpoint, status_code, region, customer_id 네 개의 dimension을 붙이고, 고객이 1,000명이고 엔드포인트가 50개고 상태 코드가 5개고 지역이 5개라면, AWS가 만드는 메트릭은 1,000 × 50 × 5 × 5 = 1,250,000개다. 무료 한도 10개에서 시작했는데 한 번의 부주의로 백만 단위가 된다. 첫 1만 개까지는 메트릭당 $0.30이고 그 위로는 단가가 낮지만, 곱셈은 단가 인하를 쉽게 앞지른다.

둘째, Logs ingestion. US East(N. Virginia) 기준 CloudWatch Logs ingestion이 GB당 $0.50. 서울 리전(ap-northeast-2)은 region별 가격이 공식 페이지에 명시되지 않고 pricing calculator로 따로 계산해야 한다. 일반적으로 N. Virginia보다 다소 비싼 경향이 있어서, 서울 리전에서 운영하는 시스템은 같은 GB 수에 청구서가 조금 더 무겁게 나온다. 평소 GB 단위로 적던 Lambda 로그가 트래픽 급증 한 번에 100GB가 들어오면 그 한 달 청구서에 50달러 줄이 새로 생긴다.

셋째, Logs Insights 쿼리. Logs를 검색하고 집계하는 SQL 비슷한 쿼리는 스캔한 데이터 GB로 과금한다. 한 번의 디버깅 세션에서 3개월치 로그를 풀스캔하면 그 자체로 청구서가 한 줄 더 늘어난다.

무료 한도만 보고 켜 두면 '관리형'이라는 말이 친절해 보이지만, AWS는 사용자의 의도가 아니라 데이터의 형태를 따라 청구한다. 그 형태를 미리 그려 두지 않으면 비용은 사용자보다 빨리 자란다.

자동 수집의 범위: 어디까지 CloudWatch가 맡나

CloudWatch가 맡는 범위는 분명하다. AWS 서비스의 기본 통계, 그 통계 위에 거는 임계값 알람, 알람을 이벤트로 보내 자동 대응을 거는 일. 작은 시스템 한 묶음을 한 화면에서 같이 확인할 때 가장 강하다.

CloudWatch만으로 안 되는 영역도 분명하다.

분산 트레이스의 깊이가 첫 번째다. 한 요청이 여러 서비스(API Gateway → Lambda → DynamoDB → 다른 Lambda → SQS)를 거칠 때, 어느 구간에서 몇 ms가 새는지 보는 일은 메트릭과 로그만으로 설명되지 않는다. 그 영역은 AWS X-Ray 또는 OpenTelemetry가 맡는다. 다만 X-Ray는 2026년 2월 25일부터 SDK·Daemon이 maintenance mode에 들어가고 2027년 2월 25일에 end-of-support다. AWS가 권하는 길은 AWS Distro for OpenTelemetry(ADOT)와 CloudWatch의 신기능(Application Signals, Transaction Search)을 함께 쓰는 쪽이다. 즉 분산 트레이스는 X-Ray에서 OpenTelemetry로 옮겨가는 중이다.

APM의 깊이가 두 번째다. 메서드 단위 프로파일링, 코드 라인 단위 latency, 사용자 세션 replay 같은 일은 CloudWatch가 잘 못한다. Datadog, New Relic, Dynatrace 같은 별도 도구가 맡는다.

풀텍스트 검색이 세 번째다. 로그를 문서처럼 다루며 빠르게 검색하고 집계하는 일은 OpenSearch 또는 Elasticsearch 쪽이 더 잘한다. Logs Insights도 텍스트 검색을 하긴 하지만, 한 번에 수억 줄을 풀스캔하면 비용도 시간도 자기 도구가 아니다.

CloudWatch를 모든 모니터링의 끝으로 두는 순간 청구서는 빠르게 자라고, 답이 안 나오는 질문 앞에서 나는 진도를 못 뺀다. 기본 모니터링이 자동으로 깔리는 영역에 두고, 그 너머는 다른 도구가 맡는다고 인정하는 한 줄. 이 한 줄을 네 축을 켜기 전에 미리 정해 둬야 한다.

네 축은 한 화면에서 보고, 그 밖의 작업은 다른 도구로 넘긴다

네 축(metric, log, alarm, event)이 한 서비스 아래에 있고, 한 축(event)은 EventBridge라는 형제 이름으로 분리되어 있다. AWS 서비스들이 기본으로 CloudWatch에 데이터를 푸시하고, 무료 한도가 작은 시스템을 거의 다 받쳐 준다. 그 너머는 데이터의 형태에 따라 청구서가 자란다. 분산 트레이스, APM, 풀텍스트 검색은 자기 도구가 따로 있다.

CloudWatch를 AWS의 기본 모니터링 도구로 두고, 모든 모니터링의 끝으로 두지 않는다는 한 줄. 이 한 줄을 정해 두면 청구서도 다음에 들여올 도구도 자연스럽게 따라온다.

참고 자료

• Amazon CloudWatch User Guide: 네 축의 공식 정의와 콘솔 사용법
• Alarm evaluation (CloudWatch User Guide): period, evaluation period, M-out-of-N의 정확한 동작
• EventBridge is the evolution of CloudWatch Events: 2019년 분리 배경과 호환성
• Amazon CloudWatch Pricing: 무료 한도와 region별 안내
• Announcing AWS X-Ray SDKs/Daemon End-of-Support and OpenTelemetry Migration: 2026-02-25 maintenance, 2027-02-25 EOL
• AWS Distro for OpenTelemetry: AWS가 권하는 OpenTelemetry 배포판