EC2의 CPU 경보를 만들고 메일함을 새로고침했는데 아무것도 없다. '경보 설정을 잘못했나?' 싶지만, 먼저 두 질문을 나눠야 한다. CloudWatch가 아직 ALARM 상태로 바뀌지 않았는가, 아니면 바뀌었는데 SNS 이메일 구독이 확인되지 않았는가? 둘은 화면에서 확인할 곳도, 고칠 방법도 다르다.
CPU가 높아 보이는데 왜 경보는 '데이터 부족'일까?
예를 들어 CPUUtilization의 5분 평균이 80%보다 클 때, 최근 평가 기간 1개 중 1개가 조건에 맞으면 ALARM으로 바뀌도록 설정했다고 하자. 생성 직후에는 평가할 지표가 아직 없어 INSUFFICIENT_DATA(데이터 부족)일 수 있다. 이 상태는 'CPU가 안전하다'는 뜻도, '이미 80%를 넘었다'는 뜻도 아니다. 판단할 데이터가 부족하다는 뜻이다. CloudWatch의 누락 데이터 평가 설명처럼 데이터가 비었을 때의 처리 설정에 따라 이후 상태도 달라질 수 있다.
같은 경보를 시간순으로 보면 구분이 쉽다. 아래 값은 평가 방법을 설명하기 위한 예시이며 AWS 계정에서 측정한 결과가 아니다.
| 평가 시점 | 최근 5분 평균 데이터 | > 80% 판단 | 경보 상태 |
|---|---|---|---|
| 생성 직후 | 없음 | 평가할 값이 없음 | INSUFFICIENT_DATA |
| 첫 데이터 도착 | 4.2% | 거짓 | OK |
| 부하 후 데이터 도착 | 99.8% | 참 | ALARM |
여기서 80%와 정확히 같은 값은 > 80을 만족하지 않는다. 그래프가 오른쪽으로 치솟는 순간마다 즉시 메일이 오는 것도 아니다. 설정한 기간의 지표가 들어오고 경보가 평가되어 상태가 바뀌어야 한다. '5분 평균'을 '5분 동안 한 번이라도 80%를 넘음'으로 읽으면 기다리는 시간이 답답해진다.
경보가 ALARM인데도 이메일이 없다면?
이제 경보 상세 화면의 상태 기록을 보고 실제로 OK → ALARM 전환이 있었는지 확인한다. 전환이 없다면 SNS보다 지표 이름·인스턴스 ID·기간·임계값을 먼저 본다. 전환이 있다면 경보의 작업이 ALARM 상태에서 해당 SNS 주제로 알림을 보내도록 설정됐는지 확인한다.
그다음 SNS 주제의 이메일 구독 상태를 본다. 주소를 입력해 구독을 만들었다고 끝난 게 아니다. 확인 메일에서 구독을 승인하기 전에는 PendingConfirmation 상태여서 이메일을 받을 수 없다. SNS 이메일 구독 안내에도 이 확인 단계가 명시돼 있다. 메일이 안 와서 경보 임계값부터 다시 낮추기 전에 구독 상태를 한 번 보는 편이 빠르다.
이 예시의 경로를 한 줄로 쓰면 다음과 같다.
CPU 5분 평균 99.8% → CloudWatch ALARM 전환 → SNS 주제
├─ 구독 확인 대기 → 이메일 미전달
└─ 구독 확인 완료 → 이메일 전달 가능구독 확인을 경보가 이미 ALARM으로 바뀐 뒤에 했다면 이전 상태 전환 메일이 뒤늦게 자동 재전송된다고 기대하지 말자. 확인된 구독으로 알림 경로를 점검하고, 다음 상태 전환에서 실제 수신을 검증해야 한다.
CPU 경보가 조용할 때 확인 순서는?
경보 상태 → 지표 데이터 → 경보 작업 → SNS 구독 순서로 좁힌다. INSUFFICIENT_DATA라면 누락 데이터 처리 설정과 실제 지표가 들어오는지를 본다. OK라면 최근 평가값이 > 80%였는지 확인한다. ALARM이라면 상태 기록과 작업에 연결된 SNS 주제, 그리고 이메일 구독의 확인됨 상태를 대조한다. 이렇게 나누면 메일함을 새로고침하는 횟수보다 원인 후보가 더 빨리 줄어든다.
운영 경보라면 1개 기간 중 1개만 초과해도 울리는 설정이 너무 민감하지 않은지도 살펴야 한다. 반대로 데이터가 사라졌다고 무조건 정상으로 간주하면 장애 신호를 놓칠 수 있다. 기간·평가 횟수·누락 데이터 처리는 지표가 얼마나 자주 들어오는지와 실제 대응 시간을 기준으로 정해야 한다. 여기의 80%와 5분은 보편적인 정답이 아니라 한 경보의 설정 예시다.
CPU 경보가 OK여도 애플리케이션 응답까지 정상이라는 뜻은 아니다. EC2가 실행 중인데 서비스가 받지 못하는 경우는 ALB 대상 그룹이 unhealthy일 때의 헬스 체크 확인법처럼 별도의 신호로 진단해야 한다.
핵심 요약
메일이 오지 않는다고 해서 경보와 SNS를 한꺼번에 다시 만들 필요는 없다. 먼저 CloudWatch가 INSUFFICIENT_DATA·OK·ALARM 중 어디에 있는지 본다. ALARM으로 전환됐다면 알림 작업과 SNS 이메일 구독 확인 상태를 본다. 지표가 조건을 충족하는 문제와 메일이 전달되는 문제를 분리하는 것이 가장 빠른 진단이다.
