AWS Savings Plansの選び方と購入手順｜東京の実割引率とコミット額の決め方

AWS Savings Plansは、1年または3年のあいだ「1時間あたり何ドル分を使うか」を先に約束する代わりに、オンデマンドより低い単価でEC2・Fargate・Lambdaなどを使える割引の仕組みです。公式ドキュメントは最大72%の割引をうたっています。ただ、この上限はEC2 Instance Savings Plansの3年全額前払いの数字で、東京リージョンのm7i.largeを1年・前払いなしのCompute Savings Plansで買った場合の割引は24.3%にとどまります。Lambdaに至っては10%です。この記事では、東京の実単価から割引率を出すPythonスクリプト、コミット額の決め方、適用順序、返品条件、利用率監視までを、AWS公式の一次情報に沿って整理します。

まとめ｜Savings Plansを買ってよい条件とオンデマンドで待つべき条件

判断の軸は割引率ではありません。1年間、どの時間帯でも下回らない支出の床がどこにあるか、です。コミット額をその床に合わせれば、Savings Plansは損をしない仕組みになります。床を超えて積むと、使わなかった時間のぶんを払い続けることになり、1年・前払いなしのCompute Savings Plansなら、コミット額の約75.7%を下回る利用が続いた時点でオンデマンドより高くつきます。

実務で押さえる順序は3つです。まずCompute Optimizerなどでインスタンスサイズを見直す。次にCost Explorerの推奨APIで60日分の実績からコミット額を出し、推奨値ではなく最小時間帯の支出を基準に金額を決める。最後に、購入後は利用率を日次で監視する。構成が固まっていない環境、Spot中心の環境、半年以内に基盤を移す計画がある環境は、今は買わずにオンデマンドのまま待つのが正解です。

4種類のSavings Plansの割引上限と適用範囲をリザーブドインスタンスと比較

どのプランを買うかで、割引の上限と効くサービスの範囲が変わります。

4種類のSavings Plansで比較する対象サービスと割引上限

Savings Plansの種類に関する公式ドキュメント（2026年10月時点）が示すCompute・EC2 Instance・Database・SageMaker AIの違いを、対象サービスと割引上限で比較したのが次の表です。

一般的なWebシステムで候補になるのは上の2つです。Compute Savings PlansはEC2からFargateへ移しても、東京から大阪へ移しても割引が続きます。EC2 Instance Savings Plansは「東京のm7i」のようにリージョンとファミリーを固定する代わりに割引が深くなります。

Database Savings Plansは扱いが別です。Savings PlansのFAQによれば、対象は第7世代以降のインスタンスに限られ、期間は1年のみ、支払いは月払いです。db.t4gやdb.r6gで動いているRDSには効かないため、RDSの費用を下げたい場合はRDSの料金を東京リージョンの実額で計算した記事で世代更新の要否を先に確かめてください。

リザーブドインスタンスとの違いは金額コミットとキャパシティ予約の有無

Savings PlansとRIを比較した公式ページは、Compute Savings Plansの割引上限がコンバーティブルRIと同じ66%、EC2 Instance Savings PlansがスタンダードRIと同じ72%だと整理しています。違いは縛る対象です。RIは「m5.largeを3台」のように構成を約束しますが、Savings Plansは「1時間あたり0.39ドル分」のように金額を約束します。

同じページには、見落とされやすい注記が並びます。Savings Plansはキャパシティ予約を提供しない。Spotの使用量とRIが適用済みの使用量には適用されない。期間中の解約はできない。特定のAZで起動枠を確実に押さえたい要件があるなら、オンデマンドキャパシティ予約を別に確保し、その上にSavings Plansを重ねる構成になります。RI側の購入手順と正規化係数の考え方は、兄弟記事のリザーブドインスタンスの購入判断と適用条件で扱っています。

東京リージョンのm7i.largeで1年と3年の実割引率をPythonで算出

「最大72%」は条件が最も有利な組み合わせの数字です。自社で使うインスタンスの実際の割引率は、単価を取り出して計算しないと分かりません。

Price List APIで東京の通常単価と割引単価を取得するスクリプト

AWSは料金データを認証不要のPrice List APIで公開しており、Savings Plansの単価も同じ仕組みで取得できます。次のスクリプトは、東京リージョン・Linux・共有テナンシーのm7i.largeについて、オンデマンド単価と全12通りのSavings Plans単価を並べ、割引率を出します。Python標準ライブラリだけで動きますが、EC2とSavings Plansの東京オファーはそれぞれ約400MBあるため、メモリに余裕のある環境で実行してください。

import json
import urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"
REGION = "ap-northeast-1"
TARGET = "APN1-BoxUsage:m7i.large"  # 東京・Linux・共有テナンシーの m7i.large


def load(path):
    with urllib.request.urlopen(BASE + path) as res:
        return json.load(res)


# 1) オンデマンド単価（AmazonEC2 の東京オファー）
ec2 = load(f"/offers/v1.0/aws/AmazonEC2/current/{REGION}/index.json")
od = None
for sku, p in ec2["products"].items():
    a = p["attributes"]
    if (a.get("usagetype") == TARGET and a.get("operation") == "RunInstances"
            and a.get("capacitystatus") == "Used" and a.get("preInstalledSw") == "NA"):
        for term in ec2["terms"]["OnDemand"][sku].values():
            for dim in term["priceDimensions"].values():
                od = float(dim["pricePerUnit"]["USD"])
print(f"On-Demand {TARGET}: {od} USD/h (version {ec2['version']})")

# 2) Savings Plans 単価（AWSComputeSavingsPlan の東京オファー）
idx = load("/savingsPlan/v1.0/aws/AWSComputeSavingsPlan/current/region_index.json")
url = next(r["versionUrl"] for r in idx["regions"] if r["regionCode"] == REGION)
sp = load(url)
for plan in sp["terms"]["savingsPlan"]:
    for rate in plan["rates"]:
        if rate["discountedUsageType"] == TARGET and rate["discountedOperation"] == "RunInstances":
            price = float(rate["discountedRate"]["price"])
            print(f"{plan['description']:<60} {price:.5f}  -{(1 - price / od) * 100:.1f}%")

TARGETを「APN1-BoxUsage:m7g.large」などに書き換えれば、別のインスタンスタイプでも比較できます。

東京の割引率24.3%から60.6%を分ける契約期間と前払い条件の比較

2026年10月1日に上のスクリプトを実行した結果です（EC2オファー version 20260925174521、Savings Plansオファー version 20260929170952）。m7i.largeのオンデマンド単価は1時間0.1302ドルでした。割引率はComputeの前払いなし1年で24.3%、EC2 Instanceの全額前払い3年で60.6%という結果です。

1つ目に、期間の差が支払い方法の差よりはるかに大きいこと。前払いなしのまま1年を3年にすると割引は24.3%から48.0%へ倍近くになり、1年のまま全額前払いにしても29.3%にしかなりません。2つ目に、ComputeとEC2 Instanceの差が1年で9.4ポイントあること。ファミリーを変える予定がない本番基盤なら、柔軟性に9ポイント強を払う理由は薄いと判断できます。公式のCompute Savings Plansの料金ページでも同じ単価を画面で確認できます。

FargateとLambdaの浅い割引とLambdaの3年契約でも同率の条件

Compute Savings Plansの同じオファーファイルからFargateとLambdaの単価も取り出し、東京のオンデマンド単価（AmazonECS・AWSLambdaのオファー）と比べました。

Lambdaは3年でも1年と同じ単価で、しかも下がるのは実行時間だけです（リクエスト料金は割引0%）。Lambda中心の構成では、先にLambdaの料金を東京リージョンの実額で計算する手順でメモリ割当やArm移行の余地を確かめたほうが、下げ幅は大きくなります。Fargateも1年では15%なので、ECS on EC2との比較はECS・EKS・Fargate・Lambdaの選び方で整理した判断軸と合わせて考えてください。

Cost Explorerの推奨APIで1時間あたりのコミット額を決める手順

コミット額は勘で決めるものではありません。過去の使用実績から、AWS側が推奨値を計算してくれます。

インスタンス増減後の推奨再生成と60日実績を指定した推奨取得の手順

推奨値は定期的に更新されますが、直近でインスタンスを増減した場合はstart-savings-plans-purchase-recommendation-generationで再計算を依頼できます。再生成は一括請求ファミリーあたり1日3回までです。完了予定時刻が返るので、それを過ぎてからget-savings-plans-purchase-recommendationで推奨を取得します。

# 1. 推奨の再計算を依頼（1日3回まで）
aws ce start-savings-plans-purchase-recommendation-generation --region us-east-1

# 2. Compute SP・1年・前払いなし・60日実績の推奨を取得
aws ce get-savings-plans-purchase-recommendation \
  --region us-east-1 \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope PAYER \
  --query "SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[].[HourlyCommitmentToPurchase,CurrentMinimumHourlyOnDemandSpend,CurrentAverageHourlyOnDemandSpend,EstimatedAverageUtilization,EstimatedSavingsPercentage]" \
  --output table

コマンドリファレンスによれば、–savings-plans-typeはCOMPUTE_SP、EC2_INSTANCE_SP、SAGEMAKER_SP、DATABASE_SPの4値、–lookback-period-in-daysはSEVEN_DAYS、THIRTY_DAYS、SIXTY_DAYSの3値です。7日を選ぶと月末バッチなどの一時的な山を拾うため、定常の床を見るなら60日を選びます。

コミット額はSavings Plans単価建てで最小時間帯の支出を基準にする

ここで誤解が多いのが、コミット額の単位です。約束するのはオンデマンド換算の金額ではなく、Savings Plans単価で計算した金額になります。m7i.largeを4台常時動かしているなら、オンデマンドでは1時間0.5208ドルですが、1年・前払いなしのCompute Savings Plansで全量を覆うコミット額は0.09862ドル×4台で0.39448ドルです。月730時間で換算すると、オンデマンドの380.18ドルに対して287.97ドルとなり、差は月92.21ドルです。

推奨値のHourlyCommitmentToPurchaseは、平均的な使用量を基準に計算された値です。夜間にオートスケーリングで台数が減る環境では、平均に合わせると夜の時間帯のコミットが余ります。出力に並べたCurrentMinimumHourlyOnDemandSpend（期間中の最小時間帯のオンデマンド支出）に割引後の比率を掛けた額を上限の目安にし、推奨値がそれを上回るなら推奨値より低く買う。これが外さない決め方です。

割引が想定と違う使用量に乗る適用順序と一括請求のアカウント共有設定

割引は自動で適用されるため、どの使用量から乗るかを知らないと試算と請求がずれます。

RIから先に適用されEC2 Instance SPの次にCompute SPが乗る順序

適用の仕組みを説明した公式ドキュメントによると、順序は次のとおりです。まずEC2のRIが適用され、残った使用量にSavings Plansが適用される。Savings Plans同士では、適用範囲が狭いEC2 Instance Savings PlansがCompute Savings Plansより先に適用される。さらに同じプランの中では、割引率の高い使用量から順にコミット額を消費し、コミットを使い切った残りにオンデマンド料金がかかります。

この順序から、試算のずれ方が読めます。Compute Savings Plansは割引率の高いEC2から先に消費されるため、Fargateの割引を見込んで買っても、EC2の使用量が多い時間帯にはFargateまで割引が届きません。また、各時間のコミットはその時間の中でしか使えず、翌時間へ繰り越せないと同ドキュメントは明記しています。

一括請求では購入アカウントが優先され共有オフなら他アカウントに乗らない

AWS Organizationsの一括請求を使っている場合、Savings Plansはまず購入したアカウントの使用量に適用され、共有が有効なときに限って組織内の他アカウントへ回ります。共有オフの組織で開発アカウントが購入すると、本番アカウントには一切適用されません。組織の請求設定の前提はAWS Organizationsの一括請求と設計判断の解説で確認でき、推奨APIで–account-scope PAYERを指定したときの値は共有が有効な前提で計算されている点に注意が要ります。

購入・返品・利用率監視をAWS CLIで回すSavings Plansの運用手順

RI満了との切り替えや返品期限の管理は、コマンドで記録を残すと事故が減ります。

create-savings-planによるRI満了日に合わせた予約購入

create-savings-planのリファレンスでは、–commitmentに1時間あたりのコミット額を0.001から1,000,000の範囲で小数点以下5桁まで指定し、–purchase-timeにUTCの日時を渡すと将来日付の予約購入になります。一部前払いを選んだ場合の–upfront-payment-amountは、総額の50%から99%の範囲です。

# RIが満了する 2026-12-01 00:00 UTC から開始する予約購入
aws savingsplans create-savings-plan \
  --region us-east-1 \
  --savings-plan-offering-id "<コンソールの購入画面で確認したオファリングID>" \
  --commitment "0.39448" \
  --purchase-time "2026-12-01T00:00:00Z" \
  --client-token "sp-2026-12-prod-web" \
  --tags Environment=Production Owner=infra

RIの満了日と開始日をそろえると、空白期間のオンデマンド料金を払わずに済みます。–client-tokenを付ければ、再実行しても二重購入になりません。

7日以内かつ1時間100ドル以下で使える返品と年10回の上限

買い間違えた場合の逃げ道は1つだけ用意されています。返品に関する公式ドキュメントによれば、コミット額が1時間100ドル以下で、購入から7日以内かつ同じ暦月（UTC）のSavings Plansは返品でき、前払い分は100%返金されます。クォータの一覧では、返品できる回数は管理アカウントあたり暦年で10回です。

# 返品（取り消し不可。savingsplans:returnSavingsPlan 権限が必要）
aws savingsplans return-savings-plan \
  --region us-east-1 \
  --savings-plan-id "<返品するSavings PlanのID>"

月末の購入は要注意です。30日に買うと、7日以内でも翌月1日で暦月が変わり返品の資格を失います。月の後半に購入するなら、購入当日のうちに利用率を確かめる手順を組んでおきます。

利用率とカバレッジによる未使用コミットの日次監視と追加購入の判断

購入後に見るべき指標は2つです。get-savings-plans-utilizationは、買ったコミットのうち使われた割合（UtilizationPercentage）と未使用額（UnusedCommitment）を返します。get-savings-plans-coverageは、対象の使用量のうちSavings Plansで覆えている割合（CoveragePercentage）を返します。どちらも粒度はDAILYとMONTHLYのみで、HOURLYは指定できません。

# 利用率：未使用コミットが出ていないか（日次）
aws ce get-savings-plans-utilization \
  --region us-east-1 \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity DAILY \
  --query "SavingsPlansUtilizationsByTime[].[TimePeriod.Start,Utilization.UtilizationPercentage,Utilization.UnusedCommitment]" \
  --output table

# カバレッジ：まだオンデマンドで払っている割合（月次・サービス別）
aws ce get-savings-plans-coverage \
  --region us-east-1 \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --group-by Type=DIMENSION,Key=SERVICE

利用率が100%でカバレッジが低いままなら、追加購入の余地があります。利用率が100%を割る日が出始めたら、それ以上は積まない合図です。コスト全体の推移はAWS Cost Explorerの使いどころの解説で整理した見方で確認します。

コミット過多で損をする損益分岐とSavings Plansの購入を見送る判断基準

料金表から見えないのはここです。Savings Plansで損が出るのは、単価を間違えたときではなく、約束した金額を使い切れない時間が続いたときになります。

利用率75.7%を下回るとオンデマンドより高くつく損益分岐の計算

コミット額は、使用の有無にかかわらず毎時間の請求対象です。m7i.large 4台分の0.39448ドルをコミットしたあと、台数が3台に減ると、Savings Plansで覆える使用は0.29586ドル分になり、残り0.09862ドル分は未使用のまま請求されます。支払いは0.39448ドルのままで、オンデマンドで3台動かした場合の0.3906ドルをわずかに上回ります。2台まで減ると、オンデマンドの0.2604ドルに対して0.39448ドルを払う計算です。

一般化すると、損益分岐の利用率は「Savings Plans単価÷オンデマンド単価」になります。1年・前払いなしのCompute Savings Plansなら0.09862÷0.1302で約75.7%、3年・全額前払いのEC2 Instance Savings Plansなら約39.4%です。割引が深いほど余りに強い反面、3年の約束は構成を変えない前提で成り立ちます。

移行予定・Spot中心・専有インスタンスでSavings Plansを見送る場面

判断を言い切ります。次のどれかに当たる環境では、Savings Plansを今は買わないでください。

• 半年以内にインスタンスサイズを見直す予定がある環境。先にCompute Optimizerのレコメンデーションでサイズを下げ、下がった後の床に合わせて買います。
• Spotインスタンスが中心の環境。Spotの使用量にはSavings Plansが適用されません。
• 専有インスタンスの費用が大きい環境。専有インスタンスを1台でも動かしているリージョンにかかる1時間2ドルの手数料は、Savings Plansの割引対象外です。
• Lambdaの実行時間が請求の中心の環境。割引は10%から14.8%にとどまり、メモリ割当の見直しのほうが効きます。
• 案件期間が12か月に満たない受託案件の環境。1年契約でも途中解約できません。

逆に、本番のEC2が常時稼働していて直近60日の最小時間帯の支出が安定しているなら、その床の7割から8割をCompute Savings Plansの1年・前払いなしで買い、利用率を1か月見てから積み増すのが失敗の少ない入り方です。稼働実績の棚卸しからコミット額の設計までをまとめて進めたい場合は、AWS・Google Cloud・Azureのインフラ構築支援で相談していただけます。

よくある質問

Savings Plansの種類の選び方・返品・RIとの関係について、問い合わせの多い質問をまとめます。

Savings Plansとリザーブドインスタンスはどちらを選ぶべきですか？

新規購入なら、多くの環境ではSavings Plansが先の候補です。EC2 Instance Savings PlansはスタンダードRIと同じ最大72%の割引で、サイズやOSの変更にも自動で追従します。RIが残る理由は、特定AZのキャパシティ予約とマーケットプレイスでの売却の2つです。両者は併用でき、RIが先に適用されます。

Savings Plansは購入後にキャンセルや返品ができますか？

期間中の解約はできません。例外は返品で、コミット額が1時間100ドル以下、購入から7日以内、かつ同じ暦月（UTC）なら前払い分が全額返金されます。回数は管理アカウントあたり暦年10回までです。

Compute Savings PlansはFargateやLambdaにも適用されますか？

適用されます。ECSやEKSで使うFargateとLambdaの実行時間が対象です。ただし東京リージョンの単価で比べると、Fargateは1年・前払いなしで15%、Lambdaは10%と、EC2より割引が浅くなります。Lambdaは3年契約でも1年と同じ単価です。EKSのクラスター料金は対象外ですが、ノードとして動くEC2インスタンスには適用されます。

コミット額はオンデマンド換算の金額で指定するのですか？

いいえ、Savings Plans単価で計算した1時間あたりの金額で指定します。オンデマンドで1時間0.52ドル分の使用を覆いたい場合、割引が24.3%なら必要なコミット額は約0.39ドルです。オンデマンド換算の金額をそのままコミット額に入れると、必要量より3割ほど多く約束することになり、未使用のコミットが毎時間発生します。

RDSやAuroraにもSavings Plansは使えますか？

Database Savings Plansが対象で、Aurora・RDS・DynamoDBなど10サービスに最大35%の割引が適用されます。ただし第7世代以降のインスタンスとサーバーレスに限られ、期間は1年のみです。db.t4gやdb.r6gで動かしているなら、世代更新の計画と合わせて判断します。

関連記事

• FinOpsとは？クラウドコスト管理の仕組み・3フェーズと導入判断を解説：Savings Plansの購入と利用率監視を継続的に回す体制づくりを整理しています。
• AWS CURとは：CUR 2.0をData Exportsで出力しAthenaで集計する手順：Savings Plansの適用結果を明細単位で集計したいときの手順です。
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を解説：オンデマンド・Spot・RI・Savings Plansの料金モデル全体の中での位置づけを確認できます。
• リザーブドインスタンスの購入判断と適用条件｜AWS CLIで割引を試算する手順：キャパシティ予約が必要な部分をRIで残す場合の購入手順です。