2026.09.23 インフラ

リザーブドインスタンスの購入判断と適用条件｜AWS CLIで割引を試算する手順

AWSのリザーブドインスタンス（RI）は、1年または3年の利用を先に確約する代わりに、オンデマンド料金より低い単価でEC2を使える請求上の割引です。公式の料金ページはスタンダードRIで最大72%、コンバーティブルRIで最大66%の割引を示しています。ただし、この数字だけで購入を決めると、サイズ柔軟性が効かないプラットフォームを選んでしまったり、停止中のインスタンスに前払い分を払い続けたりするおそれがあるため注意が必要です。この記事では、提供クラスごとの割引と変更可否、AWS CLIでオファリングを検索して実効時間単価を出す手順、正規化係数の換算、Savings Plansとの使い分け、そして購入後に割引が乗らない失敗パターンまでを、AWS公式ドキュメントの記述に沿って整理します。

まとめ｜リザーブドインスタンスを購入する条件と見送る条件の結論

結論から言うと、RIを買ってよいのは「そのインスタンスファミリーとサイズを1年以上動かし続けると言い切れる場合」だけです。判断の軸は割引率ではなく、契約期間中の稼働率の見込みになります。割引率40%の1年契約であれば、年間8,760時間のうち約5,256時間（月あたり約438時間）を超えて動かせば、オンデマンドで払うより支出が下がる計算です。

逆に、構成が固まっていない開発環境、半年で終わる案件、月末だけ動かすバッチ基盤は対象外と考えてください。RIは途中解約できず、前払い分も返金されません。構成変更の余地を残したいなら、インスタンスファミリーをまたげるCompute Savings Plansを先に検討したほうが無駄が出ません。実務でまず押さえるのは、提供クラスの選択・サイズ柔軟性の適用条件・アカウント間共有の設定の3点。以降の章では、この判断をAWS CLIの実行結果で裏づける手順を示します。

スタンダードとコンバーティブルの提供クラス別割引率と変更可否の比較

RIの購入画面で最初に決めるのが提供クラス（offering class）です。ここを間違えると、あとから取り返せる幅が変わります。

スタンダードRIの最大72%とコンバーティブルRIの最大66%の差

AWSのEC2リザーブドインスタンス料金ページ（2026年9月時点）には、スタンダードRIが「オンデマンド料金と比較して大幅な割引 (最大 72%)」、コンバーティブルRIが「オンデマンドで最大 66% オフ」と明記されています。同ページは契約期間ごとの目安も併記しており、スタンダードが1年40%・3年60%、コンバーティブルが1年31%・3年54%という並びです。

提供クラス	割引率の上限	1年契約の目安	3年契約の目安	交換	マーケットプレイス売却
スタンダード	最大72%	40%	60%	不可	可
コンバーティブル	最大66%	31%	54%	期間内で可	不可

差は6ポイント。3年で見ると60%と54%で、金額に直すと無視できない開きになります。インスタンスタイプの変更予定がないなら、迷わずスタンダードを選びます。

全額前払い・一部前払い・前払いなしで変わる割引率と資金拘束の差

支払いオプションは「全前払い」「一部前払い」「前払いなし」の3種類です。公式ページは、後者2つを選んだ場合「残額は期間を通じて毎月お支払いいただきます」と説明しています。前払い額が大きいほど割引率は上がる一方、契約期間分の資金が先に固定されます。

手元のキャッシュを寝かせたくない事業会社では、前払いなしを選んで割引率を数ポイント落とす判断が通りやすいでしょう。前払いなしでも解約はできません。「前払いしていないから途中でやめられる」という理解は誤りで、契約月数ぶんの月額請求が立ち続けます。EC2そのものの料金モデルを先に押さえたい場合は、Amazon EC2の仕組みとインスタンスタイプ・料金モデルの解説を合わせて読むと、オンデマンドとの比較軸がはっきりします。

交換とマーケットプレイス売却の可否で分かれる出口戦略の選択基準

提供クラスの公式ドキュメントによれば、コンバーティブルRIは期間内にインスタンスファミリー・インスタンスタイプ・プラットフォーム・スコープ・テナンシーを変更する交換ができます。スタンダードRIは交換できません。

代わりに、スタンダードRIはReserved Instance Marketplaceで売却も購入もできます。コンバーティブルRIはどちらも不可です。つまり出口は2種類。「使い続けるが中身を変えたい」ならコンバーティブル、「不要になったら手放したい」ならスタンダードという分かれ方になります。マーケットプレイスでの売却は買い手がつくまで成立しないため、確実な撤退手段としては数えられません。

AWS CLIでオファリングを検索し実効時間単価を試算する手順

マネジメントコンソールの購入画面は候補が多く、条件の組み合わせを比べにくい画面です。AWS CLIなら条件を固定して一覧を取り出せます。

AWS CLIでm5.largeの1年前払いなし提供条件を取得する手順

東京リージョン（ap-northeast-1）でm5.largeの1年・前払いなし・スタンダードのオファリングを引くコマンドです。契約期間は秒で指定し、1年が31536000、3年が94608000になります。

aws ec2 describe-reserved-instances-offerings \
  --region ap-northeast-1 \
  --instance-type m5.large \
  --product-description "Linux/UNIX" \
  --offering-class standard \
  --offering-type "No Upfront" \
  --instance-tenancy default \
  --filters Name=duration,Values=31536000 \
  --query "ReservedInstancesOfferings[].[ReservedInstancesOfferingId,FixedPrice,UsagePrice,RecurringCharges[0].Amount]" \
  --output table

出力のFixedPriceが前払い額、RecurringChargesのAmountが時間あたりの継続課金です。コマンドリファレンスでは、–product-descriptionに指定できる値がLinux/UNIX、Linux/UNIX (Amazon VPC)、Windows、Windows (Amazon VPC)と定められています。–instance-tenancyはdefaultとdedicatedのみで、hostは指定できません。

実効時間単価の算出式とオンデマンド比の損益分岐稼働率の計算例

取得した数字から実効時間単価を出します。式は次のとおりです。

実効時間単価＝ (前払い額＋時間単価 × 契約時間数) ÷ 契約時間数。1年契約の契約時間数は31,536,000秒を3,600で割った8,760時間、3年契約なら26,280時間になります。

ここから損益分岐を出します。実効時間単価がオンデマンド単価の60%（割引率40%）だとすると、同じ支出になる年間稼働時間は8,760時間 × 0.60 ＝ 5,256時間。月あたり約438時間、1日あたり約14.4時間です。これを超えて動かす予定があるならRIが有利になります。24時間365日動かす本番サーバーなら確実に超えますが、平日日中だけ動かす検証環境は月およそ160時間で、閾値の4割にも届きません。試算の前段として費用全体の内訳を押さえるなら、AWSの見積もりと料金計算ツールの使い方で、オンデマンド前提の総額を先に出しておくと比較が早くなります。

購入コマンドのlimit-price指定で誤発注を止める安全策

購入はpurchase-reserved-instances-offeringで実行します。このAPIは実行した時点で契約が成立し、取り消しはできません。先に–dry-runで権限だけを確認し、本実行では–limit-priceで注文総額の上限を必ず添えます。

# 1. 権限確認のみ（DryRunOperation が返れば実行可能）
aws ec2 purchase-reserved-instances-offering \
  --region ap-northeast-1 \
  --reserved-instances-offering-id ec06327e-dd07-46ee-9398-75b5fexample \
  --instance-count 3 \
  --dry-run

# 2. 上限価格を添えて本実行（Amount は instanceCount × price の総額）
aws ec2 purchase-reserved-instances-offering \
  --region ap-northeast-1 \
  --reserved-instances-offering-id ec06327e-dd07-46ee-9398-75b5fexample \
  --instance-count 3 \
  --limit-price Amount=2400,CurrencyCode=USD

–limit-priceはAmountとCurrencyCodeの構造体で、リファレンスでは通貨としてUSDのみが指定できると記載されています。Amountは1台あたりではなく注文総額の上限です。–dry-runが成功すると、権限がある場合はDryRunOperationというエラー応答が返ります。成功応答ではなくエラーが返るのが正常な挙動なので、CI上で判定するときは終了コードではなくエラーコードの文字列を見てください。

インスタンスサイズ柔軟性の正規化係数と適用外プラットフォームの確認

リージョンRIには、同一ファミリー・同一世代の範囲でサイズをまたいで割引が適用される仕組みがあります。ただし適用条件はかなり狭く、ここを誤解した購入が最も多い失敗です。

nano0.25からlarge4まで並ぶ正規化係数の換算ルール

割引の配分は正規化係数（normalization factor）で計算されます。リザーブドインスタンスの変更に関する公式ドキュメントが示す係数は次のとおりです。

サイズ	nano	micro	small	medium	large	xlarge	2xlarge	4xlarge	8xlarge
正規化係数	0.25	0.5	1	2	4	8	16	32	64

m5.xlarge（係数8）のRIを1台持っている状態は、m5.large（係数4）を2台動かしている状態と等価に扱われます。m5.2xlarge（係数16）を1台動かした場合は、係数8ぶんに割引が乗り、残り8ぶんに適用されるのはオンデマンド料金です。大きめのサイズで1本買っておけば、小さいサイズへ分割したときも取りこぼしが出ない、という設計判断がここから導けます。

Windows・RHEL・専有テナンシーでサイズ柔軟性が外れる条件

同じドキュメントは、サイズ柔軟性が効かない条件を明示しています。実務で踏みやすいのは次の並びです。

プラットフォームがWindows、Windows with SQL Server（Standard／Web／Enterprise）、Red Hat Enterprise Linux、SUSE Linux、Linux with SQL Serverの各エディションである場合（対象はLinux/UNIXのみ）
テナンシーがデフォルト以外（専有インスタンス・専有ホスト）である場合
ゾーンRI（特定のアベイラビリティーゾーンを指定して購入したRI）である場合
インスタンスファミリーまたは世代が異なる場合、およびt1.microのようにサイズが1種類しかない場合

SQL Server同梱のWindowsサーバーを動かしている環境では、サイズ柔軟性は初めから存在しないものとして、購入するインスタンスタイプを1つに固定してください。ここを見落とすと、m5.xlargeのRIを買ったのにm5.largeへ縮小した瞬間に割引が丸ごと外れます。

Cost Explorerの購入推奨APIで契約数量と支払い方法を決める運用

購入数量を勘で決める必要はありません。過去の使用実績から推奨をAWS側が計算してくれます。

Cost Explorerの推奨取得コマンドと60日ルックバックの指定

ce get-reservation-purchase-recommendationは、直近の使用状況をもとに購入すべき台数と見込み削減額を返します。–lookback-period-in-daysはSEVEN_DAYS、THIRTY_DAYS、SIXTY_DAYSの3値、–term-in-yearsはONE_YEARとTHREE_YEARS、–payment-optionはNO_UPFRONT、PARTIAL_UPFRONT、ALL_UPFRONTなどから選びます。

aws ce get-reservation-purchase-recommendation \
  --service "Amazon Elastic Compute Cloud - Compute" \
  --lookback-period-in-days SIXTY_DAYS \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --account-scope PAYER \
  --query "Recommendations[0].RecommendationDetails[].[InstanceDetails.EC2InstanceDetails.InstanceType,RecommendedNumberOfInstancesToPurchase,EstimatedMonthlySavingsAmount]" \
  --output table

–account-scopeにPAYERを指定すると管理アカウントとメンバーアカウントをまとめた推奨に、LINKEDを指定すると個別メンバーアカウント単位の推奨になります。組織で一括購入する前提ならPAYERで引いてください。ルックバックを7日にすると直近の一時的な増減を拾ってしまうため、定常稼働を見るなら60日を選ぶのが無難です。こうした購入判断を継続的に回す体制づくりは、FinOpsの仕組みと3フェーズの導入判断で整理した進め方が土台になります。

月20件のリージョン購入クォータと分割購入・申請引き上げの手順

推奨どおりに大量購入しようとすると、クォータに当たります。公式ドキュメントのデフォルト値は、リージョンRIがリージョンあたり月20、ゾーンRIがアベイラビリティーゾーンあたり月20です。3つのAZを使うリージョンなら、リージョンRI 20＋ゾーンRI 60で月80が上限になります。

数え方に注意が必要です。クォータはインスタンス数でカウントされ、インスタンス数10の設定を1回購入すると10としてカウントされます。購入回数ではありません。20台を超える規模なら、購入を翌月に分けるか、EC2コンソールからクォータ引き上げをリクエストしてから実行計画を立ててください。月初に一括購入する運用にしていると、引き上げ申請の待ち時間でその月の割引を丸ごと取り逃します。

Savings PlansとRIの併用範囲とFargate・Lambdaへの適用可否

2019年以降に追加されたSavings Plansは、RIと同じ「使用量の確約と引き換えの割引」ですが、縛る対象が違います。どちらを選ぶかは柔軟性とキャパシティ予約の要否で決まります。

Compute Savings Plansの最大66%とRI最大72%の割引差

AWSの予約モデルに関するホワイトペーパーは、Compute Savings Plansが最大66%、EC2 Instance Savings Plansが最大72%、スタンダードRIが最大72%と整理しています。Compute Savings Plansはインスタンスファミリー・サイズ・リージョン・OS・テナンシーのすべてをまたいで割引が動くため、最も柔軟な代わりに割引率の上限が6ポイント低くなります。

EC2 Instance Savings Plansはリージョン内の特定ファミリーに紐づき、その中でサイズ・OS・テナンシーの変更が可能です。RIとの違いはキャパシティ予約の有無で、同ホワイトペーパーはSavings Plansがキャパシティ予約を提供しないと明記しています。特定AZに確実に起動枠を確保したい要件があるなら、ゾーンRIかオンデマンドキャパシティ予約を選ぶことになります。

Fargate・Lambdaに効くSavings PlansとEC2限定RIの差

適用対象のサービスも分かれます。Compute Savings PlansはEC2に加えてFargateとLambdaにも適用されますが、EC2 Instance Savings PlansとRIはEC2のみが対象です。

コンテナをFargateへ寄せる計画があったり、バッチをLambdaへ移す途中だったりする組織では、RIを積むとその移行分がそのまま無駄になります。判断は単純で、12か月以内に実行基盤を動かす予定があるならCompute Savings Plans、動かさないならRIかEC2 Instance Savings Plansです。Lambda側の課金構造を確認してから決めたい場合は、AWS Lambdaの仕組みと料金体系の解説で、実行時間とメモリ割当に応じた課金の見え方を押さえておくと比較が成り立ちます。なお、RIとSavings Plansは併用が可能です。既存RIの満了に合わせてSavings Plansへ寄せていく移行が、公式ドキュメントでも推奨の形として挙げられています。

購入後に割引が乗らない適用漏れと解約不可で損失が出る失敗パターン

ここからは、料金表を読んだだけでは見えない部分です。RIで損失が出るのは、値段を間違えたときではなく、割引が乗らない状態に気づかないときになります。

起動していない時間にも前払い分の課金が続く精算の実態と対処法

RIは「割引価格でインスタンスを買う権利」ではなく、「対象条件に一致する稼働へ自動で適用される請求上の割引」です。対象インスタンスを停止していても、RIの契約分の請求は止まりません。夜間に開発環境を落とす運用をしている環境でRIを買うと、落としている時間ぶんは支払いだけが残ります。

対処は購入前に決まります。停止運用をしている環境ではRIを買わず、常時稼働のインスタンスにだけ紐づけてください。すでに買ってしまった場合は、同一条件で常時稼働しているインスタンスが他にないかを探し、割引の受け皿を作るのが現実的な回収策です。リージョンRIであれば同一リージョン内のどのAZで動いていても適用されるため、受け皿は見つけやすくなります。

購入を見送る稼働率の水準と短期案件でRIを選ばない判断の基準

判断を言い切ります。年間稼働見込みが5,000時間（1日あたり約13.7時間）を下回る環境、契約期間内に構成変更が入る見込みがある環境、そして案件期間が12か月未満の受託案件は、RIを買わないでください。割引率が高く見えても、契約の途中解約ができない以上、稼働しない時間ぶんの支払いが割引を食い潰します。

特に受託開発の検証環境は見送り一択です。要件が固まるまでインスタンスタイプは動きますし、案件終了とともに環境ごと消えます。この層はオンデマンドのまま、インスタンススケジューラで停止時間を作るほうが支出は下がります。逆に、本番の常時稼働サーバーが3台以上あり、直近60日の使用実績が安定しているなら、1年・前払いなしのスタンダードRIから始めるのが失敗の少ない入り方です。どこから手をつけるか判断に迷う段階であれば、AWS・Google Cloud・Azureのインフラ構築支援で、稼働実績の棚卸しと購入計画の設計から相談していただけます。

アカウント間共有の設定漏れで割引が分散する組織構成の落とし穴

AWS Organizationsを使っている環境では、請求の一括請求（コンソリデーティッドビリング）設定によってRIの割引共有が有効かどうかが変わります。共有が有効なら、あるアカウントで買ったリージョンRIが、組織内の別アカウントの一致する稼働にも適用されます。

問題は、共有をオフにしている組織で、開発部門のアカウントがRIを買ってしまうケースです。本番アカウント側の稼働には一切適用されず、開発側の稼働だけで割引を消化することになります。購入前に、どのアカウントで買うか、共有設定はどうなっているかを必ず確認してください。前述のget-reservation-purchase-recommendationで–account-scope PAYERを指定したときの推奨は、共有が有効な前提で計算された数字である点にも注意が要ります。

よくある質問

リザーブドインスタンスの購入・変更・解約について、実務で問い合わせの多い質問をまとめます。

リザーブドインスタンスは途中で解約できますか？

解約はできません。1年または3年の契約期間は最後まで請求が続き、前払い分も返金の対象外です。スタンダードRIであればReserved Instance Marketplaceで売却できますが、買い手がつくまで成立しないため、確実な撤退手段とは言えません。コンバーティブルRIはマーケットプレイスでの売却自体ができないので、出口を残したい場合は購入前にスタンダードを選ぶ必要があります。

購入後にインスタンスタイプを変えるとどうなりますか？

Linux/UNIXでデフォルトテナンシーのリージョンRIであれば、同一ファミリー・同一世代の範囲でサイズ柔軟性が働き、正規化係数に応じて割引が配分されます。m5.xlarge（係数8）のRIでm5.large（係数4）を2台動かせば、両方に割引が乗ります。ただしファミリーや世代が変わると適用されません。ファミリーごと変える可能性があるなら、交換に対応したコンバーティブルRIを選んでください。

スタンダードとコンバーティブルはどちらを選ぶべきですか？

契約期間中にインスタンスファミリーを変える予定がないならスタンダードです。公式ページの目安で3年契約なら60%と54%の差があり、6ポイントぶんの支出差が出ます。世代更新の予定があったり、ARM系インスタンスへの移行を検討していたりする場合は、交換できるコンバーティブルの柔軟性が割引差を上回ります。

Savings Plansとリザーブドインスタンスは併用できますか？

両方を併用することが可能です。請求時はSavings Plansとリザーブドインスタンスの割引が先に適用され、残った使用量にオンデマンド料金が適用されます。AWSのホワイトペーパーでも、既存RIの満了に合わせてSavings Plansへ移行していく形が挙げられています。キャパシティ予約が必要な部分だけゾーンRIを残し、それ以外をCompute Savings Plansへ寄せる構成が、柔軟性と割引率の折り合いをつけやすい形です。

リザーブドインスタンスは1か月に何件まで購入できますか？

デフォルトのクォータは、リージョンRIがリージョンあたり月20、ゾーンRIがアベイラビリティーゾーンあたり月20です。カウント単位はインスタンス数で、インスタンス数10の設定を1回購入すると10として数えられます。3AZを使うリージョンなら合計で月80が上限になります。これを超える規模ではEC2コンソールからクォータ引き上げをリクエストしてください。