Savings Plans と リザーブドインスタンス — 購入戦略とリスク管理
Compute Savings PlansとEC2 Instance Savings Plansの違い、購入シェアリングの範囲設計、コミットメント期間とリスクの考え方を解説します。
長期間安定して稼働するワークロードのコストを最適化する上で欠かせないのが、 Savings Plansとリザーブドインスタンス (RI) という2つのコミットメント型割引です。
SAA レベル:基礎概念
3種類の割引プランの基本比較
| プラン | コミットメント対象 | 柔軟性 |
|---|---|---|
| Compute Savings Plans | 時間あたりの利用金額($/時) | インスタンスファミリー・リージョン・OS問わず適用可能 |
| EC2 Instance Savings Plans | 特定インスタンスファミリー・リージョンの利用金額 | インスタンスサイズ・OS変更は可能。ファミリー変更不可 |
| リザーブドインスタンス (RI) | 特定のインスタンス種別 | 最も柔軟性が低いが割引率は高いケースが多い |
SAA 試験のポイント
Savings Plansは「金額($/時)」にコミットする方式で、RIは「インスタンス種別」にコミットする方式という違いが基本です。Compute Savings Plansが最も柔軟(EC2だけでなくFargate、Lambdaにも適用可)である点が頻出します。
支払いオプション
- 全額前払い(All Upfront): 最大の割引率
- 一部前払い(Partial Upfront): 中程度の割引率
- 前払いなし(No Upfront): 割引率は低いが、初期キャッシュアウトを抑えられる
SAP レベル:高度な設計シナリオ
購入シェアリングの範囲設計
SAP 試験のポイント
Savings PlansもRIも、デフォルトでは組織内の全アカウントに自動的に適用されます(一括請求記事で解説した共有設定と同じ考え方)。SAPレベルでは、予測可能な基盤ワークロード(データベース、常時稼働のバッチサーバー等)にはRIやEC2 Instance Savings Plansを、変動の大きいワークロードにはCompute Savings Plansを充てるという、ワークロード特性に応じた組み合わせ設計が問われます。
コミットメント期間とリスクの考え方
| 観点 | 1年コミット | 3年コミット |
|---|---|---|
| 割引率 | 低め | 高め |
| 柔軟性・リスク | 事業変化への追従がしやすい | 長期の利用予測が外れた場合のリスクが大きい |
SAP 試験のポイント
「割引率が高いから」という理由だけで安易に3年コミットを選ぶのは、SAPレベルでは不十分な判断です。事業のスケール予測が不確実な場合(スタートアップの急成長期等)は、1年コミットや、Compute Savings Plansのような柔軟性の高いプランを優先し、リスクを抑えるという判断が問われるケースがあります。
Savings Plansの購入推奨機能の活用
- AWS Cost ExplorerのSavings Plans推奨機能は、過去の利用実績に基づき最適な購入額・カバレッジを提案する
- 利用率 (Utilization) と カバレッジ (Coverage) の2つの指標を継続的にモニタリングし、購入額が過大(利用率が低い=無駄なコミットメント)or過小(カバレッジが低い=オンデマンド料金を払い続けている)でないかを定期的に見直す運用が重要
設計上の落とし穴
「一度Savings Plansを購入したら放置してよい」という運用は誤りです。ワークロードの増減に応じて、利用率とカバレッジのバランスを定期的に見直し、追加購入や組み合わせの調整を行う継続的な最適化サイクルを回す必要があります。これはSAPドメイン3(既存ソリューションの継続的改善)とも関連する重要な論点です。
Spotインスタンスとの組み合わせ
- ベースラインの需要はSavings Plans/RIでカバーし、変動する需要のピーク部分はSpotインスタンスやオンデマンドで補う「ベースライン+バースト」設計が、コスト効率と柔軟性を両立する定番パターン
まとめ
- SAA: Savings Plans(金額コミット)とRI(インスタンス種別コミット)の基本的な違い、Compute Savings Plansの柔軟性の高さを理解する。
- SAP: ワークロード特性に応じたプランの組み合わせ設計、コミットメント期間のリスク評価、利用率・カバレッジに基づく継続的な見直し運用ができる。
次は タグベースのコスト配分を見ていきましょう。