導入
コストを最適化する前に、「今どこにいくら使っているか」が見えていなければ話になりません。AWSにはコストを可視化するための道具が複数あり、目的によって使い分けます。
説明
コスト可視化の代表的なサービスを、目的別に整理します。
| サービス | 何をするか | 使いどころ |
|---|---|---|
| Cost Explorer | 過去のコスト・使用量をグラフで可視化、将来予測 | 「先月どのサービスにいくら使ったか」を見る |
| AWS Budgets | 予算を設定し、閾値超過でアラート通知 | 「今月の予算を超えそうなら通知したい」 |
| Cost and Usage Report（CUR） | 最も詳細な請求データをS3へ出力 | Athena/QuickSightで独自の詳細分析をしたい |
| Cost Anomaly Detection | 機械学習で異常なコスト増加を自動検知 | 「急にコストが跳ねたらすぐ気づきたい」 |
flowchart LR
B["請求データ"] --> CE["Cost Explorer<br/>（傾向を見る・予測する）"]
B --> BU["Budgets<br/>（閾値超過を通知）"]
B --> CUR["CUR → S3<br/>（Athena/QuickSightで詳細分析）"]
B --> AD["Cost Anomaly Detection<br/>（異常を自動検知）"]
粒度で見ると、Cost Explorer は「傾向をざっくり見る」、CUR は「1行単位の明細を自分で分析する」という関係です。SAPでは「経営層に月次レポートを見せたい」なら Cost Explorer、「サービス・タグ単位で細かく按分計算したい」なら CUR、というように問題文の要求粒度で使い分けを判断させる問題が出ます。
異常検知については、Budgets が「決めた閾値を超えたら通知」という静的な仕組みなのに対し、Cost Anomaly Detection は過去のパターンから機械学習で「いつもと違う」を検知する点が違います。「想定外の急増を早期に検知したい」という要件には Anomaly Detection が最適です。
具体例
コスト管理の4ツールを、動詞と粒度で使い分けます。ある企業の運用：
- 「月末に、どのサービスにいくら使ったか経営に報告したい」→ Cost Explorer（傾向をグラフで見る・予測する）
- 「今月の予算15万円を超えそうなら通知してほしい」→ Budgets（決めた閾値の静的監視）
- 「タグ・サービス単位で1行ずつ細かく按分計算したい」→ CURをS3へ出力し、Athena/QuickSightで分析
- 「設定漏れやバグでいきなり跳ねたら即気づきたい（閾値は決めていない）」→ Cost Anomaly Detection（機械学習でいつもと違うを検知）
引っ掛けはBudgetsとAnomaly Detectionの違い。「決めた閾値」ならBudgets、「想定外の急増を早期に」なら機械学習のAnomaly Detection。またCost ExplorerとCURの粒度——ざっくり傾向はExplorer、1行単位の明細分析はCUR。「動詞（見る/通知/明細分析/異常検知）」と「粒度」で選びます。
読んでみよう
「予算超過を事前に防ぎたい」→ Budgets、「異常な使用量の急増を自動検知したい」→ Cost Anomaly Detection、「詳細な明細を自分たちで分析基盤に取り込みたい」→ CUR、というキーワード対応を押さえておくと、コスト可視化系の問題は素早く解けます。