LASSIC Media らしくメディア
AWSのコスト異常検知と予算アラート運用
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- AWS Budgetsは設定したしきい値に基づく固定型のアラートであるのに対し、AWS Cost Anomaly Detectionは機械学習で通常のパターンから外れた支出を検知する仕組みで、役割が異なります。
- 通知先の設計と検知後の一次対応フローを事前に決めておかないと、アラートが届いても対応が滞留しやすくなります。
- 外注する場合も、モニターの粒度としきい値の根拠、通知の受け手をどう設計したかを発注前に確認しておく必要があります。
目次
AWSのコスト異常検知・予算アラートとは
AWSのコスト異常検知・予算アラート運用とは、AWS Budgets（予算としきい値アラート）とAWS Cost Anomaly Detection（機械学習によるコスト異常検知）を組み合わせ、意図しないコスト増加をできるだけ早く検知し、担当者へ通知する仕組みを指します。予算超過の可能性を事前に把握するBudgetsと、想定外の支出パターンを事後的に検出するCost Anomaly Detectionは、検知の考え方が異なるため、両方の役割を理解したうえで併用する設計が基本になります。
本稿で扱うのは「異常の早期検知・アラート運用」に絞った論点です。複数アカウントの請求を一元管理する一括請求（Consolidated Billing）の設計、あるいはFinOps体制構築全般（コスト最適化の組織・プロセス設計）は、扱う範囲が異なるため別稿で取り上げています。本稿は、すでに何らかの形でAWSを利用している状態から、想定外のコスト増加をどう検知し、誰が最初に動くかという運用面に焦点を当てます。
AWS Budgetsは、あらかじめ決めた予算額やしきい値に対して、実績または予測のコスト・使用量がどこまで近づいたかを監視する仕組みです。しきい値は自社で設定する固定値であるため、想定していない種類の異常には反応しない一方、予算超過という分かりやすい基準で運用しやすい特性があります。これに対してAWS Cost Anomaly Detectionは、機械学習モデルが過去の支出パターンから通常の範囲を学習し、そこから外れた支出を検知する仕組みです*1。しきい値をあらかじめ人が決める必要がなく、季節性や自然な成長を織り込んだうえで異常を判定する点が、Budgetsとの大きな違いです*1。
AWS Budgets — 予算のしきい値アラート
AWS Budgetsは、コストや使用量を追跡し、しきい値に応じてアクションを取るためのサービスです。作成できる予算にはコスト予算・使用量予算・リザーブドインスタンス（RI）の使用率予算・RIカバレッジ予算・Savings Plansの使用率予算・Savings Plansカバレッジ予算があります*2。目的に応じてこれらを使い分ける設計が基本です。
実績ベースと予測ベースの2種類のアラート
予算のアラートしきい値には、実績（Actual）と予測（Forecasted）の2種類があります。実績ベースは実際に発生したコストがしきい値を超えた時点で通知する方式で、予測ベースはCost Explorerの予測機能を用いて、今後しきい値を超える見込みが立った時点で事前に通知する方式です*3。しきい値は絶対値（金額）でもパーセンテージ（予算額に対する割合）でも指定できます*3。例えば200ドルの予算に対して「80％に達したら通知」と設定する場合、パーセンテージ指定なら80、絶対値指定なら160ドルを入力する形です*3。予測ベースのアラートを併用すると、実績が積み上がる前に対応を検討できる余地が生まれます。
予算情報の更新タイミングと通知の遅延
AWS Budgetsの情報は1日に3回更新され、更新は前回から8〜12時間後に行われるのが目安です*2。また、AWSのリソース利用が発生してから実際に請求データとして計上されるまでにも時間差があるため、費用が発生してから通知が届くまでにはある程度のタイムラグが生じ得るとAWSは案内しています*2。通知を受け取った時点で、実際のコストや使用量がさらに増減している可能性がある点は運用上の前提として理解しておく必要があります。
通知先とコスト集計方法の選択
通知はAmazon SNSトピック・メールアドレス・その両方に送ることができます*2。予算の作成画面では、通知の受信者としてメールアドレス（10件、カンマ区切り）とSNSトピックのARNを設定でき、AWS Chatbotと連携してSlackやAmazon Chimeのチャットルームへ通知することも可能です*4。コストの集計方法についても、ブレンドコスト・非ブレンドコスト・純非ブレンドコスト・償却コスト・純償却コストのいずれを対象とするかを選べる仕様になっており*2、複数アカウントでコミットメント割引を共有している組織か、単一アカウントでの実費用を追いたい組織かによって適した集計方法が変わります。
AWS Cost Anomaly Detection — MLによる異常検知とモニタータイプ
AWS Cost Anomaly Detectionは、機械学習モデルを用いてデプロイ済みのAWSサービスにおける異常な支出パターンを検知し、アラートを出す機能です*1。請求データの処理後、1日におよそ3回のペースで異常の監視が実行され、Cost Explorerのデータ（24時間の遅延がある）を利用する関係で、実際の利用から異常検知までに24時間程度かかる場合があります*1。新規に作成したモニターが異常検知を開始するまでには24時間程度、新しく利用を始めたサービスについては異常検知に10日分の利用実績データが必要とされています*1。
モニタータイプは4つの軸から選択
コストの評価軸として、AWSサービス・リンクされたアカウント・コスト配分タグ・コストカテゴリの4種類のディメンションが用意されています*1*5。さらに、それぞれのディメンションに対して、AWSが自動管理する「AWS managed monitors」と、利用者が対象を手動選択する「customer managed monitors」の2方式があります*5。AWS managed monitorsはディメンション内の対象（サービス・メンバーアカウント・タグ値・コストカテゴリ値）を自動的に、かつ5,000件まで個別に評価し、新しいアカウントやタグ値が追加されても自動的に監視対象へ含まれます*5。customer managed monitorsは10件まで対象を手動で選び、選んだ対象の支出を合算して評価する方式で、特定のプロジェクトやチームだけに異なるしきい値を設定したい場合に向いています*5。
Amazon Bedrock上のサードパーティ製品は対象外
Cost Anomaly DetectionはAWS Marketplace経由のサードパーティ製品・サービスを監視対象としない仕様です。これにはAmazon Bedrock上で提供されるAnthropicのClaudeモデルなど、サードパーティ製の大規模言語モデルも含まれます*1。これらの費用について異常検知に相当する備えをしたい場合は、AWS Budgetsのコスト予算で請求エンティティ（Billing entity）フィルターを使い、AWS Marketplace分の費用を個別に追跡する設計が案内されています*1。BudgetsとCost Anomaly Detectionを併用する意義の1つがこの点にあり、ML検知だけで全てをカバーできるわけではない点は運用設計上の重要な前提です。
根本原因の分析軸
検知した異常は、コストへの影響額の大きい順に、AWSサービス・AWSアカウント・リージョン・使用タイプという4つの軸に分解して根本原因を確認できます*1。異常の深刻度（Severity）は、過去の支出パターンと比較してどれだけ異常な変動かを示す指標で、単純な増加額の大小だけでなく、過去の支出が安定していたかどうかも加味して判定される仕組みです*6。
| 比較項目 | AWS Budgets | AWS Cost Anomaly Detection |
|---|---|---|
| 検知方式 | 利用者が設定した固定のしきい値（金額または割合） | 機械学習モデルによる支出パターンからの逸脱検知*1 |
| トリガー | 実績コストまたは予測コストがしきい値に到達*3 | 過去の傾向・季節性から外れた支出の発生*1 |
| 対象範囲 | コスト・使用量・RI/Savings Plansの使用率とカバレッジ*2 | AWSサービス・リンクアカウント・コスト配分タグ・コストカテゴリ*5 |
| 通知 | Eメール（10件）・SNS・AWS Chatbot*4 | 個別アラート（SNS必須）・日次サマリー・週次サマリー（Eメール）*7 |
| 向く用途 | 既知の予算枠に対する超過管理、Marketplace費用など個別追跡*1 | 想定していなかった支出増加の早期発見、根本原因の絞り込み*1 |
通知先とアラート運用（SNS/メール・頻度・受け手）
検知の仕組みを整えても、通知が届く先と頻度の設計が伴わないと、アラートは確認されないまま埋もれかねません。BudgetsとCost Anomaly Detectionでは通知の選択肢と粒度が異なるため、それぞれの特性を踏まえた設計が必要です。
Cost Anomaly Detectionのアラート頻度は3種類
Cost Anomaly Detectionのアラートサブスクリプションでは、通知頻度を個別アラート（Individual alerts）・日次サマリー（Daily summaries）・週次サマリー（Weekly summaries）の3種類から選択します*7。個別アラートは異常を検知した都度、即時に通知される方式で、1日に複数回届く可能性があり、この方式を使う場合はAmazon SNSトピックの設定が必須です*7。日次サマリーは前日に検知した上位10件の異常を影響額順にまとめてメールで送る方式で、UTC 0時を基準に生成されます*7。週次サマリーはその週に発生した複数の異常をまとめて週1回メールで送る方式です*7。即時性を重視するなら個別アラート、通知量を抑えて定期確認に回すなら日次・週次サマリーという選び方になります。
しきい値は絶対額とパーセンテージを組み合わせられる
Cost Anomaly Detectionのアラートしきい値には絶対値と割合の2種類があり、絶対値は異常の影響額（実際の支出と期待される支出の差額）が指定額を超えた場合、割合は影響額の割合が指定パーセンテージを超えた場合にアラートを発生させます*7。しきい値は2つまで設定でき、AND・ORで組み合わせることも可能です*7。しきい値を下回る小さな異常も検知自体は継続して行われ、検知結果の一覧（Detected anomalies）では確認できる仕様のため、通知を絞りつつ全体の傾向は把握できる設計になっています*7。
Amazon SNSトピックの権限設定
BudgetsやCost Anomaly DetectionからAmazon SNSトピックへ通知を送るには、SNSトピック側のアクセスポリシーで、budgets.amazonaws.comサービスプリンシパルにSNS:Publishアクションを許可する設定が必要です*4。SNSトピックはBudgetsと同一アカウント内に作成する必要があり、クロスアカウントでのSNS利用はサポートされていません*4。また、通知先としてメールアドレスを登録した場合、Amazon SNSからの購読確認メールに記載された「Confirm subscription」を受信者が承認しないと、以降の通知が届かない点にも注意が必要です*4。
受け手の設計は役割で分ける
通知の受け手は、技術的な一次対応を行う運用担当者向けと、コスト状況を把握したい管理職・経営層向けとで分けて設計するのが実務上有効です。個別アラートを運用担当者のSlackチャンネルへ即時通知し、週次サマリーを管理職向けメールに送るといった役割分担にすれば、即応性と経営可視化の両方を同時に満たせます。AWS Chatbotを利用すれば、SNSトピックをSlackやAmazon Chimeのチャットルームへマッピングし、チャット上でアラートを確認する運用も可能です*4*7。
検知後の対応フロー設計（誰が一次対応するか）
検知と通知の仕組みを整備しても、アラートを受け取った後に誰が何を確認し、どう是正するかという対応フローが決まっていなければ、通知が届くだけで対応が滞留する状態に陥りやすくなります。
一次対応者と確認手順を先に決める
Cost Anomaly Detectionのアラートには、異常の詳細ページへのリンクが含まれ、そこから根本原因分析（どのサービス・アカウント・リージョン・使用タイプが影響しているか）とコスト影響額を確認できます*1。Cost Explorer上で時系列グラフを見ながら、根本原因ごとの推移を掘り下げることも可能です*1。この確認作業を誰が行うかを事前に決めておかないと、通知の受信者全員が「誰か対応するだろう」と考えて放置されるリスクがあります。インフラ運用担当・アプリ開発担当のいずれが一次窓口になるか、エスカレーション先はどこかを役割表として明文化しておくことが望ましいでしょう。
意図した変更か、想定外の異常かを切り分ける
アラートを受け取った際にまず行うべきは、その支出増加が新機能のリリースやキャンペーンなど意図した変更に伴うものか、あるいは設定ミス・想定外の利用によるものかの切り分けです。Cost Anomaly Detectionでは検知結果に対して「Not an issue」「Accurate anomaly」といった評価（Assessment）を送信でき、この評価がモデルの検知精度向上にも活用されます*6。意図した支出であればその旨を記録し、想定外であれば次のステップに進むという判断フローを明確にしておくと、対応のばらつきを抑えられます。
是正措置と再発防止の記録
想定外の異常と判断した場合は、該当リソースの停止・設定変更・権限の見直しといった是正措置を実施し、その内容を記録に残す運用が有効です。同種の異常が繰り返し発生する場合は、Cost Anomaly Detectionのモニター粒度（サービス単位か、アカウント単位か）やBudgetsのしきい値設定自体を見直す契機にもなります。検知から通知、一次対応、是正までの一連の流れをドキュメント化しておくと、担当者が変わった場合にも運用品質を保ちやすくなります。
外注時に確認すべき設計範囲と引き継ぎの論点
コスト異常検知・予算アラートの運用設計をシステム開発会社やインフラ運用会社に外注する場合、モニターやアラートを「設定しただけ」で終わらせないための確認事項があります。
内製に必要なもの
自社でこの運用を内製するには、AWS Budgetsのしきい値設計・Cost Anomaly Detectionのモニター設計・SNS/メールの通知設計という3つの領域に加え、検知後の一次対応を担える体制が必要です。特にモニターの粒度設計（AWSサービス単位で見るか、アカウント単位で見るか、特定のコスト配分タグで見るか）は、自社のAWS利用構成やコスト管理の目的に応じた判断が求められる領域であり、単に画面の指示に従って作成するだけでは自社に合った粒度にならない場合があります。加えて、検知後にアラートを一次受けし、意図した変更か異常かを切り分けられる担当者が社内にいるかどうかも、内製の可否を左右します。
発注先への確認
提案書に「コスト監視を導入します」とだけ書かれている場合、Budgetsのしきい値をどう設定するのか、Cost Anomaly Detectionのモニタータイプ（AWS managed／customer managed、対象ディメンション）をどう選んだのか、その判断根拠まで確認する必要があります。あわせて、通知の頻度設計（個別・日次・週次のどれを採用するか）、通知先の受け手構成、検知後の一次対応を発注先が担うのか自社が担うのかという役割分担も具体的に質問し、回答の解像度を見ることが実装力を見極める手がかりになります。
契約明記の3点
契約段階では、次の3点を納品物・引き継ぎ範囲として明記しておくことが望ましいでしょう。第一に、設定したモニター・予算・アラートサブスクリプションの一覧と設定根拠をまとめた設計書です。第二に、SNSトピックのARNやアクセスポリシーなど、通知経路に関する設定情報一式です。第三に、検知後の一次対応フロー（誰が確認し、どう切り分け、どこにエスカレーションするか）を運用手順書として整備することです。これらが揃っていないまま契約が終了すると、後任の担当者が既存の設定を1つずつ確認し直すところから作業を始めることになり、追加の調査コストが発生しかねません。
コスト異常検知・予算アラートの運用は、一度設定して終わりではなく、AWSの利用構成が変わるたびにモニターの対象範囲やしきい値を見直し続ける前提の仕組みです。発注時にはこの継続運用のフェーズまで含めた体制を確認しておくことが、長期的な検知精度の維持につながります。
まとめ：コスト異常検知・アラート運用を機能させる3つの判断軸
本稿では、AWS BudgetsとAWS Cost Anomaly Detectionを用いたコスト異常検知・予算アラートの運用設計について、両者の役割の違いから通知設計、検知後の対応フロー、外注時の論点までを整理しました。要点を3つに集約すると次の通りです。第一に、Budgetsは自社で決めた固定しきい値に基づく管理であり、Cost Anomaly DetectionはMLによる異常パターンの検知であるという役割の違いを理解したうえで、両方を併用する設計が欠かせません。第二に、通知の頻度（個別・日次・週次）と受け手の役割分担を事前に設計しておかないと、アラートが届いても確認や対応が滞留しやすくなります。第三に、検知後に誰が一次対応し、意図した変更か想定外の異常かをどう切り分けるかというフローを明文化しておくことが、外注する場合も内製する場合も、運用を機能させる前提条件になります。
よくある質問
AWS BudgetsとAWS Cost Anomaly Detectionはどちらか一方だけ導入すればよいですか。
目的が異なるため、両方を併用する設計が基本です*1*2。Budgetsは決めた予算枠に対する超過管理に向いており、Amazon Bedrock上のサードパーティ製モデルなどCost Anomaly Detectionの対象外となる費用の追跡にも使えます*1。Cost Anomaly Detectionは、しきい値を人が決めなくても機械学習が通常パターンからの逸脱を検知してくれる点が異なる強みです。
Cost Anomaly Detectionを設定すればすぐに異常を検知できますか。
即座には検知できません。新規に作成したモニターは検知を開始するまでに24時間程度かかり、新しく利用を始めたサービスについては10日分の利用実績データが必要とされています*1。導入直後は検知の立ち上がりに一定の期間を要する前提で運用開始のスケジュールを組む必要があります。
通知はメールとSNSのどちらを選ぶべきですか。
用途によって使い分けます。Cost Anomaly Detectionの個別アラート（即時通知）を利用する場合はAmazon SNSトピックの設定が必須です*7。日次・週次サマリーはメールアドレスへの通知が基本で、即時性より定期確認を重視する受け手に向いています*7。運用担当者には個別アラート、管理職には週次サマリーといった役割分担も有効です。
検知後、誰が最初に対応すべきか決まっていません。どう設計すればよいですか。
通知の受信者全員に判断を委ねると対応が滞留しやすいため、一次対応者とエスカレーション先を役割表として先に明文化しておくことが有効です。一次対応者は、異常が意図した変更によるものか想定外かをまず切り分け、想定外であれば是正措置とその記録に進むという流れを事前に手順化しておくと、担当者が変わっても運用品質を保ちやすくなります。
外注する場合、どこまで運用を任せられますか。
モニターやしきい値の初期設計・構築までは外注しやすい一方、検知後の一次対応は自社の業務や利用状況を理解した担当者が関わる必要がある場合が多く、全てを任せきりにすると異常の切り分けに時間がかかることがあります。契約時には、設計書・通知経路の設定情報・一次対応フローの手順書を納品物として明記し、引き継ぎ範囲を具体化しておくことが望ましいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「Detecting unusual spend with AWS Cost Anomaly Detection」https://docs.aws.amazon.com/cost-management/latest/userguide/manage-ad.html
- *2 出典：AWS「Managing your costs with AWS Budgets」https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html
- *3 出典：AWS「Creating a cost budget」https://docs.aws.amazon.com/cost-management/latest/userguide/create-cost-budget.html
- *4 出典：AWS「Creating an Amazon SNS topic for budget notifications」https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-sns-policy.html
- *5 出典：AWS「Getting started with AWS Cost Anomaly Detection」（Monitor types）https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html
- *6 出典：AWS「Getting started with AWS Cost Anomaly Detection」（Detected anomalies overview）https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html
- *7 出典：AWS「Getting started with AWS Cost Anomaly Detection」（Creating your cost monitors and alert subscriptions）https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html
