AWS Purchasing Options

1. 購入選択肢はコストと制約のトレードオフ

購入オプションは料金だけの違いではありません。コストを下げる代わりに、長期コミットメントや設定の制約、中断リスクなどを受け入れる選択肢があります。

「最安」を探すのではなく、要件が許容できる制約とリスクをコストと交換すると考えます。

2. オンデマンドは長期コミットメントが不要

オンデマンドは長期コミットメントを必要とせず、短期・不規則・将来の使用量が読みづらいワークロードに向きます。

短期
不規則
成長予測が不確実
設定変更が多い
        ↓
オンデマンドを候補

ただし、オンデマンド = EC2キャパシティが常に保証されるではありません。特定AZのキャパシティを確実に起動できることが要件なら、料金モデルとは別にキャパシティ確保を考えます。

3. リザーブドインスタンスはEC2のコミットメント選択肢

Amazon EC2 リザーブドインスタンス（RI）は、EC2使用量へ長期コミットすることで割引を得る選択肢です。主なオファリングクラスとしてスタンダードRIとコンバーティブルRIがあります。

コンバーティブルRIでもリージョンをまたいだ交換はできません。リージョン変更まで想定するなら、Compute Savings Plansなど別の柔軟性を比較します。

4. リージョン単位のRIとゾーン単位のRIではキャパシティの意味が違う

RIをすべて「キャパシティを予約するもの」と考えてはいけません。

リージョン単位のRIにはAZ 柔軟性があり、条件を満たすLinux/UNIX・デフォルトテナンシー等ではインスタンスサイズ柔軟性も利用できます。ただし、すべてのプラットフォーム / テナンシーで無条件にサイズ柔軟になるわけではありません。

割引を柔軟に使いたい
→ リージョン単位のRIを評価

特定AZのキャパシティ利点も必要
→ ゾーン単位のRIを評価

5. 一般的なコストコミットメントではSavings Plansを優先評価する

Savings PlansはRIと同様にコミットメントと引き換えに割引を得ますが、コンピューティング使用量の変更へより柔軟に対応できます。一般的なコンピューティングコストコミットメントでは、まずSavings Plansが要件に合うかを評価します。

一方、RIにはゾーン単位のRIのキャパシティ予約の利点など固有の性質があります。したがって、Savings Plansが常にRIを置き換えるのではなく、コスト割引とキャパシティ要件を分けて選択します。

6. Savings Plansは時間単位の金額コミットメント

Savings Plansでは特定のインスタンス数やvCPU数を予約するのではなく、Savings Plans料金で評価した1時間あたりの金額へコミットします。

安定した対象使用量
        ↓
Savings Plans料金で評価
        ↓
時間単位の金額コミットメント
        ↓
コミットメントまで割引料金
        ↓
コミットメントを超える対象使用量
→ オンデマンド率

購入後のコミットメント条件を自由に変更・取消できる料金モデルではないため、将来使うか不確かなピークではなく、高い確度で継続するベースラインを中心にコミットメントを評価します。

7. Compute Savings Plansは高い柔軟性を持つ

Compute Savings PlansはEC2について、インスタンスファミリー、サイズ、リージョン、オペレーティングシステム、テナンシーが変わっても割引を自動適用できます。さらにEC2だけでなくFargateやLambdaにも適用できます。

EC2 ファミリー変更
リージョン変更
OS / テナンシー変更
EC2 → Fargate / Lambda
        ↓
Compute Savings Plansの柔軟性を評価

ワークロードのモダナイゼーションやリージョン移行まで想定する場合、この柔軟性が判断要因になります。

8. EC2 Instance Savings Plansはファミリー + リージョンへコミットする

EC2 Instance Savings Plansは、特定インスタンスファミリー + 特定リージョンへのコミットメントと引き換えに割引を得ます。その範囲内でインスタンスサイズ、OS、テナンシーが変わっても割引を適用できます。

ファミリー / リージョンは安定
サイズ / OS / テナンシーは変わる可能性
        ↓
EC2 Instance Savings Plansを評価

ファミリーやリージョンまで変わるならCompute Savings Plansの方が要件に合う可能性があります。

9. Savings Plansはコンピューティングだけに限定された仕組みではない

現在のAWSではCompute Savings Plans / EC2 Instance Savings Plansに加えて、Database Savings PlansとSageMaker AI Savings Plansがあります。したがって、Savings Plans = EC2専用またはコンピューティング専用と固定的に覚えないことが重要です。

Database Savings PlansではAurora、RDS、DynamoDB、ElastiCache、Amazon OpenSearch Serviceなどの対象使用量に対し、対応サービス・エンジン・インスタンスファミリー・サイズ・リージョンなどの変更をまたいで割引を適用できます。

RDS for Oracle
      ↓ 移行
Aurora PostgreSQL
      ↓ アーキテクチャ変更
DynamoDB

対象条件を満たすデータベース使用量
→ Database Savings Plansを評価

10. Savings Plansはキャパシティ予約ではない

Savings Plansが提供するのは料金割引であり、EC2キャパシティを確保する仕組みではありません。

Savings Plans
→ 料金割引

キャパシティ予約
→ キャパシティ保証

特定AZのキャパシティを確保しつつSavings Plans割引を利用したい場合は、オンデマンドキャパシティ予約 + Savings Plansのように別レイヤーの仕組みを組み合わせます。

11. スポットインスタンスは中断リスクを受け入れる

スポットインスタンスはAWSクラウドの未使用EC2キャパシティを低価格で利用できる一方、AWSがキャパシティを必要とした場合に中断される可能性があります。

バッチ、CI/CD、レンダリング、コンテナワーカーなど、中断を前提に設計できるワークロードで有力です。

12. スポット中断通知を可用性保証にしない

スポットでは中断通知が提供される場合がありますが、通知はベストエフォートです。通知が来ることを前提にしないアーキテクチャが必要です。

悪い設計
通知が来れば必ず状態を保存できる

良い設計
通知がなくても耐障害性
+
通知が来れば安全な終了処理に利用

スポットキャパシティ自体も常に得られるとは限らないため、中断許容度だけでなくキャパシティ柔軟性も選択基準になります。

13. コミットメントはピークではなく確信できるベースラインから決める

長期コミットメントは「最大でどこまで使うか」ではなく、「どこまでなら継続利用に確信を持てるか」で評価します。

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

ピークまでコミットすると、需要が下がったときに未使用コミットメントリスクが増えます。安定ベースラインへコミットし、変動分を別料金モデルで吸収する考え方が基本です。

14. 柔軟性を「何が変わるか」に分解する

「柔軟性が必要」だけでは選択肢を選べません。変更可能性を具体的に分解します。

例えば「サイズだけ変わる」のか、「ファミリー / リージョン / コンピューティングモデルまで変わる」のかで、EC2 Instance Savings PlansとCompute Savings Plansの判断が変わります。

15. 可用性アーキテクチャと料金モデルを分離する

購入オプションは高可用性アーキテクチャそのものではありません。

料金モデル
→ オンデマンド / RI / Savings Plans / スポット

可用性アーキテクチャ
→ マルチAZ / スケーリング / フェイルオーバー / 再試行

キャパシティ保証
→ ゾーン単位のRI / キャパシティ予約など

Savings Plansを購入してもマルチAZになるわけではなく、リージョン単位のRIを購入してもキャパシティが予約されるわけではありません。それぞれ別要件として設計します。

16. 主要選択肢を比較する

17. 割引の適用境界を理解する

同じアカウントでRI、Savings Plans、スポットなどを併用する場合でも、同じ使用量へ割引が二重に重なるわけではありません。

RIの割引対象使用量
→ RIを適用

残るSavings Plans対象使用量
→ Savings Plansを適用

スポット使用量
→ Savings Plans対象外

ここで押さえるのは割引の適用境界です。カバレッジや使用率の詳細分析は別の最適化観点として扱います。

18. 障害モード

19. SAP-C02判断フロー

使用量パターンを把握
        ↓
継続使用量へコミットできる？
   ┌────┴────┐
   │         │
  いいえ      はい
   │         │
   ▼         ▼
オンデマンド   Savings Plans / RIを比較
候補              │
                  ▼
         何が変更される？
      ファミリー / リージョン / モデル
                  │
                  ▼
         必要な柔軟性を選ぶ
                  │
                  ▼
        中断を許容？
           ┌────┴────┐
           │         │
          はい      いいえ
           │         │
           ▼         │
        スポットも候補    │
           │         │
           └────┬────┘
                ▼
     特定AZキャパシティ保証が必要？
           ┌────┴────┐
           │         │
          はい      いいえ
           │         │
           ▼         │
 ゾーン単位のRI / キャパシティ予約
           │         │
           └────┬────┘
                ▼
コスト / コミットメント / 柔軟性 /
中断 / キャパシティを比較

まとめ

• オンデマンドは長期コミットメントが不要で、短期・不規則・変更が多いワークロードに向きます。
• RIではスタンダード / コンバーティブルとリージョン規模の / ゾーン単位の違いを分けて考え、キャパシティ利点が必要なら範囲が判断要因になります。
• Savings PlansはSavings Plans料金で評価した時間単位の金額コミットメントであり、ピークではなく高確度のベースラインを中心に検討します。
• Compute Savings Plansはファミリー / リージョン / コンピューティングモデルをまたぐ高い柔軟性を持ち、EC2 Instance Savings Plansはファミリー + リージョンが安定した使用量に向きます。
• Savings Plansはキャパシティ予約ではありません。キャパシティ確保は別レイヤーで設計します。
• スポットは中断リスクとキャパシティ変動を受け入れられる耐障害性のあるワークロードで有力です。
• 中断通知へ依存せず、中断そのものを前提にアーキテクチャを作ります。
• 料金モデル、可用性アーキテクチャ、キャパシティ確保は別要件として判断します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• Amazon EC2 請求と購入オプション / リザーブドインスタンス ユーザーガイド
• AWS Savings Plans ユーザーガイド
• Amazon EC2 スポットインスタンス ユーザーガイド
• Amazon EC2 オンデマンドキャパシティ予約ユーザーガイド