Amazon CloudWatch 지표 알람 로그 차이와 EC2 CPU 알람 설정하는 순서

서버를 운영하다 보면 "지금 서비스가 정상인가"라는 질문을 하루에도 몇 번씩 하게 됩니다. AWS에서 이 질문에 숫자로 답하는 기본 도구가 Amazon CloudWatch입니다. EC2 인스턴스를 하나만 만들어도 CPU 사용률 같은 지표가 자동으로 쌓이기 시작하지만, 어떤 값이 기본으로 수집되고 어떤 값은 따로 설정해야 하는지 모르면 정작 필요할 때 데이터가 없는 상황을 겪게 됩니다.

 

CloudWatch는 기능이 많아 보이지만 핵심은 지표, 알람, 로그 세 가지입니다. 지표는 시간에 따라 기록되는 숫자이고, 알람은 그 숫자를 기준값과 비교해 상태를 바꾸는 규칙이며, 로그는 애플리케이션과 서비스가 남긴 텍스트 기록입니다.

 

이 글에서는 세 구성 요소의 차이, EC2에서 기본으로 제공되는 지표와 에이전트가 필요한 지표, 지표 보존 기간, 알람이 울리는 조건을 정하는 방법, 그리고 EC2 CPU 알람을 실제로 설정하는 순서를 정리합니다.

 

결론부터 말씀드리면 EC2는 기본 모니터링으로 5분 간격 지표를 무료로 보내지만, 메모리와 디스크 사용률은 기본 지표에 없어 CloudWatch 에이전트를 설치해야 합니다. 또 알람은 지표가 기준을 넘는 상태가 지정한 기간 동안 유지될 때만 동작하므로, 기간과 평가 횟수를 어떻게 정하느냐가 알림의 품질을 좌우합니다.

 

 

CloudWatch는 지표, 알람, 로그를 한곳에서 다룹니다

지표(metric)는 시간 순서대로 쌓이는 데이터 포인트의 모음입니다. EC2 인스턴스의 CPU 사용률, EBS 볼륨의 읽기 횟수, 로드 밸런서의 요청 수처럼 AWS 서비스가 자동으로 보내는 지표가 있고, 사용자가 직접 보내는 사용자 지정 지표도 있습니다. 지표는 AWS/EC2 같은 네임스페이스로 구분되고, 인스턴스 ID 같은 차원(dimension)으로 대상을 좁혀 봅니다.

 

지표는 만들어진 리전 안에만 존재하며 직접 삭제할 수 없습니다. 새 데이터가 들어오지 않으면 15개월 뒤 자동으로 만료됩니다. 그래서 서울 리전에서 만든 인스턴스의 지표를 보려면 콘솔 오른쪽 위 리전이 서울로 선택되어 있어야 합니다.

 

구성 요소	하는 일	예시
지표	시간별 숫자 기록	CPUUtilization, NetworkOut
알람	지표 하나를 기준값과 비교해 상태 변경과 작업 실행	CPU 80% 초과 시 메일 알림
로그	텍스트 이벤트를 로그 그룹과 스트림에 저장	웹 서버 접근 로그, Lambda 실행 로그
대시보드	여러 지표와 알람을 한 화면에 배치	서비스별 상태 화면

 

지표는 숫자, 알람은 그 숫자에 대한 규칙, 로그는 텍스트 기록이며, 지표는 리전 단위로 저장되고 15개월이 지나면 만료됩니다.

 

EC2 기본 지표와 에이전트가 필요한 지표

EC2 인스턴스를 만들면 기본 모니터링이 켜진 상태로 CPU 사용률, 네트워크 입출력 같은 지표가 5분 간격으로 무료 수집됩니다. 세부 모니터링을 켜면 1분 간격으로 바뀌는 대신 요금이 추가됩니다. 인스턴스 상태 검사 지표는 기본적으로 1분 간격으로 무료 제공됩니다.

 

많은 분이 놀라는 부분은 메모리 사용률과 디스크 여유 공간이 기본 지표 목록에 없다는 점입니다. 이 값은 운영체제 안에서만 알 수 있기 때문에, 인스턴스에 CloudWatch 에이전트를 설치해 사용자 지정 지표로 보내야 합니다. 에이전트가 지표를 보내려면 인스턴스 역할에 CloudWatchAgentServerPolicy 같은 권한도 필요합니다.

 

지표	기본 제공	간격	비고
CPUUtilization	예	5분(세부 모니터링 1분)	운영체제 도구의 값과 다르게 보일 수 있음
NetworkIn / NetworkOut	예	5분(세부 모니터링 1분)	기간 동안의 바이트 합계
StatusCheckFailed	예	1분	0은 정상, 1은 실패
CPUCreditBalance	T 계열만	5분	버스트 크레딧 잔량 확인
메모리 사용률	아니요	에이전트 설정값	CloudWatch 에이전트 필요
디스크 사용률	아니요	에이전트 설정값	CloudWatch 에이전트 필요

 

DiskReadOps 같은 디스크 지표가 계속 0으로 보여 당황하는 경우도 있습니다. EC2 네임스페이스의 디스크 지표는 인스턴스 스토어 볼륨 기준이라, EBS 볼륨만 쓰는 인스턴스에서는 값이 없거나 0으로 나옵니다. EBS 볼륨 지표는 AWS/EBS 네임스페이스나 Nitro 기반 인스턴스의 EBS 관련 지표에서 확인해야 합니다.

 

CPU와 네트워크는 기본으로 5분마다 무료 수집되지만, 메모리와 디스크 사용률은 CloudWatch 에이전트를 설치해야 볼 수 있습니다.

 

지표 보존 기간과 해상도

CloudWatch는 데이터를 영구히 같은 정밀도로 보관하지 않습니다. 시간이 지날수록 더 긴 간격으로 묶어서 보관합니다. 1분 간격 데이터는 15일 동안 1분 단위로 볼 수 있고, 그 뒤에는 5분 단위로 합쳐지며, 63일이 지나면 1시간 단위로 합쳐집니다.

 

데이터 간격	보존 기간
60초 미만(고해상도 사용자 지정 지표)	3시간
60초(1분)	15일
300초(5분)	63일
3,600초(1시간)	455일(15개월)

 

이 규칙은 장애 분석 계획에 영향을 줍니다. 예를 들어 두 달 전 특정 시각에 몇 분 동안 CPU가 튀었는지 확인하려 해도, 이미 5분이나 1시간 단위로 합쳐진 뒤라 짧은 순간의 변화는 보이지 않습니다. 세밀한 분석이 필요한 지표라면 기간 안에 따로 내보내 보관해야 합니다.

 

1분 데이터는 15일, 5분 데이터는 63일, 1시간 데이터는 15개월까지 보관되므로 오래된 구간일수록 짧은 순간의 변화는 확인할 수 없습니다.

 

알람이 울리는 조건은 기간과 평가 횟수로 정합니다

알람은 지표 하나를 지켜보다가 기준값을 넘는 상태가 일정 기간 유지되면 상태를 바꾸고 작업을 실행합니다. 알람의 상태는 정상(OK), 경보(ALARM), 데이터 부족(INSUFFICIENT_DATA) 세 가지입니다.

 

조건은 세 가지 숫자로 정합니다. 기간(period)은 데이터를 몇 초 단위로 묶어 볼지, 평가 기간은 최근 몇 개의 기간을 살펴볼지, 경보를 발생시킬 데이터 포인트는 그중 몇 개가 기준을 넘어야 경보로 볼지입니다. 이를 흔히 N개 중 M개 규칙이라고 부릅니다.

 

 

예를 들어 기간 5분, 평가 기간 3, 경보 데이터 포인트 2로 설정하면 최근 15분을 5분씩 세 칸으로 나눠 보고, 그중 두 칸의 평균 CPU가 80%를 넘을 때 경보 상태가 됩니다. 한 번 잠깐 튄 값에는 반응하지 않고, 부하가 이어질 때만 알림이 오도록 걸러 주는 효과가 있습니다.

 

알람 기간은 지표의 수집 간격보다 짧게 잡으면 안 됩니다. 기본 모니터링 지표는 5분 간격이므로 기간을 300초 이상으로 설정해야 하고, 세부 모니터링을 켠 경우에만 60초 기간이 의미가 있습니다. 데이터가 들어오지 않을 때의 처리 방법도 고를 수 있습니다. 누락으로 보기, 정상으로 보기, 기준 초과로 보기, 무시하고 이전 상태 유지하기 중에서 서비스 특성에 맞게 선택합니다.

 

알람은 기간, 평가 기간, 경보 데이터 포인트 세 숫자로 조건을 정하며, 기본 모니터링 지표에는 5분 이상의 기간을 써야 합니다.

 

EC2 CPU 알람 설정하는 순서

가장 많이 쓰는 CPU 사용률 알람을 기준으로 순서를 정리하면 다음과 같습니다.

 

1. Amazon SNS에서 주제를 만들고 이메일 구독을 추가한 뒤, 받은 메일에서 구독 확인을 눌러 둡니다. 확인하지 않으면 알림이 오지 않습니다.
2. CloudWatch 콘솔에서 경보 메뉴의 경보 생성을 누르고 지표 선택에서 EC2, 인스턴스별 지표, 해당 인스턴스의 CPUUtilization을 고릅니다.
3. 통계는 평균, 기간은 5분으로 두고 조건을 보다 큼, 기준값 80으로 입력합니다.
4. 추가 구성에서 경보를 발생시킬 데이터 포인트를 3개 중 2개로 설정하고, 누락 데이터 처리 방식을 정합니다.
5. 작업 구성에서 경보 상태일 때 1단계에서 만든 SNS 주제로 알림을 보내도록 지정합니다. 필요하면 정상 상태로 돌아왔을 때의 알림도 추가합니다.
6. 알람 이름을 서비스와 지표가 드러나게 짓고 생성합니다.

 

만든 알람이 실제로 메일을 보내는지는 부하를 주지 않고도 확인할 수 있습니다. AWS CLI의 set-alarm-state 명령으로 알람 상태를 잠시 ALARM으로 바꾸면 알림이 발송되고, 다음 평가 때 실제 지표 값에 따라 원래 상태로 돌아옵니다.

 

SNS 구독 확인, 지표 선택, 기준값과 N개 중 M개 설정, 알림 대상 지정 순서로 만들고, set-alarm-state로 알림 발송까지 시험해 두는 것이 좋습니다.

 

로그는 보존 기간 기본값부터 바꿔야 합니다

CloudWatch Logs는 로그를 로그 그룹과 로그 스트림으로 관리합니다. 같은 애플리케이션의 로그를 한 그룹으로 묶고, 서버나 실행 단위별로 스트림이 나뉘는 구조입니다. 보존 기간과 접근 권한은 로그 그룹 단위로 설정합니다.

 

주의할 점은 보존 기간의 기본값이 만료 없음이라는 것입니다. 로그는 수집량과 저장량에 따라 요금이 붙기 때문에, 설정을 바꾸지 않으면 오래된 로그가 계속 쌓이면서 저장 요금도 함께 늘어납니다. 운영 로그는 30일이나 90일처럼 필요한 기간을 정해 두고, 장기 보관이 필요한 로그만 따로 S3로 내보내는 방식이 일반적입니다.

 

로그에서 지표를 만드는 기능도 유용합니다. 지표 필터로 ERROR 같은 문자열이 나온 횟수를 세어 지표로 만들면, 그 지표에 알람을 걸어 오류가 급증할 때 알림을 받을 수 있습니다.

 

로그 그룹의 보존 기간은 기본이 만료 없음이므로 만들자마자 필요한 기간으로 바꾸고, 중요한 오류 문자열은 지표 필터로 알람까지 연결해 두세요.

 

CloudWatch 핵심 정리

CloudWatch는 지표, 알람, 로그를 중심으로 동작합니다. EC2는 CPU와 네트워크 지표를 5분 간격으로 무료 제공하지만 메모리와 디스크 사용률은 에이전트가 필요합니다. 지표는 시간이 지날수록 더 긴 간격으로 합쳐져 최대 15개월 보관됩니다. 알람은 기간과 N개 중 M개 규칙으로 일시적인 튐을 걸러 내도록 설정하고, 로그 그룹은 보존 기간을 반드시 지정해 불필요한 저장 요금을 막는 것이 기본입니다.

 

질문 QnA

기본 모니터링만으로 충분할까요?

개인 프로젝트나 트래픽 변화가 완만한 서비스라면 5분 간격으로도 추세를 보기에 충분합니다. Auto Scaling처럼 부하 변화에 빨리 반응해야 하는 경우에는 1분 간격의 세부 모니터링이 권장됩니다.

메모리 지표를 추가했는데 콘솔에 보이지 않아요.

에이전트 설정 파일에 메모리 항목이 들어 있는지, 인스턴스 역할에 지표 전송 권한이 있는지, 콘솔의 리전이 맞는지를 확인해 보세요. 에이전트가 보낸 지표는 AWS/EC2가 아니라 CWAgent 같은 별도 네임스페이스에 표시됩니다.

알람이 계속 데이터 부족 상태로 남아 있어요.

인스턴스가 중지되어 지표가 들어오지 않거나, 알람 기간이 지표 수집 간격보다 짧게 설정된 경우가 많습니다. 기본 모니터링 지표라면 기간을 5분 이상으로 바꿔 보세요.

CloudWatch 요금은 어디서 발생하나요?

AWS 서비스의 기본 지표는 무료이고, 세부 모니터링, 사용자 지정 지표, 알람, 대시보드, 로그 수집과 저장 등에 요금이 붙습니다. 일정 범위의 무료 사용량이 있으니 정확한 기준은 공식 요금 페이지에서 확인하세요.

 

모니터링은 장애가 난 뒤에 설정하면 늦습니다. 서비스를 만들 때 알람 몇 개와 로그 보존 기간을 함께 정해 두는 것만으로도 문제를 사용자보다 먼저 알아챌 수 있습니다.

 

지금 운영 중인 EC2 인스턴스가 있다면 CPU 알람 하나와 상태 검사 실패 알람 하나를 먼저 만들어 보세요. 그다음 CloudWatch Logs에서 보존 기간이 만료 없음으로 되어 있는 로그 그룹이 있는지 확인해 보시길 권해드립니다.

함께 읽으면 좋은 글: AWS Budgets 예산 알림 설정 / EC2 인스턴스 유형 이름 읽는 법

참고 자료: CloudWatch 지표 개념, EC2 인스턴스의 CloudWatch 지표, CloudWatch Logs 로그 그룹과 보존 기간, CloudWatch 요금

※ 본 글은 2026년 9월 기준 Amazon CloudWatch, Amazon EC2 사용 설명서와 CloudWatch 요금 페이지를 참고해 작성했으며, 지표 목록과 보존 기간, 요금 기준은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.