Cost Anomaly Detection の検知を AWS FinOps Agent に調査させてみた
こんにちは、クラスメソッド運用イノベーション部の kaz です。
はじめに
いきなりですが、みなさんは Cost Anomaly Detection を設定してますか？
コストの急な上昇など、異常なコストを検知した際にアラートを飛ばしてくれる便利なサービスです。
ただ、通知内容は「どのアカウントのどのサービスがいくら増えたか」というところまでになるので、「なぜ増えたのか」を自分で調査する必要があります。
この一次調査がなかなか手間で、慣れていないと時間がかかりますよね。
そこで、本記事ではコスト異常の検知をきっかけに AWS FinOps Agent が調査レポートを作り、Slack へ投稿するところまでを実装してみます。
参考にするユースケースは以下となります。
また、少し話は逸れますが、先日 AWS のコストが過大に表示される障害が発生しました。
〇〇兆円規模という驚きの数字が出るケースもあり、前代未聞の事態でしたね。
当時は私も「やべぇ、やらかした・・・！！」と思い、かなり焦りました。。
以下の記事も個人的には印象に残っています。
あのときも Cost Anomaly Detection ではコスト異常が検知されていたので、事実確認を AWS FinOps Agent が先回りしてくれるだけでも、不安が和らぐケースはあるかもしれません。
前置きが長くなりましたが、ここからは実際に実装していきましょう！
前提条件
今回の検証環境はこちらです。
- FinOps Agent はパブリックプレビュー版（2026 年 9 月時点）
- FinOps Agent と Cost Anomaly Detection はどちらも us-east-1（バージニア北部）で設定
- 通知先は Slack チャンネル（
cost-anomaly-detection-alertというチャンネルを作成済み）
事前準備
まずは、いくつかの設定を済ませておきます。
Amazon Q Developer in chat applications（旧: AWS Chatbot）の作成
Slack に通知するため、Amazon Q Developer in chat applications（旧: AWS Chatbot）のクライアントを作成します。
クライアントの作成時に通知先が必要になるので、SNS トピックもあわせて作成しておきます。
Cost Anomaly Detection の有効化
次に、Cost Anomaly Detection のモニターを作成します。
今回はすべてのサービスを対象にした「AWS のサービス」タイプのモニターにしました。
また、アラートサブスクリプションのしきい値は、すぐに通知を検知できるように $0.10 に設定しておきます。
詳細な手順は以下を参考にしてみてください。
FinOps Agent のスペース作成
FinOps Agent のスペースを作成し、Slack チャンネルとの連携をしておきます。
やってみた
では、Cost Anomaly Detection の検知をトリガーにして FinOps Agent が自動で調査を行うよう、つなぎ込みをしていきます。
1. Slack チャンネルを接続する
FinOps Agent が Slack に調査内容を通知するには、チャンネル内に FinOps Agent を招待しておく必要があります。
問題なく招待できれば、「エージェントとアプリ」に「AWS FinOps Agent」が表示されているはずです。
2. コンテキストファイルをアップロードする
Cost Anomaly Detection の検知を受け取ったときに、どんな調査をしてほしいかを伝えるため、コンテキストファイルに記載してアップロードします。
今回は次のような Markdown を cad-investigate.md として用意しました。
報告フォーマットと判断区分に加えて「よくある変動パターン」を書いておき、想定内の変動を過度に重大視しないようにしています。
コンテキストファイル（cad-investigate.md）の全文
# 目的
このスキルは、FinOps 担当と関係する利用部門メンバーが、Cost Anomaly Detection のコスト異常検知に対するハンドリング判断と一次対応の判断を速やかに下せる状態を作ることを目的とする。
読み手は一定の知識はあるが、AWS や課金の仕組みに深くは詳しくない前提とする。
あなた（FinOps Agent）の役割は判断材料の提供であり、最終判断と対応（リソース停止、予算修正、フィードバック登録など）は人が行う。
# 前提・スコープ
- 調査対象は、受け取った Anomaly の内容と、支払い（管理）アカウントの Cost Explorer から取得できる情報に限る
- Cost Anomaly Detection は日次評価であり、検知までに最大24時間程度の遅れがある。「今まさに発生中」か「すでに終息済み」かは AnomalyEndDate の有無で判断する
# 報告内容
下記の出力フォーマットに沿ってレポートを作成する。
---------------------------------------
## サマリ（4行以内）
- 想定内変動 / 対応不要の可能性が高いか否かの見立て
- 何が検知されたか（サービスと増加要因）
- 影響範囲と影響額（アカウント / リージョン / サービス、実績額・予測額・差分）
- 一次対応の推奨アクション（判断区分から1つ）
## 検知内容の解説
- 現在も継続中か、すでに終息しているか
- 何を監視しているモニターが、どういう基準で異常と判定したか
- 増加した使用タイプ（UsageType）の意味と、通常どういう使い方で発生する費用か
- 今回のケースで実際に何が起きていると推定されるか
## 一次対応の推奨アクション（判断区分を明示）
- [即時対応必要] : 課金の停止を推奨。停止すべき対象と具体的なアクションを提示する。
不正利用が疑われる場合はセキュリティ担当への同時連携も明記する
- [要エスカレーション] : FinOps/CCoE および利用部門への引き継ぎ事項を整理する。
確認してほしい点（該当リソースの要否、いつまで必要か）を具体的に書く
- [経過観察] : 監視継続で良い理由と、再発時のトリガー条件（金額・日数）を示す
- [想定内変動の可能性高] : 根拠と、Cost Anomaly Detection へのフィードバック登録
（計画済みの作業として登録する）や閾値見直しの要否を示す
## 補足情報
- 未調査の項目と、追加で確認すべきこと
- 利用部門への確認
- CloudTrail での操作履歴の調査など
---------------------------------------
# Slack への投稿
レポートを作成したら、Slack に投稿して関係者が参照できる状態にする。
## 投稿先チャンネル名
- cost-anomaly-detection-alert
## 投稿本文の整形
以下に合わせて整形する。
- 見出し `##` は使わない。太字（`*見出し*`）と空行で区切る
- 強調は `**text**` ではなく `*text*`
- リンクは `<https://example.com|リンクテキスト>` の形式
- 1行目に判断区分と対象を置き、チャンネル一覧から判別できるようにする
例: `[要エスカレーション] 123456789012 / Amazon EC2 のコスト異常`
## メンション
- `@channel` / `@here` は使わない
- `[即時対応必要]` の場合のみ、対応主体（該当アカウントの担当者、セキュリティ担当）を個別にメンションする。
メンション先が特定できない場合はメンションせず、「担当者の確認をお願いします」と本文に記載する
# 制約
- 推測と事実を明確に区別する（「〜の可能性がある」「〜が確認できた」を使い分ける）
- 金額は通貨単位と、未確定値である旨を添えて記載する
- 専門用語には補足説明をつける
- 異常スコアの高さと影響額の大きさは別物である。少額の統計的外れ値を過度に重大視しない
# よくある変動パターン
以下は頻出する変動パターン。多くは想定内だが、必要な対応はパターンごとに異なる。
## 月初1〜3日に発生する単発のスパイク
Savings Plans / リザーブドインスタンスの前払い（All Upfront / Partial Upfront）分は
購入日に一括計上される。また月初は前月分の請求確定処理や税額の計上も重なる。
金額が購入額と一致し、翌日以降に平常値へ戻っていれば静観。
## 月末・月初の定期バッチによる一時的な増加
月次の ETL・集計処理・バックアップ等による Glue / EMR / Lambda / データ転送の増加。
前月同時期にも同様のパターンが出ていれば想定内。抑制のためモニターの閾値見直しを検討する。
## 割引適用の失効・切り替えに伴う増加
RI / Savings Plans の期間満了、またはカバレッジ低下により、
使用量が変わらないままオンデマンド料金分だけコストが上がるケース。
使用量（UsageQuantity）が横ばいであることが判別の手がかりになる。
静観ではなく、購入計画の見直しとして FinOps 担当へ引き継ぐ。
## 無料利用枠（Free Tier）の終了
アカウント作成から12か月経過後、それまで無料だった分が課金に転じる。
アカウント作成時期と一致していれば想定内。
## 新規環境の構築・負荷試験・データ移行
利用部門の計画的な作業によるもの。作業予定が確認できれば静観とし、
一時的なものか恒常的な増加かを利用部門に確認する。
## AWS Marketplace のサブスクリプション課金
年額・月額のソフトウェア課金が計上されたもの。
`RECORD_TYPE` での分解により、実使用の増加と区別できる。
アップロードが完了すると、以下のように表示されます。
3. Automations を構築する
次に機能の 1 つである「Automations」を構築します。
これによって、Cost Anomaly Detection がコスト異常を検知するたびに、自動で調査を行ってくれるようになります。
FinOps Agent の画面を開き、左メニューから「Automations」を選択します。
「Create automation」ボタンをクリックします。
「Instructions」には以下のプロンプトを入れてみました。
調査の中身はコンテキストファイル側に書いてあるので、ここでは参照先を指定するだけにしています。
Cost Anomaly Detectionの検知を受け取った場合、cad-investigate.md を参考に調査してください
また、When to run は「Run when an event occurs」を、Event trigger は「Cost Anomaly」を選択します。
ほかはデフォルトのままです。
なお、Instructions については AWS ドキュメントのガイドに以下のプロンプト例が載っているので、設定する際の参考にしてみてください。
「本番環境のモニターでコストの異常が検出された場合は、根本原因を調査し、その概要を<slack-channel>に投稿してください。」
「1,000ドルを超えるコストの異常が検出された場合は、根本原因を調査し、その結果を<slack-channel>に投稿してください。」
登録されると、こんな感じに表示されます。
また、裏では EventBridge のマネージドルールが自動的にプロビジョニングされます。
イベントパターンを見ると、Cost Anomaly Detection の Anomaly Detected イベントを受け取る形になっていることが分かります。
4. コスト異常を発生させる
つなぎ込みができたので、あとはコスト異常を起こすだけです。
今回は課金が発生するリソースとして、VPC エンドポイントを作成しました。
Cost Anomaly Detection は日次で評価されるため、検知までには最大 24 時間ほどの遅れがあります。
ここは放置して、ひたすら待ちましょう。
コスト異常が検知されると Automation がタスクを起動し、コンテキストファイルのフォーマットに沿ったレポートが Slack へ投稿されます。
5. 調査結果を確認する
1日ほど待機すると、以下のような投稿が FinOps Agent からきました。
なお、調査結果はスレッドになるようです。
おおっ！めちゃくちゃいいですね。
調査結果のサマリーや、粒度もちょうどいいです。
なお、CloudTrail の調査も行われるので、誰に確認をすればよいのかが明確になります。
また、FinOps Agent の画面からも、実行されたタスクと調査の過程を確認できますね。
まとめ
今回は、FinOps Agent で Cost Anomaly Detection の検知を調査する流れを実装してみました。
コスト異常が検知されたときに、FinOps Agent が一次調査まで済ませた状態で通知してくれるので、スムーズに実態を把握できるようになりました。
コストの調査は時間がかかるうえ、担当者以外だと状況をつかみにくいところがあります。レポートの形まで整えてくれるなら、誰が最初に気づいても同じ判断材料に乗れるのがありがたいですね。
また、Slack への報告時には、アカウントごとの担当者を記載したコンテキストファイルをアップロードしておけば、その担当者へのメンションも可能になるはずです。
このあたりは次回試してみたいと思います。
これから FinOps Agent の導入を検討されている方の参考になれば幸いです！
参考
