導入
同じインスタンスでも、買い方次第で料金は数倍変わります。SAAのコスト最適化ドメインで最も出題頻度が高いのが、この購入オプションの使い分けです。
説明
EC2には5つの購入オプションがあり、それぞれ「安さ」と「柔軟性」のトレードオフが異なります。
| 購入オプション | 特徴 | 割引率の目安 | 向いている用途 |
|---|---|---|---|
| オンデマンド | 使った分だけ、コミットなし | 基準（0%） | 短期・予測不能な負荷、開発初期 |
| リザーブドインスタンス(RI) | 1年/3年の利用をコミット | 最大72% | 定常的に稼働し続けるワークロード |
| Savings Plans | 1年/3年、金額ベースでコミット（インスタンス種変更に柔軟） | 最大72% | 定常負荷だが将来インスタンスを変える可能性がある |
| スポットインスタンス | 余剰キャパシティを入札、中断あり | 最大90% | 中断に耐えられるバッチ処理、CI、ステートレスな並列処理 |
| Dedicated Host | 物理ホストを専有 | 割引なし〜中程度 | ライセンス持ち込み(BYOL)、コンプライアンス要件 |
flowchart TD
Q["負荷の性質は？"] -->|24時間365日、定常的| RI["RI / Savings Plans"]
Q -->|中断されても困らない| SP["スポットインスタンス"]
Q -->|短期・スパイク・予測不能| OD["オンデマンド"]
Q -->|ソフトウェアライセンスの都合で物理ホスト単位が必要| DH["Dedicated Host"]
RIとSavings Plansはどちらも長期コミットで大幅割引を得ますが、RIはインスタンスファミリー/リージョンを固定しがちで、Savings Plansは金額コミットなのでインスタンス変更に強いという違いがあります。「将来構成が変わるかもしれない」という文脈ではSavings Plansが優先されます。
具体例
あるSaaS企業のインフラを、ワークロードごとに買い分けてコストを最適化します。
| ワークロード | 稼働の性質 | 選ぶ購入オプション |
|---|---|---|
| 本番Webサーバー群 | 24時間365日、構成も安定 | リザーブド（3年）で最大級の割引 |
| 本番アプリ層（近くインスタンスを新世代へ変える予定） | 定常だが将来構成変更あり | Savings Plans（金額コミットなので種変更に強い） |
| 夜間の大規模バッチ | 中断されても再実行すればよい | スポット（最大90%引き） |
| 新機能の検証環境 | いつ使うか読めない | オンデマンド |
ここでのSAA的な勘所が、Web層とアプリ層の違いです。どちらも定常負荷ですが、アプリ層は「半年後にm5からm6gへ載せ替える」計画がある。RIはファミリーを固定しがちなので、載せ替えると割引が無駄になりかねない。将来インスタンスを変える予定があるなら、金額ベースでコミットするSavings Plansが柔軟です。「定常＝コミットで割引、中断可＝スポット、将来変更あり＝RIよりSavings Plans」という判断がコスト設計の核です。
読んでみよう
「本番の定常負荷はRI/Savings Plans」「バッチ・中断可はスポット」「短期・不確実はオンデマンド」という3分類をまず覚え、そのうえで「ライセンス」というキーワードが出たらDedicated Hostを思い出してください。コスト最適化ドメインの定番パターンです。