AWS(Amazon Web Services)の利用が拡大するにつれて、毎月のインフラコストが高騰し、「どのようにコストを最適化すべきか」と頭を悩ませている担当者様は少なくありません。
AWSでコスト削減を検討する際、真っ先に候補に挙がるのが「Savings Plans(SP)」と「リザーブドインスタンス(RI)」という2つの割引モデルです。しかし、両者は似ている部分も多く、「どちらを選べば自社にとって一番お得なのか」「運用にどのような違いが出るのか」が分かりにくいため、導入を迷ってしまうケースが多々見受けられます。
本記事では、AWSのコスト削減を目指すインフラエンジニアや情報システム担当者様に向けて、Savings Plansとリザーブドインスタンスの明確な違いから、それぞれのメリット・デメリット、そして自社の環境に合わせた最適な選び方までを徹底的に比較・解説します。
この記事を最後までお読みいただくことで、どちらのプランが自社に適しているのかを論理的に判断できるようになり、無駄のないコスト最適化を実現するための第一歩を踏み出せるはずです。
この記事はこんな人にオススメ!
- AWSの利用料を削減したいが、何から手をつければいいか迷っている方
- 「Savings Plans」と「リザーブドインスタンス」の違いと選び方を明確にしたい方
- 過去にRIを購入したことがあるが、今後の更新でSPに乗り換えるべきか検討している方
\ RI/SPを含むAWS全体のコスト削減を考えている方へ /
AWSのコスト削減に欠かせない「Savings Plans」と「リザーブドインスタンス」とは?
AWSをオンデマンド(従量課金)で利用し続けることは、システム構築の初期段階や需要が予測しにくい状況においては非常に有効です。しかし、システムが安定稼働し、常時稼働するサーバー(EC2など)が増えてくると、オンデマンド料金のままでは割高になってしまいます。
そこでAWSが提供しているのが、1年または3年という長期利用を約束(コミットメント)することで、オンデマンド料金から大幅な割引を受けられる制度です。その代表格が「Savings Plans(セービングプラン)」と「リザーブドインスタンス(RI)」です。
リザーブドインスタンス(RI)
2009年から提供されている、特定の条件(インスタンスタイプやリージョンなど)を指定して予約することで割引を受けるモデル。
Savings Plans(SP)
2019年に登場した、より柔軟な新しい割引モデル。「利用金額」をコミットすることで、条件の変更にも自動で割引が適用されます。
【比較表】Savings Plansとリザーブドインスタンスの5つの違い
Savings Plansとリザーブドインスタンスの違いを理解するためには、以下の5つのポイントに注目することが重要です。
まずは一目でわかる比較表をご覧ください。
| 比較ポイント | Savings Plans (SP) | リザーブドインスタンス (RI) |
| 対象サービス | EC2, Fargate, Lambda, SageMaker | EC2, RDS, ElastiCache, Redshift, OpenSearch |
| コミットメント単位 | 利用金額(例:1時間あたり10ドル) | インスタンスの稼働数(例:m5.largeを2台) |
| 柔軟性 | 非常に高い(自動で適用先が変更) | 制限あり(手動交換が必要な場合あり) |
| 最大割引率 | 最大72%(Compute SPは約66%) | 最大72% |
| 運用・管理手間 | ほぼ不要(自動適用) | 手間がかかる(構成変更時に見直し必要) |
それぞれの違いについて、さらに詳しく解説します。
1.対象となるAWSサービス
最も大きな違いの一つが、割引の対象となるAWSサービスです。
Savings Plansは、主にコンピュートリソース(EC2、Fargate、Lambda)と機械学習サービス(SageMaker)に特化しています。
一方、リザーブドインスタンスは、EC2に加えて、RDS(データベース)やElastiCache、Redshiftなど、幅広いサービスで利用可能です。
そのため、「RDSのコストを削減したい」という場合は、必然的にリザーブドインスタンス(RDS RI)を選択することになります。
2.コミットメント(契約)の単位(金額か、インスタンスか)
リザーブドインスタンスが「特定のインスタンスを、1時間あたり〇台稼働させる」という“リソース量”での契約であるのに対し、Savings Plansは「1時間あたり〇ドル分利用する」という“金額”での契約となります。
金額ベースであるSavings Plansのほうが、将来的な構成変更に対して圧倒的に柔軟に対応できます。
3.柔軟性(インスタンスファミリーやリージョンの変更)
システムの拡張やアーキテクチャの変更に伴い、インスタンスファミリー(例:m5からm6iへ)やOS、リージョンを変更したいケースは多々あります。
Savings Plans(特にCompute Savings Plans)の場合、これらの変更を行っても自動的に新しい環境へ割引が適用されます。
対してリザーブドインスタンスの場合、スタンダードクラスではこれらの変更ができません。
コンバーティブルクラスであれば変更可能ですが、手動での交換作業(Exchanges)が必要となり、運用負荷が高くなります。
4.割引率の比較
どちらも「1年または3年」「前払いなし・一部前払い・全額前払い」という支払いオプションを選択でき、条件を同一にした場合の最大割引率は最大72%で同等です。
ただし、Savings Plansの中でも最も柔軟な「Compute Savings Plans」を選択した場合の最大割引率は約66%となります。
柔軟性を取るか、わずかな割引率の差を取るかが判断の分かれ目となります。
5.運用・管理の手間
リザーブドインスタンスは、システム構成が変わるたびに「割引が適用されずに無駄になっていないか(カバレッジと使用率)」を監視し、必要に応じて手動で調整を行う必要があります。
一方、Savings Plansはアカウント内で最も割引率の高いリソースから自動的に適用されていくため、一度購入してしまえば日々の運用管理の手間を大幅に削減できます。
Savings Plans(SP)の特徴とメリット・デメリット
Savings Plansは、特定の利用金額(例:1時間あたり10ドル)を1年または3年の期間コミットすることで、オンデマンド料金から割引を受けることができる柔軟な料金モデルです。
<メリット>
圧倒的な柔軟性:インスタンスファミリー、サイズ、OS、リージョンを変更しても、割引が自動的に適用され続けます。
運用負荷の軽減:手動での変更作業が不要で、環境の変化に合わせて最適化されます。
<デメリット>
対象サービスが限定的:RDSなど、コンピュートリソース以外には適用できません。
3種類のSavings Plans(Compute, EC2 Instance, SageMaker)
Savings Plansには、用途に合わせて以下の3種類が用意されています。
- Compute Savings Plans:最も柔軟性が高い。EC2、Fargate、Lambdaに適用。
- EC2 Instance Savings Plans:特定リージョンとインスタンスファミリーをコミット。割引率はCompute SPより高い。
- SageMaker Savings Plans:SageMaker専用。
リザーブドインスタンス(RI)の特徴とメリット・デメリット
リザーブドインスタンス(RI)は、特定のインスタンスの稼働をコミットすることで割引を受けるモデルです。
<メリット>
対象サービスが幅広い:RDS、ElastiCache、Redshiftなど、主要DBサービスに適用可能。
最大割引率が高い:条件が合えば最大72%の割引を享受。
<デメリット>
柔軟性が低い:構成変更時に割引が無効になるリスクや、手動交換の手間がある。
RIの2つのクラス(スタンダードとコンバーティブル)
RIには、変更が一切できない代わりに割引率が高い「スタンダード」と、手動交換が可能だが割引率が少し下がる「コンバーティブル」の2種類があります。
結局どっち?目的別のおすすめの選び方
「Savings Plans」がおすすめなケース(現在の主流)
- 将来的にシステム構成や拡張の可能性がある場合(推奨)
- 運用管理の手間を極力減らしたい場合
- FargateやLambdaを活用したサーバーレス構成を含む場合
「リザーブドインスタンス」がおすすめなケース
- RDSなど、Savings Plans対象外のサービスを割引したい場合(必須)
- 数年間、構成を絶対に変えないと断言できる極めて安定した環境の場合
以下に、RI/SPのプランを選ぶ簡単な診断チャートをご用意しました。

RI/SPの判断に迷う方へ ~セミナーのご案内~
本記事では、Savings Plansとリザーブドインスタンスの違いや選び方を中心に解説しました。
実際に購入する際は、Cost Explorerの推奨額をどう見るか、どの程度のコミット額から始めるか、購入後に利用率・カバレッジをどう確認するかまで判断する必要があります。
RI/SPの活用や料金管理の見直しについては、セミナーでも解説しています。
導入時の注意点(買いすぎ・使い残しを防ぐには)
- 現在の利用状況の正確な把握:ベースラインを見極める。
- スモールスタート:最初から100%を目指さず、8割程度から始める。
- 不要リソースの削除:購入前にアイドル状態のインスタンスを整理する。
重要なのは、割引率だけで判断しないことです。
割引率が高くても、対象範囲が狭く、使い切れなければ結果的に無駄が出ます。逆に、割引率が少し低くても、対象範囲が広く、安定して適用される方が実務上は扱いやすいこともあります。
Savings Plans購入前に確認すべきこと
Savings Plansを選ぶ前には、まず現在のAWS利用状況を確認する必要があります。
EC2の利用が中心なのか、FargateやLambdaも使っているのか。特定のリージョンやインスタンスファミリーを長く使い続けるのか、今後構成変更がありそうなのか。ここを見ないまま選ぶと、割引制度のはずが固定費の増加につながることがあります。
特に確認したいのは、以下の4点です。
| 確認項目 | 見るべき内容 |
| 利用サービス | EC2だけか、Fargate・Lambdaも使っているか |
| 利用の安定性 | 毎月安定して使うベースラインがあるか |
| 構成変更予定 | インスタンスタイプ、リージョン、サービス構成を変える予定があるか |
| コミット額 | 使い切れる範囲で契約できるか |
Savings Plansは、過去の利用実績をもとに推奨事項を確認できます。
ただし、推奨額はあくまで過去の利用実績をもとにした参考情報です。
今後の構成変更や、一時的な利用増減を考慮せずにそのまま購入すると、使い切れないコミットが発生する可能性があります。
そのため、Savings Plansを検討する際は、まず「確実に使い続ける利用分」を見極めることが重要です。
まとめ
Savings Plansとリザーブドインスタンスは、どちらも強力な削減手段です。
コンピュートならSP、DBならRIという使い分けが基本となります。まずは自社の状況を可視化することから始めましょう。
【期間限定】AWSコストに関する30分の無料お悩み相談会実施中
「料金が増えている原因を知りたい」「RI/SPを買うべきか迷っている」「どこから見直せばよいか分からない」といったお悩みをAWS専任担当者がお伺いします。
ご相談内容に応じて、専門的な視点から確認すべきAWS利用状況や見直しの進め方をお伝えします。
まずは資料で整理したい方はこちら

