結局ガバメントクラウドの長期継続割引はどうすれば良いのか
2025年2月4日のデジタル庁説明会にて、長期継続割引に関する必要な説明は一定済んだという認識です。チェックリスト等の話もありますが、まあ無くとも準備を進めることは可能です。
しかしながら、大多数の団体に取っては「で、結局どうすれば良いの？」という状況ではないでしょうか。
説明はされ尽くしているのに、どうすれば良いか分からないのは、予備知識としてガバメントクラウド周りの契約やAWSの基礎的な知識が必要となるからです。
そのため、本記事で補足しようと思います。
なお、共創PFに加入されている方は、本市の長期継続割引利用にかかる内部向け文書をガバクラチャンネルの2025/1/22に投稿していますので、是非確認してみてください。「長期継続割引利用の方針」で検索すると早いです。
１．長期継続割引とは？
リザーブドインスタンスとかセービングプランとか色々出てきますが、一旦それは忘れて、長期継続割引とは何か？というのをまず理解しましょう。
長期継続割引を簡単に言えば、交通定期券のようなものです。この定期券は１年と３年があります。
通勤経路の乗車について24時間365日利用可能ですが、利用頻度が低ければ都度乗車料金を支払った方が得です。
このため、利用頻度に応じて都度乗車か定期券かどちらが得かを計算して判断した上で選ぶことになりますが、ガバメントクラウドの長期継続割引も全く同じです。
ただし交通定期券と違う点が１つあり、それは解約や払い戻しは原則できないということです。途中で通勤経路を変えたくても１年分の料金を負担し続けなればなりません。
例外的に通勤経路の変更に一部対応できるものもありますが、ここでの説明は割愛します。
Q. リザーブドインスタンス/リザーブドノードをキャンセルすることは可能ですか？
https://aws.amazon.com/jp/aws-jp-faq/#ri-cancel
Q. Savings Plans をキャンセルすることは可能ですか？
https://aws.amazon.com/jp/aws-jp-faq/#sp-cancel
２．ガバメントクラウドの独自ルール
これまでの説明はAWSでの一般的な利用についての話ですが、ガバメントクラウドや役所特有のルールがいくつかあります。
１つ目は、地方自治法による単年度会計の原則から、年度単位の執行が求められることです。
簡単に言えば、令和７年度の予算であれば、令和７年４月１日から令和８年３月３１日までの定期券しか買えません。
民間の利用者は５月から１年間とか、９月から１年間とか自由に買えますが、役所は法律の縛りで出来ないのです。
２つ目は、地方公共団体はガバメントクラウドを利用するためにデジタル庁と契約を行いますが、その契約がデジタル庁とAWSとの契約を前提としたものであるということです。後者が基本契約で前者が個別契約と理解すれば分かりやすいと思います。そしてデジタル庁が締結している基本契約の期間は令和８年３月３１日までしかありません。
このため、幾ら地方公共団体が長期継続契約や債務負担の手続きを取って会計上の課題をクリアしたとしても、３年の定期券を購入することは出来ません。
３つ目は、購入時に一括前払いが出来ないということです。通常は定期券購入時に全額料金を支払いますが、そうではなく毎月料金を支払う事になります。
なぜこの前払いが禁止されているのかは良く分かりませんが、デジタル庁の資料では法的に許容されないと記載されており、何らかの法律に抵触するものと思われます。
恐らくは役務の検査確認を経ずに契約代金を支払う事は出来ないとか、そのあたりのルールでは無いかと思います。
４つ目は、転売が出来ないという事です。先ほど長期継続割引は構成変更等で使いみちが無くなっても解約や払い戻しができないと説明しました。
この際、通常のAWS利用であれば、長期継続割引対象の物件（リザーブドインスタンス）をマーケットプレースに安価で出品して、誰かに購入してもらう事で、損失を抑える事が可能です。
しかしガバメントクラウドだと、このマーケットプレースの利用自体が制限されています。
長期継続割引自体、使いどころの判断が必要ですが、こうした役所特有のルールがあるため、輪をかけて難解であり、かつ使いづらくなってしまっています。
３．４月１日午前９時から午前９時５９分
デジタル庁の説明で「４月１日午前９時から午前９時５９分に購入する」という説明があったかと思います。なぜそんな不可解な指示がされているかというと、実はこれも地方自治法関係です。
AWSの長期継続割引は１時間単位であり、かつ購入した瞬間から適用されます。
つまり令和７年４月１日０時００分から令和８年３月３１日２３時５９分までの定期券を購入するには、令和７年４月１日０時００分から令和７年４月１日０時５９分までの１時間の範囲で購入しないといけないのです。
仮に令和７年４月１日１時００分に購入操作をしてしまったら、令和７年４月１日１時００分から令和８年４月１日０時５９分までの定期券となってしまいます。
たった１時間であっても、令和７年度予算で令和８年度の役務を調達していることとなるため、地方自治法違反となってしまうわけです。
ここまで説明して「いや午前９時どこいった？」と思われるかもしれません。それを今から説明します。
先ほどAWSの長期継続割引は１時間単位と説明しましたが、もう１つルールがあり、AWSの請求の時間はJST/日本標準時ではなく、UTC/協定世界時を基準に請求金額を計算します。
UTCはGMT/グリニッジ標準時と同一であり、日本との時差は９時間です。
つまりAWS会計における令和７年４月１日０時００分から令和７年４月１日０時５９分までの１時間というのは、日本時間だと令和７年４月１日９時００分から令和７年４月１日９時５９分までの１時間なのです。
Q. AWSの請求の時間はJST/日本標準時ですか？
https://aws.amazon.com/jp/aws-jp-faq/#billing-timezone
もしかすると「そもそもその９時間のズレは良いのか？何かの法律に抵触しないのか？」と思われるかも知れません。
自分も同感ですが、恐らくは国において整理済みなのでしょう。そうでなければ、現在ガバメントクラウドでAWSを利用している国の機関が全部法律違反になってしまいます。
機会があれば今後そこの解釈についても調べてみたいと思います。
４．実際の購入
長期継続割引対象の物件（仮想サーバ等のリソース）をどうやって購入するのか？という疑問もあると思います。
令和６年度まではデジタル庁への事前申請や審査があり、書面でのやり取りがありましたが、令和７年度からはこの手続きが不要となりましたので、一般的なAWSでの購入操作と同じです。
具体的に言うと、AWSのマネジメントコンソールから通常の仮想サーバを建てるのと同様の操作で購入を行います。またAWS CLIというコマンドラインツールから購入操作を行う事も可能です。
必然的に購入操作を行うのは運用管理補助者であり、職員は行いません。（なお名古屋市は全面単独利用方式であるため、職員が購入しようと思えば出来ますが、やらないルールとしています）
先ほど４月１日午前９時から午前９時５９分に購入操作をする必要があると説明しましたが、長期継続割引の多くは事前に予約購入（キューイング）を行う事が可能です。
ですので４月１日の朝、全国のエンジニアがコンソール画面に貼りついて全自治体分の購入を行うといった、アイドルコンサートのチケット販売のようなことにはなりません。
しかし、仮想データベース（Amazon RDS）のみは予約購入が出来ません。この対策は次の５で説明します。
５．各長期継続割引購入オプションの適用
本項目は難解ですので自治体職員が内容を理解する必要はありません。運用管理補助者のエンジニアに本項目を読んでもらい、理解してもらうようにしてください。
長期継続割引については一定緩和されたものの、全ての購入オプションが認められているわけではありません。結局、認められているのは以下に挙げる４つのみです。
○ EC2 RI・１年・リージョナル・スタンダード
○ RDS RI・１年・リージョナル・スタンダード
○ EC2インスタンス SP・１年
○ コンピュート SP・１年
なおゾーンRIやコンパーティブル、OpenSearch Service RI等、調整中のものもありますが、上記からは省いています。
また上記に掲載されていなくとも、GCASヘルプデスクから申請・調整を行い、必要性が認められれば許可される可能性もあります。
上記に挙げた購入オプションの対象となるコンピュートリソースはEC2、RDS、Lambda、Fargateの４つのみです。
順番に見ていきましょう。
EC2の選択肢としては、RI、EC2インスタンスSP、コンピュートSPの３つです。
割引率からコンピュートSPは除外、またリージョナルのためキャパシティー予約が付随せず、かつマケプレが禁止されているため、RIの優位性はありません。消去法でEC2インスタンスSPとなります。
LambdaとFargateの選択肢はコンピュートSPしかありません。
しかし。そもそもサーバレスで適正なコミットメント額の算出が困難のような気がします。
とは言え、自治体の予算であるため、コミットメント額の算出根拠は確実に説明できるようにしておく必要があります。EC2インスタンスSPのコミットメント額をオーバーした時の保険にもなるしエイヤで購入といったノリは非推奨です。
実績を積み重ねて十分予測が可能であれば良いのですが、そうでなければ採用しない方が良いでしょう。
問題はRDSです。
こちらも選択肢はRIしかないため迷う事は無いのですが、キューイングが出来ないので自動購入の仕掛けを作る必要があります。（人力オペレーションで対処するのはやめましょう）
具体的には、Lambda でAWS CLI にてpurchase reserved db instances offering コマンドを実行する関数を予め作成しておき、StepFunction（もしくはEventBridge スケジューラ）で当該Lambda 関数を 2025-04-01T00:00:00Z に実行するようにしておく方法が考えられます。
この仕掛けの事前テストには留意が必要です。
取り消しが出来ず、かつガバクラ環境で実施すると即法律違反になってしまいますので、事業者独自のアカウントで、t4g.nano などで試していただく事になると思います。
加えて、購入が失敗した場合のリカバリーも考慮しておく必要があります。
６．結局どうすれば良いのか？
まずは、運用管理補助者に長期継続割引をどうするか相談してみてください。
長期継続割引の購入作業も無料ではありません。
対象となるコンピュートリソースのそれぞれについて、稼働時期や運用を踏まえた上で、オンデマンドの場合と長期継続割引適用時の料金を比較し、対象を選定する必要があります。
また購入対象についても予約購入操作を行う必要があり、仮想データベースについては自動購入の仕掛けを作る等の作業が発生します。
これらの役務が運用管理補助者との契約上どのような扱いになるか確認が必要であり、場合によっては追加料金が発生するでしょう。
追加料金を補填する予算があれば良いのですが、無ければ流用等の対応が必要です。その際、財政担当者に「これだけの追加費用が今年度かかるけれども、対応すれば次年度にこれだけのクラウド利用料が節約できる」といった説明が必要となり、それらの根拠資料の作成も必要となるでしょう。
それでもやるのか、やらないのか、判断しなければならないかもしれません。
あるいはそもそも長期継続割引の対象となる物件のタイプやサイズがまだ決まっておらず、運用管理補助者に断られてしまうかもしれません。
やらない場合でも、やらない理由を各方面に説明する必要があると思いますし、それとは別に次年度の利用に向けて準備を進める事になると思います。
もう２月で時間がありません。とにかく早急に動くことが重要です。
補足事項
運用経費には運用管理補助者のインフラ保守料や標準準拠システムのアプリケーション利用料等があり、クラウド利用料はその一部です。
長期継続割引はそのクラウド利用料のうちの一部を２割程度軽減するものです。
運用経費の一部の更に一部を２割程度カットするものなので、過度な期待は禁物です。
加えて、前述のように長期継続割引に対応するための経費も発生する可能性があります。
また５で、EC2に適用すべき購入オプションをコスト重視でEC2インスタンスSPと記載しましたが、リスク回避重視であればコンピュートSPを選択する考え方もあります。
いずれにせよ、運用管理補助者と良く相談し、メリットやデメリット＆リスクを理解した上で判断する必要があります。