EC2コスト削減 リザーブドインスタンスとSavings Plansの違いと選び方

「EC2の月額料金が想定以上に膨らんでいる。オンデマンドのまま動かし続けるのはさすがにもったいない」——そんな悩みを抱えているインフラ担当の方は多いのではないでしょうか。

AWSにはEC2の利用料金を大幅に削減できる割引プランとして、リザーブドインスタンス（RI）とSavings Plansの2つが用意されています。しかし、どちらを選ぶべきか、どう使い分ければ良いのか、情報が多くて判断に迷うことも少なくありません。

この記事では、両者の仕組みと違いを整理し、あなたの環境に合った選び方を具体的に解説します。

なぜEC2のコスト最適化が重要なのか？オンプレとの違い

オンプレミス環境では、サーバーを購入してしまえば減価償却の範囲で使い続けられます。初期投資は大きいものの、月々の変動費はそこまで気にならなかったという方も多いでしょう。

一方、クラウドは「使った分だけ課金」が基本です。これは柔軟性の裏返しでもあり、何も対策をしなければオンデマンド料金がそのまま積み上がります。

たとえば、東京リージョン（ap-northeast-1）でm6i.xlargeをオンデマンドで24時間365日稼働させると、1台あたり年間約$1,752（2026年3月時点）になります。これが10台あれば年間$17,520です。

RIやSavings Plansを活用すれば、この費用を最大72%削減できます。オンプレ時代の「まとめ買い」に近い感覚で、長期利用のコミットメントと引き換えに割引を受ける仕組みです。

リザーブドインスタンス（RI）の基本

RIの仕組み

リザーブドインスタンスは、特定のインスタンスタイプ・リージョン・期間（1年または3年）を指定して予約購入する割引モデルです。

支払い方法は3種類あります。

・全額前払い（All Upfront）：割引率が最も高い
・一部前払い（Partial Upfront）：前払い＋月額の組み合わせ
・前払いなし（No Upfront）：月額のみ、割引率は最も低い

RIの種類

・スタンダードRI：変更の柔軟性が低い代わりに割引率が高い（最大72%）
・コンバーティブルRI：インスタンスファミリーの変更が可能（最大66%）

オンプレで例えるなら、スタンダードRIは「特定機種のサーバーをリース契約するイメージ」、コンバーティブルRIは「同じ予算枠内で機種変更できるリース」に近い感覚です。

RIの購入方法（AWSマネジメントコンソール）

1. EC2コンソールを開く
2. 左メニューから「リザーブドインスタンス」を選択
3. 「リザーブドインスタンスの購入」をクリック
4. インスタンスタイプ、プラットフォーム、期間、支払い方法を指定
5. 内容を確認して購入

AWS CLIで現在のRI一覧を確認するには、以下のコマンドを使います。

# リザーブドインスタンスの一覧を表示
aws ec2 describe-reserved-instances \
  --filters "Name=state,Values=active" \
  --query "ReservedInstances[*].[ReservedInstancesId,InstanceType,InstanceCount,Start,End]" \
  --output table

Savings Plansの基本

Savings Plansの仕組み

Savings Plansは、1時間あたりの利用金額（$/hr）をコミットする割引モデルです。RIと異なり、特定のインスタンスタイプに縛られません。

2019年に登場した比較的新しい仕組みで、AWSも現在はSavings Plansを推奨しています。

Savings Plansの種類

・Compute Savings Plans：EC2、AWS Fargate、AWS Lambdaに適用。インスタンスファミリー・リージョン・OS問わず最大66%割引
・EC2 Instance Savings Plans：特定のインスタンスファミリーとリージョンに限定。最大72%割引
・Amazon SageMaker Savings Plans：機械学習用途向け

Savings Plansの購入方法

1. AWS Cost Explorerを開く
2. 左メニューから「Savings Plans」→「推奨事項」を選択
3. AWSが利用実績から最適なプランを提案してくれる
4. コミット金額・期間・支払い方法を選んで購入

AWS CLIで現在のSavings Plans一覧を確認するコマンドはこちらです。

# Savings Plansの推奨事項を取得
aws savingsplans describe-savings-plans \
  --query "savingsPlans[*].[savingsPlanId,savingsPlanType,commitment,start,end]" \
  --output table

料金の仕組みと比較

両者の違いを表で整理します。東京リージョン（ap-northeast-1）のm6i.xlargeを1年間・全額前払いで比較した場合の目安です（2026年3月時点）。

ポイントは、割引率だけ見ればRIとEC2 Instance Savings Plansはほぼ同等ということです。差が出るのは「柔軟性」の部分です。

Savings Plansは利用金額ベースのコミットなので、インスタンスタイプを変更しても自動的に割引が適用されます。RIの場合は、購入時に指定したインスタンスタイプから変更すると割引が効かなくなるリスクがあります。

実務で役立つ選び方のポイント

RIを選ぶべきケース

・インスタンスタイプが確定していて、1年以上変更の予定がない
・マーケットプレイスで中古RIを売却する可能性がある（スタンダードRIのみ）
・既にRIで運用しており、管理体制が整っている

Savings Plansを選ぶべきケース

・インスタンスタイプの変更やリサイジングの可能性がある
・EC2以外にFargateやLambdaも利用している
・これから初めて割引プランを導入する（管理がシンプル）

実務上のおすすめ戦略

まずはCost Explorerの推奨事項を確認しましょう。過去の利用実績に基づいて、AWSが最適なプランと金額を提案してくれます。

私が現場で実践しているのは「段階的コミット」です。いきなり全ワークロード分を購入するのではなく、確実に使い続けるベースライン分だけをSavings Plansで購入し、ピーク分はオンデマンドやスポットインスタンスで対応します。

オンプレで言えば、常時稼働分はリース契約し、繁忙期の増設分はレンタルで対応するイメージです。

Cost Explorerで月別のコスト内訳を確認するCLIコマンドも紹介しておきます。

# 過去3ヶ月のEC2コストを月別に確認
aws ce get-cost-and-usage \
  --time-period Start=2026-01-01,End=2026-03-31 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --output json

よくあるトラブルと対処法

購入したRIが適用されていない

RIはアベイラビリティゾーン（AZ）指定で購入すると、そのAZで稼働するインスタンスにしか適用されません。リージョン指定で購入すれば、同一リージョン内のどのAZでも適用されます。新規購入時は「リージョン」スコープを選択するのが無難です。

Savings Plansの割引が想定より少ない

コミット金額が実際の利用金額を下回っている可能性があります。Cost Explorerの「Savings Plans利用率レポート」で、利用率が100%に近いかどうかを確認しましょう。利用率が常に100%であれば、追加購入を検討して良いタイミングです。

インスタンスタイプを変更したら割引が外れた

スタンダードRIで起きやすい問題です。インスタンスファミリーの変更が予想される場合は、コンバーティブルRIかSavings Plansを選んでおくと安全です。変更が発生してしまった場合は、不要になったスタンダードRIをRIマーケットプレイスで売却することも検討してください。

前払い後にインスタンスが不要になった

全額前払いで購入したRIは、途中解約しても返金されません。ワークロードの将来が不確実な場合は、前払いなし（No Upfront）を選ぶか、まず1年契約で様子を見るのが安全です。

本記事のまとめ

EC2のコスト削減には、リザーブドインスタンスとSavings Plansの2つの選択肢があります。

・RIは特定インスタンスを長期固定で使う場合に最大72%の割引
・Savings Plansは金額ベースのコミットで柔軟性が高く、初めての導入にも向いている
・まずはCost Explorerの推奨事項を確認し、ベースライン分から段階的に導入するのが実務上のベストプラクティス

オンプレ時代の「まとめ買い・リース契約」の感覚が、クラウドでもそのまま活かせます。まずは自分の環境の利用実績を確認するところから始めてみてください。