AWS Cost Anomaly Detection(コスト異常検出)の改善「検知の迅速化」を確かめてみた

AWS Cost Anomaly Detection(コスト異常検出)の改善「検知の迅速化」を確かめてみた

コスト異常検知の高速化を実機ログで検証。APIの時刻データは変化が確認できませんでしたが、SNSの通知ログよりローリングウィンドウによる迅速な通知が行われた痕跡が確認できました。
2025.11.25

2025年11月21日、AWS Cost Anomaly Detection(コスト異常検出)において、検出アルゴリズムのアップデートがありました。

https://aws.amazon.com/about-aws/whats-new/2025/11/aws-cost-anomaly-detection-accelerates-anomaly/

公式アナウンスによると、改良されたアルゴリズムにより「誤検知の低減」と「検知の迅速化」が実現されたとのことです。
本記事では、特性の異なる3つのAWSアカウント(検証用、大規模DB環境、Web本番環境)の実機ログを用いて、アップデート後の挙動変化および設定上の注意点を確認する機会がありましたので、紹介します。

1. 検証:APIログに見る「検知時刻」の仕様

「検知が迅速化された」のであれば、履歴データにも「何時何分に発生したか」という詳細なタイムスタンプが記録されるようになったのではないか、という仮説のもと検証を行いました。

検証環境

以下の3つの環境からデータを取得しました。

  • Account A (検証用): 一般的なリソース構成
  • Account B (大規模DB): Aurora Serverless v2 等、分単位でコストが変動する環境
  • Account C (Web本番): App Runner / CloudWatch が稼働する常時接続環境

get-anomalies の実行結果

Account C(Web本番環境)における、アップデート適用後(2025年11月22日)の異常検知データをAWS CLIで取得しました。

aws ce get-anomalies --date-interval Start=2025-11-20,End=2025-11-25

出力結果は以下の通りです。

{
    "Anomalies": [
        {
            "AnomalyId": "695265a4-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "AnomalyStartDate": "2025-11-22T00:00:00Z",
            "AnomalyEndDate": "2025-11-22T00:00:00Z",
            "DimensionValue": "AmazonCloudWatch",
            "Impact": {
                "TotalActualSpend": 5.8,
                "TotalExpectedSpend": 2.51,
                "TotalImpactPercentage": 131.08
            }
        }
    ]
}

比較として、Account B(大規模DB)におけるアップデート直前(11月18日)のデータも確認しましたが、こちらも同様の形式でした。

{
    "AnomalyId": "f676f2d1-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "AnomalyStartDate": "2025-11-18T00:00:00Z",
    ...
}

結果

3つの環境すべてにおいて、AnomalyStartDate は依然として T00:00:00Z(UTC 0時)で正規化されている ことを確認しました。

Cost Explorer API のデータ粒度が「日次(Daily)」をベースに設計されているため、バックエンドの検知エンジンがリアルタイムに近い評価を行っていたとしても、APIレスポンス上は日次バケットに丸められる仕様であると判断しました。

2. 検証:通知ログによる実検知時刻の特定

API上の記録からは変化が読み取れなかったため、実際にアラートが通知された時刻(SNS/Chatbotの着信ログ)に着目しました。
通知設定を IMMEDIATE(即時)にしている Account C において、過去2ヶ月間(2025/10/01〜11/24)の通知着信時刻(計91件)をプロットしました。

通知着信時刻の推移

期間 傾向 具体的な着信時刻例 (UTC)
Before
(10/01 〜 11/13)
バッチ的挙動
特定の時間帯に固まって通知される傾向を確認。
10/19 05:00
10/22 06:00
10/28 22:00〜23:00 (集中)
After
(11/14 〜 11/24)
分散・リアルタイム化
定期チェックに加え、任意の時間帯での検知が発生。
11/14 01:00, 04:00
11/21 09:00 (Update発表日)
11/23 02:00

考察

11月21日の 09:00 UTC や、11月23日の 02:00 UTC といった時刻は、従来の日次集計バッチのリズムとは明らかに異なります。このログより、データ到達とともに評価が走り、即座に通知トリガーが引かれていることが裏付けられました。

また、公式発表は11月21日ですが、ログ上は11月14日頃から通知パターンの変化を確認しました。バックエンドでは段階的なロールアウトが行われていたと推測されます。

3. 設定変更の検証(メール通知の制約)

アップデートによる「迅速な検知」の恩恵を受けるためには、サブスクリプションの通知頻度(Frequency)が IMMEDIATE である必要があります。
設定が DAILY であった Account A に対して、CLIで設定変更を試みました。

aws ce update-anomaly-subscription \
    --subscription-arn "arn:aws:ce::XXXXXXXXXXXX:anomalysubscription/..." \
    --frequency IMMEDIATE

実行の結果、以下のエラーが発生しました。

An error occurred (ValidationException) when calling the UpdateAnomalySubscription operation: 
Immediate frequencies only support SNSTopic subscriptions

エラー原因と対策

エラーメッセージの通り、「IMMEDIATE(即時通知)」は、通知先がSNSトピックの場合のみサポートされています。

メールアドレスを直接登録している場合、DAILY(日次)または WEEKLY(週次)しか選択できません。この構成のままでは、検知自体が高速化されても、通知は翌朝のサマリーメールまで遅延することになります。

対策として、以下の構成変更を実施しました。

  1. Amazon SNS トピックを作成し、メールアドレスをサブスクライブする。
  2. Cost Anomaly Detection の通知先を、作成したSNSトピックに変更する。
  3. 通知頻度を IMMEDIATE に設定する。

まとめ:予期せぬ料金増加の把握と初動のために

AWS Cost Anomaly Detection は、予期せぬ料金増加を素早く把握する上で非常に有効であり、今回のアップデートはその価値を大きく高めています。

検証で確認された事実

  • 迅速化は達成済: APIログの T00:00:00Z は変わらずとも、通知ログの分析によりローリングウィンドウによる迅速な検知が機能していることが証明されました。
  • 最大の課題: メールアドレスへの直接配信(DAILY設定)では、検知が高速化されても通知が遅延します。

迅速な初動のために今すぐすべき確認事項

特にコスト異常に対して素早い初動、すなわち「検知されたその日のうちに、サービス停止やリソースの縮退といった対応を取る」必要がある場合、以下の確認と見直しを強く推奨します。

  1. 現在の設定の確認:

    aws ce get-anomaly-subscriptions
    
  2. 設定が不適切な場合:

    もし FrequencyDAILY または WEEKLY の場合は、検知が高速化されていても通知が翌日以降に遅延するため、IMMEDIATE への変更と、通知方法の見直しを検討する事をおすすめします。

    特に、メールアドレスを通知先としている場合は、IMMEDIATE に変更しようとすると ValidationException で弾かれます。このため、SNSトピックを経由する構成への移行をご検討ください。

この記事をシェアする

FacebookHatena blogX

関連記事