はじめに
こんにちは。エンジニアの @wa6sn です。開発組織を横断した課題を解決する Platform Unit というところに所属し、色々をやっています。
2025/03/27 に、srest(スレスト) 様による AWSコスト 春の総決算2025 というイベントがありました。組織での Reserved Instances（RI）と Savings Plans（SP）の運用について、前々から話す機会を伺っていたので、LT をさせていただきました。その内容と、補足について書こうと思います。
話した内容
以下のスライドです。
ギフティではそこそこのプロダクト数・AWS アカウント数があります。1 プロダクトに対して 1-3 個程度の AWS アカウントが紐づき、各開発チームでオーナーシップをもってインフラからアプリまで開発しています。誰かがまとめて RI や SP を買ってくれるような体制ではなく、各開発チームで調べながら、買ったり買わなかったりしていました。
RI や SP は言ってしまえば購入ボタンを押すだけなので、仕様さえ理解していれば 時間対効果は高いです。しかし、メンバーそれぞれがこれらの概念を確実に理解するのは大変です。メンバーにはなるだけ開発に専念してもらいたいので、最終的なオーナーシップは持ってもらいつつ、認知負荷を軽減することを目指しました。この運用は自分が入社してすぐくらいの、2022 年ごろに整えています。
スライド中に紹介される API は以下です。今どきだと、LLM でそれらしいスクリプトはすぐ書けて、再現できると思います。
- https://docs.aws.amazon.com/cli/latest/reference/ce/get-reservation-purchase-recommendation.html
- https://docs.aws.amazon.com/cli/latest/reference/ce/get-savings-plans-purchase-recommendation.html
- https://docs.aws.amazon.com/cli/latest/reference/ce/get-reservation-utilization.html
- https://docs.aws.amazon.com/cli/latest/reference/ce/get-savings-plans-utilization-details.html
スライドの補足
懇親会でいただいた質問も含め、ここで補足します。
ギフティでの AWS コストとの向き合い方
コスト効率の良いアーキテクチャ選定を行うことも、大事なスキルの一つとしてとらえています。開発チームの中でサービス運用も行うため、なるだけクラウドの特性を活かしたアーキテクチャが好まれ、結果的にコスト効率の良いアーキテクチャとなることが多いです。
また、「使った分だけ支払う」料金モデルであるクラウドのコスト削減の分類には、アーキテクチャに直結しているものと、そうでないものがあると思っています。
- 適切な分量のリソースを利用すること
- サーバレスなアーキテクチャ、利用しないインスタンスを終了する、インスタンスのサイジングなど
- 利用するリソースに対して割引をかけること
- RI や SP の活用など
後者に時間を割くよりは、前者に向き合ってもらいたいです。こうした考えから、「今期は X % コスト削減をしてほしい」といった号令がトップダウンで出たこともありません。
スライド p19 の、Coverage Report の割合が時間基準ってどういうこと？
まず、今回の運用設計によって、ギフティ社内では主に以下の RI/SP が利用されるようになりました。
- Compute Savings Plans
- RDS の Reserved Instances
- ElastiCache の Reserved Instances
いずれも Coverage Report からカバレッジ率を確認できるのですが、この Coverage (%) は、例えば RDS の RI であれば「RI が適用されているリソースの起動時間 / RI が適用出来うるすべてのリソースの起動時間」になります。
単純な例として、db.r6g.8xlarge 1 インスタンスと db.t3.small 1 インスタンスを起動しており、うち db.r6g.8xlarge 1 インスタンス分の RI のみ購入していたとします。コスト観点ではこれで十分と言えそうですが、起動時間に対する Coverage (%) は 50 % となってしまいます。よって、この数字だけでなく、他の指標と合わせて判断したほうがよいでしょう、ということでした。
（なお EC2 の RI では Normalized units に対する Coverage に切り替えられたりするので、今後アップデートされるかもしれません。より使いやすくなることを期待しましょう）
インスタンスタイプは、どれぐらい揃えていますか？
「RDS と ElastiCache は最新世代の Graviton シリーズを利用する」のようなルールを設けて、割引共有の機会を拡大することは出来そうです。ただ、こうしたコンポーネントは変更に少なからずダウンタイムを伴うことと、その調整に引っ張られるのもなと思い、ルール化はしませんでした。
とはいえ、（EC2 と異なり）RDS と ElastiCache は選択できるインスタンスタイプは多くないので、結果的にカバーできています。
エッジケースとして、RI 購入後に、購入時に指定したインスタンスタイプが廃止されてしまったことがあります。RI が無駄になってしまうと思いきや、その RI は（AWS による告知とともに）移行先のインスタンスタイプに合わせてアップグレードされました。ただしこれは AWS 側の裁量によるものだと思われるので、素直に新しいインスタンスタイプを利用できるようにしておいたほうがいいと思います。
おわりに
主催のみなさま、ありがとうございました！
他の方の発表内容、懇親会でお話させていただいたこと、いずれも他社がどのようにコスト最適化に向き合っているのかを伺えて楽しかったです。 また、今回の内容が誰かの参考になれば幸いです。
