ガバメントクラウドにおける長期継続割引について
AWS の EC2 や RDS の料金は基本的に 1 時間当たりのオンデマンド利用料がかかります。これを安くしたい場合、使用していない時間にインスタンスを停止することが思いつきます。しかし、停止したインスタンスを起動する際、AWS 側のリソース不足で希望のインスタンスを起動できない可能性（いわゆる InsufficientInstanceCapacity エラー）があり、特にキャパシティ予約のできない RDS の本番環境を停止することは推奨されていません。EC2 もオートスケーリングなど、本番サービス時に確実に最低限のインスタンスが起動できるようコントロールしておかないと、安易に安くなるからと EC2 インスタンスを停止するのはリスクがあると思います。
一方、1 年以上の一定期間、確実に EC2 や RDS を使うのであれば、事前に AWS 側に一定期間の利用を確約することで割引を受けられる、リザーブドインスタンスや Savings Plans（EC2 のみ） をうまく活用することで、利用料を削減できる可能性があります。
地方自治体のガバメントクラウド環境では、現状 EC2 や RDS を使う構成が多いと思うので、上記の理由から、リザーブドインスタンスや Savings Plans を活用した方が良いケースは多いと考えられます。
地方自治体のガバメントクラウドにおけるリザーブドインスタンスや Savings Plans の活用については、名古屋市の高橋さんのブログが参考になります。
地方自治体がリザーブドインスタンス、Savings Plans を活用する場合、いくつかの制限事項があるようで、詳細は高橋名人のブログを参照してもらうとして、私の雑な理解では、これらの長期継続割引のプランは以下の特徴があると考えています。
Savings Plans は EC2 への適用のみを前提として書いています。Lambda などは考慮していません。また、インスタンスの変更という表現は、変更後も引き続き割引を受けられるか否かという意味です。
| マネージドサービス | 長期継続割引 | スコープ | 区分 | メリット | デメリット |
|---|---|---|---|---|---|
| EC2 | リザーブドインスタンス | リージョナル | スタンダード RI | 割引率が高い。インスタンスの一部属性の変更、予約購入可。 | インスタンス変更に柔軟性がない。 |
| EC2 | リザーブドインスタンス | リージョナル | コンバーティブル RI | 同等以上の価格になるインスタンスへの交換可。 | 割引率が低い。 |
| EC2 | リザーブドインスタンス | ゾーン | スタンダード RI | 割引率が高い。 | インスタンスの変更、予約購入不可。 |
| EC2 | リザーブドインスタンス | ゾーン | コンバーティブル RI | 同等以上の価格になるインスタンスへの交換可。 | 割引率が低い。予約購入不可。 |
| EC2 | Savings Plans | - | インスタンス SP | 割引率が高い。 | 同一インスタンスファミリー・リージョンでなければインスタンスの変更不可。 |
| EC2 | Savings Plans | - | コンピュート SP | 柔軟にインスタンスの変更可。 | 割引率が低い。 |
| RDS | リザーブドインスタンス | - | スタンダード RI | 割引率が高い。 | 予約購入不可。 |
RDS はリザーブドインスタンスしか選択肢はありません。
EC2 はリザーブドインスタンスより Savings Plans の方がメリットデメリットのバランスが良いと思います。長期継続割引の期間中にインスタンスファミリーを変更する可能性がある場合はコンピュート Savings Plans を、インスタンスファミリーが固定しているならインスタンス Savings Plans が良いのではないでしょうか。
判断基準として、はちみつさんの X のポストがとても参考になりました。
早速 EC2 用に Savings Plans を実際に購入（コミット）してみる
ガバメントクラウドでの長期継続割引を検討するにあたり、実際の購入オペレーションをやってみた方がイメージが湧くと思いましたので、個人の検証環境で一つ Savings Plans を購入してみることにしました。
ガバメントクラウドを想定し、AWS Organizations のメンバーアカウントで Savings Plans を購入してみます。
Organizations の SCP の設定
Organaizations のメンバーアカウントで Savings Plans を購入できるようにするには、SCP で Savings Plans の操作を許可してあげる必要があります。
Organizations の管理アカウントで、メンバーアカウントに適用されている SCP で savingsplans: に対する許可がされているか確認してください。以下は参考として東京リージョンと大阪リージョン以外はグローバルサービスのみ許可する SCP に Savings Plans を許可したサンプルです。
なお、ガバメントクラウドではデジタル庁がこの辺りを管理しているはずなので、自治体側は特に意識する必要はありません。
Savings Plans の選定
先日書いた以下の記事で、自宅のオンプレミスと AWS を閉域で接続するため、t4g.nano の EC2 インスタンスを VPN ルーターインスタンスとして検証環境に立てました。
このインスタンスは当面 1 年くらいは検証作業で使うだろうと思ったので、今回 t4g.nano の EC2 インスタンス 1 台分を、ガバメントクラウドの制限に倣って前払いなしの 1 年分を購入（AWS にコミット）することとします（本当は前払いの方が割引率は高いです。また、3 年分買えるならその方が更に割引率は高いです。）
コンピュート SP とインスタンス SP で迷うところですが、この先 ARM アーキテクチャじゃ動かないアプリケーションをこの EC2 インスタンスで動かしたくなる可能性もあると思うので、他のアーキテクチャの EC2 インスタンスへの変更を考慮し、コンピュート SP を選択しました。
インスタンス SP で変更可能なインスタンスとは
インスタンス Savings Plans のポイントは、同一インスタンスファミリーでのインスタンス変更であれば引き続き割引を受けられるということです。
AWS の公式サイトから引用します。
Instance Savings Plans は、そのリージョンのファミリー内におけるインスタンス間で使用量を変更する柔軟性を提供します。例えば、Windows を実行する c5.xlarge から Linux を実行する c5.2xlarge に移動しても、自動で Savings Plan 料金の恩恵を受けることができます。
また、はちみつさんの作成した「架空の「ガバメントクラウド認定試験」 #18-#23（長期継続割引編）」の第 23 問が具体的なケースを解説されているので引用します。
次のうちEC2 Instance Savings Plansで長期継続割引の期間中に実施しても引き続きディスカウントが期待できるものはどれか。
A) r6i.2xlarge → r6i.4xlarge
B) r6i.2xlarge → c6i.2xlarge
C) r6i.2xlarge → r7i.2xlarge
D) r6i.2xlarge → r6a.2xlargeこちらの正解は「A) r6i.2xlarge → r6i.4xlarge」です。
r6iを題材にしていますが、どのインスタンスでも同様です。c6i（ファミリー変更)、r7i（世代変更）、i→a（intelからamdへの変更）はコミットメントを満たせません。ほかにr6iシリーズを使っていない場合などで、重複課金になる可能性があります。
Savings Plans のコミット金額（1 時間あたりの利用金額）を計算する
Savings Plans の条件が決まったら、これを適用した場合の EC2 インスタンスの 1 時間あたりの利用金額を調べます。
なぜなら、Savings Plans で購入（コミット）する金額とは、1 時間あたりの利用金額となるからです。要するに、AWS に対し 1 時間あたりいくら分使いますと約束することで割引を受けられる仕組みになっています。
そのため、使用する EC2 インスタンスの Savings Plans 適用後の 1 時間あたりの利用金額を、AWS に約束する形で購入（コミット金額として入力）することになります。複数の EC2 インスタンスであれば、それぞれの EC2 インスタンスの Savings Plans を適用した 1 時間あたりの利用金額を計算し、これを合計した金額をコミット金額にします。
AWS 公式サイトに、選択した条件を入力すると Savings Plans 適用後の 1 時間あたりの利用金額を表示してくれるものがあるので、これを使って計算します。
コンピュート SP の 1 時間あたりの利用金額を算出したところです。0.0042 USD であり、元のオンデマンドの利用金額に対し 22% 割引となることが分かります。
ちなみにインスタンス SP で算出すると、こちらの方が割引率は高いことが分かります。
購入アナライザーの実施
Savings Plans のコミットにあたって、過去の利用状況から AWS の推奨値を提案してもらえる機能があるので、実際にコミットする場合は参考にした方がいいです。AWS マネージメントコンソールから「Billing and Cost Management」→「Savings Plans」→「購入アナライザー」に進み、Savings Plans の条件を入力します。
ただ、今回の私の使い方だと元々の利用金額が小さすぎて、提案を受けられませんでした……。
そのため、本来は推奨事項を確認して Savings Plans の購入に進むのが良いのですが、カスタムで先ほど計算したコミット金額を入力して購入へ進むことにします。「時間単位のコミットメント」に、これまで計算した EC2 インスタンスの Savings Plans 適用後の 1 時間あたりの利用金額（複数インスタンスがある場合は全部の 1 時間あたりの利用金額を足し上げた金額）を入力し、誤りがないことを確認して「Savings Plans をカートに追加」に進みます。
誤った金額をコミットしてしまうと 基本的にキャンセルが効かない 一定の条件を満たさない限りキャンセルできないので、十分に注意して入力してください。
（2025/03/02 追記）はちみつさんから Savings Plans のキャンセルの条件についてコメントいただいたので上記注意事項を修正しました。併せて AWS 公式サイトの Savings Plans のキャンセルポリシーの記載を引用します。
Savings Plans をキャンセルすることはできますか?
同じ暦月内、かつ、直近 7 日間以内に購入された、1 時間あたりの契約額が 100 USD 以下の Savings Plans はキャンセルできます。Savings Plans をキャンセルすると、Savings Plans について発生した前払い料金が 100% 返金され、これらの返金はキャンセルから 24 時間以内に請求書に反映されます。プランによってカバーされていた使用量は、オンデマンド料金で課金されるか、または該当する場合は別の Savings Plans でカバーされます。
Savings Plans の適用開始日を予約して購入する
Savings Plans は未来の日付時刻から適用できるよう予約購入が可能です。月初からぴったり Savings Plans を適用したかったので、今回は 3/1 00:00:00 (UTC) から開始するよう予約購入してみます。Savings Plans のカートの画面から「開始日を設定」に進みます。
開始する日付と時刻（UTC）を入力します。
入力する時刻は UTC であることに十分注意して入力してください。誤って日本時間で入力してしまうと 9 時間 Savings Plans の適用が遅くなってしまいます。
開始日のほか、全ての条件が正しいことをよく確認し（ ここから先は後戻りできません！ ）、「注文書の送信」をします。
正常に購入できたら、Savings Plans の期間が終わる前にアラートメールを受け取れるようにします。here と書かれたリンクに進みます。
期間終了の何日前にアラートメールを送るかチェックを入れ、メールの送信先を入力します。
以上で Savings Plans の購入は終了です。
EC2 インスタンスのキャパシティ予約の実施
Savings Plans の注意点は、キャパシティ予約が付いていないことです。つまり、今回のように 1 年間の Savings Plans を購入したとしても、Savings Plans が適用されている EC2 インスタンスのキャパシティ予約がされたわけではないので、当該 EC2 インスタンスを停止して、再度起動しようとした際に確実に起動する保証はありません。ここがゾーンリザーブドインスタンスとの違いです。
そこで、今回のように Savings Plans を適用させる EC2 インスタンスが特定されているケースの場合、オンデマンドキャパシティ予約を合わせて実施するのがよいと思います。何かの都合で EC2 インスタンスが停止してしまった場合も、キャパシティ予約があれば起動が保証されるので安心です。
料金は心配要りません。オンデマンドキャパシティ予約をすると、対象の EC2 インスタンスを起動していても停止していても、オンデマンドキャパシティ予約の期間中ずっと EC2 インスタンスのオンデマンド利用料がかかります。ただし、このオンデマンド利用料には Savings Plans の割引が適用されます。
つまり、今回のケースであれば、Savings Plans でコミットした金額 = EC2 インスタンスのオンデマンド利用金額となるため、オンデマンドキャパシティ予約をしたからと言って追加料金がかかるわけではありません。
（例 1）今回のケースで対象の EC2 インスタンスを月 20 時間停止した場合の料金
| EC2 インスタンスのオンデマンド利用料 | オンデマンドキャパシティ予約の料金 | 合計 |
|---|---|---|
| 0.0042 USD * 710 H | 0.0042 USD * 20 H | 0.0042 USD * 730 H |
（例 2）今回のケースで対象の EC2 インスタンスが無停止だった場合の料金
| EC2 インスタンスのオンデマンド利用料 | オンデマンドキャパシティ予約の料金 | 合計 |
|---|---|---|
| 0.0042 USD * 730 H | 0.0042 USD * 0 H | 0.0042 USD * 730 H |
それでは早速オンデマンドキャパシティ予約を実施していきます。
オンデマンドキャパシティ予約の作成
EC2 のマネージメントコンソールから、「オンデマンドキャパシティ予約の作成」に進みます。
インスタンスタイプや AZ など必要なパラメーターを入力します。
キャパシティ予約も未来の日付を入力できます。しかし……。
今回のケースでは使うインスタンスが少なすぎて、未来の日付でのオンデマンドキャパシティ予約はできませんでした。ある程度の規模でなければ不可のようです。
そこで、今すぐオンデマンドキャパシティ予約を開始することにします。インスタンスの適格性を「オープン」にすると、自動的に適用するインスタンスを AWS が設定してくれます。
これでオンデマンドキャパシティ予約が作成されました。
オンデマンドキャパシティ予約が適用されているか確認
実際に EC2 インスタンスにオンデマンドキャパシティ予約が適用されていることが分かります。
Savings Plans、EC2 インスタンス、オンデマンドキャパシティ予約の実際の料金の確認
最後に Billing and Cost Management から実際に Savings Plans、EC2 インスタンスオンデマンド利用料、オンデマンドキャパシティ予約の料金がどのように請求されてくるか見てみます。
3 月は 31 日間あるので、Savings Plans の料金として、コミットした 0.0042 USD * 744 H = 3.12 USD となっていることが分かります。
一方 EC2 の料金は、記事執筆時点で 3/1 16:00 UTC 頃なので約 16 時間分請求されているところですが、オンデマンド利用料は 0.09 USD に対し、Savings Plans で同額カバーされているため、差し引きゼロとなっています。
また、この例では、オンデマンドキャパシティ予約を実施してから EC2 インスタンスは停止していないため、オンデマンドキャパシティ予約の料金は発生せず、オンデマンド利用料のみとなっています。もし EC2 インスタンスを停止すると、オンデマンドキャパシティ予約の料金が発生しますが、オンデマンドキャパシティ予約の料金も Savings Plans の割引が適用されますので、結果差し引きゼロとなります。
結果として、今回の例では狙い通り EC2 インスタンスの利用金額は Savings Plans でコミットした額のみとなっていることが分かります。
なお、EBS には割引は効きませんので注意してください。
以上 AWS Organizations のメンバーアカウントで Savings Plans を購入し、EC2 に適用させる手順でした。
参考サイト