AWS Savings Plans

1 年または 3 年の利用コミットメントと引き換えに EC2、Fargate、Lambda の料金を割り引く柔軟なコスト削減モデル

概要

AWS Savings Plans は、一定額の利用を 1 年または 3 年間コミットすることで、オンデマンド料金より割安な単価が適用される料金モデルです。リザーブドインスタンス (RI) と異なり、インスタンスファミリー、リージョン、OS、テナンシーの変更に柔軟に対応できます。2026 年 9 月時点では Compute Savings Plans、EC2 Instance Savings Plans、SageMaker AI Savings Plans、Database Savings Plans の 4 種類があり、コミットメント額を超えた使用分はオンデマンド料金が適用されます。

Savings Plans の種類と RI との比較

Compute Savings Plans は最も柔軟なタイプで、EC2FargateLambda のすべてに適用されます。インスタンスファミリー、リージョン、OS、テナンシーを自由に変更しても割引が維持されるため、ワークロードの構成が頻繁に変わる環境に適しています。割引率は EC2 Instance Savings Plans より低くなりますが、柔軟性とのトレードオフとして合理的です。EC2 Instance Savings Plans はリージョンとインスタンスファミリーを固定する代わりに、Compute Savings Plans より高い割引率が適用されます。同一ファミリー内であればインスタンスサイズ (m5.large → m5.2xlarge)、OS (Linux → Windows)、テナンシー (共有 → 専有) の変更は自由です。ワークロードが特定のリージョンとインスタンスファミリーに集中している場合に最もコスト効率が高くなります。このほか、SageMaker AI Savings Plans は SageMaker AI のインスタンス利用に、Database Savings Plans は AuroraRDSDynamoDB などのデータベースサービスに適用されます (2026 年 9 月時点)。RI との比較では、AWS 公式ドキュメントは割引の上限を EC2 Instance Savings Plans と Standard RI、Compute Savings Plans と Convertible RI でそれぞれ同水準としていますが、RI は特定のインスタンス構成に紐づくため変更の柔軟性で劣ります。Convertible RI は割引そのものは対象インスタンスに適用されますが、インスタンスファミリーや OS、テナンシーを変えた場合に割引を追随させるには手動の交換手続きが必要です (Savings Plans は構成変更に自動で追随します)。新規購入では Savings Plans を第一選択とし、RI は既存の契約を維持する場合に限定する形が扱いやすくなります。各タイプの割引率の上限は AWS の料金改定で変わるため、購入前に AWS 公式の料金ページで対象リージョンとインスタンスファミリーの値を確認してください。

コミットメント額の算出と購入戦略

Savings Plans の購入で最も重要なのは、適切なコミットメント額の算出です。コミットメント額が高すぎると未使用分が無駄になり、低すぎると割引の恩恵を最大化できません。Cost Explorer の Savings Plans 推奨機能は、過去の使用パターンを分析して最適なコミットメント額を提案します。推奨に従う場合でも、直近 30 日間だけでなく 7 日間と 60 日間の推奨も比較し、季節変動やプロジェクトの増減を考慮して判断します。購入戦略として、初回は推奨額を下回る水準から始め、数か月の実績を見て追加購入する段階的アプローチが安全です。全額前払い、一部前払い、前払いなしの 3 つの支払いオプションがあり (Database Savings Plans は 1 年契約・前払いなしのみ)、全額前払いが最も割引率が高くなります。ただし、キャッシュフローの観点から前払いなしを選択し、割引率の差を許容するケースも多いです。Compute Savings Plans と EC2 Instance Savings Plans は併用可能で、安定したベースラインには EC2 Instance Savings Plans (高割引)、変動分には Compute Savings Plans (高柔軟性) を割り当てるハイブリッド戦略がコスト効率に優れます。

利用率の監視と契約更新の判断

Savings Plans を購入した後は、利用率 (Utilization) とカバレッジ (Coverage) の 2 つの指標を継続的に監視します。利用率はコミットメント額に対する実際の使用額の割合で、100% に近いほど無駄がありません。利用率が低い水準で続く場合は、次回の更新時にコミットメント額を引き下げます。どの水準を下限とみなすかは AWS が定めているわけではないため、自社で許容ラインを決めて監視すると判断がぶれません。カバレッジはオンデマンド使用額全体に対する Savings Plans 適用額の割合で、カバレッジが低い場合は追加購入の余地があります。Budgets で Savings Plans 利用率予算とカバレッジ予算を設定し、閾値を下回った場合にアラートを受け取る構成が推奨されます。契約更新の判断では、1 年契約と 3 年契約の選択が重要です。一般に 3 年契約は 1 年契約より割引率が高くなりますが、3 年間のワークロード予測が必要です。クラウドネイティブへの移行途中でアーキテクチャが大きく変わる可能性がある場合は、1 年契約を繰り返す方がリスクが低くなります。Savings Plans は期限が来ても自動では更新されず、継続する場合は購入を事前に予約 (キュー登録) して切れ目なくつなぎます。更新時期には改めて使用パターンを分析し、最適なプランを再購入するのが基本です。

参考資料 (AWS 公式)

本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。

本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。

共有するXB!