AWS Savings Plans vs Reserved Instances 2026:エンジニアのための意思決定ガイド

著者: Dima Kramskoy — Senior Cloud Architect, DoiT International

誰もが間違える問い

クラウド最適化の案件を担当していた頃、お客様から最も多く寄せられた質問がこれでした。「Savings PlansとReserved Instances、どちらを使うべきか?」週に3〜4回は、別々のお客様から同じ質問を受けていました。

しかし、これは問いの立て方が間違っています。

本当に問うべきはこちらです。12か月後、自社のworkloadはどうなっているか?

なぜ問い直しが重要なのか。Gravitonへの移行を計画している組織がStandard RIを購入すれば、workloadが新しいインスタンスファミリーに移ったときにRIが追随できず、そのまま死に金になります。逆に、2年間構成を変えていない盤石なRDSクラスターを抱えるチームがCompute Savings Plansを選んでしまえば、Standard RIなら得られたはずの6〜9ポイント分の割引を取り逃すことになります。

SPかRIかという議論は、製品選びの問題ではありません。アーキテクチャの方向性の問題です。コミットメント戦略はインフラのロードマップに合わせるべきであり、その逆ではありません。

**そして、ここに不都合な真実があります。**私が関わるお客様のほとんどは、12か月後のworkloadがどうなっているかを把握できていません。来四半期にGravitonに移行するのか、コンテナに移るのか、コンピュートを倍増させるのか — どれも確証はないのです。これは計画の失敗ではなく、現実です。そして、workloadの行き先がわからないということ自体が、すでに答えになっています。不確実性=柔軟性。最低限Compute Savings Plansを選ぶ。もっと言えば、コミットメントのリスクをツールに丸ごと肩代わりさせるのがベストです(これについては最後に詳しく触れます)。

それでは、エンタープライズのお客様向けに私が使っているフレームワークを、2025〜2026年の変更点を反映してご紹介します。

結論を急ぐ方へ: 意思決定フローチャート

詳細に入る前に、最短ルートをお見せします。

START: 主要なコンピュートworkloadは?
│
├─ EC2のみ、単一インスタンスファミリー、12か月以上安定
│   └─ → EC2 Instance Savings Plan または Standard RI
│       ├─ キャパシティ予約が必要? → Zonal Standard RI
│       └─ 運用をシンプルにしたい? → EC2 Instance SP
│
├─ 複数のインスタンスファミリーにまたがるEC2
│   └─ → Compute Savings Plan
│
├─ Graviton移行を計画中 (x86 → arm64)
│   └─ → Compute Savings Plan (新ファミリーに自動適用)
│
├─ Fargate、Lambda、またはサーバーレス中心
│   └─ → Compute Savings Plan (これらをカバーする唯一の選択肢)
│
├─ RDS / Aurora / データベース層
│   └─ 構成が安定、最大割引を狙う? → Standard RI (最大69%)
│   └─ マルチエンジン、Gen 7+、柔軟性重視? → Database SP (最大35%)
│
└─ 再アーキテクチャ進行中、またはAWSからの移行中
    └─ → コミットしない。安定するまでOn-Demand/Spotで対応。

クイック比較表

2025〜2026年の変更点

前回のコスト最適化レビュー以降、4つの大きな変化がありました。

1. Database Savings Plansの登場 (2025年12月)

FinOps視点では、re:Invent 2025最大の発表です。Database Savings Plansが対象とするのは10サービス — Aurora、RDS、DynamoDB、ElastiCache、DocumentDB、Neptune、Keyspaces、Timestream、DMS、OpenSearchです。

ただし注意点があります。期間は1年のみ (3年は不可)、No Upfrontに限定され、Gen 7+インスタンス (db.r7g、db.m7g) が必須です。最大割引率は約35%で、Standard RDS RIで実現できる69%を大きく下回ります。つまりDB RIの代替ではなく、多様で進化し続けるデータベース環境を抱える組織のための柔軟性オプションと位置付けるべきものです。

2. RI/SP共有の制限 (2025年6月)

AWSは、MSPやリセラーが複数のエンドカスタマー間でRI/SP割引を共有することを禁止しました。パートナー経由で購入している場合、コミットメントは自社の使用分にしか適用されなくなります。直接契約のエンタープライズ顧客はほぼ影響を受けません。

3. Group Sharing機能 — GA (2025年11月)

地味な発表でしたが、現実的な悩みを解決してくれます。Organization内のどのアカウントが共有コミットメントの恩恵を受けるかを、次の2モードで細かく制御できるようになりました。

• Prioritized Group Sharing: 指定したグループに優先適用し、余剰分を組織全体に波及させる
• Restricted Group Sharing: 完全分離 — 指定したグループだけが恩恵を受ける

これにより、長年連結請求につきまとってきた「意図しないチームが自社のRIで得をする」問題が解消されます。グループ定義にはCost Categoriesを使います。チャージバックモデルを採用するマルチBU組織にとっては、まさにゲームチェンジャーです。

4. RIは廃止されていません

繰り返し憶測が飛び交いますが、Reserved Instancesは引き続き完全にサポートされています。AWSの料金ページは継続的に更新されており (最終更新は2026年5月)、Cost ExplorerはRIの推奨を生成し続け、RI Marketplaceも稼働中です。新機能の開発やドキュメント整備ではAWSが明らかにSavings Plansを優先していますが、RIがなくなる気配はありません。

**もう一点。**時間あたり100ドルを超えるSavings Plansは返却できません。100ドル未満であれば、同一暦月内に7日間の返却ウィンドウがあり、年間最大10回まで返却可能です。エンタープライズ規模では、コミットは事実上恒久的だと考えて計画してください。

徹底比較: Compute SP vs EC2 SP vs Standard RI vs Convertible RI

当時、判断を下していた頃にあればよかったと思う全項目比較表です。

*EDP契約のお客様はRI Marketplaceで売却できません。

請求への適用順序 (ここが肝心)

AWSは次の優先順位で割引を適用します。

1. Reserved Instancesが最初に適用される (一致する使用分に対して)
2. EC2 Instance Savings Plansが次に適用される
3. Compute Savings Plansが最後に適用される (最も広範囲をカバー)

各層内では、節約率が最も高い使用分から優先的にカバーされます。つまり3種類すべてを安心して重ねられる構造になっており、適用の最適化はAWSが自動でこなしてくれます。

Workloadのポータビリティ: 柔軟性が割引に勝る場面

Compute SP (66%) とEC2 Instance SP (72%) の割引差は約6ポイント。エンタープライズで一般的な条件 (1年、前払いなし) では、この差は2〜4ポイントまで縮まります。この「柔軟性プレミアム」を払うべきケースを具体的に見ていきましょう。

Graviton移行

x86 (m5、c5、r5) からGraviton (m7g、c7g、r7g) への移行:

• Compute SP: シームレスに対応。Gravitonインスタンスを起動した瞬間に割引が自動適用されます。
• EC2 Instance SP: 機能しません。m5 ≠ m7g — 別のインスタンスファミリーだからです。
• Standard RI: 新しいインスタンスにはまったく使えません。コミットメントが宙に浮きます。
• Convertible RI: 手動交換が必要で、同等以上の価値であることが条件。しかもリージョン固定のままです。

Graviton移行を進めるなら (価格性能比が20〜40%向上するので進めるべきです)、Compute SPが構造的に最適です。

コンテナ化 / サーバーレスへの移行

EC2からECS/FargateまたはLambdaへの移行:

• Compute SP: FargateとLambdaを自動でカバー。割引がそのまま追随します。
• それ以外: コンテナやサーバーレスのコンピュートは一切カバーされません。

クロスリージョン展開

新リージョンの開設、または4リージョンから2リージョンへの集約:

• Compute SP: 全リージョンに割引がグローバルに適用されます。
• その他すべて: リージョン固定。集約するとコミットメントが宙に浮きます。

数字で見る

年間500万ドルのコンピュート支出で見ると、6ポイントの差は3年間で約30万ドル。一見大きく感じます。しかし、ロックインされたRIから抜け出せずGraviton移行に失敗すれば、フリート全体で得られたはずの20〜40%の性能向上をまるごと逃すことになります。柔軟性プレミアムは保険です。しかも、極めて安い保険です。

アンチパターン (間違えるとどうなるか)

クラウドコスト最適化に携わった10年以上の経験で、組織に何百万ドルもの損失をもたらしたミスを数多く見てきました。なかでも特に高くついた5つを紹介します。

アンチパターン1: ベースラインではなくピークにコミットする

ミス: 観測された最大使用量を基準にコミットメントを購入する。

結果: 月曜朝のピークが時間あたり50ドルだからと、そのまま50ドルでコミット。実際の持続的ベースラインは時間あたり35ドル。コミットの利用率は70%にとどまり、残り30%は完全な無駄になります。

コスト: 時間あたり50ドルのコミットで30%が無駄 = 年間13.1万ドルが燃えていく計算です。

対策: 持続的な下限の70〜80%にコミット (60〜90日のデータを利用)。スパイクはSpotとOn-Demandでカバーします。

アンチパターン2: 移行間近のworkloadにStandard RI

ミス: Graviton移行がロードマップにあるm5フリートに対し、3年のStandard RIを購入する。

結果: 半年後にm7gへ移行する準備が整っても、Standard RIは追随できません。Convertibleでもありません。EDP契約のお客様であれば、Marketplaceで売却することもできません。稼働していないインスタンスの分を払い続ける羽目になります。

コスト: r5.4xlargeで宙吊りになった3年RIの場合: 月額約278ドルのコミットが残り30か月間まったく恩恵を生まない = インスタンスあたり8,340ドルの無駄。フリート全体に広がれば被害は甚大です。

対策: コミットメント期間内にアーキテクチャ変更の計画があるなら、Compute SPを選びましょう。

アンチパターン3: コミットメントを気づかぬまま失効させる

ミス: 失効監視も更新キューイングも設定していない。

結果: 火曜日にRIの一群が失効。月末の請求が届くまで誰も気づかない。r5.4xlarge1台あたりの実効レートが月額278ドルから736ドルに跳ね上がる — 一夜で62%超のコスト増です。

コスト: 20インスタンスのフリートが1か月だけOn-Demandに戻るだけで、想定外の支出は約9,160ドル。

対策: AWS Budgetsで失効アラートを設定し、失効日前にSavings Planの購入をキューイングしておきます。

アンチパターン4: EC2以外のコンピュートを無視する

ミス: コンピュート支出の40%以上がLambda、Fargate、EKSに集中しているのに、EC2にしかコミットしない。

結果: サーバーレス/コンテナの大きな支出が満額のOn-Demandレートのまま放置される。EC2コミットメントだけを最適化している組織は「やり切った」と思い込んだまま、最も急成長しているworkloadsで20〜30%の節約を取り逃しています。

コスト: LambdaとFargateで年間20万ドルがOn-Demandの場合、Compute SPで20〜66%節約できれば、年間4万〜13.2万ドルの逸失利益となります。

対策: 対象となるサービスをすべて棚卸ししましょう。Compute SP一本で、EC2、Lambda、Fargateを同時にカバーできます。

アンチパターン5: 再アーキテクチャの最中にコミットする

ミス: ライトサイジング、プラットフォーム移行、クラウド移行の真っ最中にコミットメントを購入する。

結果: 今日、時間あたり80ドルでコミット。その後6か月で最適化が進み、ベースラインが55ドルに低下。残りの期間、時間あたり25ドル分の無駄を背負い続けることになります。

コスト: 1年契約の残り時間 × 時間あたり25ドル × 8,760時間 = 21.9万ドルの宙吊りコミットメント。

対策: まず安定させてからコミットする。確信度に応じて段階的にコミットを積み増しましょう — 移行中は小さく、使用パターンが固まったら大きく、です。

意思決定フレームワーク

スクリーンショットで保存しておきたい表です。

階層型戦略 (ほとんどの組織への推奨アプローチ)

1種類だけを選ぶのではなく、重ねて使いましょう。

1. Layer 1 — Compute SP (ベースラインの60〜80%): 最小のコンピュート床面を最大の柔軟性でカバー
2. Layer 2 — EC2 Instance SP: 自信のあるファミリーに上乗せ (追加で6ポイントの割引を獲得)
3. Layer 3 — Standard RI: 極めて安定したデータ層workloadとキャパシティ要件向けに確保
4. Layer 4 — On-Demand/Spot: 変動が大きく不確実なworkloadはコミットせず維持

まずは1年契約でパターンを検証してください。12か月分の安定した使用データが揃ったら、実証済みのベースラインに3年契約を重ねます (15〜22ポイントの追加割引)。

DoiTが自動化する仕組み

不確実性の話を覚えているでしょうか。ほとんどのお客様は12か月後のworkloadがどうなるかを把握できていません。まさにそのケースに向けて作られたのが**FlexSave for Compute**です。

一言で言えば、お客様はコミットメントゼロのまま、1年契約のSavings Plans並みの割引率を享受できます。リスクはDoiTが引き受けます。

仕組みは次のとおりです。

• オンデマンド使用量を継続監視 — 何が稼働し、何が安定し、何が変化しているかを分析
• 最適な割引メカニズムを自動適用 — 自社のRI/SPでまだカバーされていない対象workloadをカバー
• 継続的に調整 — Gravitonへの移行中? スケールダウン中? Fargateへの移行中? FlexSaveがスプレッドシートを開くことなく自動で追随します
• お客様側のコミットメントは不要 — コミットメントリスクはDoiTが負担。お客様は割引だけを受け取り、いつでも離脱できます
• コンピュートスタック全体をカバー — EC2、ECS、EKS、Fargate、Lambda、SageMaker (EC2だけではありません)

データベースについては、AWSの新しいDatabase Savings Plans (2025年12月) がRDSとAuroraの最有力候補です。FlexSaveは、不確実性と柔軟性のニーズが最も大きいコンピュート領域に集中しています。

コミットメントポートフォリオ全体を俯瞰したいときは、DoiT Cloud Analyticsが利用率・カバレッジ・無駄の指標を一元的に提供します。戦略が機能しているかを常に把握できる仕組みです。

この組み合わせで両方の課題が片付きます。FlexSaveが「次に何が来るかわからない」状況での実行を担い、Cloud Analyticsが俯瞰を提供する。ツール側がともに適応してくれるなら、不確実性はもはや問題ではありません。

まとめ (TL;DR)

1. ほとんどの組織にとってCompute SPがデフォルトの選択 — 柔軟性プレミアム (一般的な条件で2〜4ポイント) は、ロードマップにアーキテクチャ変更があるチームならほぼ常に払う価値があります。

2. 極めて安定したworkloadsでは依然Standard RIに分がある — データベース層、コンプライアンス要件のキャパシティ予約、18か月以上の安定実績があるworkloadsが該当します。

3. Database Savings Plans (2025年12月の新機能) は割引狙いではなく柔軟性のための選択肢 — Standard RIの69%に対し35%です。マルチエンジンでGen 7+の環境に選びましょう。

4. コミットメントは階層化する — Compute SPをベースに、自信のあるファミリーにはEC2 Instance SP、安定したデータベースにはStandard RI、それ以外はOn-Demand、という構成です。

5. 移行中は絶対にコミットしない — まず安定、そしてコミット。宙吊りコミットメントのコストは、待つことのコストを常に上回ります。

正しいコミットメント戦略とは、割引を最大化することではなく、コミットメントをアーキテクチャの方向性に合わせることです。

手作業での管理から抜け出す準備はできていますか? デモを予約して、FlexSaveがAWSコミットメントをどう自動最適化するかをご確認ください。

Dima KramskoyはDoiT InternationalのSenior Cloud Architect。ソフトウェアエンジニアリング20年以上の経験、AWS認定資格10種、AWS Community Builder (2026)。エンタープライズ組織向けのFinOpsとクラウドコスト最適化を専門としています。