AWS Savings Plans実践設計入門｜CommitmentとCoverage RateをAWS Cost Explorerで最適化する購入戦略ガイド

クラウドのコスト削減に取り組むインフラエンジニアから「Savings PlansをReserved Instanceより柔軟と聞いて切り替えたのに、期待した削減効果が出なかった」という声を聞くことがある。実際に調べると、毎時コミットメント額（Commitment）の設定が勘に頼っていたり、3種類あるプランの違いを整理しないまま購入していたりするケースが多い。

AWSのSavings Plansは、正しい設計なしに購入するとコミットメント過剰（払いすぎ）またはCoverage不足（割引が十分に効いていない）のどちらかに陥る。逆に、過去の使用量データとAWS Cost Explorerの推奨機能を活用すれば、投資回収を見越した購入判断が可能になる。

この記事では、Compute Savings Plans・EC2 Instance Savings Plans・SageMaker Savings Plansの違い、CommitmentとCoverage Rateの正しい設計方法、AWS Cost Explorerを使った最適購入量の算出手順、1年 vs 3年・前払い vs 月払いの財務判断基準、そしてマルチアカウント環境でのSavings Plans共有設計を解説する。

Savings PlansとReserved Instanceの根本的な違い

Reserved Instance（RI）は「特定のEC2インスタンスタイプ・リージョン・テナンシーの組み合わせに対してコミットする」仕組みだ。オンプレのサーバー調達と発想が近く、「この構成を1年間使い続ける」という約束と引き換えに割引を受ける。

Savings Plansはそこから一歩進み、「毎時いくら分の使用量をコミットするか」という金額ベースのコミットメントに変わった。コミットした金額分の使用量は割引レートで計算され、超過分はオンデマンド料金が適用される。インスタンスタイプやリージョンを固定しないため、ワークロードの変化に追従しやすいのがメリットだ。

Savings Plansに移行しても、RDS・Redshift・ElastiCacheなどはRIが引き続き使われる点を押さえておこう。Savings Plansが対象とするのはEC2・Fargate・Lambda・SageMaker（プランによる）であり、RDSコスト削減は引き続きRIで対応する。

Savings Plansの3種類を使い分ける基準

1. Compute Savings Plans（最も柔軟）

EC2・AWS Fargate・AWS Lambdaの使用量に適用される。インスタンスファミリー・リージョン・OS・テナンシーを問わないため、ワークロードの変化や移行への対応力が最も高い。割引率はEC2 Instance SPより数ポイント低いトレードオフがある。

向いているケース:
・継続的に新しいインスタンスタイプ（Gravitonへの移行など）を試す環境
・複数リージョンにまたがるシステム
・FargateやLambdaの使用量がEC2と混在している構成

2. EC2 Instance Savings Plans（より高い割引率）

特定のEC2インスタンスファミリー（例: m5系）と特定リージョン（例: ap-northeast-1）に縛られる代わりに、Compute SPより高い割引率が得られる。インスタンスサイズ（large/xlarge/2xlarge等）やOSは問わない。

向いているケース:
・長期間安定して同一ファミリーを使い続けるDB・アプリサーバー層
・Graviton移行を完了しており、以後しばらくファミリーが固定できる環境
・コスト削減率を最大化したいフェーズ

3. SageMaker Savings Plans

Amazon SageMakerのML学習・推論・ノートブックインスタンス等に適用される。インスタンスタイプ・リージョン・コンポーネントを問わず、毎時ドル額のコミットメントで割引を受ける。SageMakerを大規模活用している環境では、Compute SPとSageMaker SPを組み合わせることで全体のCoverage Rateを高められる。

CommitmentとCoverage Rateの関係を理解する

Savings Plansで最もつまずきやすいのがこの2つの概念の関係だ。

Commitment（毎時コミットメント額）は、1時間あたり何ドル分の使用量をSavings Plansレートで処理するかという約束の量だ。たとえば $1.00/時間 のCompute SPを購入すると、その1時間内に発生したEC2・Fargate・Lambdaの使用料をオンデマンドとの差額分だけ割り引いた料金で処理される。実際の使用量が $0.80/時間 であれば $0.80 分を割引レートで処理し、残り $0.20 はコミットしていても繰り越せず無駄になる（未使用分は払い戻されない）。

Coverage Rate（カバレッジ率）は、「Savings Plansの割引が適用された使用量」が「割引対象となり得る全使用量」に占める割合だ。Coverage Rateが低いと、多くの使用量がオンデマンド料金のままになっており、割引の恩恵を十分に受けていない状態を意味する。

一般的な設計方針として、Savings PlansはベースロードとなるEC2等の最低使用量に合わせてCommitmentを設定し、ピーク帯の増加分はSpot Instanceやオンデマンドで賄うのが基本だ。全使用量の100%をSPで賄おうとすると、谷間の未使用分が発生しやすく、結果として割引効果が薄れる。

AWS Cost ExplorerでCommitment量を算出する手順

1. 過去のオンデマンド使用量を確認する

Cost Explorerの「サービス別コスト」ビューで過去30～90日のEC2・Fargate・Lambdaのオンデマンド使用料を確認する。時間帯別（1時間粒度）に見ることで「夜間・週末は使用量が少ない」「常時安定している」などのベースライン像が把握できる。

# AWS Cost Explorer API で過去30日の日次コストを取得する（AWS CLI）
aws ce get-cost-and-usage \
  --time-period Start=2026-09-21,End=2026-10-21 \
  --granularity DAILY \
  --metrics "UnblendedCost" \
  --filter '{"And":[
    {"Dimensions":{"Key":"PURCHASE_TYPE","Values":["On Demand"]}},
    {"Dimensions":{"Key":"SERVICE","Values":["Amazon EC2","AWS Lambda","AWS Fargate"]}}
  ]}' \
  --group-by '[{"Type":"DIMENSION","Key":"SERVICE"}]'

コンソールから確認する場合は「Cost Explorer → Savings Plans → 推奨事項（Recommendations）」が最も効率的だ。

2. Savings Plans推奨事項レポートを読む

Cost ExplorerのSavings Plans推奨事項画面には以下の情報が表示される。

・推奨購入額（$/時間）: 過去使用量から算出された毎時コミットメントの推奨値
・推定節約額（年間）: 今後同様のワークロードが継続した場合の試算節約額
・推定ROI: SP購入コストに対する節約額の割合
・推定Coverage: 購入後のカバレッジ率予測

レポートの「参照期間」は7日・30日・60日から選べる。使用量が安定している環境では30日または60日を選ぶと、一時的なスパイクに引きずられた過大なCommitmentを防ぎやすい。

3. 推奨Commitmentを自チームの計画に合わせて調整する

推奨値をそのまま購入するのではなく、以下の観点で補正することを推奨する。

・成長予定がある場合: 今後3か月でインスタンスを増設する計画があれば、推奨値の110～120%程度を目安に購入する
・縮小予定がある場合: リソース整理やマイグレーション後に使用量が減る見通しなら、推奨値の80～90%に抑えてコミットメント過剰を防ぐ
・段階的に購入する: 推奨値の60～70%を購入してCoverage Rateを1か月観察し、不足分を追加購入する段階購入でリスクを分散できる

想定例として考えてみよう。現在のEC2オンデマンド使用量が毎時約$6.50で、Cost Explorerの推奨CommitmentがCompute SP $4.20/時間と算出されたとする。いきなり$4.20/時間を購入するより、$3.50/時間から始めて翌月の実績を見てから$0.70/時間を追加購入する段階購入の方が、後悔するリスクが低い。

1年 vs 3年・前払い vs 月払いの財務判断

期間と支払い方法は割引率に直結する。一般的な傾向（2026年10月時点、インスタンスタイプやリージョンにより異なる）を示す。

注: 上記は傾向を示す参考値であり、実際はインスタンスタイプ・リージョン・OSによって異なる。購入前に必ずAWS公式のSavings Plans料金ページで確認すること（2026年10月時点）。

実務的なアプローチとして、大規模なクラウド移行の初年度は1年プランから入り、ワークロードが安定したことを確認してから3年プランに切り替える流れが多く採られる。移行直後はインスタンスタイプの変更や不要リソースの整理が続くため、3年プランで過剰コミットしてしまうリスクが高い。Compute SPを選んでおけば、期間中にGraviton移行が発生しても割引が引き続き適用されるのもメリットだ。

マルチアカウント環境でのSavings Plans設計

AWS OrganizationsのConsolidated Billing（一括請求）を使っている場合、Savings PlansはOrganization全体で共有される。管理アカウントまたはメンバーアカウントのどちらで購入しても、Organization内の対象サービス使用量に割引が自動的に適用される。

この仕組みを活かした実務設計の要点を整理する。

・管理アカウントで集中購入: 各ビジネスユニットのアカウントから集計した使用量ベースで管理アカウントが一括購入する。複数アカウントの使用量を束ねることで、個々のアカウントでバラバラに購入するよりCommitmentの過不足が吸収されやすい
・Coverage Rateはアカウントフィルタで確認: Cost Explorerでアカウントフィルタを使い、各アカウントのCoverage Rateを定期確認する。特定アカウントの使用量が急増してOrganization全体のCoverageが下がっていないかを月次でウォッチする
・メンバーアカウントのSP購入権限を制限: メンバーアカウントが独自にSPを購入するとCommitmentが分散・重複しやすい。SCPでSavings Plans購入アクションを管理アカウントのFinOpsロールにのみ許可し、一元管理する体制が望ましい

Consolidated Billingの設計全般についてはAWS Organizations一括請求（Consolidated Billing）設計入門も合わせて参照してほしい。

よくある設計ミスと対策

オンプレ調達の感覚のままSavings Plansを購入するとよく踏む落とし穴をまとめた。

ミス1: Cost Explorerの推奨値をそのまま全額購入する
推奨額は「過去の使用量を維持した場合の最適値」であり、ワークロード増減・不要リソース整理・Graviton移行計画などを織り込んでいない。推奨値はあくまで参考値として扱い、自チームの利用計画で調整することが必要だ。

ミス2: EC2 Instance SPで縛ったファミリーをGravitonに移行して割引が外れる
m5ファミリーでEC2 Instance SPを購入した後にm7g（Graviton3）に移行すると、EC2 Instance SPはm5ファミリーにのみ適用されるため、m7gの使用量には割引が効かなくなる。Graviton移行を計画している場合はCompute SPを選ぶか、EC2 Instance SPの更新タイミングを移行完了後に合わせるよう設計する。

ミス3: SPとRIが同一インスタンスに重複購入されている
RIとSPが同一インスタンスの使用量に重複して購入されていても、割引はいずれか一方だけが効く（AWSの内部ロジックで適用優先順位が決定される）。既存RIがある場合は、RI満了スケジュールとSP購入タイミングを突き合わせてCommitment重複を防ぐ。

ミス4: Coverage Rateを定期確認せずCommitmentが陳腐化する
ワークロードは変化する。6か月前に最適だったCommitment量も、インスタンス増設やサービス廃止を経てオーバー/アンダーになっていることがある。月次でCoverage Rateを確認し、乖離が大きければ翌更新時の補正計画を立てる習慣が必要だ。使用量の急変を早期に検知するにはAWS Cost Anomaly Detectionと組み合わせると効果的だ。

Savings Plansのコスト管理は、タグ設計と組み合わせることでどのプロジェクト・サービスに割引が効いているかを可視化しやすくなる。詳しくはAWSコスト配分タグ入門も参照してほしい。

本記事のまとめ

AWS Savings Plansの購入設計でおさえるべきポイントをまとめる。

Savings Plansはオンプレのライセンス調達とは異なり、データに基づく購入設計と定期的なCoverage Rateの見直しが欠かせない。RI時代の「とりあえず3年全額前払い」の感覚のままでは、コミットメント過剰または割引漏れのどちらかに陥りやすい。Cost Explorerの推奨機能を活用しつつ、自チームの利用計画を重ね合わせた継続的な最適化サイクルを回すことが、Savings Plans設計の本質だ。

AWS Cost Explorerの基本操作と予算管理についてはAWS Cost ExplorerとAWS Budgets入門も参照してほしい。