DEVELOPER’s BLOG

技術ブログ

EC2・Fargateコスト最適化:Savings Plansとリザーブドインスタンスの使い分けガイド

2025.12.25 Momoka FUJIEDA
AWS
EC2・Fargateコスト最適化:Savings Plansとリザーブドインスタンスの使い分けガイド

  1. はじめに
  2. Savings Plansとリザーブドインスタンスの基本
  3. EC2とFargate(ECS/EKS)に対する割引プランの選び方
  4. まとめ

1. はじめに

EC2やFargate(ECS/EKS)を長期間運用する場合、Savings Plansやリザーブドインスタンスによる割引を適切に活用し、コストを抑えることが欠かせません。
本記事では、EC2・Fargate を対象に、Savings Plansとリザーブドインスタンスの基本を整理し、それぞれの特性を踏まえた割引プランの選び方を解説します。



2. Savings Plansとリザーブドインスタンスの基本

Savings Plansとは

EC2やFargateなどの複数のコンピューティングリソース全体の使用量に対し、割引が適用される仕組みです。
Billing and Cost Management(請求とコスト管理) から購入することができます。

使用後の料金に対して割引が適用されるのではなく、将来利用するコンピューティング使用量を事前に予測し、1時間あたりの使用量($)を「購入コミットメント」として設定することで割引が適用されます。

購入した使用量までは割引料金が適用され、超えた分はオンデマンド料金で請求されます。

(購入例)

Saving Plansの購入画面

EC2とFargateに関連するプランは下記の2つです。

■ Compute Savings Plans
EC2・Fargate を使用した料金全体に対して、割引が適用されます。
リージョンやインスタンスタイプ、OSを購入時に指定する必要はありません。

■ EC2 Instance Savings Plans
EC2の使用料金に対して、割引が適用されます。
リージョンとインスタンスファミリーを購入時に指定する必要がありますが、前述のプランと比べてより高い割引率が適用されます。


リザーブドインスタンスとは

EC2の画面から操作できる、購入オプションです。

リザーブドインスタンスは、購入時にインスタンスタイプ・リージョン・OS・期間を指定し、それに一致するインスタンスに対して割引が適用されます。

Savings Plansのように「時間単位($/時間)」での利用金額に対して割引が適用される仕組みとは異なります。

(購入例)
EC2 RIの購入画面

リザーブドインスタンスには、柔軟性と割引率のバランスによって2つのタイプが用意されています。

これらの上位にリージョナルリザーブドインスタンスとゾーンリザーブドインスタンスという区分もありますが、これは主にはスコープの違いによるものです。本記事ではリザーブドインスタンスとSavings Plansの比較に焦点を当てるため、説明は割愛します。

■ スタンダードリザーブドインスタンス
一度購入すると、インスタンスタイプやOSなどの変更が基本できません。
購入後に不要になった場合、マーケットプレイスに出品ができます。
柔軟性が低い反面、割引率は高いのが特徴です。

■ コンバーティブルリザーブドインスタンス
インスタンスタイプ・OS・テナンシーなど多くの属性を交換によって変更できます。
ただし、交換時にはオンデマンド料金ベースで、交換後のリザーブドインスタンスの総額が交換前と同等かそれ以上であることが前提条件となります。
また、交換は自動ではなく手動対応が必要となるため、柔軟性が高い反面、割引率は前述のプランと比べてやや低く設定されています。


購入期間と支払いオプションについて

EC2やFargateを長期間利用する場合、Savings Plansまたはリザーブドインスタンス等の活用が基本となります。

これらの割引プランでは、購入期間を 1 年または 3 年 から選択でき、 あわせて 支払い方法(全額前払い・一部前払い・前払いなし) を選ぶことが可能です。

一般的に、購入期間が長く、前払い額が多いほど割引率は高くなります。
そのため、3 年かつ全額前払いを選択した場合が、最も割引効果が高くなります。



3. EC2とFargate(ECS/EKS)に対する割引プランの選び方

下記のフローチャートを参考に割引プランを決定します。

RI・SPのフローチャート図


購入時の計算はリザーブドインスタンスが容易

リザーブドインスタンスはインスタンスタイプなどを直感的に選択するだけで購入できるため、
手続きが比較的簡単というメリットがあります。

一方で、Savings Plansは、どのリソース(EC2・Fargate・Lambda)で、どの程度のvCPU・メモリをどれくらいの時間使用するかを見積もる必要があるため、購入時に入力する購入コミットメントの計算がやや複雑です。

例えば、Fargate2台が下記の設定で常時稼働しているケースを想定します。


  【 Fargate(ECS)】

  ■ リージョン:東京
  ■ タスクサイズ: vCPU:1、メモリ:2GB
  ■ 常時稼働タスク数:2タスク
  ■ 稼働時間:24時間/日

上記の例におけるオンデマンド料金は、以下のとおりです。

 
 vCPU:$0.05056 / vCPU・時間
 メモリ:$0.00553 / GB・時間

1タスクあたりの時間単価は、

 
 vCPU:1 × $0.05056  = $0.05056
 メモリ:2 × $0.00553 = $0.01106
 -----------------------------------
 合計 ≒ $0.061 / 時間

よって2タスク分の利用額は、

 
 $0.061 × 2 = $0.122 / 時間
 

だとわかります。

この値から、
将来のタスク減少を考慮し、購入分の未消化リスクを抑えたい場合は、70%程度の $0.085 / 時間。
タスクが安定して稼働する見通しなら、90%程度の $0.11 / 時間。

このように予測・計算した値を購入コミットメントとします。


柔軟性の観点では Savings Plansが有利

Savings Plansはインスタンスタイプやリージョン、OS に縛られず使えるため、リザーブドインスタンスより柔軟性が高いです。

そのため、購入後にコンピューティングリソース構成の変更が見込まれる場合には、まずはSavings Plansを選択しておくのも有効な方法です。



4. まとめ

以上の流れを参考にしていただくことで、EC2やFargateのどちらの場合も、迷わず割引プランを選択することができます。

※ FargateにSavings Plansを適用した際の費用の見積もりは、こちらの記事で解説しています。

弊社では、Savings Plans / リザーブドインスタンスの購入提案を含めたコスト削減のご提案も承っております。
お気軽にお問い合わせください。




X(旧Twitter)・Facebookで定期的に情報発信しています!

関連記事

AWS Security Incident Response解説!AIが99%のノイズを自動削減

「セキュリティアラートの50%以上は未対応のまま放置されている」 2023年にIBM と Morning Consultが実施した調査の結果は、セキュリティチームが直面する厳しい現実を示しています。 その原因は、リソース不足と、日々大量に届く通知によるアラート疲労。 アラートが発生しても実際に確認すればほとんどが問題ない。にもかかわらず毎日大量のアラートが通知される。 このような状況では「どうせいつもの過検知だろう」と油断が生まれ、アラートが実質的には機能

記事詳細
AWS Security Incident Response解説!AIが99%のノイズを自動削減
AWS SRE 生成AI
AWSマルチアカウント管理とは?AWS OrganizationsとIAM Identity Centerを解説

目次 はじめに 1.AWSアカウントは環境ごとに作る 2.シングルアカウント構成 3.マルチアカウント構成 + AWS Organizations 4.ユーザー管理:IAM Identity Center(旧SSO) 5.【実例】IAM Identity Centerでユーザーを一元管理する おわりに はじめに AWSでクラウドリソースを作成する際、必ず作成するのが「AWSアカウント」です。しかし、プロジェクトが成長するにつれ、単一

記事詳細
AWSマルチアカウント管理とは?AWS OrganizationsとIAM Identity Centerを解説
AWS
EOL管理のコストと手間を解消!Amazon InspectorとAIで実現する低負担な方法

目次 はじめに:EOL管理、やった方がいいのはわかっているけど...... 1.EOL管理には、3つの壁がある 2.Amazon Inspectorと生成AIで実現する、第三の選択肢 3.実際にやってみました 4.低コスト・低負担で運用を続けられる 結論:EOL管理は、思っているほど大変じゃない はじめに:EOL管理、やった方がいいのはわかっているけど...... EOL(End of Life)をしっかり管理することは、ソフトウェアの

記事詳細
EOL管理のコストと手間を解消!Amazon InspectorとAIで実現する低負担な方法
AWS 生成AI
DevOps Agentとは?マルチクラウド時代の自律型AI運用ガイド

マルチクラウドやハイブリッド環境が当たり前になったいま、SREやDevOpsチームの皆様は、こんな悩みを抱えていないでしょうか。 サービスと環境が増え続け、全体像が誰の頭にもない 各社クラウド・オンプレが入り組み、障害原因の切り分けに時間がかかりすぎる デプロイ起因の障害はコード変更まで追うのが大変 こうした課題を打破するのが、2026年3月に一般提供開始された「AWS DevOps Agent」です。 本記事では、その概要とAIエージェントを真の戦力にす

記事詳細
DevOps Agentとは?マルチクラウド時代の自律型AI運用ガイド
AWS SRE 生成AI

お問い合わせはこちらから