비용 이상 탐지, 급증을 월말이 아니라 당일에 받기

발견이 늦으면 금액은 날짜만큼 곱해집니다

비정상 지출의 피해 크기는 단가가 아니라 발견까지 걸린 날짜로 결정됩니다. 학습용 가정으로 잘못된 설정 때문에 하루 80,000원이 추가로 발생한다고 두겠습니다. 월말 청구서에서 발견하면 25일이 지나 2,000,000원입니다. 당일 발견하면 80,000원입니다. 차이는 1,920,000원이고, 이것이 탐지 체계에 투자할 수 있는 상한의 근거가 됩니다. 그래서 질문은 '알림을 몇 개 둘까'가 아니라 '며칠 안에 발견하고 싶은가'입니다. 목표 일수를 먼저 정하면 필요한 감지 방식이 따라 정해집니다.

예산 알림과 이상 탐지는 역할이 다릅니다

예산 알림은 미리 정한 금액을 넘었는지 봅니다. 그래서 예상 범위 안에서 조용히 늘어나는 낭비는 잡지 못하고, 예산을 넉넉히 잡아 두면 더 늦게 울립니다. 이상 탐지는 과거 패턴과 다른 모양을 찾습니다. 금액이 예산 안이어도 평소와 다르면 알립니다. 두 수단은 겹치지 않으므로 함께 씁니다. 설정 순서는 1단계 서비스별 또는 계정별로 감지 범위를 나누고, 2단계 각 범위의 알림 수신자를 정하고, 3단계 알림을 받았을 때의 확인 절차를 적는 것입니다. 수신자와 절차 없이 감지만 켜면 알림이 쌓이다가 무시됩니다.

범위를 쪼개야 작은 급증도 보입니다

감지 범위를 전체 계정 하나로 두면 작은 급증이 전체 금액에 묻힙니다. 가정 계산으로 전체 월 비용이 20,000,000원인 조직에서 하루 80,000원 증가는 전체의 0.4퍼센트여서 정상 변동과 구분되지 않습니다. 같은 증가가 월 500,000원 규모의 한 서비스에서 일어났다면 비중이 커져 즉시 드러납니다. 그래서 범위를 서비스별로 쪼갭니다. 쪼갠 뒤에는 각 범위의 평상시 폭을 적어 둡니다. 3일만 늦게 발견해도 240,000원이 추가되므로, 범위를 나누는 작업은 한 번에 끝나고 효과는 매달 반복됩니다.

정상인 급증을 미리 등록해 둡니다

결론을 뒤집는 조건은 계획된 급증입니다. 신규 서비스 출시, 대량 이전 작업, 행사 트래픽은 비용이 정상적으로 뜁니다. 이것을 모두 알림으로 받으면 잡음이 늘어 진짜 이상을 놓칩니다. 그래서 계획된 작업은 시작 전에 예상 증가액과 기간을 기록하고, 그 기간의 알림은 별도로 분류합니다. 두 번째 조건은 신규 계정입니다. 과거 데이터가 없으면 이상 판정 기준이 없으므로 초기에는 예산 알림을 주로 쓰고, 패턴이 쌓인 뒤 이상 탐지로 옮깁니다. 그래서 운영 문서에는 계획된 급증 목록과 신규 범위 목록을 따로 두고, 각 항목의 해제 예정일을 함께 적어 둡니다.

AWS 비용 실행 전 점검표

• 며칠 안에 발견할지 목표 일수를 정했다
• 예산 알림과 이상 탐지를 함께 설정했다
• 감지 범위를 서비스별로 쪼갰다
• 계획된 급증과 신규 범위를 목록으로 관리한다