メインコンテンツへスキップ

コストのアノマリー

DoiT Anomaly Detection は、Google Cloud、Amazon Web Services、Microsoft Azure、Oracle Cloud Infrastructure（OCI）、Snowflake、Databricks、Datadog、OpenAI、Anthropic - Claude.ai、ClickHouse Cloud、Cloudflare、Cursor、Elastic Cloud、GitHub、Grafana Cloud、Vercel におけるコストスパイクをエンドツーエンドで監視します。

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

デフォルトでは、組織全体の請求および使用状況が監視対象となります。特定の支出サブセット（例：チーム・プロダクト・環境）を監視するために、カスタムアロケーション に対して検知を有効にすることもできます。

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

ソースデータ​

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

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

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

ベースライン期間​

アノマリー検知システムは、新規登録後すぐにデータの解析を開始します。ただし、精度の高い検知を行うには、十分な履歴データが必要です。機械学習モデルが請求データおよびリアルタイムデータに基づいて使用パターンの信頼できるベースラインを確立できるように、請求データについて 14 日間、リアルタイム使用状況データについて 4 日間 のベースライン期間を設定しています。

アノマリー検知がお客様の業務にとって重要な場合は、クラウド支出に大きな変更を加える前に、ベースライン期間が終了するまでお待ちいただくことを推奨します。ベースライン期間中は、いかなる支出もアノマリーとして分類されません。

集約レベル​

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

請求データ​

請求データについては、アノマリー検知システムは同一の請求データを使用して、SKU レベルとサービスレベルの両方でコストを評価します。SKU レベルの監視は、きめ細かくプロジェクトスコープのアラートを生成し、検出されるアノマリーの大部分を占めます。サービスレベルの監視では、サービス内のプロジェクトおよび SKU をまたいで支出を集約し、関連する複数のスパイクを 1 つのノイズが少ないアラートに統合できます。

サービスレベルの監視は、新規に作成されたプロジェクトや新しい SKU による早期のスパイクの検知にも有効です。新しいプロジェクトが作成されるか、新しい SKU がコストを発生し始めると、新しいタイムシリーズ が識別され、コストデータの収集を開始します。ただし、新しいタイムシリーズは十分な履歴データポイント がないため、最初の数日間は SKU レベルのアノマリー候補を生成しません。新しいタイムシリーズの「通常の」支出がまだ確立されていない間でも、新たに発生したコストがサービスレベルではアノマリーなスパイクを引き起こしている可能性があります。

リアルタイム使用状況データ​

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

評価スコープ​

システムによって評価されるデータサンプルは、次のように分割されます。

  • 請求アカウントごと
  • プロジェクト／アカウントごと
  • サービスごと
  • SKU ごと
  • アロケーション ごと（カスタムアロケーションの検知を有効にしている場合）

評価スコープは、集約レベルによって異なります。

  • SKU レベル：リージョンをまたいで SKU ごと・サービスごと・プロジェクト／アカウントごと
  • サービスレベル：プロジェクトおよび SKU をまたいだサービスごと

検知システムは、複数サービスのコスト合計を評価することはありません。

アロケーション​

組織全体の監視では、常に請求アカウント、プロジェクト、サービス、SKU が評価対象となります。そのスコープを調整するには、シングルルールアロケーション に対して検知を有効にしてください。システムは、そのグルーピング（例：team:platform のようなラベル）を追加のパーティションとして評価するため、SKU 全体の支出が一定であっても、使用状況の一部で発生したスパイクを検知できます。

アロケーションベースの検知は、組織全体の監視に加えて実行されます。SKU レベルの請求データのみに適用され、サービスレベルの検知やリアルタイム使用状況データには適用されません。

検知は Allocations 画面から有効にしてください。コストのアノマリーを監視する も参照してください。既存のアノマリー通知は、特定のアロケーションを対象にフィルタリング していない限り、新しいアロケーションを自動的に取り込みます。フィルタリングされている場合は、その通知設定にもアロケーションを追加してください。

基準​

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

請求データ​

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

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

  2. 1 日あたりの支出が、月次の季節性 を上回っていること。

  3. 1 日あたりの支出が、システムの normal range（または acceptable range） の上限を超えていること。

リアルタイム使用状況データ​

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

  2. 1 時間あたりの支出が、システムの normal range（または acceptable range） の上限を超えていること。

感度​

アノマリー検知システムは、直前の期間のデータで学習したタイムシリーズモデルを使用して、想定される支出を予測します。通常範囲は DoiT 固有の予測区間 によって決定されます。予測区間とは、可能な値のうち一定パーセンテージが収まると見込まれる区間の推定値です。たとえば、90% の予測区間には、新しいデータポイントが取りうる可能な値の 90% が含まれます（モデルに適合させた過去の値に基づきます）。通常範囲は、コストアノマリーチャート 上では網掛け領域として表示されます。

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

検知レイテンシ​

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

請求データ​

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

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

検知レイテンシの主な要因は、クラウドプロバイダが使用状況およびコストデータを報告する間隔が異なることです。データレイテンシ も参照してください。

リアルタイム使用状況データ​

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

動的な更新​

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

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

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

  • アクティブ期間の上限に達した場合（請求データに基づく場合は 7 日間、リアルタイム利用データに基づく場合は 3 日間）

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

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

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

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

ヒント

CloudFlow triggers を使用してコストのアノマリーへの対応を自動化できます。例えば、アノマリーが検知されたとき、そのステータスやコストが変化したとき、または確認されたときなどです。フローを開始できるイベントの全一覧については、Cost anomaly events を参照してください。

アノマリーのグループ化​

検知システムが同じコストインシデントに属する複数のアノマリー（例：同一サービスに対する SKU レベルとサービスレベルのアノマリー）を特定した場合、それらを 1 つのグループにまとめます。グループ内の各アノマリーは、自身のコスト系列を個別に追跡します。デフォルトでは、グループのプライマリアノマリーのみがコンソールに表示され、通知をトリガーします。これにより、関連するアラートによるノイズが軽減されます。

当初はサイレントだったグループ化されたアノマリーでも、その超過コストがグループで既に報告されている額と比べて有意に大きくなった場合には、表面化されたアノマリーとして昇格されます。これにより、重要なコストスパイクが、より小さなプライマリアノマリーの背後に隠れてしまうことを防ぎます。

グループメンバーは、その超過額が次のいずれかの閾値を満たすと昇格します。

  • インシデントでこれまでに報告されている最大の超過額の10 倍以上である場合

  • インシデントでこれまでに報告されている最大の超過額より1,000 米ドル以上多い場合

昇格すると、そのアノマリーはアノマリー一覧、アノマリー詳細ページ、およびダッシュボードウィジェットに表示され、自身の通知をトリガーします。昇格しても、そのアノマリーがグループから外れることはありません。グループに属したまま、独立して表示・通知されるようになります。

コンソールは、アノマリーが最初に検知されたときと、アクティブなアノマリーの継続的なメンテナンス時の両方で、グループメンバーの昇格可否を評価します。1 回の評価につき昇格されるグループメンバーは最大 1 つです。

月初のスパイク​

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

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

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

月初にコストスパイクが発生するサービス
  • Amazon API Gateway
  • Amazon CloudWatch
  • Amazon Cognito
  • Amazon DynamoDB
  • Amazon ElastiCache
  • Amazon GuardDuty
  • Amazon Managed Service for Prometheus
  • Amazon OpenSearch Service
  • Amazon Redshift
  • Amazon Rekognition
  • Amazon Relational Database Service
  • Amazon Route 53
  • Amazon Virtual Private Cloud
  • Amazon WorkSpaces
  • AWS Certificate Manager
  • AWS Data Transfer
  • AWS Elemental MediaConvert
  • AWS End User Messaging
  • AWS Identity and Access Management Access Analyzer
  • AWS Outposts
  • AWS Shield
  • Bright Data Enterprise non metered
  • Cloud Navigator
  • Cloud Speech API
  • Compute Engine
  • 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
  • Maps Static 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

FAQ​

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

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

クラウドコストのスパイクがアノマリーとして検知されなかった場合、まずそのスパイクがサービスをまたぐ SKU によって発生したかどうかを確認することが重要です。さらに、その支出がアノマリーと判定されるには、特定の条件セットを満たす必要があります。

チーム・プロダクト・その他のグルーピング単位でアノマリーを監視するにはどうすればよいですか？​

単一ルールアロケーションを使用してグルーピングを定義し、そのアロケーションに対してアノマリー検知を有効にしてください。Allocations を参照してください。

アノマリー検知はコストアラートとどのように異なりますか？​

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

  • スコープ: アノマリー検知は、個々の SKU およびサービスを監視します。また、カスタムアロケーションに対して検知を有効化することで、一部の支出のみを監視することもできます。コストアラートのスコープは、これより柔軟です。

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

  • 客観性: アラートは客観的な閾値に反応しますが、アノマリー検知ではフィッティングされた時系列モデルにより確立された、予測される支出パターンも考慮します。

一般的に、アラートの方がアノマリー検知よりも「敏感」、つまりトリガーされやすくなります。

コストアノマリーのアラートとそのレポートはどのように異なりますか？​

データ値​

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

対応するレポート（Open in Reports ボタンからアクセス）は、最新のデータを反映しており、直近のタイムステップでは値がわずかに異なる場合があります。

データの利用可能性​

アノマリー検知システムは、アラートの送信を早めるため、利用可能な中で最も新しい請求データを使用します。

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

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

インタラクティブデモを使って、ハンズオンのウォークスルーを体験してください。

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

参照
に最終更新