AWS 예산 알림 지연과 이상 비용 탐지 설정

예상치 못한 AWS 청구를 발견하려면 AWS Budgets에 월 비용 예산을 만들고 실제 지출과 예측 지출의 임계값을 각각 설정한 뒤, Cost Anomaly Detection의 모니터와 알림 구독을 점검해야 한다. AWS의 Budgets 운영 지침에 따르면 청구 데이터는 적어도 하루에 한 번 갱신되고, 예측 알림에는 약 5주의 사용 기록이 필요하다. 예산 알림이 사용 직후 도착할 것이라고 기대해서는 안 되는 이유다.

두 기능이 보내는 신호는 다르다. 예산은 정해 둔 월 비용에 실제 지출이 도달했거나 기간 말 예측액이 도달할 것으로 보일 때 알리고, 이상 비용 탐지는 평소 패턴과 다른 증가를 찾는다. AWS의 이상 비용 탐지 설명에 따르면 사용이 발생한 뒤 이상을 감지하기까지 최대 24시간이 걸릴 수 있다. 둘을 함께 사용해도 비용이 발생하는 순간 지출을 멈추는 방식은 아니다.

월 한도와 갑작스러운 증가를 따로 감시하는 이유

실제 지출 알림은 이미 집계된 비용을 기준으로 한다. 조건부로 월 예산을 100달러로 잡고 실제 지출 임계값을 80%로 설정했다면, 집계 비용이 80달러에 이르렀을 때 알림 조건을 충족한다. 청구 데이터가 갱신된 뒤 판단하므로 이 알림을 사용량의 실시간 계기판처럼 취급하면 대응 시점을 잘못 예상할 수 있다.

예측 지출 알림은 현재까지의 누적액 대신 기간 말에 예상되는 금액을 본다. 같은 조건부 예시에서 실제 지출이 아직 80달러 미만이어도 월말 예상액이 100달러를 넘는다면 예측 임계값이 먼저 신호를 줄 수 있다. 다만 사용 기록이 충분하지 않은 새 계정에서는 예측 알림이 설정돼 있어도 작동하지 않을 수 있어, 실제 지출 임계값을 기본 경로로 두는 편이 낫다.

이상 비용 탐지는 월 예산의 남은 금액과 별개로 작동한다. 한도까지 여유가 있어도 특정 서비스의 지출이 평소 패턴에서 벗어나면 탐지 대상이 될 수 있다. 탐지 결과에는 비용 영향과 함께 서비스, 계정, 리전, 사용 유형별 잠재 원인이 표시된다. 월 한도 접근을 알리는 예산과 증가가 발생한 위치를 좁혀 주는 탐지가 서로 다른 질문에 답하는 셈이다.

알림의 반복 방식도 다르다. 실제 지출 예산 알림은 해당 예산 기간에 임계값을 처음 넘을 때 발송되므로, 이후 비용이 계속 늘어도 같은 임계값에서 연속 경고를 기대하기 어렵다. 예측 알림은 예측액이 임계값 위아래로 움직이면 같은 기간에 다시 발송될 수 있다. 따라서 알림 횟수만 보고 비용 증가가 멈췄는지 판단하지 말고 누적액과 원인 항목을 함께 봐야 한다.

AWS Budgets에 실제·예측 임계값 설정하기

처음에는 계정 전체의 월 비용을 보는 예산을 만들면 감시 범위를 이해하기 쉽다. 서비스나 프로젝트별 비용을 따로 맡는 사람이 있다면 이후 필터를 적용한 예산을 추가할 수 있다. 예산액은 허용할 지출 수준으로 정하고, 그 금액에 도달하기 전에 확인할 수 있도록 실제 지출 임계값을 배치한다.

Billing and Cost Management 콘솔에서 Budgets와 Create budget을 차례로 연다. Budget setup의 Customize (advanced)에서 Cost budget을 선택하고, 알림을 받았을 때 범위를 알아볼 수 있는 예산 이름을 붙인다.
Period는 Monthly, 갱신 방식은 Recurring budget으로 설정하고 월 예산액을 입력한다. 전체 비용을 보려면 필터를 불필요하게 좁히지 않는다. 별도 서비스 예산을 만들 때는 서비스 필터를 확인하고, 환불·크레딧·세금 등을 비용에 포함할지 정해 전체 청구액과 예산액의 차이를 이해해 둔다.
Add an alert threshold에서 실제 지출용 조건을 만든다. 예를 들어 월 예산에 도달하기 전에 확인하려는 조건부 운영안이라면 80%와 Actual을 선택한다. 예산액 도달 자체도 별도로 알리고 싶다면 100% Actual 임계값을 추가한다. 이 비율은 AWS가 모든 계정에 권하는 고정값이 아니라 대응 여유에 맞춰 정하는 예시다.
사용 기록이 쌓인 계정에는 Forecasted 임계값도 추가한다. 조건부로 100%를 선택하면 현재 비용이 이미 예산액에 이르렀다는 뜻이 아니라, 해당 예산 기간의 예상 지출이 예산액에 도달할 수 있다는 신호다. 새 계정에서는 이 조건만 믿고 실제 지출 알림을 생략하지 않는다.
각 임계값의 Email recipients에 확인할 사람의 주소를 넣고 수신 확인 절차를 마친다. 팀으로 전달하려면 Amazon SNS 토픽도 사용할 수 있다. 이때 토픽에 Budgets의 발행 권한을 부여하고 SNS 구독 승인을 마쳐야 전달 경로가 완성된다. 마지막으로 예산 기간, 비용 범위, 임계값 유형, 수신자를 검토한 뒤 생성한다.

예산의 Actual과 Forecasted를 같은 비율로 설정해도 해석은 다르다. Actual은 갱신된 청구 데이터가 기준에 닿았다는 뜻이고, Forecasted는 계산된 기간 말 비용이 기준에 닿을 수 있다는 뜻이다. 수신자가 알림에서 어느 조건이 발동했는지 구분할 수 있도록 임계값과 담당자를 정해 두면 조사 순서를 결정하기 쉽다.

예산 알림 자체는 결제를 중단하는 상한이 아니다. 별도의 예산 조치를 구성하지 않았다면 임계값을 넘은 뒤에도 리소스 사용과 비용 발생은 이어질 수 있다. 수신 주소에는 비용을 확인하고 해당 리소스의 지속 사용 여부를 판단할 수 있는 사람을 포함하는 것이 실용적이다.

Cost Anomaly Detection의 모니터와 수신 방식 정하기

Cost Anomaly Detection에서는 먼저 감시 범위를 정하는 모니터와 알림을 받을 구독을 확인한다. Cost Explorer 활성화 안내에 따르면 Cost Explorer를 활성화할 때 AWS 서비스 모니터와 일일 요약 알림 구독이 자동으로 구성된다. 이미 만들어진 항목이 있다면 범위, 임계값, 수신자를 확인한 뒤 필요한 부분을 조정하거나 추가하면 된다.

Billing and Cost Management에서 Cost Anomaly Detection을 열고 Cost monitors를 확인한다. 개인 계정이라면 AWS services 차원의 모니터가 전체 서비스의 비용 패턴을 살피는 출발점이다. 기존 모니터가 없는 경우 Create monitor에서 감시 차원을 고르고 이름을 지정한다.
조직의 여러 계정을 관리한다면 관리 계정에서 Linked account 차원의 모니터를 검토한다. 연결 계정, 비용 할당 태그, 비용 범주를 대상으로 하는 모니터는 관리 계정에서 만든다. 팀별 담당 범위가 다르면 모든 알림을 한 주소에 모으기 전에 어느 계정이나 범주를 누가 조사할지 정한다.
Alert subscriptions에서 비용 영향의 절대액 또는 예상 비용 대비 증가율을 임계값으로 설정한다. 작은 실험 계정과 큰 운영 계정에 같은 절대액을 적용하면 체감하는 증가 규모가 달라진다. 어느 수준부터 조사가 필요한지에 맞춰 임계값을 정하고, 팀별 기준이 다르면 구독도 구분한다.
수신 속도에 따라 알림 빈도를 고른다. Individual alerts는 이상이 감지될 때 각각 보내며 Amazon SNS 토픽이 필요하다. Daily summaries는 이메일로 지난 기간의 탐지 결과를 묶어 보내므로, 감지 직후 개별 통지를 기대하는 경로로 쓰기 어렵다. 구독을 만든 뒤 원하는 모니터와 연결됐는지 확인한다.

새 모니터는 생성 직후 이전 비용을 소급해 경고하는 방식으로 생각하지 않는 편이 정확하다. 감시를 시작하기까지 시간이 걸릴 수 있고, 새로 사용하는 서비스는 이상을 판별할 만큼의 기록이 필요할 수 있다. 첫날 탐지 결과가 비어 있다는 이유만으로 비용에 변화가 없다고 결론 내리지 말고 실제 지출 예산과 청구 내역도 살핀다.

개인 계정과 팀 계정의 알림 경로 나누기

개인 계정에는 전체 월 비용 예산, 이른 실제 지출 임계값, 예산액 도달 임계값을 먼저 두는 구성이 간단하다. 사용 기록이 충분해지면 예측 임계값을 더하고, 이상 비용 모니터의 일일 요약을 받을지 SNS를 통한 개별 알림을 받을지 자신의 확인 주기에 맞춰 선택한다. 같은 사람이 예산과 이상 비용을 모두 받더라도 두 알림의 의미는 구분해야 한다.

팀 계정에서는 비용 책임자와 조사 담당자를 구분할 수 있다. 전체 예산의 한도 접근은 비용 책임자에게 보내고, 특정 연결 계정이나 비용 범주의 이상은 해당 운영 담당자가 받도록 구성하는 식이다. 한 팀의 증가가 조직 전체 비용에서는 작게 보일 수 있으므로, 중요한 비용 범위에는 별도 모니터나 구독 임계값을 검토할 만하다.

예산 알림도 SNS 토픽으로 전달할 수 있어 여러 수신 경로를 운영할 수 있다. 다만 SNS 토픽을 만들었다는 사실만으로 전달이 완료되지는 않는다. 발행 권한과 구독 승인, 실제 수신자가 맞물려야 하며, 팀 채널로 보낸다면 누가 알림을 확인하고 원인을 조사할지도 정해 두어야 한다.

같은 지출 증가가 예산과 이상 비용 알림에 모두 나타날 수 있다. 이때 예산은 누적액이 월 기준에 얼마나 가까운지, 이상 비용 탐지는 어느 범위에서 평소와 다른 증가가 생겼는지를 보여준다. 알림 이름과 모니터 범위를 알아보기 쉽게 붙여 두면 수신자가 중복 알림으로 넘기지 않고 두 신호를 함께 해석할 수 있다.

알림을 받은 뒤 비용을 좁혀 보는 순서

예산 알림을 받으면 Actual인지 Forecasted인지 먼저 확인한다. Actual이라면 이미 집계된 비용이 임계값에 닿았는지 살피고, Forecasted라면 남은 기간의 예상액을 현재 사용 추세와 함께 본다. 그다음 Cost Explorer나 청구 내역에서 증가한 서비스와 기간을 좁혀 계속 필요한 사용인지 판단한다.

이상 비용 알림에서는 비용 영향과 잠재 원인의 서비스, 계정, 리전, 사용 유형을 확인한다. 이 항목들은 조사를 시작할 범위를 제시하며, 개별 리소스의 실제 사용이나 최근 설정 변경까지 자동으로 확정해 주지는 않는다. 담당자는 해당 범위의 사용량과 변경 내역을 확인한 뒤 조치 여부를 결정하면 된다.

함께 읽기: