서비스가 이상하게 동작할 때 사람이 먼저 알아채려면 지표에 경보를 걸고 알림을 이메일로 받는 구성이 필요합니다. 이 글에서는 CloudWatch 콘솔에서 지표 하나를 골라 경보를 만들고, 같은 화면에서 SNS 주제와 이메일 구독을 함께 만듭니다. 이 글의 목표는 경보를 만드는 화면의 구성을 읽는 것입니다. 경보가 실제로 울려 메일이 도착하는지는 확인하지 않았습니다. 이 실습에서 고른 지표는 보안 감시용으로 의미가 있는 지표가 아니라, 화면 구성을 보기 위한 임의의 API 호출 횟수 지표입니다. 거부된 API 호출 같은 보안 이벤트를 경보로 받으려면 CloudTrail 로그를 CloudWatch Logs로 보내 지표 필터를 만드는 방법이 있는 것으로 알려져 있고(CloudTrail 사용자 가이드 기준, EventBridge 규칙을 쓰는 방법도 있습니다), 이 실습 계정에는 로그 그룹이 없어서 그 구성은 다루지 못했습니다. 이 글은 경보와 SNS 알림의 기본 화면까지만 다룹니다.
준비물
| 항목 | 내용 |
|---|---|
| AWS 계정 | 실습용 IAM 사용자. CloudWatch 경보와 SNS 주제를 만들고 지울 수 있는 권한이 필요합니다(세부 권한 이름은 확인하지 않았습니다) |
| 리전 | 이 실습에서는 리전 선택기에 미국 (버지니아까지만 보였고(잘림), 미국 동부(버지니아 북부) us-east-1로 읽었습니다 |
| 이메일 주소 | 알림을 받을 주소 1개. 이미지에서는 가렸습니다 |
| 경보 이름 | cr-demo-listanalyzers-calls |
| SNS 주제 이름 | cr-demo-alarm-topic |
| 변경 사항 | 경보 1개와 SNS 주제 1개(이메일 구독 포함)를 만들고 마지막에 모두 삭제합니다. 경보와 SNS는 쓰는 만큼 요금이 생길 수 있으므로 실습 뒤 정리가 필요합니다(요금 수준은 확인하지 않았습니다) |
화면의 계정 ID, 사용자 이름, 이메일 주소는 가렸습니다.
1. 경보 만들기 시작
CloudWatch 콘솔의 경보에서 경보 생성을 누르면 4단계 마법사가 열립니다. 단계는 지표 및 조건 지정, 작업 구성, 경보 세부 정보 추가, 미리 보기 및 생성입니다.

데이터 소스는 지표(CloudWatch 지표 모니터링), 로그(CloudWatch Logs 쿼리 모니터링), 경보 결합(여러 경보 결합) 세 가지이고, 이 글에서는 처음부터 선택되어 있던 지표와 유형 클래식을 썼습니다. 이어서 지표 선택을 누릅니다.
2. 지표 고르기
지표 선택 창에서 모두 아래의 Usage, AWS 리소스별 순으로 들어가 서비스별 API 호출 횟수(CallCount) 지표 목록을 봤습니다. 네임스페이스 목록 화면은 캡처하지 않았습니다.

목록은 서비스, 리소스(API 이름), 유형, Class, 지표 이름(CallCount), 경보 열로 이루어져 있었고, 이 화면에 보이는 행은 모두 경보 열이 경보 없음이었습니다. 첫 번째 행의 Access Analyzer / ListAnalyzers / CallCount를 골랐습니다. 지표 이름은 보안 감시 용도로 고른 것이 아니라 이 글에서 화면을 보기 위해 임의로 고른 것입니다.

체크하면 그래프가 CallCount로 바뀌지만 이 실습에서는 사용 가능한 데이터가 없습니다.라고 표시되었습니다(최근 3시간 범위 기준). 지표 선택으로 닫으면 조건 입력 화면으로 돌아갑니다.
3. 조건 정하기
조건 화면에는 통계(기본값 평균), 기간(5분), 그리고 임계값 조건이 있습니다.
| 화면 | 입력칸 | 입력값 |
|---|---|---|
| 지표 및 조건 지정 | 통계 | 평균(처음부터 선택됨) |
| 지표 및 조건 지정 | 기간 | 5분(처음부터 선택됨) |
| 조건 | 경보 조건 | 보다 큼 (> 임계값, 처음부터 선택됨) |
| 조건 | 임계값 | 5(이 글의 화면에는 입력한 값이 보이지 않습니다) |

경보 조건은 보다 큼(> 임계값), 보다 크거나 같음, 보다 작거나 같음, 보다 작음 네 가지이고 처음부터 보다 큼이 선택되어 있었습니다. 임계값 칸의 안내 문구(입력 예시)는 10,000이었고 이 글에서는 5를 입력했습니다. 미리 보기 위쪽에는 이 경보는 5 분 내 1개의 데이터 포인트에 대해 파란색 줄이 빨간색 줄을 초과할 때 트리거됩니다.라는 설명이 있었습니다. 이 화면은 스크롤한 상태라 입력한 임계값이 이미지에 보이지 않습니다. 입력한 값은 4단계 미리 보기의 1단계 요약에서 확인하는 것으로 알고 있지만 이 글에서는 그 요약을 캡처하지 않았습니다. 다음을 누릅니다.
4. 알림 보낼 SNS 주제 만들기
2단계 작업 구성에서는 경보 상태가 되었을 때 무엇을 할지 정합니다.

경보 상태 트리거는 경보 상태(임계값을 벗어남), 정상(임계값 범위 안), 데이터 부족(데이터가 부족함) 중에서 고르며 처음부터 경보 상태가 선택되어 있었습니다. 알림 방식은 기존 SNS 주제 선택, 새 주제 생성, 주제 ARN을 사용하여 다른 계정에 알림 세 가지입니다. 아래로 내리면 Lambda 작업과 Auto Scaling 작업을 추가하는 칸도 있었지만 이 글에서는 쓰지 않았습니다(그 아래 칸은 캡처하지 않았습니다).
새 주제 생성을 고르고 입력합니다.
| 화면 | 입력칸 | 입력값 |
|---|---|---|
| 작업 구성 | 경보 상태 트리거 | 경보 상태(기본값) |
| 작업 구성 | 알림 방식 | 새 주제 생성 |
| 새 주제 생성 | 주제 이름 | cr-demo-alarm-topic |
| 새 주제 생성 | 알림을 수신할 이메일 엔드포인트 | 알림을 받을 이메일 주소 |

이름 규칙 안내는 영숫자, 하이픈, 밑줄만 쓸 수 있다는 것입니다(입력 전 기본 이름은 캡처하지 않았습니다). 이메일 칸은 쉼표로 여러 주소를 구분하는 방식이라고 안내되어 있습니다. 주제 생성을 누릅니다.

주제가 만들어지면 알림 칸이 기존 SNS 주제 선택으로 바뀌고 방금 만든 cr-demo-alarm-topic이 선택되어 있습니다. 아래에 이메일 엔드포인트가 표시되고 SNS 콘솔에서 보기 링크가 생겼습니다. 이 단계에서 SNS 주제가 이미 만들어진 것으로 보입니다. 경보 생성을 중간에 취소하면 주제가 남는지는 시험하지 않았습니다. 어쨌든 경보를 지워도 SNS 주제는 따로 지워야 하는 이유가 이 때문으로 짐작합니다(추정).
5. 이름 붙이고 미리 보기
3단계에서 경보 이름을 cr-demo-listanalyzers-calls로 입력했습니다. 이 단계 화면은 캡처하지 않았습니다. 설명 칸은 입력하지 않아도 되는 칸으로 보였고 이 실습에서는 cr-demo라고만 적었습니다. 이 화면에서 설명은 마크다운 서식을 쓸 수 있지만 콘솔에서 경보를 볼 때만 적용되고 경보 알림에서는 일반 텍스트로 유지된다고 안내합니다. 4단계 미리 보기에서 입력한 내용을 확인합니다.

미리 보기에서는 경보 상태 상태인 경우 "cr-demo-alarm-topic"(으)로 알림 전송이라고 표시되었습니다. 이미지는 아래쪽이라 1단계(지표와 조건) 요약은 보이지 않습니다. 경보 생성을 누릅니다.
6. 만들어진 경보 읽기

화면에서 읽은 내용은 다음과 같습니다.
- 초록 알림: 경보
cr-demo-listanalyzers-calls가 생성되었습니다. - 파란 알림:
일부 구독이 확인 보류 중임,구독이 확인될 때까지 Amazon SNS가 엔드포인트로 메시지를 전송하지 않음. 이메일 구독은 SNS가 보낸 확인 메일의 링크를 수신자가 눌러야 활성화되는 것으로 알려져 있습니다(SNS 문서 기준). 이 실습에서는 알림을 받을 주소로 SNS의AWS Notification - Subscription Confirmation확인 메일이 실제로 도착했습니다. 이 메일의 링크는 주제를 삭제할 것이어서 누르지 않았습니다. - 목록의 경보 상태는
데이터 부족, 작업은작업이 활성화됨(옆에 빨간 점선 글자가 있었고 읽기 어려웠습니다), 조건 열은5 분 내 1개의 데이까지만 보이고 잘려 있었습니다.
데이터 부족은 이 지표에 데이터가 없어서 나온 상태로 읽었습니다. 이 실습에서는 경보가 실제로 울리는 상태(경보)로 바뀌는 것을 보지 못했습니다.
7. 정리: 경보와 SNS 주제 삭제
경보 목록에서 경보를 선택하고 작업 메뉴의 삭제를 고릅니다(메뉴를 연 화면은 이 글에 싣지 않았습니다).

대화상자 제목의 경보 이름이 만든 것 하나와 같은지 확인하고 삭제를 누릅니다.

목록이 비었습니다. 하지만 같은 마법사에서 만든 SNS 주제는 경보를 지워도 남아 있습니다. SNS 콘솔의 주제에서 확인합니다.

SNS 콘솔의 주제에 들어가면(이동 화면은 캡처하지 않았습니다) 이 실습에서 만든 주제 1개만 있었습니다. 삭제 대화상자는 주제 이름을 보여 주고 delete me 문구를 입력하라고 안내합니다. 이름이 맞는지 확인한 뒤 입력해 삭제했습니다.

주제가 0개가 되었습니다. 이메일 구독은 주제와 함께 사라지는 것으로 보이지만 구독 목록을 따로 열어 확인하지는 않았습니다.
자주 막히는 곳
- 경보가
데이터 부족으로 계속 남는 경우: 이 실습에서는 지표에 데이터가 없어서 그랬습니다. 지표를 실제로 내는 리소스가 있는지, 기간과 통계가 맞는지 확인합니다. - 알림 메일이 안 오는 경우: 이 실습에서는 구독이 확인 보류 중이었습니다. SNS 문서에서는 확인 메일의 링크를 눌러야 알림이 가는 것으로 안내하며, 확인되지 않은 구독은 일정 시간 뒤 삭제되는 것으로 알려져 있습니다(시간은 문서에서 확인하시기 바랍니다). 스팸함도 확인합니다.
- 경보를 지웠는데 SNS 주제가 남은 경우: 경보와 주제는 따로 지웁니다. 이 글의 7번 단계입니다.
- 지표 목록이 너무 많은 경우: 이 실습의 Usage 목록은 453개였습니다. 검색 칸에 서비스나 API 이름을 넣어 줄입니다(검색은 시험하지 않았습니다).
이어서 해 볼 것
- 실제로 값이 나오는 지표(예: 실행 중인 인스턴스의 CPU)로 경보를 만들고
데이터 부족에서정상이나경보로 바뀌는지 보기 - 구독 확인 메일의 링크를 눌러 구독 상태가 바뀌는 것을 주제 화면에서 읽기(삭제 전에 해야 합니다)
- CloudTrail을 CloudWatch Logs로 보내는 구성을 해서 로그 지표 필터와 경보로 거부된 API 호출을 알리는 구성에 도전하기
- Budgets 글의 이메일 알림과 이 글의 SNS 알림이 어떻게 다른지 비교하기
확인한 범위와 확인하지 않은 것
- 확인한 것: SNS 구독 확인 메일의 도착, 경보 만들기 마법사의 네 단계 구성과 선택지, 지표 선택 화면, 조건과 알림 설정 화면, SNS 주제와 이메일 엔드포인트를 한 화면에서 만드는 것, 생성 결과의
데이터 부족상태와 구독 확인 보류 안내, 경보와 SNS 주제 삭제. - 확인하지 않은 것: 임계값 입력 결과 화면, 경보가 실제로 울리는 것과 경보 알림 메일 도착, 구독 확인 이후의 상태, 로그 기반 경보와 CloudTrail 연동, 다른 경보 작업(Lambda 등), 요금, 필요한 IAM 권한. 화면 문구는 이 실습 시점의 한국어 콘솔 기준이며 일부 안내는 영어로 표시되었습니다.
이 글의 다음 단계
- AWS Budgets로 월별 비용 예산과 알림 만들고 지우기AWS Budgets의 월별 비용 예산 템플릿으로 월 10달러 예산을 만들고, 템플릿이 자동으로 붙이는 세 가지 알림 조건과 이메일 수신자의 인증 대기 상태를 화면에서 읽습니다. 확인이 끝나면 예산을 삭제합니다.
- AWS CloudTrail 이벤트 기록에서 누가 언제 무엇을 했는지 읽기CloudTrail 이벤트 기록 화면에서 최근 변경 이벤트를 보고, 리소스 이름으로 걸러 한 보안 그룹의 생성부터 삭제까지를 추적합니다. 이벤트 상세와 JSON 레코드에서 사용자, 시각, 호출 내용, MFA 여부를 읽는 방법을 정리합니다.