月10万ドルのAWS請求へ30%の割引を付けられるなら、年間36万ドルが浮くように見えます。ところが予約した時間単位コミットの2割を使わなければ、値引きではなく未使用の固定費です。クラウド予約割引の判断で難しいのは割引率ではありません。1年後も同じ場所で動く負荷と、半年後に消えるかもしれない負荷を分けることです。
AWS Savings Plansは、1時間当たりの利用額を1年または3年にわたり約束し、対象コンピュートへ割引料金を適用する仕組みです。Reserved InstancesはEC2などの条件を指定して割引を得る考え方で、種類や購入条件によって適用範囲と容量予約の扱いが違います。どちらも「前払いすれば安い」ではなく、将来利用への拘束を引き受ける契約です。
購入判断の単位は月額請求ではなく、毎時間ほぼ必ず使う基礎負荷です。日中だけ膨らむ負荷や季節ピークまで予約すると、夜間と閑散期に未使用コミットが残ります。
本記事は2026年9月4日にAWS公式ドキュメントを確認して作成しました。料金、対象サービス、割引率、返品条件はアカウント、リージョン、購入時点で変わるため、実際の購入画面と見積書を最終確認してください。
割引ではなく「毎時いくら使うか」の契約
月平均を時間別の基礎負荷へ分解します。
Savings Plansのコミットは月10万円という予算枠ではなく、1時間当たり何ドル使うかで表されます。24時間動く本番基盤へ10ドル／時をコミットすれば、深夜も休日も10ドル／時分の支払いが続きます。月末に利用が足りなかった時間を、翌月のピークへ繰り越すことはできません。
たとえば通常料金の対象利用が毎時10ドル、割引後のコミットが毎時7ドルだとします。毎時10ドル以上使い続ければ差額3ドルが節約です。しかし半分の時間しか対象利用がなければ、使わない時間にも7ドルを払い、年間の名目割引率と実効節約率は大きく離れます。
請求データを月合計だけで集計すると、この空白が見えません。Cost and Usage Reportを時間単位で集計し、各時間の対象利用を小さい順に並べます。P10、つまり全時間の90%で上回る負荷は基礎負荷の候補です。P50は半分の時間しか支えないため、初回購入の根拠としては攻めすぎです。
100万円使った月が続いたことと、毎時間同じ100万円相当を使ったことは別です。予約量は月平均ではなく時間別分布の下側から決めます。
Savings Plansは構成変更に強い
割引率と技術変更の自由度を交換します。
Compute Savings Plansは、対象となるEC2のインスタンスファミリー、サイズ、OS、テナンシー、リージョンが変わっても割引を適用しやすく、FargateやLambdaも対象に含まれます。コンテナ化、ARM移行、リージョン移転などがあり得る会社では、特定構成へ縛られにくいことが価値です。
EC2 Instance Savings Plansは特定リージョンとインスタンスファミリーへの条件が強い代わりに、Compute型より高い割引が示される場合があります。構成が3年間ほぼ変わらない基幹処理なら候補ですが、次世代インスタンス、Graviton、サーバーレスへ移行する計画があるなら、割引差より変更不能の原価が大きくなります。
AWSはSavings Plansについて、1年を365日、3年を1,095日と定義し、支払方法を全額前払い、一部前払い、前払いなしから選べると説明しています。前払いなしでも契約拘束が消えるわけではありません。資金の支払時期と利用義務を混同しないようにします。
柔軟性は無料ではありません。高い割引率を取る代わりに構成を固定するか、割引を少し譲って移行余地を残すかを、技術ロードマップで選びます。
Reserved Instancesは容量予約と割引を分けて読む
料金上の恩恵と起動できる保証を混同しません。
EC2 Reserved InstancesにはStandardとConvertibleなどの違いがあり、条件変更や交換の自由度が異なります。さらに、リージョン単位の割引適用と、Availability Zoneを指定する容量予約は同じ話ではありません。災害対策や繁忙イベントで「起動できること」を求めるなら、料金割引だけを見てはいけません。
Savings Plansは原則として料金上の恩恵であり、EC2容量を確保しません。特定のAvailability Zoneで必要台数を確実に起動したい場合は、オンデマンドキャパシティ予約などを別に設計します。割引商品を買ったから本番容量も予約されたと思い込むと、最も必要な日に起動できない可能性があります。
クラウド出口戦略を検討中なら、AWSに残る基礎負荷だけを切り出します。クラウド間で移せると言いながら3年コミットを増やせば、契約上の退出費が移行判断を歪めます。
料金の予約と容量の予約は別です。Savings Plansの購入額を増やしても、必要なAvailability Zoneの空きは確保されません。
推奨額は予測ではなく過去利用の要約
停止、移行、成長を人がシナリオへ加えます。
Cost Explorerの購入推奨は便利ですが、過去の利用を前提に算出されます。来月のサービス終了、予約済み移行、組織統合、リージョン撤退、値下げ交渉までは自動で知りません。直近30日がセール期間なら、そのピークを平常需要として提示することもあります。
購入前に、推奨期間に含まれる一時負荷を注記します。開発環境のつけっぱなし、データ移行、負荷試験、障害迂回、買収先の暫定基盤を除外し、逆に契約済みの新規顧客やリリース予定で増える負荷を別シナリオとして加えます。
予測は一点ではなく、縮小、基準、成長の三本にします。縮小シナリオでも残る金額だけを初回コミット候補にし、成長分はオンデマンドで観測してから追加購入します。AI計算資源の費用最適化でも、検証中のGPUと本番の定常負荷を分けます。
推奨画面は「過去と同じなら」の計算です。購入承認には、次の12か月で消える負荷と増える負荷を人が追記します。
利用率とカバレッジは反対方向へ動く
購入量と割引適用範囲の釣り合いを読みます。
Savings Plansの利用率は、購入したコミットのうち対象利用へ使われた割合です。カバレッジは、対象利用のうち割引で覆えた割合です。小さく買えば利用率は100%に近づきますが、カバレッジは低いままです。大きく買えばカバレッジは上がる一方、未使用が出て利用率が落ちます。
両方を100%へ近づけること自体を目標にしません。変動の大きいサービスでは、利用率98%、カバレッジ60%でも合理的です。余った40%のオンデマンド料金は、需要変動と退出自由を買う保険料と考えられます。
実効節約額は、オンデマンド換算額からSavings Plans適用後料金と未使用コミットを引いて計算します。割引適用額だけを成果にすると、使っていない前払いを隠します。サービス別、環境別、プロダクト別に配賦し、誰の判断で未使用が生じたかも記録します。
利用率とカバレッジを同時に見て、余らせずに覆える基礎負荷を探します。
利用率100%だけを追うと購入不足、カバレッジ100%だけを追うと過剰購入になります。実効節約額と変更余地を並べて判断します。
25%、50%、75%と段階購入する
購入ミスと需要変化の損失を小さくします。
初回に3年分を一括購入する必要はありません。確実性の高いP10基礎負荷の25%を1年契約で購入し、1か月後に利用率、カバレッジ、未使用時間を確認します。変化がなければ50%、75%へ積み増します。満期月を分散すると、毎年一度に全量を再契約するリスクも減ります。
購入権限は日常の運用権限から分けます。AWSの返品制度は、購入後7日以内、同じ暦月、時間コミット100ドル以下などの条件を満たす購入ミスに限られ、回数制限もあります。通常の見通し変更を自由に解約できる制度ではありません。UTC基準の月末をまたぐと条件を外れる点も購入手順へ入れます。
承認票には、商品種別、期間、支払方法、毎時コミット、対象アカウント、購入根拠期間、除外負荷、技術変更、損益分岐、最大未使用額、返品期限を記載します。クリック一つの購入でも、1年分の固定費を作る契約です。
数字を入れて比べます。オンデマンド換算で毎時100ドルの利用があり、割引後コミットを毎時70ドルで買う案を考えます。全時間で対象利用が続けば1時間30ドル、年間約26万2,800ドルの差です。ところが利用が半減し、対象利用の割引後相当が毎時35ドルしかなければ、毎時35ドル分のコミットが余ります。年間の未使用は単純計算で約30万6,600ドルとなり、当初の節約見込みを上回ります。
実際の適用順序と料金はサービス、アカウント、商品で異なりますが、この簡易試算は承認会議に役立ちます。節約シナリオだけでなく、需要50%減、予定より6か月早い移行、為替変動の三つを置き、最大損失を事業責任者が引き受けられるかを確認します。
返品可能なのは限定的な購入ミスです。「需要が減ったから戻す」を前提にせず、縮小シナリオでも使い切れる量から買います。
退出条件を先に決める
満期前に更新しない負荷を技術計画から選びます。
毎月のレビューで、利用率が90%を下回った理由を、需要減、技術移行、タグ欠落、適用優先順位、アカウント移動へ分けます。閾値を2か月連続で割ったら新規購入を停止し、技術部門と原因を解消します。未使用を埋めるためだけに不要なインスタンスを起動してはいけません。
コミット満期の120日前には、更新しない負荷を決めます。サービス終了、Kubernetes集約、ARM移行、サーバーレス化、他社クラウド移転を反映し、自動更新のように前年額を再購入しません。FinOpsのユニットエコノミクスでは、財務だけでなくエンジニアと事業責任者を同じ会議へ入れます。
新規サービスは、最初の8〜12週間をオンデマンドで観測します。日次の成長率が高くても、毎時間使う下限が安定するまでは予約しません。小さなオンデマンド差額より、方向転換できる価値を優先します。
連結請求では、割引がどのアカウントへ適用されたかも追います。中央チームが購入し、利用部門へオンデマンド単価で配賦すると、会社全体の節約が中央だけに残り、各部門は削減する理由を失います。反対に未使用を購入部門だけへ負わせると、共通最適化が進みません。割引前原価、割引配賦、未使用コミットを分け、購入ルールを組織へ公開します。
障害対応で別リージョンへ一時移動した時、通常のカバレッジが落ちても購入失敗とは限りません。復旧のために払ったオンデマンド差額を事故費として切り分けます。毎月の利用率だけで運用担当を評価すると、安全な切替えをためらうため、平常時と緊急時のKPIを分けます。
購入会議では「最大72%割引」の見出しを外し、自社の直近利用へ当てた実効率を先頭へ置きます。最大値は特定商品・期間・支払条件の表示であり、自社の節約保証ではありません。候補ごとに毎時コミット、未使用上限、満期日、技術変更の影響を一行で説明できる案だけを承認します。
満期を分散し、技術変更を反映できる再判断の窓を毎四半期残します。
まとめ
使い切れる最小コミットから始めます。
Savings Plansは構成変更へ強く、Reserved Instancesは指定条件と容量予約の違いを理解して使います。どちらも1年または3年の支払いを伴うため、最大割引率より、確実に残る毎時負荷へ合わせることが先です。
時間別のP10負荷を作り、停止・移行予定を除き、25%から段階購入します。利用率、カバレッジ、実効節約額を一緒に追い、満期前に更新しない条件を決めます。
クラウド予約割引の正解は最安率ではありません。事業と技術が変わっても使い切れる最小コミットを買い、次の判断機会を残すことです。
参考情報
契約、適用、監視、返品をAWS公式資料で確認します。
以下は2026年9月4日に確認したAWS公式情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
QSavings Plansは途中解約できますか？
A通常の需要減を理由に自由解約できる商品ではありません。AWSには購入直後のミスを戻す限定制度がありますが、7日以内、同一暦月、時間コミット100ドル以下などの条件があるため、縮小時も使える量から購入します。
QSavings Plansを買えばEC2容量も確保されますか？
A確保されません。Savings Plansは料金上の割引です。特定Availability Zoneの容量が必要なら、オンデマンドキャパシティ予約やReserved Instancesの条件を別に確認します。
Q利用率とカバレッジは何が違いますか？
A利用率は購入コミットをどれだけ使ったか、カバレッジは対象利用のどれだけを割引で覆ったかです。小さく買えば利用率は上がり、買い増すほどカバレッジは上がります。
Q3年全額前払いが最も得ですか？
A名目割引が高くても、技術移行や需要減で使わなければ損失になります。縮小シナリオの実効節約額、資金コスト、変更自由度を含めて比べます。
QAWSの推奨額をそのまま買ってよいですか？
A過去利用の要約として使い、停止予定、一時負荷、リージョン移転、製品成長を追記します。推奨期間と時間別下限を確認し、25%程度から段階購入する方が安全です。
Q新サービスはいつ予約割引を買いますか？
A8〜12週間ほどオンデマンドで観測し、時間別の下限が安定してからです。平均利用や短期成長率だけでなく、終了・縮小シナリオでも残る負荷を基準にします。
