Cost ModelingとAWS Cost Tools

ゴール

この内容を終えた時点で、

業務上の需要
↓
使用量
↓
コストドライバー
↓
見積り / 予測
↓
TCO

という流れでAWSコストをモデル化し、

AWS Pricing Calculator
AWS Cost Explorer
AWS Trusted Advisor

などから得られる情報を、

そのまま答えとして使う

のではなく、

コストモデルの入力

として使えることがゴールです。

1. コストモデルは業務需要から始める

最初からAWSサービス料金を並べるのではなく、

何が利用量を増減させるのか

から考えます。

例えばECサイトなら、

利用者数
↓
注文数
↓
APIリクエスト数
↓
DB読み書き
↓
ログ量
↓
保存データ量
↓
データ転送量

のように、業務上の需要をAWS上の使用量へ変換します。

このとき、

利用者数
注文数
取引件数
ファイル数
保存期間
1件あたりデータ量

などが、コスト変化の起点になります。これらをコストドライバーとして扱います。

重要なのは、

AWSサービス
↓
料金

から始めるのではなく、

業務需要
↓
技術的な使用量
↓
課金対象
↓
コスト

とつなぐことです。

2. コストドライバーと課金対象を分ける

例えば、

月間注文数

自体がAWSの請求項目になるとは限りません。

注文数が増えた結果、

リクエスト数
実行時間
データベースアクセス数
保存量
ネットワーク転送量

などが変化します。

つまり、

業務コストドライバー
↓
AWS使用量
↓
料金計算

という段階があります。

例えば、

月間利用者数
        ↓
1人あたり平均20 APIリクエスト
        ↓
総APIリクエスト数
        ↓
平均処理量 / 保存量 / 転送量
        ↓
AWS使用量

のようにモデル化します。

この変換関係が間違っていると、料金単価が正しくても見積りは外れます。

3. 固定的な部分と使用量に連動する部分を分ける

コストモデルでは、

需要が変わっても
分析期間中ほぼ変わらない部分

と、

使用量に応じて増減する部分

を分けます。

概念的には、

総コスト
=
固定的に発生する部分
+
使用量に応じて変化する部分

です。

ただし、AWS料金をすべて単純な固定費・変動費の2種類へ分類できるわけではありません。

実際には、

一定量までは同じ
↓
ある点で増える

使用量の階層で単価が変わる

契約条件によって料金が変わる

などがあります。

したがって、

使用量2倍
=
総コストも必ず2倍

とは限りません。

重要なのは、

何が需要に比例して変化するか
何が一定範囲では変わらないか

をモデル上で分けることです。

4. 月間平均だけでは使用量パターンを表せない

同じ月間リクエスト数でも、発生方法によって必要な構成は変わります。

例えば、

月間7200万リクエスト

でも、

24時間ほぼ一定

なのか、

毎日2時間だけ集中

なのかでは使用量パターンが違います。

コストモデルでは、

平常時
ピーク
ピーク継続時間
稼働時間
停止時間
成長率
季節性

を分けます。

例えば、

平常時
100 req/s

キャンペーン時
1000 req/s

キャンペーン
月4回 × 2時間

なら、

1000 req/s
×
1か月すべて

として計算すると過大評価になります。

逆に、

月間平均だけ

を見ると、ピーク時に必要なキャパシティを見落とす可能性があります。

つまり、

平均
+
ピーク
+
継続時間
+
頻度

を一緒に扱います。

5. 「単価が高いもの」ではなく「総額を動かすもの」を見る

コストドライバーは、

単価が最も高い項目

とは限りません。

例えば、

項目A
単価は高い
使用量は少ない

項目B
単価は低い
使用量が非常に多い

なら、総コストへの影響は項目Bの方が大きい場合があります。

見るべきなのは、

使用量
×
料金条件

による総額への影響です。

さらに、

どの入力値が少し変わるだけで
総コストが大きく変化するか

も確認します。

例えば、

保存期間
30日 → 90日

で総コストが大きく変わるなら、

保存期間

は重要なコストドライバーです。

6. 感度分析で重要な仮定を見つける

すべての仮定を同じ精度で調査する必要はありません。

例えば、

月間利用者数
±20%

平均データサイズ
±20%

保存期間
±20%

と値を変えたとき、

保存期間だけで
総コストが30%変化する

なら、保存期間の仮定を優先して精査します。

考え方は、

入力値を変化
↓
総コストへの影響を見る
↓
影響が大きい仮定を特定
↓
精度を上げる

です。

この方法によって、

コストモデルの精度を左右する項目

へ調査時間を集中できます。

7. 既習の見積りと予測を1つのモデルへ統合する

見積りと予測の役割そのものではなく、

複数の入力を
どう重複なく1つの将来コストへ統合するか

を考えます。

例えば既存環境を変更する場合、

既存環境の将来基準
+
新しく追加する構成
-
廃止する構成
+
新しい事業需要による増分

という形で整理できます。

重要なのは、

既存環境
変更対象
新規追加
廃止予定
需要増分

を分離することです。

例えば、

既存構成の将来コスト
100万円

廃止予定の構成
-20万円

新構成
+15万円

キャンペーンによる追加使用量
+10万円

なら、

100 - 20 + 15 + 10
= 105万円

とします。

特に注意するのが二重計上です。

新構成の見積りにキャンペーンでの利用量増加をすでに含めているなら、その同じ需要増分を別項目としてもう一度加えてはいけません。

どの需要を
どの入力が担当しているか

まで明確にします。

8. 過去傾向と事業上の変化を組み合わせる

例えば、

過去6か月
利用量ほぼ一定

だったとしても、

来月
全国キャンペーン開始
↓
注文数2倍見込み

が分かっているなら、過去傾向だけを将来予測として使うのは不十分です。

モデルでは、

既存ワークロード
↓
過去傾向から基準を作る

既知の事業イベント
↓
注文数 / ユーザー数などから
追加使用量をモデル化

両方
↓
将来コスト

とします。

ただし、

同じ使用量を
予測と見積りの両方へ入れる

と二重計上になるため注意します。

9. AWSコストツールの出力に含まれる前提を管理する

既習のAWSコストツールをコストモデルへ取り込むときは、

どのツールか

だけでなく、

その数値が
どの範囲と仮定を表しているか

を記録します。

例えば、

月額50万円

という数字だけをモデルへ入れても、

何を含んだ50万円なのか

が分からなければ、別の入力と重複する可能性があります。

そのため、

数値
+
対象範囲
+
使用量仮定
+
時点

をセットで扱います。

10. Pricing Calculatorの入力仮定をコストドライバーへ接続する

AWS Pricing Calculatorへ入力した値は、コストモデルの仮定と対応付けます。

例えば、

月間実行時間
720時間

という入力があるなら、

なぜ720時間なのか

まで追跡できるようにします。

例えば、

24時間
×
30日
=
720時間

です。

一方、実際の業務要件が、

平日12時間だけ稼働

なら、モデル側の稼働時間というコストドライバーを変更し、それに対応する入力も更新します。

業務上の仮定
↓
使用量
↓
Pricing Calculator入力
↓
見積り結果

というつながりを維持します。

これにより、利用者数や保存期間などの仮定を変更したとき、どの入力や料金項目へ影響するかを追跡できます。

重要なのは、見積り結果だけを保存するのではなく、その結果を作った仮定もコストモデルの一部として管理することです。

11. TCOはAWS利用料だけではない

AWSの月額利用料とTCOは同じ意味ではありません。

TCOでは、

何を比較対象に含めるか

を先に定義します。

例えば比較目的によっては、

AWSサービス利用料
ソフトウェアライセンス
サポート
運用に必要なコスト
導入・変更に必要な一時的コスト

などを含めます。

重要なのは、

AWS利用料が最も低い案
=
TCOも最も低い案

とは限らないことです。

ただし、TCOに何を含めるかは比較目的によって異なります。そのため、

分析期間
+
分析対象の範囲

を先に固定します。

12. 単一の金額ではなく複数シナリオを持つ

将来の利用量を完全に当てることはできません。

そのため、

月額 100万円

という1つの数字だけではなく、

低需要
基準
高需要

など複数のシナリオを作ります。

例えば、

利用者数

低需要
80万人

基準
100万人

高需要
130万人

として、

利用者数
↓
リクエスト
↓
保存量
↓
AWS使用量
↓
コスト

をそれぞれ計算します。

これにより、予想が外れた場合にどの程度コストが動くかを事前に把握できます。

13. 実績とモデルの差をコストドライバーまで戻って確認する

コストモデルは、一度作ったら完成ではありません。

デプロイ後には、

見積り
vs
実績

を比較します。

例えば、

利用者数
想定どおり

APIリクエスト数
想定どおり

1利用者あたり保存量
想定の1.5倍

なら、保存量の仮定を更新します。

見るべきなのは総額が違ったことだけではなく、

どのコストドライバーが
想定と違ったか

まで戻ることです。

モデル
↓
実績
↓
差異
↓
原因となる仮定
↓
モデル更新

という循環を作ります。

14. 代表的なアンチパターン

15. SAP-C02での判断フロー

1. 何を比較 / 計画するのか
   ↓
分析期間と範囲を決める

2. 業務上のコストドライバーは何か
   ↓
利用者 / 取引 / データ量 / 保存期間など

3. AWS使用量へ変換する
   ↓
リクエスト / 実行時間 / 保存量 / 転送量など

4. 使用量パターンを確認する
   ↓
平常 / ピーク / 継続時間 / 成長 / 季節性

5. 固定的な部分と使用量連動部分を分ける

6. 料金条件を適用してコストへ変換する

7. 既存環境なら実績 / 予測を基準として利用

8. 新規・変更予定なら想定使用量から見積り

9. 改善候補は実現可能性を確認してシナリオへ反映

10. 低 / 基準 / 高需要を比較

11. 実績が得られたらコストドライバー単位で差異分析

12. 仮定を更新する

ポイントは、

AWS料金
↓
答え

ではなく、

業務需要
↓
使用量
↓
コストドライバー
↓
料金条件
↓
見積り / 予測
↓
実績で検証

とつなぐことです。

まとめ

コストモデリングでは、AWSサービスの料金を調べるだけでは不十分です。

重要なのは、何が使用量を増やすかを把握することです。

業務需要
↓
AWS使用量
↓
コスト

をつなぎ、固定的な部分、使用量連動部分、平常時、ピーク、成長率を分けて考えます。

既存環境では実績や予測を利用し、新規・変更予定の構成では使用量の仮定から見積りを作ります。

AWS Cost Explorer、AWS Pricing Calculator、AWS Trusted Advisorなどの出力は、自動的な最終回答ではなくコストモデルを作るための入力として扱います。

見積り
↓
実績
↓
差異分析
↓
仮定更新

を繰り返すことで、コストモデルの精度を上げていきます。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 2.6
• AWS Well-Architected Framework — Cost Optimization Pillar
• COST01-BP03 Establish cloud budgets and forecasts
• AWS Cost Explorer — Forecasting with Cost Explorer
• AWS Pricing Calculator Documentation
• AWS Trusted Advisor — Cost optimization checks