円安だしコスト節約のため、EC2のリザーブドインスタンスを購入する

このページの目的。AWSのEC2のコスト削減・節約をする

本記事では、EC2のリザーブドインスタンス（Reserved Instances、RI）を購入した時の事を書いています。また、EC2のRI購入後に、稼働中のEC2にRIがしっかり適用されて料金が安くなっているかを確認した事についても説明しています。

リザーブドインスタンスは結構昔からあるAWSのコスト削減策なので、仕事でAWSを使っているITエンジニアなら当然のように使っていると思います。けど、自分の場合は個人でAWSを使っていて、多くのEC2を使っているわけでもないので、AWSのコストについてはほとんど気にしていませんでした。それでも、昨今の円安ドル高でさすがにAWSの使用料金の上昇を意識するようになってきました。（2021年から2022年にかけてドル円が30%もドル高に動いたから、ドル建てのAWS使用料金は一気に上昇したという体感があってちょっと焦りました。）

自分の場合、AWS料金の大半がEC2だったので、ターゲットをEC2に絞ってもっと料金が安くならないか、コスト削減策についてネットや本で調べてたら、リザーブドインスタンス（RI）、Savings Plans（SP）、スポットインスタンスなどの方法があり、それらを使うとEC2のコストをかなり安く済ませられるケースがある事が分かりました。（今まではオンデマンドのEC2インスタンスを使っていて、オンデマンドEC2は使った時間分だけ料金が発生する従量課金制。）

オンデマンドEC2を使うより、RIやSPやスポットインスタンスを購入する方がかなり安くなる、はっきり言って格安になるケースもあると知って、「あ〜無知って損だな、もっと早く知っていれば料金を安く抑えされたのに」と正直感じました。

という事で今更ですが、SIの購入からSI適用後の利用料金が安くなるまでの確認についてまとめて書いていきます。個人で独学でAWSを勉強しているAWS入門者・初心者の方や、オンデマンドEC2を使っているけど料金をもっと安くしたいと考えている方に参考になればと思います。

EC2のRIとSPで迷うが、RIを購入する事にする。AWSのコスト節約・削減方法のお勧めのKindle本の紹介についても

まず、EC2のRI、SP、スポットインスタンスについて、ネットやKindle本などで調べて勉強して大まかな理解をしました。
私の場合、常時稼働しているオンデマンドのEC2インスタンスがあったので、そのEC2料金のコストを下げる選択肢はRIかSPのどちらかだなとすぐに決められたけど、RIとSPのどちらを選ぶかで迷いました。

RIとSPのどちらを購入しても問題なくいけそうだったので結構迷ったのですが、RIの方がシンプルで理解しやすかったので最初はRIにしようと考えましたが、EC2のリザーブドインスタンスのコンソール画面を見たら、「リザーブドインスタンスよりも Savings Plans をお勧めします。」という文言のインフォメーションを見てまた迷う事に…（SPが出たのは2019年で、RIと比較して新しい料金体系で柔軟性もあるらしい。）

ただ、AWSコスト管理（AWS Cost Explorer）画面で、"Savings Plans"と"予約"の推奨事項というのがあるのですが（"予約"はRIの事、Reservredは予約済みという意味）、Savings Plansの推奨事項画面では何も推奨されてなかったけど、予約（RI）の推奨事項画面ではEC2のリザーブドインスタンスを購入する推奨がされていました。

アクションの推奨事項のリンクを選択すると、推奨するRIの詳細情報（プラットフォームやテナンシーなど）も教えてくれます。

ただ、RIの推奨事項を教えてくれるのは嬉しいけど、ここでちょっと疑問が湧きます。自分の場合、常時稼働しているEC2のインスタンスタイプはt2.microなのですが、推奨事項では「2個のt2.nano」のRIの購入を推奨しています。何故、1つのt2.microではなく、2つのt2.nanoなのか？

これはどうやらEC2のRIでは、インスタンスサイズの柔軟性と正規化係数という考え方があり、2台のt2.nanoのRIでt2.microのECに適用させる事ができるみたいで、コンソール画面の予約（RI）の推奨事項ではそういう表示の仕方をしているみたいです。（ただし、インスタンスサイズの柔軟性を有してるRIは、リージョン指定でプラットフォームはLinux/UNIXかつテナンシーはデフォルト（共有）選択時のRIに限るらしい。）

もちろん、インスタンスの柔軟性を有していて2台のt2.nanoのRIでt2.microのECに適用させるだけでなく、1台のt2.microのRIでt2.microのEC2に適用させる事も可能です。

このへんの、インスタンスの柔軟性、正規化係数、予約（RI）画面の推奨事項の見方については、AWSの公式動画がわかりやすく説明していて参考になりました。（2:50~からインスタンスの柔軟性と正規化係数について、6:10~からRIの推奨事項の見方について説明しています。）

また、こちらのAWSの公式動画もEC2のリザーブドインスタンス（RI）を理解するのに勉強になりました。

また、このすぐ後に紹介しているKindle本でもリザーブドインスタンスのインスタンスサイズの柔軟性と正規化係数について具体例を用いながら詳細に説明していて勉強になりました。

少し話がそれましたが、私の場合はRIの方がシンプルでわかりやすかったのと、AWSコスト管理画面でRIが推奨事項にあった事と、あとは事前に料金のシミュレーションをして、今回はRIを購入する事に決めました。（次はSavings Plans(SP)を購入してみようと思う。）

あと、RIの料金シミュレーションを事前にしたい場合はこちらの公式サイトでできます。（画面内のタブの切り替えで、スタンダートRIとコンバーティブルRIの料金の計算を切り替える事ができる。）
Amazon EC2 リザーブドインスタンス料金表
SPの料金シミュレーションをしたい場合もこちらの公式サイトでできます。（画面内のタブの切り替えで、Amazon EC2のCompute Savings PlansとEC2 Instance Savings Plansの料金の計算を切り替える事ができる。）
Compute Savings Plans

RIとSPのどちらを選択するかで迷いましたし、RIに決めた後も、スタンダードRIとコンバーティブルRIのどちらを選択するかや、リージョンRIとゾーンRI(AZ RI)のどちら（キャパシティ予約を付けるかどうか）を選択するかでもかなり迷いました。選択肢が多いと便利で柔軟性もあるけど、その分迷って色々と調べたり理解したりで時間がかかって大変すね。特にほぼAWS入門者・初心者レベルの自分には。けどその分勉強にはなったし、何よりAWSの料金コストを抑えられる結果に繋がったので良かったです。

この後は、実際にEC2のRIを購入した時の説明や、RI購入後の料金削減の確認などについて説明していきます。

実際にEC2のRI（リザーブドインスタンス）を購入する

それでは実際にEC2のリザーブドインスタンスを購入してみます。EC2のRIの購入は、AWSコンソールのEC2のサイドバーのインスタンス->リザーブドインスタンス画面からできます。

リザーブドインスタンス画面でリザーブドインスタンスの購入ボタンを押すと、リザーブドインスタンスの購入画面が開くので、そこで提供タイプの詳細を選択して検索ボタンを押します。

私の場合ですが、この提供タイプのリザーブドインスタンスを購入しました。
（*これはあくまで私の場合で、環境や運用ケースによってタイプの選択は全然異なると思います。）

プラットフォーム	Linux/UNIX
テナンシー	デフォルト
提供クラス	スタンダード
インスタンスタイプ	t3.micro
期間	1年（1~12ヶ月）
支払い方法	前払いなし
キャパシティ予約のある提供タイプのみ表示	選択しない。つまりリージョンRI

この提供タイプのリザーブドインスタンスの料金は、従量課金のオンデマンドのt3.micro EC2と比較すると37%コスト削減になります（2023/7/29時点）。37%のコスト節約は本当に大きいです。改めて何故もっと早くリザーブドインスタンスに切り替えなかったのかと思いました。
ちなみに期間を1年ではなく3年にした場合、オンデマンドと比較した割引率は37%から57%まで増えます。57%なんて格安どころか激安なのでちょっと迷いましたが、3年はやはりちょっと長いし、今回は初めてのリザーブドインスタンスの購入なので1年を選択しました。

プラットフォームとテナンシーについてですが、自分が使用しているEC2のプラットフォームとテナンシーが何なのかを確認したい場合、EC2のコンソール画面（対象のEC2にチェックして詳細タブ）で確認できます。もしくはAWSコスト管理（AWS Cost Explorer）画面にRIの推奨事項があれば、その推奨事項の画面にも書いてあると思います。

私の場合、AMIがAmazon Linux 2のEC2に適用させたかったので、プラットフォームはLinux/UNIXを選択しました。
あと、EC2のテナンシーのデフォルト(default)は、共有(Shared)テナンシーの事です。

提供クラスはスタンダードを選択しました。スタンダートかコンバーティブルのどちらを選択するかは運用ケースによって異なると思うけど、スタンダードの方が安いのでスタンダードで問題なくいけそうならスタンダードを選択するのが普通かと思います。

キャパシティーの予約に関してはすごく迷ったけど、今回はキャパシティーの予約をしない選択をしました。つまり、アベイラビリティーゾーン(AZ)を指定しないリージョンRIを選択しました。（AZを指定するゾーンRIでも特に問題ないだろうとも思ったけど…）

私の今回の運用ケースの場合、RIを適用させて運用する予定のEC2はそこまでクリティカルなシステムでも無いし、それにオンデマンドキャパシティ予約とリージョンRIの組み合わせは可能みたいなので何か問題があった時はそれに頼ればいいかなと思い、RIはキャパシティ予約をしない選択をしました。

ちなみにキャパシティ予約のあるRIを購入したい場合、リザーブドインスタンスの購入画面の右上にある「キャパシティ予約のある提供タイプのみ表示」をオンにして、アベイラビリティーを選択すればできます。（キャパシティ予約のあるRIにする場合はゾーン指定になる。）

このあたりの、テナンシー、提供クラス、キャパシティ予約などの知識についても最初よく解らなかったので、ネットの情報や上の方で紹介したAWSのKindle本などを読みながら１から勉強して理解しました。（それぞれの運用環境によって最適なRI(SPもそうですが)は異なると思うので、特に初めてRIを購入する場合はしっかり運用環境を考えてからRIを購入するのが良いと思います。）

RIの購入画面の説明に戻ります。
RIの購入画面で各提供タイプを選択して検索ボタンを押すと、条件に合うRIが一覧表示されるので（たまに販売者がサードパーティのRIも一覧に出てくるので注意）、購入したいRIのカートに入れるボタンを選択->カートを見るボタンを選択して、RIの最終的な購入確認画面に進みます。購入確認画面を見て問題がなければすべて注文ボタンを押してRIの購入ができます。（RIを購入した後で購入をキャンセルできないので、しっかり最終確認する。）

RIの購入処理が完了したら、リザーブドインスタンスのコンソール画面に購入したRIが追加されて、そのRIの情報を確認できます。
そして、支払いが承認されると状態が「アクティブ」になります。

RIを購入して状態がアクティブになればOKです。RI適用対象のEC2インスタンスが稼働していれば自動的にRIが適用されて料金割引になります。（EC2の料金は、オンデマンド料金からRI料金に変更になって安くなる。）
RIを適用させたいEC2を再起動したり、EC2とRIを紐付けるなどの特別な処理を行う必要は一切ないです。

とは言っても、本当に購入したRIが稼働中のEC2に適用されて料金が安くなっているか心配なので、次はそのあたりの確認もしていこうと思います。

EC2のRI購入したので稼働中のEC2にRIが適用されて料金が割引され安くなっているかを確認する。AWSコスト管理（AWS Cost Explorer）画面とBillingの請求書画面

EC2のRIを購入したので、稼働中のEC2にRIの割引が適用されて安くなっているかを確認したいと思います。

AWSの料金の事なので、AWSコスト管理（AWS Cost Explorer）とBillingの2つの画面を見ていきます。AWSコスト管理は日単位でコスト（料金）を表示して見れますし、Billingの請求書は月単位だけどサービス別に料金を表示して確認できます。

ただ、RIを購入したすぐ後に確認してもまだ料金の変化を確認しづらいと思うので、1日だけ待ってからこの2つの画面を確認する事にしました。

それでは、RIを購入して大体１日経ったので、AWSコスト管理のCost Explorerを確認します。 そして、跳ねてる数字（コスト）を見てちょっとビビります。

AWSコスト管理画面では日別の料金を確認できるわけですが、前日の料金が増えていました･･･（RIを購入した日です。）
この日はRI購入以外で特別な事は何もしていないので、RIの購入が影響していると考えるのが自然です。
RIの支払い方法は「前払いなし」を選択したので、想定ではRI購入後に日単位の料金が安くなると考えていたけど、逆に増えてる料金グラフを見てちょっと焦ります。（ただ、コスト上昇額はそれ程大きくはない。）

コストが増えた原因を考えたけどわからないので、今度はAWSのサービス別の料金を確認できるBillingを確認します。
Billingの請求書画面は月単位でAWSサービス別料金を確認できるので、当月を選択して確認します（画像はEC2の部分だけ）。

EC2料金の表示部分は、オンデマンドEC2とRIのEC2の料金に分かれています。
オンデマンドEC2は「Amazon Elastic Compute Cloud running Linux/UNIX」、RIのEC2は「Amazon Elastic Compute Cloud running Linux/UNIX Reserved Instances」です。

RIのEC2の料金表示の方は、もちろんRI購入前にはありませんでした。RIの料金は「USD 2.06」となっていますが、この2.06ドルが何の料金なのかわかりません（購入したRIのインスタンスタイプはt3.micro）。

ただこの2.06ドルという数字は、先に確認したAWSコスト管理のRIを購入した日のコストと一致しています。
やはり料金が跳ねた日の原因は、RIの購入のせいだったという事は理解できます。ただ、2.06ドルという数字が何なのかが分かりません。

もう少しRIのEC2の料金部分を見ると、明細が２行あります。

Amazon Elastic Compute Cloud running Linux/UNIX Reserved Instances                              USD 2.06
Linux/UNIX (Amazon VPC), t3.micro reserved instance applied, t3.micro instance used    7 Hrs	USD 0.00
USD 0.0086 hourly fee per Linux/UNIX (Amazon VPC), t3.micro instance                 240 Hrs	USD 2.06

「t3.micro reserved instance applied, t3.micro instance used」は、t3.microのリザーブドインスタンスがt3.microのインスタンスに適用されてる（applied）という意味なので、やはりしっかり購入したRIがEC2に適用されているみたいです。そして、その時間が7時間で料金が0ドル。
時間は問題ないと思うけど、料金が0ドル？ RIを購入してEC2に適用されて7時間経ったわけだから、7時間分のRIの料金がかかるんじゃないの？

一方、「USD 0.0086 hourly fee per Linux/UNIX (Amazon VPC), t3.micro instance」の方は、240時間で2.06ドルになっています。この時間と料金の数字の意味がわからん。
（*0.0086ドルは今回自分が購入したt3.microのRIの1時間あたりの料金で、「0.0086 * 240 = 2.06」となるのはわかる。）

それでネットで調べてたら、こちらのページを見て理解しました。
AWSの月初めの高額課金にビビる

どうやら、リザーブドインスタンスの課金と料金明細の表示の仕方は、月初めにその月の全時間分の料金が課金されて料金明細に表示されるみたいです。RIの場合、1時間単位で課金を増やしても、月に1度まとめて課金しても、確かに結果は同じになるので納得です。

今回の私の場合は、月の途中の21日頃にEC2のRIを購入したから、その月の月末までの期間があと10日（240時間）なので、240時間で2.06ドルという数字はそういう意味なんだなと理解しました。

という事で、今後のBillingの料金明細についてですが、RIの料金2.06ドルは来月になるまでは変化しないはずで、「t3.micro reserved instance applied, t3.micro instance used 」は、EC2のRIがEC2に適用されて使われていれば時間は増えていくはず（ただ料金は0ドルのまま）だと予測できます。

また、オンデマンドEC2の方の料金明細に「$0.0136 per On Demand Linux t3.micro Instance Hour 105.199 Hrs USD 1.43」の１行がありますが、これはt3.microのEC2インスタンスがオンデマンドで動いていた時の料金で、t3.microのRIを購入した時からこのEC2の料金体系はオンデマンドからRIに切り替わったはずなので、オンデマンドの方はもう時間も料金も変わらずで増えないはずです。

という事で、また数日程経ってからBilling->請求書画面で当月の料金明細を確認してみました。

まず、リザーブドインスタンスの料金は2.06ドルなので、数日前から変わっていません。
また、「t3.micro reserved instance applied, t3.micro instance used 」の明細は、t3.microのRIがEC2に適用されている時間だけは増えています（料金は0ドルのまま）。
そして、オンデマンドのt3.microの時間と料金は数日前から変わっていません。

これは全て予測した通りです！これでようやく、購入したRIが稼働中のEC2にしっかり適用されて料金が割引されて安くなっている事を確信できました。

ついでにAWSコスト管理画面も再度確認してみます。

リザーブドインスタンスを購入した日のコストが跳ねていますが、その後のコストは安くなっています！
この料金変化も予測通りなので大丈夫です。

AWSコスト管理画面のリザーブドインスタンスの利用率とカバレッジ率を見て、EC2のリザーブドインスタンスが稼働中のEC2に適用されている事を確認する

これまではAWSの料金の変化から（AWSコスト管理とBilling）、購入したEC2のリザーブドインスタンスが稼働中のEC2に適用されて料金が割引されているかを確認しましたが、AWSコスト管理画面の、リザーブドインスタンスの利用率とカバレッジ率を日別（日次推移）でも確認する事ができます。

リザーブドインスタンスの利用率は、購入したRIの時間のうちどの程度の割合稼働中のEC2によって使われたかを表し、一方でカバレッジ率は、オンデマンドで稼働しているEC2の全体使用量に対してどの程度の割合RIによってカバーしているかを表します。

つまり、すごくシンプルな例として、オンデマンドで稼働しているEC2が1台あり、そのEC2に適用させるRIを購入した場合、RI利用率とカバレッジ率は両方とも0%から100%に変化します。

それではリザーブドインスタンスの利用率とカバレッジ率を確認していきます。
リザーブドインスタンスの利用率は、AWSコスト管理画面の左サイドバーの予約->使用状況レポート、カバレッジ率は予約->カバレッジレポートで見れます。 または、レポート画面のRI Utilization（予約の利用率）とRI Coverage（予約カバレッジ）からでも見れます。

先に、リザーブドインスタンスの利用率（RI Utilization）を確認します。
画面の右サイドバーで日付範囲を指定できるので、確認したい期間を指定します。（ただし、最新データが見れるようになるまで48時間かかるようなので、RIを購入してから少なくとも2日以上経ってから確認しましょう。）

RIの購入前に0%だった使用状況が、RI購入後は100%に変化しています。
つまり、購入したRIが稼働中のEC2に適用されて使われている事を確認できました。

次に、リザーブドインスタンスのカバレッジ率（RI Coverage）を確認します。
カバレッジ率も画面の右サイドバーで日付範囲を指定できます。あと、インスタンスタイプ毎にカバレッジ率を確認できるので、対象のEC2インスタンスタイプにチェックを入れて確認してもいいと思います。

カバレッジ率も、RIの購入前は0%だったのに、RI購入後は100%に変化しています。
つまり、稼働しているEC2が、購入したRIに100%カバーされてるという事です。

利用率もカバレッジ率も予測通り（期待通り）の結果を示してくれました！

ちなみにこのリザーブドインスタンスの利用率とカバレッジ率はAWS Budgetsで監視してメール通知などもできるようです。このあたりの詳細は、上の方で紹介したAWSのKindle本に書いてあるので気になる方は参考にしてください。

これでリザーブドインスタンスの利用率とカバレッジ率のレポートを見て、稼働中のEC2にRIがどれだけ適用されているかを確認する事ができたので良かったです。

EC2コンソール画面とEC2メタデータからは、リザーブドインスタンスが適用されているEC2かどうかの区別ができない

これまではAWSの料金の変化や（AWSコスト管理の日別コストとBillingの請求書の料金明細）、AWSコスト管理の予約（リザーブドインスタンス）の利用率とカバレッジ率を見て、購入したEC2のRIが稼働中のEC2に適用できているかを判別してきました。

これらの方法で判別できてるのでもう十分なのですが、EC2のコンソール画面とEC2メタデータから判別できないかを調べてみた事について少し書いておきます。先に結論を言うと、判別できませんでした。

まず、EC2のコンソール画面についてです。EC2コンソール画面の左サイドバーのインスタンスを選択して、対象のインスタンスを選択して詳細タブを選択すると、ライフサイクルという項目があるのですが、この値がノーマル（normal）の場合、そのEC2インスタンスはオンデマンドインスタンスかリザーブドインスタンスのどちらかです。という事で、オンデマンドかRIの区別ができないですね。（スポットインスタンスの場合はspotと表示されるらしい。）

[Details (詳細)] タブの [Instance details (インスタンスの詳細)] で、[Lifecycle (ライフサイクル)] を見つけます。値が spot の場合、そのインスタンスはスポットインスタンスです。値が normal の場合、インスタンスは オンデマンドインスタンス または リザーブドインスタンス です。
（引用元：インスタンス購入オプション）

次に、EC2のメタデータについてですが、sshログインしたEC2上でcurlコマンドを使いEC2インスタンスの様々なメタデータを取得する事ができます（例えば、インスタンスタイプやIPアドレスなどがわかる）。curlコマンドでのEC2メタデータ取得例については別ページで書いてあるので、よければそちらを参考にしてください。
ec2(Amazon Linux 2、Amazon Linux 2023)でプライベートIPアドレス（ローカルIPアドレス）とグローバルIPアドレス（パブリックIPアドレス）をコマンドで確認する。curlやec2-metadataコマンド

それで、EC2のメタデータの中に"instance-life-cycle"というのがあるので、それを取得してみました。

$ curl http://169.254.169.254/latest/meta-data/instance-life-cycle
on-demand

ただ結果は、RI購入前と購入後ともに"on-demand"で変化無しでした。RIを購入したら変わるのかなと少し期待したのですがダメでしたね。変わったら簡単にRIが適用されてるEC2かどうかを判別できたのですが。

という事で、少なくとも現時点では（2023/8/5時点）、EC2コンソール画面とEC2メタデータからは稼働しているEC2にリザーブドインスタンスが適用されているかどうかの判別は無理みたいです。この方法から判別できたら簡単で分かりやすいので、今後そうなってくれる事を期待しときます。

最後に。AWSのその他のサービスのコスト節約・削減策について

本記事では、AWSのコスト節約・削減のためにEC2のリザーブドインスタンスを購入した事と、購入したリザーブドインスタンスが稼働中のEC2に適用されて料金が安くなる確認をしました。確認方法としては、Billingの請求書でAWSサービス別の料金明細を見たり、AWSコスト管理画面でリザーブドインスタンスの利用率やカバレッジ率を見て確認できました。

これでEC2の料金がオンデマンド料金からリザーブドインスタンス料金に切り替わり、当初の目的通り無事AWSの料金を安く抑える事に成功しました！ただ、冒頭でも話しましたが、正直もっと早くリザーブドインスタンスを購入すればよかったと思います。自分がAWSの料金に対して無頓着で無知だったせいで、今までは結構な損をしていた事になります。やっぱり知識がある無いの差は大きく、無知は損だなと感じています。

今後はもう少しAWSの料金の情報を気にかけたり、AWSのコスト節約術はEC2以外でもまだまだ色々とありそうなので少しづつでも勉強しながら試したいと思います。為替もまだドル高円安が進む可能性もありますし（将来の為替がどうなるかなんて読めないと思うので）。

参考サイト

AWS の利用方法を見直してコスト最適化してみよう ~前編~
リザーブドインスタンス よくある質問 - Amazon EC2 | AWS
インスタンスメタデータのカテゴリ