Billing AlertとCost Monitoringを改善する

既存環境のコストを分析できても、

高額になった後で
初めて気付く

状態では、コスト管理として不十分です。

例えば、通常は1日3〜4万円程度のワークロードが、

通常
3〜4万円 / 日

突然
15万円 / 日

となった場合、月次Budgetにはまだ余裕があっても、通常とは異なる支出が発生しています。

一方、

月末バッチ
季節イベント
計画済みキャンペーン
事業成長

によって支出が増えることが通常であれば、単純な固定しきい値だけでは不要なAlertが増える可能性があります。

そのため、

Expected Usage
↓
何を正常とみなすか
↓
何との差を検出したいか
↓
Threshold
↓
監視方式
↓
Alert

として考えます。

ゴール

既存環境の監視要件を、

Expected Usage
↓
何を検出したい？
│
├─ 計画したBudgetとの差
│   → AWS Budgets
│
├─ 現在の推定料金と固定額との差
│   → Billing Alarm
│
└─ 通常の支出パターンとの差
    → Cost Anomaly Detection
↓
意味のあるThreshold
↓
Alert

へ整理できることがゴールです。

AWS Budgetsの基本的な作成方法やBudget Actionによる制御ではなく、予想される使用パターンから監視の不足を特定し、適切な監視方式を選ぶことに集中します。

1. まずExpected Usageを確認する

Thresholdを先に決めるのではなく、通常どのような使用量・支出になると予想されるかを確認します。

例えば、

平日
3万円 / 日

週末
1万円 / 日

月末バッチ
+10万円

通常月
80〜100万円

という環境なら、

月末に一時的に支出が増えた

だけでは異常とは判断できません。

一方、

通常
3万円 / 日

今回
12万円 / 日

なら、月次Budgetを超えていなくても調査対象になる可能性があります。

2. Expected Usageは単一の金額とは限らない

予想される使用パターンには、

曜日

月初 / 月末

営業時間

定期バッチ

季節性

事業成長

計画済みイベント

などが含まれます。

例えば、

毎週月曜日は
通常の2倍の処理量

という環境で、

月曜日にコスト増加
=
異常

と判断すると、正常な処理でもAlertが発生し続ける可能性があります。

したがって、「いつもより高い」ではなく、そのワークロードで予想される使用パターンから外れているかを確認します。

3. Thresholdは「何との差か」で意味が変わる

同じThresholdでも、比較対象によって意味が異なります。

例えば、

Budget
100万円

Alert
80%

なら、

計画したBudget
との比較

です。

一方、

推定料金
8,000 USD超

をBilling Alarmで監視する場合は、

CloudWatch Billing の EstimatedCharges メトリクスの通貨単位はUSDです。Billing Alarmのしきい値はUSDで設定します。

現在の推定料金
との固定額比較

です。

Cost Anomaly Detectionでは、

通常予想される支出
対
実際の支出

の差から異常を評価します。

したがって、

Thresholdはいくら？

だけでなく、

何との差を
監視するThresholdなのか？

を先に確認します。

4. AWS Budgetsは「計画との差」を監視する

AWS Budgetsでは、あらかじめ決めたBudgetに対して、

実際のコストや使用量

または

予測されるコストや使用量

がどの位置にあるかを監視できます。

ここで重要なのは細かな設定手順ではなく、

会社やシステムとして
計画した値

対

実際 / 予測

という比較です。

例えば、

月次Budget
100万円

月末予測
115万円

なら、通常の支出パターンかどうかとは別に、計画したBudgetを超える見込みとして監視できます。

5. Budget超過とAnomalyは別の判断

次の状態を考えます。

Budget
100万円

Expected Spend
115万円

Actual Spend
115万円

事業成長や計画済みイベントによって、115万円が現在の正常な支出パターンになっているとします。

この場合、

Actual Spend
=
Expected Spend

なので、支出パターンとしては異常ではない可能性があります。

しかし、

115万円
>
Budget 100万円

なので、計画上は超過です。

つまり、

Budget超過
≠
Anomaly

です。

このような場合は、異常検出だけではなく、AWS Budgetsによる計画額監視が必要です。

6. Billing Alarmは「現在の推定料金」と固定額を比較する

CloudWatch Billing Alarmは、

現在の推定AWS料金
対
固定Threshold

を監視するために利用できます。

例えば、

推定料金
8,000 USD超
↓
Alarm

という要件です。

Billing Alarmは、

今月末には
いくらになるか

というBudget予測ではありません。

また、

通常パターンから
異常に外れたか

を学習して判断する仕組みでもありません。

決定打は、現在の推定料金が固定額を超えたかです。

7. Billing AlarmだけではExpected Usageとの差を判断できない

例えば、

Billing Alarm
10,000 USD

を設定している環境で、

通常
2,000 USD

現在
6,000 USD

まで急増したとします。

固定Thresholdでは、

6,000 USD
<
10,000 USD

なのでAlarmは発生しません。

しかし通常2,000 USD程度の環境なら、

2,000 USD
↓
6,000 USD

は大きな変化です。

つまりBilling Alarmだけでは、固定Thresholdには達していないが、通常パターンから大きく外れた支出を見逃す可能性があります。

8. Cost Anomaly Detectionは通常パターンとの差を見る

AWS Cost Anomaly Detectionは、機械学習を利用して過去の支出パターンを評価し、

Expected Spend
対
Actual Spend

の差から異常を検出します。

例えば、

Expected Spend
20万円

Actual Spend
35万円

なら、

Cost Impact
15万円

です。

そのため、

Budgetはまだ未超過

Billing Alarmの固定額にも未到達

しかし通常の支出パターンからは大きく外れている

という状態を検出する用途に適しています。

9. 正常な周期変動と異常を分ける

通常の利用パターンには、

毎週月曜日だけ高い

毎月末に処理量が増える

季節イベントで増加する

事業成長に合わせて徐々に増える

といった変化があります。

そのため、

昨日より高い

だけで異常とは判断しません。

Cost Anomaly Detectionでは、過去の支出パターンを基にExpected Spendを評価するため、

通常の周期的変動

と、

予想されていない支出増加

を区別する助けになります。

10. Anomalyの検出とAlertは分けて考える

小さな異常をすべて通知すると、

小さな変動
↓
Alert

小さな変動
↓
Alert

となり、本当に重要な通知が埋もれる可能性があります。

したがって、

Anomalyを検出
↓
コスト影響を評価
↓
意味のあるThreshold
↓
Alert

と考えます。

つまり、異常として検出されたことと、通知すべき重要度であることは同じではありません。

11. 3種類の監視は比較対象が異なる

例えば、

月次Budgetを
超える見込み
↓
AWS Budgets

推定料金が
8,000 USDを超えた
↓
Billing Alarm

通常20万円程度なのに
突然40万円
↓
Cost Anomaly Detection

のように判断します。

12. 1種類だけでは監視の穴が残る

AWS Budgetsだけの場合

Budget
100万円

現在
40万円

なら、計画額には余裕があります。

しかし同時期のExpected Spendが、

20万円

なら、40万円への増加は異常かもしれません。

Billing Alarmだけの場合

固定Threshold
10,000 USD

現在
6,000 USD

ならAlarmは発生しません。

しかし通常2,000 USDなら、大きな変化を見逃す可能性があります。

Cost Anomaly Detectionだけの場合

Expected Spend
120万円

Actual Spend
120万円

Budget
100万円

なら、異常ではなくても計画額を超えています。

したがって、

計画との差

固定額との差

通常パターンとの差

のうち、何を監視する必要があるかを確認します。

13. ThresholdはExpected Usageから決める

Thresholdが低すぎると、

正常な変動
↓
Alert
↓
正常な変動
↓
Alert

となります。

一方、高すぎると、

異常発生
↓
支出拡大
↓
ようやくAlert

となります。

そのため、

Expected Usage

通常の変動幅

計画額

異常時のCost Impact

Alert後に対応できる時間

を考慮してThresholdを決めます。

重要なのは、最も低いThresholdではなく、監視目的に対して意味のあるThresholdを選ぶことです。

14. Alertはリアルタイムの支出上限ではない

コスト監視のAlertは、

支出を検知
↓
通知
↓
確認

するための仕組みです。

絶対に100万円を超えない

リソース作成時点で必ず拒否する

といったリアルタイムの強制上限とは役割が異なります。

したがって、

Billing Alarm

AWS Budgets Alert

Cost Anomaly Detection Alert

を設定しただけで、支出そのものが即座に停止すると判断してはいけません。

ここでは監視と通知までを扱います。

15. 既存監視の不足を見つける

既存環境が、

Billing Alarmだけ

なら、

固定Threshold未満だが
通常パターンから外れた支出

を見逃す可能性があります。

AWS Budgetsだけなら、

Budget未満だが
通常とは異なる急増

を見逃す可能性があります。

Cost Anomaly Detectionだけなら、

異常ではないが
計画Budgetを超える支出

を代替できません。

そこで、

何を検出したい？
↓
計画超過？
固定額超過？
通常パターンとの差？

から、現在の監視に不足している方式を特定します。

16. Billing Alert / Cost Monitoringの改善フロー

既存の監視方式を確認
↓
Expected Usageを確認
↓
正常な変動を確認
↓
何との差を検出したい？
│
├─ 計画したBudgetとの差
│   ↓
│ AWS Budgets
│
├─ 現在の推定料金と固定額との差
│   ↓
│ Billing Alarm
│
└─ 通常の支出パターンとの差
    ↓
  Cost Anomaly Detection
↓
意味のあるThreshold
↓
Alert
↓
影響と原因を調査

17. この段階では改善施策そのものを選ばない

Alertによって、

Amazon EC2のコストが
急増している

と分かっても、この段階では、

Rightsizing

Savings Plans

Spot

リソース削除

ネットワーク変更

のどれを実行するかまでは決めません。

まず、

異常 / 超過を検出
↓
影響を確認
↓
原因を分析

します。

その分析結果を基に、具体的なコスト改善策を判断します。

混同ポイント

SAP-C02での判断

既存環境のBilling AlertとCost Monitoringを改善するときは、

Expected Usageは？
↓
正常な変動は？
↓
何との差を検出したい？

と考えます。

計画したBudgetとの差
↓
AWS Budgets

現在の推定料金と
固定額との差
↓
Billing Alarm

通常の支出パターンとの差
↓
Cost Anomaly Detection

です。

決定打は、単にAlertを増やすことではなく、Expected Usageを基準に、どの差を検出したいのかを明確にして監視方式とThresholdを選ぶことです。

まとめ

Billing AlertとCost Monitoringを改善するときは、まずExpected Usageを確認します。

Expected Usageには、

通常使用量
通常コスト
曜日
季節性
定期処理
成長傾向

などが含まれます。

AWS Budgetsは、

計画したBudget
対
実際 / 予測

を監視します。

Billing Alarmは、

現在の推定料金
対
固定Threshold

を監視します。

Cost Anomaly Detectionは、

Expected Spend
対
Actual Spend

から通常パターンとの差を検出します。

したがって、

Expected Usage
↓
監視したい差
↓
Threshold
↓
AWS Budgets
Billing Alarm
Cost Anomaly Detection
↓
Alert

という順序で判断します。