SAP-C02-095 · セクション 11 / タスク 2.6

Compute Pricing Modelの選択

オンデマンド / Reserved Instances / Savings Plans / Spot Instances / コミットメント / 使用量の安定性

コンピューティングコストを最適化するとき、

1か月で何時間使うか

だけを見ても、適切な料金モデルは決まりません。

重要なのは、

いつ使うのか
↓
毎時間どこまで継続するのか
↓
その使用量が何年間残るのか

です。

同じ月間使用量でも、

24時間ほぼ一定

と、

1日の一部だけ大量利用

では、コミットメントとの適合度が異なります。

ここでは既習の購入オプションそのものを覚え直すのではなく、

使用量モデル
↓
時間単位の安定性
↓
利用継続期間
↓
コミットメント量
↓
コミットメント期間
↓
料金モデルへの割り当て

へ変換する方法を扱います。

ゴール

最終的に、

月間総使用量

ではなく、

時間単位で残る使用量
+
その使用量が残る期間

から、

どこまでコミットできるか

を判断し、その結果を既習の料金モデルへ割り当てられることがゴールです。

1. 料金モデルは月間総量ではなく使用量の「形」から選ぶ

例えば、次の2つのワークロードを考えます。

ワークロード	使用方法
A	50台を24時間ほぼ一定で利用
B	150台を毎日8時間だけ利用

1日の合計はどちらも、

1200 instance-hours

です。

しかし時間ごとに見ると、

A
50 50 50 50 50 ...

に対し、

B
0 0 0 ... 150 150 ... 0

となります。

月間総使用量が同じでも、

毎時間継続する使用量

は異なります。

したがって、

月間総量が安定
=
コミットメントに適する

とは限りません。

まず、

時間単位で
どこまで使用量が残るか

を確認します。

2. 平均値・ピーク・安定ベースラインを分ける

使用量を次のように分解します。

使用量
│                  ┌───────
│          ┌───────┘
│    ┌─────┘
│────┴────────────────
│    安定ベースライン
└──────────────────── 時間

見るべき値は、

平均使用量
ピーク使用量
時間単位の安定ベースライン

です。

長期コミットメントを考えるとき、

最大でどこまで使うか

より、

ほぼすべての時間で
どこまで使用量が残るか

が重要になります。

ピークをそのままコミットすると、需要が低い時間に未使用部分が発生する可能性があります。

3. Savings Plansは時間単位のコミットメント

Savings Plansでは、1年または3年の期間について、1時間あたり一定額の使用をコミットします。

特に重要なのは、

ある時間に余ったコミットメント
↓
別の時間には持ち越せない

ことです。

例えば、

00:00〜16:00
使用量ほぼ0

16:00〜24:00
使用量20 USD/h相当

というワークロードについて、

1日の平均
約6.7 USD/h

だけを根拠にコミットメントを決めると、

利用しない時間

を見落とします。

したがって、

月間平均
↓
コミットメント

ではなく、

時間帯別使用量
↓
継続する時間単位使用量
↓
コミットメント

で判断します。

4. リザーブドインスタンスも時間分布を無視できない

Amazon EC2リザーブドインスタンスは、選択した期間中、インスタンスが実行されているかどうかにかかわらず各クロック時間について課金されます。

そのため、

月に合計720時間使う

という情報だけでは不十分です。

例えば、

1台を720時間連続

と、

多数のインスタンスを
短時間だけ断続的に利用

では、時間ごとの利用分布が異なります。

したがって、

総実行時間

だけでなく、

どの時間に
どれだけ対象使用量が存在するか

を確認します。

5. 「現在安定している」と「期間中残り続ける」は分ける

コミットメント判断では、

現在の使用量

と、

その使用量が将来も残る期間

を分けます。

例えば、

現在
80単位を24時間利用

8か月後
システム廃止予定

なら、

現在の時間単位使用量
→ 非常に安定

でも、

1年間残る使用量
→ 0

になる可能性があります。

したがって、

時間単位で安定

だけではコミットメント量を確定できません。

どの量が
どこまでの期間
残る確度が高いか

まで確認します。

6. 安定ベースラインには「確度」がある

将来の使用量は、1つの数字で確定しているとは限りません。

例えば、

最低でも40
通常は70前後
多いと120

と予測されているとします。

このとき、

が最も可能性の高い値でも、

70を毎時間必ず使う

とは限りません。

コミットメント量では、

最も可能性の高い使用量

より、

高い確度で
継続して残る使用量

を重視します。

例えば、

40
→ ほぼ全時間で必要

40〜70
→ 日によって変動

70〜120
→ 特定期間だけ

なら、

が安定ベースラインの有力候補です。

7. 「平均使用量」と「コミット可能量」は一致しない

次のような1日の使用量を考えます。

18時間
20単位

6時間
100単位

1日の平均は、

40単位

です。

しかし40単位を毎時間コミットすると、

18時間
使用量20
コミット40

となり、

20単位分

を使い切れない時間が発生します。

したがって、

平均使用量
=
コミット可能量

とは限りません。

時間単位で見ると、

ほぼすべての時間で残る20

と、

特定時間だけ増える80

へ分解できます。

コミットメント量を考えるときは、

月平均
日平均

より、

時間単位の下限に近い安定使用量

を見ることが重要です。

8. コミットメント期間中にベースラインが変わる場合

利用量が将来変化することが分かっている場合は、現在のベースラインだけを使いません。

例えば、

1〜6か月目
80単位

7〜12か月目
40単位

で、7か月目に既存システムの一部廃止が確定しているとします。

現在の、

だけを見て1年間コミットすると、

後半6か月
40単位分が余る

可能性があります。

この場合は、

コミットメント期間
↓
期間内で予定されている需要変化
↓
期間全体で残る安定使用量

を確認します。

つまり、

現在のベースライン

ではなく、

コミットメント期間全体を通して
残るベースライン

を見ます。

9. 低需要・基準・高需要シナリオをコミット量へ変換する

コストモデルで、

低需要   40
基準     70
高需要  120

というシナリオを作ったとします。

さらに、

40
→ 全時間帯で高い確度

40〜70
→ 日によって変動

70〜120
→ キャンペーン時のみ

と分かっているなら、

120すべてコミット

する必要はありません。

また、

最も可能性が高い70

をそのままコミット量にするとも限りません。

見るのは、

シナリオが外れても
高い確度で残る使用量

です。

低需要でも残る
+
時間単位でも残る
+
期間中も残る

という条件を満たす範囲が、コミットメント候補になります。

10. コミットメント量とコミットメント期間を分けて決める

コミットメントでは、

どれだけコミットするか

と、

どれくらいの期間コミットするか

を別々に判断します。

例えば、

毎時間40単位
今後18か月は高い確度で必要

だとしても、

40単位

という量の判断と、

1年
3年

という期間の判断は別です。

まず、

時間単位使用量
↓
安定ベースライン
↓
コミット可能量

を求めます。

次に、

利用継続の確度
↓
コミットメント期間

を判断します。

量
↓
時間単位の安定性

期間
↓
将来利用の確度

と分けると判断しやすくなります。

11. 割引率だけで長い期間を選ばない

3年コミットメントの方が割引面で有利になる場合でも、

3年間使う確度

が十分とは限りません。

例えば、

18か月
高い確度で継続

その後
システム更改予定

なら、

3年間の割引率

だけではなく、

19か月目以降も
コミットメントを利用できるか

を考えます。

料金モデル選択では、

割引率

と、

将来利用の確度

を交換条件として評価します。

12. 同じ月間コストでも適切な料金構成は変わる

例えば、どちらも現在月100万円のコンピューティング費用だとしても、

ワークロードA

24時間継続
需要変動小
今後3年間継続

ワークロードB

昼間だけ利用
需要変動大
9か月後に再設計予定

では、コミットメントの適合度は異なります。

したがって、

現在の月額コスト

だけから、

何%をコミットすべきか

を決めません。

見るのは、

時間分布
+
利用継続期間

です。

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

アンチパターン	問題
月間総使用量だけでコミット量を決める	時間ごとの未使用を見落とす
月間平均をそのままコミットする	低使用時間の未使用を見落とす
最大ピークまでコミットする	ピーク外の時間に余りやすい
現在のベースラインが期間中ずっと続くと考える	廃止・縮小予定を無視する
基準シナリオだけでコミット量を決める	低需要時の未使用リスクを見落とす
未使用コミットメントを別時間へ繰り越せると考える	時間単位の課金特性を誤る
割引率だけで長期間を選択する	利用継続期間との不一致を見落とす

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

1. 月間総量ではなく
   時間単位使用量を確認
   ↓
平均
ピーク
安定ベースライン

2. ほぼすべての時間で残る量を確認
   ↓
コミット可能量の候補

3. 低 / 基準 / 高需要でも
   その量が残るか確認

4. 期間中に
   廃止・縮小・移行予定がないか確認

5. コミットメント期間全体で
   残る使用量を求める

6. コミットメント量を決める

7. 利用継続の確度から
   コミットメント期間を判断

8. 既習の購入オプションへ割り当てる
   ↓
   高確度で継続する部分
   → Savings Plans / RIを比較

   コミットしない・中断不可の部分
   → オンデマンドを評価

   中断可能な部分
   → スポットを評価

9. 未使用コミットメントが
   発生しないか再確認

ここで、オンデマンドやスポットの機能を改めて覚え直す必要はありません。

ここで行うのは、

使用量 Model
↓
コミットできる部分
コミットしない部分
中断可能な部分

へ分解した結果を、既習の料金モデルへ割り当てることです。

判断の中心は、

どれが最も割引率が高いか

ではありません。

どの使用量なら
各時間かつ契約期間中に
使い切れる確度が高いか

を先に決め、その後で適切な料金モデルへ割り当てます。

まとめ

Compute 料金モデルを選ぶときは、

月間使用量

だけではなく、

時間単位の使用量分布

を確認します。

Savings Plansでは各時間のコミットメントを別の時間へ繰り越せず、リザーブドインスタンスも期間中の各クロック時間で課金されます。

そのため、

平均
ピーク
時間単位の安定ベースライン

を分離します。

さらに、

そのベースラインが
コミットメント期間中も残るか

を確認します。

まず、

時間単位で残る量
↓
コミットメント量

将来利用が続く期間
↓
コミットメント期間

を決めます。

その結果を、

高確度で継続する部分
→ Savings Plans / RI候補

コミットしない中断不可部分
→ オンデマンド候補

中断可能部分
→ スポット候補

として、既習の料金モデルへ割り当てます。

つまり、

料金モデルを先に選ぶ

のではなく、

使用量を分類
↓
コミット量と期間を決定
↓
料金モデルへ割り当て

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

主要AWS公式資料

AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 2.6
AWS Savings Plans User Guide — What are Savings Plans?
AWS Savings Plans User Guide — Understanding how Savings Plans apply to your usage
Amazon EC2 User Guide — Reserved Instances for Amazon EC2 overview
Amazon EC2 User Guide — How billing works with Reserved Instances