いまさら聞けないリザーブドインスタンスのお話し
投稿日: 2025/12/23
はじめに
こんにちは、園田です。
前回に引き続き、「いまさら聞けない」シリーズを開催したいと思います。
いまさら聞けないシリーズの第４弾は「リザーブドインスタンス」になります。
リザーブドインスタンスは長いのでRI（アールアイ）と略させていただきます。
意外とみんなRI、RIと呼んでいるので、これの機会にリザーブドインスタンスはRIと呼ぶという事を覚えておきましょう。
なお、公式資料としてはAWSさんからBlack Beltシリーズが詳しくサービス説明をしています。URLを載せておきます。
いつも通り、AWS Black Beltは見ずに園田がAWSのサービスについて紹介したいと思います。
AWS サービス別資料
https://aws.amazon.com/jp/events/aws-event-resource/archive/?cards.sort-by=item.additionalFields.SortDate&cards.sort-order=desc&awsf.tech-category=*all
※ フィルターにてサービス名（今回だとリザーブドインスタンス）を入力してください。
ちなみにAWS Black Beltシリーズは基本よくできているのですが、リザーブドインスタンスについては誤解を招きそうな記述があります。本記事ではその辺もフォローしたいと思います。
RIってなに？
通常、AWSの課金はオンデマンドとなります。
オンデマンドとは、「要求に応じて」という意味になります。
名は体を表す、素晴らしい名称ですね。
名前の通り、要求に応じて利用した分のみ費用が掛かる形式となります。
EC2だと1分（60秒）単位での課金となります。
（これも誤解を招きやすいですが、1分での課金はフリーOSだけです。シェアOS（Windowsなど）は1時間課金となります。なので、1時間単位での課金としていた方が無難です。）
そのため、1時間の利用すれば、1時間分の費用のみAWSに支払うという形になります。
このオンデマンドがクラウドの一般的な形式となり、使った分だけ支払いをするという至極まっとうなルールとなっています。
ただ、「なんだかんだ言って結構従量費用が高くなってしまった。もうちょっと安くできないかな。」という場合にコストを削減する手段として用意されているのが「RI」になります。
RIをシンプルに表現すると、
「事前に利用券（チケット）を購入することでオンデマンドより安い費用で利用する」
というものとなります。
コスト削減したい場合の選択肢
RIがお手軽にコスト削減できる（ように見える）ため、RIを購入したいというお客様は多いですが、RI以外にもコストを削減する手段は多く用意されています。
個人的にRIはコスト削減の一番最後の手段であり、とりあえずRIというものではありません。
コスト削減の方法と順番
1．不要リソースの削除
クラウド環境を長く使うとゴミが溜まってしまいます。
使っていないEBS、インスタンス、EIPなどは消してしまいましょう。文字通りゴミです。
2．アーキテクチャの見直し
やたらと書き込みが多いDynamoDB、1ヶ月に数十テラもログを出力させるCloudWatch logsとか正しくない使い方をしているサービスも散見されます。
実現したい機能に対し、費用が最適化されているか（ある程度想定通りか）を確認しましょう。
3．効率的な利用方法の検討（オートスケール、など）
- 常時稼働が不要なサーバについては、定期的に停止する
- 必要に応じてインスタンスを増強する
など、常時そのスペックが必要かきちんと考慮しましょう。
リアルタイム処理が必要でないのであれば、キューにいれて、キューの数でECS等を起動するのがコスパの良い使い方です。
また、複数のAWSアカウントで共有できるものは共有しましょう。
リソースの無駄遣いですし、費用も掛かってしまいます。
VPCエンドポイントなどはその代表例です。すべてのアカウントでVPCエンドポイントを作成するのではなく、VPCエンドポイントを集約するアカウントにまとめることでかなりのコスト削減が可能です。（※）
- ※1つのエンドポイントあたり20.16ドル/30日（IF型、東京リージョンの費用）が発生します。10個のエンドポイントを100アカウントで作成すると、約2万ドルかかる計算になります。
極端な例ですが、アカウントが増えるとこのようなことが発生する可能性があります。
4．RI、SPの検討
「1」～「3」までの対応が全部終わってからようやくRI、SPの検討ですね。SPはSavings Plans（せいびんぐ ぷらん、と読みます）の略にあります。
SPはそのまま「エスピー」と呼んでください。
SPについても後でちょっとだけお話ししたいと思います。
RIを購入する
RIを購入する際には以下を選択する形となります。
- インスタンスタイプ、OSを選択
- リージョン、またはAZを選択
- 1年 or 3年を選択
- 支払い形式選択
- スタンダード、コンパーチブルを選択
1つずつ見ていきましょう。
1．インスタンスタイプ、OSを選択
RIを購入するインスタンスタイプ、およびOSを選択します。
具体的には、
- インスタンスタイプは「m5.large」
- OSは「Windows」
という形です。
後の注意点で記載しますが、
例えば「インスタンス：m5.large」「OS：windows」のチケットを購入した場合、他のインスタンスタイプやOSにはチケットは適用できません。
そのため、リプレイスを計画しているサーバ等に対し、RIを購入するとRIが利用できず、損をしてしまう可能性があります。
2．リージョン、またはAZを選択
購入時、リージョン、またはAZを選択します。
- リージョンを選択
-
リージョンに対し、RIを購入します。
このRI方式の場合、別のAZにインスタンスを作成した際、同じインスタンスタイプ、OSであればチケット適用対象となります。要するにより柔軟性が高くなるわけです。
一方、リージョンを選択した場合、起動保証はつきません。
（AWSのリソースに空きがあった場合は、起動が可能となります。通常のオンデマンドと一緒のロジックです） - AZを選択
-
AZを選択した場合、起動保証が実施されます。
ただし、指定したAZ、およびインスタンスタイプ、OSが完全一致した場合のみRIが適用される形となります。「RIの注意点」の項目でも記載しますが、OSがフリーOSの場合、リージョン指定であればインスタンスタイプの変更についてはRIのチケット対象となりますが、AZの場合は対象外となりますのでご注意ください。
3．1年 or 3年を選択
購入するチケットを1年有効か、3年有効かを選択します。
有効期限以外には差はありませんが、1年より3年の方が割引率が高くなります。
4．支払い形式選択
以下の3つの形式から支払い方式を選択します。
- 全額前払い
- 購入月にて、1年、または3年利用のチケット費用全額を支払う方式です。
- 一部前払い
- 購入月にて、RIの費用の一部を支払い。残りの金額を1年、または3年かけて支払いパターンです。
具体的には12,000ドル/1年のRIの場合、最初の月で6,000ドル、残り12ヶ月で500ドル支払いするパターンです。
（6,000ドル + 500ドル x 12ヶ月 = 12,000ドル）
正直、意味が良く分からない支払い方法です。
- 前払いなし
- 前払いをしません。
具体的には12,000ドル/1年のRIの場合、毎月1,000ドル支払いするパターンです。
支払い形式ですが、割引率が高い順番としては
全額前払い ＞ 一部前払い ＞ 前払いなし
の順番になります。まぁ、当たり前です。
ぶっちゃけ、全額前払いだろうが、前払いなしであろうが、会社の処理としては一緒になるので（全額前払いでも1年間で計上するので、結局分割される）、全額前払いを選択しない理由が良く分かりません。
強いて言えば、為替リスクがあるので、「FXが好きな人は前払いなしにする？」ぐらいしか思いつきません。
（これから円安になるか、円高になるかなんて誰にも分からないですよ。）
5．スタンダード、コンパーチブルを選択
- スタンダード
- 購入したRIの変更不可
- コンパーチブル
- より費用が高いインスタンスモデル・OSへの変更が可能（差分支払いは発生）となります。
通常、RIは一旦購入するとキャンセルはできません。
たとえば、「RIを購入した後、リプレイスを実施してインスタンスタイプとOSが変わってしまった。」という時でもキャンセルはできず、無駄にお金を払ってしまう形となります。
コンパーチブルを購入した場合は、より費用が高いインスタンスモデル・OSへの変更が可能となっています。
ただし、当たり前ですが、追加費用は発生します。
費用発生 = 決済権限を持っている方に「何でリプレイスする予定だったのにRI買ったの？ちゃんと計画立てたの？」とお小言をいただくことが想定されるので、色々面倒です。
計画をきちんと立てて、スタンダードを選択することをお勧めします。
割引率も
スタンダード ＞ コンパーチブル になります。
なお、RIの費用はインスタンスファミリーやOSに依存します。（フリーのOSだと1年で大体40%引きぐらいですかね。）
詳細はこちらを参照ください。（EC2）
https://aws.amazon.com/jp/ec2/pricing/reserved-instances/pricing/
RDSの費用はこちらです。
https://aws.amazon.com/jp/rds/aurora/pricing/
-
※
上記ページに飛んだ後、上タブから「エンジン」で調べたいDBを選択後、さらに「料金」のタブをクリックしましょう。
RIの注意点
注意点①：サーバにRIは適用できない
何度か記載していますが、RIは「事前にお金を支払った利用券（チケット）」になります。イメージとしては、東京ディズニーランドに入るためのパークチケットみたいなものです。このパークチケットを事前に毎日10人分購入するみたいな感じです。
東京ディズニーランドに行きたい人が10名以上いればよいですが、いなくてもチケットの返却は出来ません。
特定の誰か向けのチケットではなく、基本だれでも使えるものです。
あくまで東京ディズニーランドに「行きたい人に渡すためのチケット」（かつ当時使うよりちょっと安く買えるチケット）です。
なので、サーバAに対してRIを購入するというものではありません。
チケットの割り当てという処理も必要がありません。
条件が合致すれば勝手に割当たります。
そのため、同一アカウント内で複数システムが混在している場合は、以下のような問題が発生する可能性があります。
上記はシステムAでRIを買ったのに、システムB側にもRIが適用されてしまう問題です。
このため、RIを購入する場合は、システム単位でアカウントを分割する必要があります。
（アカウントを持っている管理者の方がすべて費用を管理するのであれば、特に問題はありません。）
注意②：インスタンスタイプを変更しても適用されるものとされないものがある
- Black Beltには
- 「ファミリー内ならサイズが異なっても割引料⾦が適⽤される」という表記がありますが、これには条件があります。
RIの特徴の項目で「インスタンスタイプ、OSを選択」と記載しましたが、以下の条件を満たす場合、インスタンスタイプが異なってもRIチケットが適用されます。
- OSがフリーOSの場合
- リージョンを指定（AZを指定した起動保証ではない）
ようするにEC2の場合は、Amazon Linuxのみ。RDSの場合は、MySQL、Postgres（Aurora含む）のみインスタンスタイプが異なっても問題ないという事です。
結構な確率でWindows（SQL入ってるのも含む）とかRedhatとかOracleとかSQL Serverを利用しているパターンが多いので、その場合は、インスタンスタイプの変更はできません。
（タイプ変更してもよいが、チケットは無駄になります。）
これは、RIがハードウェアにのみ適用され、OSは適用外であるためです。
商用OSの場合、CPUやメモリ数により費用が異なりますので、RIは適用することはできません。
WindowsはRIの割引率が悪くて～、みたいな話がありますが、実際にはそんなことはありません。
ハードウェアが500ドル、OSが500ドルで併せて1000ドルの場合、RIを購入するとハードウェアの500ドルにのみ適用されるので、40%引きの場合、ハードウェア：300ドル + OS：500ドルの合わせて800ドルとなるため、見た目上の割引率は悪いように見えますが（見た目上は20%になります）、ハードウェアは40%引きという事に変更ありません。
なお、条件を満たす場合、こんなイイ感じでチケットの割り当てが実施されます。
あくまでインスタンスファミリー（上記の場合は、「m5」ですね。）に変更が無い場合、「2xlarge」を「xlarge × 2」として適用することが可能です。
（逆に「xlarge」のチケット2枚で、「2xlarge」に適用も可能です。）
なので「フリーOS」、かつ「リージョン指定」のみしか使わないよ。というのであればRIって意外と柔軟性が高いんですよね。
問題はここまでお客様に理解いただくことが非常に難しいので、であれば、「インスタンスタイプを変更してはいけません。
（RDSの場合は、シングルからマルチにしてもダメ）」と言っていた方がトラブルが少なくて結果的に良いです。）
せっかくなのでSPについても説明
SP（Savings Plans）も購入についてはRIと一緒です。
- 1年 or 3年を選択
- 支払い形式選択（全額前払い、一部前払い、前払いなし）
を選択して購入する形です。
ただ、面倒なことにSPでは以下の4種類が存在します。
- EC2 Instance Savings Plans
- Compute Savings Plans
- SageMaker Savings Plans
- Database Savings Plans
簡単に説明しましょう。
1．EC2 Instance Savings Plans
インスタンスファミリーを指定し、台数、インスタンスサイズ、OS、テナンシーに関係なく適用されるものです。
RIとの差異は、「インスタンスファミリーが一緒ならOSが異なっても大丈夫」という点です。
とはいえ、割引率はRIより低いし、自由度はCompute Savings Plansより低いという実に中途半端なプランです。
自由度を向上させたかったという点は理解できますが、「それならCompute Savings Plansの方がよくね」という感じです。対象はEC2だけですし…。
2．Compute Savings Plans
EC2、lambda、ECS、EKSなどに対して適用されます。
インスタンスファミリーやOSなど、全てにおいて制約がありません。
厳密にするならRIでスタンダードを購入（タイプ変更は実施しない）。
自由度を求めたい場合は、Compute Savings Plansというのが最もシンプルで分かり易いです。
もしくはEC2はRIで、ECS、EKSだけCompute Savings Plansというのもいいですね。
3．SageMaker Savings Plans
SageMakerにのみ適用されるものです。
SageMakerについてはRIが無いので、費用を安くしたい場合は、SageMaker Savings Plans一択です
4．Database Savings Plans【New（2025年12月）】
DB系のサービスに適用されるものです。
ただし、RDSの場合、2025年12月現在ではm7、m8、r8、r9などの最新インスタンスのみ適用となっているため、注意が必要です。（RDSは結構古めのインスタンスタイプを使っているお客様も多い印象です。）
SPの特徴
SPについてはSP対象（Fargate、Lambda）の時間当たりの金額を購入するのが特徴となります。
例えば、1時間あたり100の利用量をコミットした場合、通常10ドルの費用が発生するところを8ドルで利用可能となります。
（あくまでイメージになります。）
SPで利用量100（仮に8ドルとする）を購入した場合の利用イメージ
2/1 17:00の利用量：120 → 利用量100を8ドルで支払い、余剰の20ドルをオンデマンド（通常費用：2ドル）で支払い
2/1 18:00の利用量：110 → 利用量100を8ドルで支払い、余剰の10ドルをオンデマンド（通常費用：1ドル）で支払い
2/1 19:00の利用量：90 → 利用量90を8ドルで支払い（利用量10が無駄になっている状態（1ドル））
2/1 20:00の利用量：90 → 利用量90を8ドルで支払い（利用量10が無駄になっている状態（1ドル））
実際の費用としては、例えばAWS Fargate の Compute Savings Planの場合、1年契約だと約22%引きとなります。
1時間あたりの vCPU費用（fargateの場合です）（※）
| オンデマンド | 0.05056ドル/時間 |
|---|---|
| SP | 0.0394368ドル/時間 |
→ 結果的に22%引き。
-
※
条件は以下の場合の費用です。
- 東京リージョン
- 全額前払い
- Linux
細かい費用についてはこちらを参照ください。（結局SPのRIとおんなじでインスタンスファミリー等により割引率が変化します）
https://aws.amazon.com/jp/savingsplans/compute-pricing/
SPっていくら買えばいいんですかね？
SPの特徴で記載した通り、1時間あたりの利用量で購入するSPの金額を決める形となります。
そのため、例えば1日でfargateを96ドル使っているから、96 / 24 = 4ドルということで1時間 4ドルの購入、という訳にはいきません。
もしかしたら日中は1時間6ドルぐらい使っていて、夜は2ドルぐらいしか使っていない。という事もあります。
このような場合において、4ドル購入しちゃうと、夜の2ドル分は無駄になってしまいます。
なので、SPを購入する際は、AWSからの推奨値を取得するのが一般的です。
推奨値は、マネジメントコンソール「請求とコスト管理」のページの左タブ「Savings Plans」の「推奨値」から確認することが可能です。
問題なのはOrganizations機能から確認しないといけない点と、リセラー（CTC含む）からAWSを契約している場合、このページはお客様に開放されていない。という点ですね。
リセラーはAWSとの約束で、お客様には「請求とコスト管理」のページは見せない契約となっています。
なのに、SPについてはここからしか分からないというのは…。
という訳で、SPを購入したい場合は、リセラーから推奨値を教えてもらうよう依頼をしてみましょう。
CUVIConAWSではこのSP推奨値をお客様ポータルから確認できるよう、サービス改善をしたいな、と計画しています。
終わりに
という訳で、「いまさら聞けないリザーブドインスタンスの話」でした。
途中SPも挟みましたが、この話も長かったです…。
RI、SPについては中々知る機会が無いと思いますので、じっくり読んでいただければと思います。
個人的にRI、SPをしっかり理解している人ってほとんどいないのでは？、と思っています。
まぁ、お金の話ですしね。
とはいえ、お金の話にきちんと技術者が向き合わせないといけない（強制的に向き合わされる）のはクラウドの面白い点だなと思います。
クラウドは技術者の幅を広げる技術なのだと思っています。
お金の勉強も頑張りましょうね。
ではまた、別の記事でお会いしましょう。
- 関連コラム
