ガバメントクラウド移行に伴う運用経費の増加は、どの自治体も頭を悩ませている課題になっていて、ガバメントクラウド利用料を最適化したいという話はよく聞こえてきます。
クラウド利用料の最適化の方法は色々あると思いますが、自治体基幹業務システムの場合、EC2 や RDS のインスタンスのオンデマンド利用料の割合の高いケースが多いため、これを削減するアプローチは効果がありそうです。
AWS の場合、長期継続割引をうまく使うことで、インスタンスのオンデマンド利用料を節約できる仕組みがあるため、これは積極的に活用したいところです。
そこで、インスタンスのオンデマンド利用料にターゲットを絞って、改めて AWS の長期継続割引についてどうやって活用すべきか、整理してみたいと思います。
本記事は ガバメントクラウド Advent Calendar 2025 の 8 日目の投稿となります。
インスタンスのオンデマンド利用料の長期継続割引とは
長期継続割引の仕組み
AWS のインスタンスのオンデマンド利用料の割引は、リザーブドインスタンスと Savings Plans の 2 つがあります。RI/SP といった略記がよく使われます。
RI/SP はどちらも、1 年または 3 年の期間（Database SP は 1 年のみ）で、この条件でインスタンスを使用しますと利用者が前もって AWS に約束（コミット）すると、利用者はその期間、その条件のインスタンスの利用権をオンデマンド料金よりも安く購入できる、という仕組みです。
本記事では、これを便宜上、長期継続割引ということにします。
長期継続割引は途中でキャンセルできない
リザーブドインスタンスは購入後のキャンセルができません。Savings Plans も購入した月内かつ購入から 7 日以内で 1 時間当たりの契約額が 100USD 以下の場合でなければキャンセルはできないため、どちらも購入してからしばらく様子を見て不要ならキャンセルするといった使い方はできないことに注意が必要です。
長期継続割引の適用の考え方
ここで覚えておきたいのは、RI/SP は特定のインスタンスを購入するわけではなく、条件に合致するインスタンスの利用権を購入するもの であることです。
言い換えると、せっかく RI/SP で利用権を購入しているのに、条件に合致するインスタンスを起動していなければ、利用権は無駄に消費されるだけですし、この間、条件に合致しないインスタンスを起動していると、当然このインスタンスのオンデマンド利用料が追加でかかってしまいます。
居酒屋で 90 分飲み放題を頼んで、飲み放題の対象外の飲み物しか注文しない人はいないですが、RI/SP の購入は、購入の条件をしっかり確認しないとそれをするのと同じ無駄遣いが生じることになるため、十分な注意が必要です。
それではこれらの長期継続割引の特徴を踏まえて、ガバメントクラウドにおける長期継続割引の利用方法を見ていきます。
ガバメントクラウドにおける長期継続割引の制限事項についておさらい
ガバメントクラウドにおける長期継続割引については、公開資料がありませんが、以下のような制限事項があると言われています。
- 1 年を超える期間をコミットする長期継続割引の購入はできない
- 4 月 1 日から 3 月 31 日の間の 1 年間に対するコミットしか認められない（年度をまたぐ購入ができない）
- 長期継続割引の始期は 4 月 1 日 00 時 00 分（世界標準時・UTC）からしか認められないため、購入オペレーションは 4 月 1 日 09 時 00 分から 09 時 59 分まで（日本時間・JST）の間に行わなければならない（事前予約は可能）
- 支払いは前払いを認められず、毎月後払いしか選択できない
要するに、ガバメントクラウドで認められる RI/SP の購入は 1 年間のみで、購入する場合は日本時間の 4 月 1 日 09 時 00 分から 09 時 59 分までに購入オペレーションをしなければなりません。
そのため、年度の途中から RI/SP を購入したいと思ったとしても、購入は翌年の 4 月まで待たなければなりません。また前述のとおり RI/SP を途中でキャンセルすることはできないので、RI/SP を購入するときは、慎重な判断が求められます。
それでは、ガバメントクラウドでは、どういった場合に RI/SP を購入するのがよいのでしょうか？
ガバメントクラウドで RI/SP を購入すると得をする前提条件
私の主観となりますが、以下のような条件であれば、ガバメントクラウドで RI/SP を購入することでインスタンスのオンデマンド利用料を削減できる可能性があると思います。
- 4 月 1 日から 1 年間、24 時間 365 日確実に使うインスタンスがある
- 1 年の間、安定して運用できるインスタンスのサイジングが既にできており、選定するインスタンスタイプが決まっている
具体的にこの理由を見ていきます。
24 時間 365 日起動するインスタンスであるか？
購入した RI/SP は前述のとおり言ってしまえばインスタンスの利用権なので、条件に合致するインスタンスを起動していないと無駄になってしまいます。
そのため、特定の時間帯だけしか起動しないインスタンスに RI/SP を適用するのは、費用の観点だけで言えば無駄になる可能性が極めて高いです。
EC2 については、そのインスタンスが確実に起動しなければ運用に支障があるケースであれば、EC2 インスタンスのコンピューティングキャパシティ予約を検討した方がよい場合があります。（RDS にはキャパシティ予約の機能はありません。）
キャパシティ予約をすると、対象の EC2 インスタンスを停止していてもオンデマンド利用料相当の料金がかかってしまうため、オンデマンド利用料を節約する目的は達せられないですが、その代わり必要なタイミングで EC2 インスタンスを確実に起動できるため、運用の安全性が向上します。
また、キャパシティ予約の料金は RI/SP が適用できるので、対象の EC2 インスタンスをオンデマンド料金で起動している分だけ支払うプランか、RI/SP とキャパシティ予約を組み合わせて割り引かれた 24H/365D の料金を支払うプランか、どちらを選択するかはコストとリスクを総合的に判断すると良いと思います。
インスタンスのサイジングは適正であるか？
RI/SP は購入した時点で支払うインスタンスのオンデマンド利用料が決まってしまうため、いざ RI/SP を購入してからインスタンスサイズが過剰であると分かった場合、無駄な費用を払い続けることになります。
あとで説明しますが、選んだ RI/SP のプランがインスタンスサイズ変更を認めている場合は、インスタンスサイズを下げても RI/SP の適用自体は受けますが、支払う額は変わりません。
つまり、RI/SP を購入する時点で適正なサイジングができない場合は、途中でインスタンスサイズを下げられたとしても損をすることになります。
それでは実際に RI/SP のどの割引プランを選択すべきか見ていきましょう。
EC2 の長期継続割引は Savings Plans 一択
EC2 の長期継続割引は、リザーブドインスタンスより Savings Plans の方がおすすめです。なぜなら、Savings Plans の方が、運用の場面で柔軟に対応できる可能性が高いためです。
運用の柔軟性に着目して、リザーブドインスタンスと Savings Plans を比較してみます。（以下説明は全て共有インスタンスのみを指すこととします。）
| 観点 | インスタンス SP | コンピュート SP | スタンダード RI | コンバーティブル RI |
|---|---|---|---|---|
| インスタンス変更の柔軟性 | 普通（購入時に指定したリージョンとインスタンスファミリーに限り、インスタンスサイズ、OS を問わず適用） | 極めて高い（インスタンスファミリー、インスタンスサイズ、リージョン、OS を問わず適用） | 低い（購入時に指定したリージョン内に限り、AZ を変更可（ゾーン RI）、AZ を問わず適用（リージョナル RI）、Linux のみインスタンスサイズを変更可） | 高い（購入時に指定したリージョン内に限り、同額以上になるインスタンスファミリー、インスタンスサイズ、OS のインスタンスに交換可） |
| 割引率（1 年間前払いなし、東京リージョン、m6i.xlarge、Windows と仮定） | 高い（19%） | 普通（14%） | 高い（19%） | 普通（14%） |
| キャパシティ予約の有無 | なし（別途オンデマンドキャパシティ予約が必要） | なし（別途オンデマンドキャパシティ予約が必要） | ゾーン RI はあり、リージョナル RI はなし（別途オンデマンドキャパシティ予約が必要） | ゾーン RI はあり、リージョナル RI はなし（別途オンデマンドキャパシティ予約が必要） |
割引率はリザーブドインスタンスと Savings Plans で同じです。
しかしインスタンス変更の柔軟性に着目すると、Savings Plans が OS を問わずインスタンスサイズを変更しても適用されるのに対し、スタンダードリザーブドインスタンスは Linux しかインスタンスサイズを変更できないため、Windows OS が多いと思われる自治体基幹業務システムの場合はこの制限が致命的です。
コンバーティブルリザーブドインスタンスであれば Windows OS でもインスタンスサイズの異なるインスタンスへ交換できますが、この目的だけで見るとインスタンス Savings Plans に対し割引率で劣ります。
キャパシティ予約はゾーンリザーブドインスタンスにのみ付いていますが、Savings Plans にオンデマンドキャパシティ予約を別途併用すれば、オンデマンドキャパシティ予約の料金に対しても Savings Plans は適用されるため、リザーブドインスタンスが優位というわけではありません。
結論として、以下のとおり Savings Plans を使い分けるのがベストだと思います。
- インスタンスファミリー（m6i など）が決まっている場合は、インスタンス Savings Plans を選択
- インスタンスファミリーを変更する可能性がある場合は、コンピュート Savings Plans を選択
例えば 4 月 1 日から 24 時間 365 日、東京リージョンにて Windows OS の m6i.xlarge の EC2 インスタンスを 1 台使う場合で、インスタンスファミリーは少なくとも 1 年間 m6i で行くと決めているとします。
この場合、m6i.xlarge 1 時間当たりのインスタンス Savings Plans の料金をコミットした場合と、オンデマンド料金で支払う場合とのコストの差は次のとおりとなります。
| オンデマンド | インスタンス SP | コストの差 |
|---|---|---|
| 0.432 USD * 730 h = 315.36 USD | 0.34832 USD * 730 h = 254.27 USD | 61.09 USD |
次に同じ条件で、月の途中の 5 日間だけ、m6i.2xlarge にインスタンスサイズを変更した場合の料金です。（厳密な計算とは異なる可能性があります。）
| 内訳 | オンデマンド | インスタンス SP | コストの差 | 備考 |
|---|---|---|---|---|
| m6i.xlarge | 0.432 USD * 610 h = 263.52 USD | 0.34832 USD * 490 h = 170.68 USD | - | m6i.2xlarge の利用にコミット分を先食いしたため、490 時間分のみ SP で充当される |
| m6i.2xlarge | 0.864 USD * 120 h = 103.67 USD | 0.69665 USD * 120 h = 83.59 USD | - | 先にコミット分から充当されるため、SP の割引が適用される |
| コミットを超えて利用した分 | - | 0.432 USD * 120 h = 51.83 USD | - | コミットを超えた分はオンデマンド料金が課金される |
| 合計 | 367.19 USD | 306.10 USD | 61.09 USD | インスタンスサイズを上げた分、利用料は上がっているが、条件を満たしたインスタンスへの変更であれば、割り引かれる額自体は変わらない |
インスタンス Savings Plans の条件を満たすインスタンスへの変更であれば、コミットした分までは割引が適用されるので、当然インスタンスサイズを増やした分の利用料は増えますが、インスタンス SP の割引は無駄になっていないことが分かります。
もしこれが、同じように月の途中の 5 日間だけ、インスタンス SP の条件を満たさない c6i.2xlarge への変更だったとしたらどうなるでしょうか？
| 内訳 | オンデマンド | インスタンス SP | 備考 |
|---|---|---|---|
| m6i.xlarge | 0.432 USD * 610 h = 263.52 USD | 0.34832 USD * 730 h = 254.27 USD | m6i.xlarge を 610 時間しか使っていないが、730 時間分コミットしているため、730 時間分の SP 料金がかかる |
| c6i.2xlarge | 0.796 USD * 120 h = 95.52 USD | 0.796 USD * 120 h = 95.52 USD | コミット分では充当できないので、c6i.2xlarge のオンデマンド料金がかかる |
| 合計 | 359.04 USD | 349.79 USD | 120 時間分の m6i.xlarge の SP 料金が無駄になる |
せっかくコミットした 120 時間分の m6i.xlarge の SP 料金が無駄になったことが分かります。
このようにインスタンスファミリーの変更が予想される場合は、割引率が多少落ちますが、コンピュート SP を購入することで、無駄なく割引を受けることができます。
EC2 の Savings Plans にはオンデマンドキャパシティ予約を併用しよう
Savings Plans には前述のとおりキャパシティ予約の機能がありません。運用で一時的に EC2 インスタンスを停止することがあると思いますが、オンデマンドキャパシティ予約を併用し、確実にインスタンスが起動できるようにしましょう。
オンデマンドキャパシティ予約の料金がかかるのは、該当の EC2 インスタンスが停止している間のみです。しかもこの料金は Savings Plans の対象となるため、Savings Plans と併用しても追加の料金がかかるわけではありません。
詳細はガバメントクラウドアドベントカレンダー 15 日目のはちみつさんの記事でしっかり勉強しましょう。
また、Savings Plans の購入の流れは過去記事に書いていますので良ければ参考にしてください。
RDS の長期継続割引について
RDS は Database Savings Plans とリザーブドインスタンスの選択
RDS には Savings Plans がありません。そのため、選択肢はリザーブドインスタンスのみとなります Database Savings Plans がつい先日発表されましたため、RI/SP の両方の選択肢ができました。
RDS と EC2 のリザーブドインスタンスの違い
RDS のリザーブドインスタンスは、EC2 のリザーブドインスタンスよりも適用条件が狭くなります。具体的には、購入した RDS リザーブドインスタンスと以下の条件が一致した RDS インスタンスを使用しないと、割引が受けられないので、リザーブドインスタンス料金とオンデマンド料金の二重課金となってしまいます。
- リージョン
- DB のエンジン
- インスタンスクラスタイプ（db.m6i など）
- インスタンスサイズ（DS for Microsoft SQL Server および Amazon RDS for Oracle ライセンス込みのみ。それ以外はインスタンスサイズの柔軟性あり）
- エディション（RDS for Oracle と RDS for SQL Server のみ）
- ライセンスタイプ（ライセンス込みなのか、BYOL なのか）
Database Savings Plans とリザーブドインスタンスの比較
一番の違いは割引率とインスタンス変更の柔軟性だと思います。
Database Savings Plans は非常に柔軟な割引が RDS へ適用できるので、購入してからインスタンスを変更する可能性があっても安心な代わりに、割引率は低いです。
リザーブドインスタンスはインスタンス変更の柔軟性が低い（特に Oracle と SQL Server）代わりに割引率は高いため、事前にサイジングが決まっていてインスタンスを変更する可能性がないケースで有効です。
支払い方法は、リザーブドインスタンスは選択肢が多い一方、Database Savings Plans は 1 年間前払いなしのみとなります。
東京リージョンの db.m7i.large で DB エンジンが PostgreSQL のインスタンスを 1 年間前払いなしの条件で RI/SP いずれかで購入する場合の比較結果は、以下のようになります。
| 観点 | RI | Database SP |
|---|---|---|
| 割引率 | 33%（高い） | 20%（低い） |
| インスタンス変更の柔軟性 | 低い | 極めて高い（エンジン、インスタンスファミリー、サイズ、デプロイオプション、AWS リージョンに関わらず適用） |
| 事前予約購入 | 不可 | 可 |
| 支払い方法 | 1 年間または 3 年間、全額前払い、一部前払い、前払いなしから選択可（ガバメントクラウドの場合は 1 年間前払いなしのみ） | 1 年間前払いなしのみ |
個人的な意見になりますが、RDS のサイジングがしっかりできていて、運用中にインスタンスサイズを変更する可能性が極めて低い場合で、かつ日本時間の 4/1 午前 9:00 から 9:59 の間でリザーブドインスタンスの購入作業をできる人員を確保できている場合はリザーブドインスタンスの方が良いと思います。
RDS のサイジングが決まっておらず、年度途中でインスタンスサイズを変更しないとならないケースが予想されるなら、Database Savings Plans が良いと思います。こちらは事前に予約購入も可能なので、作業リスクはリザーブドインスタンスに比べて圧倒的に低いです。
本稼働が始まったばかりの団体が多いガバメントクラウドでは、最初は Database Savings Plans の方がいいのではないでしょうか？
RDS にはキャパシティ予約の機能自体がないことに注意
また、EC2 のゾーンリザーブドインスタンスと違い、キャパシティ予約の機能がないことには注意しましょう。
ミッションクリティカルな本番環境の RDS インスタンスを停止することが推奨されていない理由は、RDS インスタンスにはキャパシティ予約ができないためです。EC2 インスタンスのように確実な起動を担保することができないため、RDS インスタンスは停止しないことでキャパシティ不足を回避します。
RDS のリザーブドインスタンスの購入は事前予約できない
RDS のリザーブドインスタンスは、Savings Plans と違い、事前に日時を指定して購入することができません。
そのため、ガバメントクラウドでは、日本時間で 4 月 1 日の午前 9 時 00 分から 59 分の間に RDS のリザーブドインスタンスの購入オペレーションを実施する必要があります。
確実にこの時間に購入オペレーションを完了するためにはどうしたらよいか、前もって運用管理補助者と相談する必要があります。なお、この作業にはリスクが伴うこと、運用管理補助者の作業工数がかかることに十分留意してください。
なお、Lambda と EventBridge スケジューラで RDS リザーブドインスタンスを事前に日時指定して購入する検証を以下の記事でやってみていますので、良ければ参考にしてください。
長期継続割引に関する共同利用方式（ネットワーク分離）の罠
前述のとおり、RI/SP は条件に合致するインスタンスへ適用される仕組みです。
裏を返せば、特定の VPC の特定のインスタンスに適用させようと思っても、同じアカウント内に、他に優先して適用される条件を満たすインスタンスが別の VPC にある場合、そちらのインスタンスに RI/SP が適用されてしまう可能性があるということです。
勘のいい人は気付くと思いますが、ネットワーク分離の共同利用方式、つまり一つのアカウント内に複数の自治体の環境を VPC で分けているケースで問題が起きます。
例えば A 団体が自分の VPC にあるインスタンスへ RI/SP を適用して欲しいと希望しているとします。しかし同じアカウント内の B 団体の VPC もあり、もし A 団体のインスタンス構成から算出した RI/SP を購入すると、全て B 団体のインスタンスの方が適用条件を満たしてしまっているとします。
この場合、A 団体のインスタンスは通常のオンデマンド料金のままで、B 団体は特に希望していないのにいつの間にか RI/SP が適用されてしまっているといった事態が起き得ることになります。
A 団体の RI/SP のために B 団体の構成を変えるわけにはいかないでしょうし、A 団体はアカウント分離しない限りいつまでも自団体へ RI/SP が適用されないことになります。
解決策はアカウント内の全てのインスタンス分がきれいに RI/SP が適用されるよう購入し、インスタンスの停止や変更を行わないよう運用するしかないと思いますが、複数の団体で果たして足並みを揃えてこれができるでしょうか？
結果として、ネットワーク分離方式のところは全団体一律で長期継続割引の適用を見送るという判断になってしまうのではないでしょうか。
まとめ
最後にまとめです。
- EC2 の長期継続割引は、インスタンス Savings Plans か、コンピュート Savings Plans を選びましょう
- EC2 の Savings Plans は、オンデマンドキャパシティ予約と併用しましょう
- RDS はインスタンスのサイジングがきっちりできるまでは Database Savings Plans の方が良さそうです
- RDS のリザーブドインスタンスを選択する場合は、日本時間で 4 月 1 日の午前 9 時 00 分から 59 分の間にしか購入作業ができないので、実現方法を事前に整理しておきましょう
来年度を迎える前に、ガバメントクラウドにおける AWS の長期継続割引について、利用を検討する場合は、しっかりこれらの特徴を学んでおきましょう。
この記事を書くに当たり、参考にした URL を共有します。すごく分かりやすく、また詳細なので、ぜひ一読しましょう。