メインコンテンツまでスキップ

コストアノマリー

DoiT Anomaly Detection（異常の検出）は、Google Cloud、Amazon Web Services、Microsoft Azure、Snowflake、Databricks、Datadog、OpenAI におけるコストスパイクをエンドツーエンドで監視します。

本検出サービスは、時系列モデリング を活用してデータを監視し、クラウド環境における支出のトレンドを分析します。DoiT 顧客全体の請求パターンを特定し、クラウド支出を予測し、より正確な結果を提供できるよう継続的に改良されています。確立された支出行動と一致しない請求レコードは、潜在的なアノマリーとして識別されます。DoiT コンソールは、寄与リソースの一覧 や AI 分析 など、必要に応じて調査と是正措置の実施を支援する詳細情報を提供します。

以下のセクションでは、DoiT Anomaly Detection の仕組みを説明します。

取得データ​

DoiT Anomaly Detection は、次の 2 種類のソースデータをサポートします。

  • ■ 請求データ：クラウドプロバイダおよびサードパーティプラットフォームによるコストと使用量データ。例：AWS CUR、Google Cloud の Billing データエクスポート、Azure の billing export など。

  • ■ リアルタイム使用量データ：ほぼリアルタイムのコストアノマリー検出のため、DoiT はリアルタイム使用量データを活用して、以下のサービスのコストを推定します。

ベースライン期間​

アノマリー検出システムは、新規登録後すぐにデータの分析を開始します。ただし、正確な検出には十分な過去データが必要です。機械学習モデルが請求データとリアルタイムデータそれぞれに基づく使用パターンの信頼できるベースラインを確立できるよう、請求データは 14 日間、リアルタイム使用量データは 4 日間をベースライン期間として設定しています。

運用上アノマリー検出が重要な場合は、クラウド支出に大きな変更を加える前に、このベースライン期間が経過するまでお待ちいただくことをおすすめします。ベースライン期間中は、いかなる支出もアノマリーとして分類されません。

集計レベル​

アノマリー検出システムは、時系列モデルを用いて、コストと使用量データを SKU レベルとサービスレベルの両方で監視・評価します。過去のパターンを分析し、現在の使用トレンドと比較することで、顕著なコストスパイクを検出するよう設計されています。アノマリーなコストスパイクを検出すると、アノマリーアラート がトリガーされます。

請求データ​

請求データについては、解決までの時間を短縮するため、アノマリー検出システムは主として SKU レベルで動作します。つまり、検出されるコストアノマリーの多くは SKU レベルのアノマリーとなります。

サービスレベルでの監視は、主に新規プロジェクトや新しい SKU によって生じる初期スパイクに対処する補完的な役割を担います。新しいプロジェクトが作成された場合や新しい SKU のコストが発生し始めた場合、新しい時系列 が識別され、コストデータの収集が始まります。しかし、十分な過去データポイント がないため、最初の数日間は SKU レベルのアノマリー候補が生成されません。「通常」の支出が新しい時系列でまだ確立されていない間でも、新たに発生したコストがサービスレベルでアノマリーなスパイクを引き起こす可能性があります。

リアルタイム使用量データ​

2025 年 5 月 21 日以降、時間単位の粒度をもつリアルタイム使用量データ向けのアノマリー検出システムは、高解像度サンプリングに起因するノイズを軽減するため、サービスレベルのみにて動作します。

評価範囲​

システムが評価するデータサンプルは、次のとおり分割されます。

  • 請求アカウント単位
  • プロジェクト／アカウント単位
  • サービス単位
  • SKU 単位
  • アロケーション単位（該当する場合）

評価範囲は集計レベルによって異なります。

  • SKU レベル：SKU 単位、サービス単位、プロジェクト／アカウント単位（リージョンをまたいで）
  • サービスレベル：サービス単位（プロジェクトおよび SKU をまたいで）

検出システムは、複数サービスの合算コストは評価しません。

判定基準​

誤検知を抑制するため、アノマリー検出システムは、以下のすべての条件を満たした場合にのみ、SKU またはサービスの支出をアノマリーとして分類します。

請求データ​

  1. 1 日あたりの支出が最小閾値に達していること：

    • SKU レベルのアノマリー：US$50

    • サービスレベルのアノマリー：US$100

  2. 1 日あたりの支出が月次の季節性を超えていること。

  3. 1 日あたりの支出が、システムの「通常範囲」（または「許容範囲」）の上限を超えていること。

リアルタイム使用量データ​

  1. 1 時間あたりの支出が US$10 の最小閾値に達していること。

  2. 1 時間あたりの支出が、システムの「通常範囲」（または「許容範囲」）の上限を超えていること。

感度​

アノマリー検出システムは、直前期間のデータで学習した時系列モデルを用いて、想定支出を予測します。通常範囲は DoiT 固有の予測区間によって決定されます。これは、あるパーセンテージの値が収まると見込まれる区間の推定です。例えば、90% の予測区間には、モデルが当てはめた過去の値に基づき、新しいデータポイントが取り得る可能値の 90% が含まれます。通常範囲は、コストアノマリーチャート上でシェーディングされた領域として表示されます。

DoiT コンソールでは、アノマリー感度の設定を調整して予測区間を変更し、通常範囲を再定義できます。感度を高くすると範囲が狭まり、検出されるアノマリーの数が増え、感度を低くすると範囲が広がり、検出数は減少します。

検出レイテンシ​

検出レイテンシは、ソースデータの種類によって異なります。

請求データ​

多くの場合、集計コストが所定の閾値を超えると、請求データのアノマリーは 12 時間以内に報告されます。

アノマリー検出エンジンは、一定間隔で使用量およびコストデータを評価します。SKU レベルのアノマリーについては毎時、サービスレベルのアノマリーについては 6 時間ごとに評価が実行されます。

検出レイテンシは主に、クラウドプロバイダが使用量およびコストデータを報告する間隔の違いに関連します。あわせて データレイテンシ もご参照ください。

リアルタイム使用量データ​

アノマリー検出エンジンは、リアルタイム使用量データを 30 分ごとに評価します。リアルタイム使用量データで検出されたアノマリーは、使用から 1 時間以内に報告されます。

動的な更新​

進行中のアノマリーは Active と見なされます。検出システムは、アクティブ なアノマリーを継続的に監視し、利用可能な最新データでシステムを更新し続けます。

以下のいずれかの条件を満たすと、アノマリーは Inactive になります。

  • コストが新しい通常範囲に戻った場合

  • アノマリーが最大アクティブ期間に達した場合（請求データに基づく場合は 7 日間、リアルタイム使用状況データに基づく場合は 3 日間）

アノマリーが Active および Inactive になるタイミングの詳細は、コストアノマリーチャートをご参照ください。

コストアノマリーのアラート​

アノマリーが検出されると、システムは請求アカウント・サービス・プロジェクト ID を確認し、同じコンテキストに対して既に他のアラートが送信されていない場合にのみアラートがトリガーされるようにします。

つまり、同じサービスに対して、SKU レベルのアラートが送信された場合はサービスレベルのアラートは送信されません。逆も同様です。

月初のスパイク​

一部のサービスでは月初の 1 日にまとめて請求が行われるため、月の他の日に比べて不釣り合いなコストスパイクが発生します。ただし、その金額が過去数カ月と同程度であれば、アノマリーとは見なされません。

精度向上のため、月初のコストを評価する際、アノマリー検出モデルは日次のコストモデリングに加えて月次比較も実施します（ほぼリアルタイムのアノマリー検出は、より短期間で詳細な評価を行うため、月次の季節性は考慮しません）。

以下は評価対象のサービス一覧です。

月初にコストスパイクが発生するサービス
  • Amazon Cognito
  • Amazon DynamoDB
  • Amazon ElastiCache
  • Amazon OpenSearch Service
  • Amazon Redshift
  • Amazon Relational Database Service
  • Amazon Route 53
  • Amazon WorkSpaces
  • AWS Certificate Manager
  • AWS Data Transfer
  • AWS Elemental MediaConvert
  • AWS Identity and Access Management Access Analyzer
  • AWS Outposts
  • AWS Shield
  • Bright Data Enterprise non metered
  • Cloud Navigator
  • Compute Engine（一部の SKU）
  • Contact Center Telecommunications（service sold by AMCS, LLC）
  • Coralogix
  • Datadog
  • Datadog Pro
  • Directions API
  • Drata Security & Compliance Automation Platform
  • Fastly for GCP Marketplace
  • Geocoding API
  • Geolocation API
  • Grafana Cloud observability: Grafana, Prometheus metrics, logs, traces
  • HYCU R-Cloud™ Platform
  • Identity Platform
  • JFrog DevOps Platform - Enterprise X
  • JFrog Software Supply Chain Platform
  • Looker Studio
  • Maps API
  • Office LTSC Professional Plus 2021
  • Places API
  • Plerion Cloud Security Platform（Contract）
  • Snyk: Developer Security Platform
  • Twilio Segment
  • Vantage Cloud Cost Platform - Enterprise
  • WIZ Cloud Infrastructure Security Platform

▶️ インタラクティブデモ​

操作しながら学べるインタラクティブデモをお試しください。

デモが正しく表示されない場合は、ブラウザウィンドウを拡大するか、新しいタブでデモを開いてお試しください。

参照してください

FinOps Foundation: Managing Cloud Cost Anomalies

よくある質問（FAQ）​

なぜ自分のコストのスパイクがアノマリーとして報告されなかったのですか？​

アノマリー検出システムは、SKU レベルとサービスレベルの 2 つのレベルでコストを評価します。複数のサービスにまたがる複数 SKU の合算コストは評価しません。

クラウドコストのスパイクがアノマリーとして検出されなかった場合、まずそのスパイクがサービスを跨いだ SKU によるものかを評価することが重要です。加えて、支出はアノマリーと認定されるために特定の条件セットを満たす必要があります。

アノマリー検出はコストアラートとどう違いますか？​

アノマリー検出は、次の点でコストアラートと異なります。

  • 概要（Scope）：アノマリー検出は個々の SKU およびサービスを監視しますが、コストアラートの範囲はより柔軟です。

  • 条件（Condition）：アラートをトリガーする条件は単一の閾値です（例：週次コストが 5% 増加）。これに対し、アノマリーとして分類されるには、コストが複数の基準を満たす必要があります。

  • 客観性（Objectivity）：アラートは客観的な閾値に反応しますが、アノマリー検出は当てはめた時系列モデルによって確立された想定支出行動も考慮します。

一般に、アラートはアノマリー検出よりも「敏感」で、トリガーされやすい傾向があります。

コストアノマリーのアラートは、そのレポートとどう違いますか？​

データ値​

コストアノマリーのアラートに含まれるチャートは、検出時点の請求データをスナップショットで提供します。

対応するレポート（Open in Reports ボタンからアクセス）では、最新のデータが反映され、直近のタイムステップで僅かな差異が生じる場合があります。

データの可用性​

アノマリー検出システムは、アラートを迅速化するため、利用可能な最新の請求データを使用します。

レポートは、より詳細なテーブルを使用するため追加の処理を要し、データの可用性に遅延が生じます。その結果、アラートをトリガーした請求データが、アラート送信時点では一時的にレポートで利用できない場合があります。

に最終更新