← wa6snマルチアカウント環境での、そこまでがんばらない RI/SP 運用設計#

マルチアカウント環境での、

そこまでがんばらない RI/SP 運用設計

2025/03/27 AWSコスト 春の総決算2025

$ whoami

@wa6sn（わらしな）

  • 株式会社ギフティ / エンジニア
    • Yahoo!JAPAN で DBA → AWS Japan で SA → 今
    • 弊社の年度初めは 1 月なので、3 月は総決算シーズンではなかったり
  • CCoE っぽいこと、データ基盤、セキュリティ、データベースなど
    • 社内 ISUCON 主催や AWS Gameday の企画、技術広報っぽいことなども
  • 話したやつとか

先にまとめ

  • AWS Organizations を利用していて、そこそこアカウント数のある環境で、
    RI/SP 運用のベースライン設計 を行った話をします
  • 各メンバーには「買う/買わない」ぐらいに情報量を落としたうえで、
    各アカウント内で購入判断をしてもらっています
    • 弊社の場合、各メンバーに RI/SP の深い理解を求めるのは（人件費的に）本末転倒
    • 球拾いは相対的に詳しい人（自分）が担当
  • RIfactor という自前ツールで集約的にリマインドやレコメンドを行っています

Disclaimer

  • 2025/03 時点の仕様で話します
  • コスト管理のあり方は組織体制によって大きく異なるので、
    あくまで「弊社はこう」というスタンスを話します
    • 費用を事業部が持つのか、"技術部" 的なところで持つのかでも違いますよね
    • RI を買うにもキャッシュフローでどうこう、とかありますよね

弊社の前提

  • AWS Organizations を利用していて、170+ の AWS アカウントが存在します
    • リセラーを利用していません
    • 概ねプロダクトごとにアカウントがあります。アカウントの切り方から開発者に
      お任せしていて、stg, prd のように環境ごとに作成されるケースもあります
    • 個人用 sandbox や stg 系アカウントを除くと、80 アカウントぐらい
  • 横断 SRE のような存在は、今は居ません
    • 各開発チーム（2-6 人ぐらい）が全員、インフラからアプリまでやっているイメージ
    • エンジニアは合計 60 人ぐらい

おさらい｜Reserved Instances（RI）

  • https://aws.amazon.com/jp/ec2/pricing/reserved-instances/ (EC2)
    • おなじみ一定期間継続して利用することを前提に、
      利用料金に対して割引を受けられるサービス
  • EC2, RDS, OpenSearch, ElastiCache, MemoryDB, DynamoDB, Redshift が対象
    • サービスに内包された（？）概念なので、購入時の導線も各サービスから
  • リージョンやインスタンスタイプなど、色々な条件を指定して購入する
    • 「ap-northeast-1 の r6g.large を 2 つ、1 年間分前払いで！」みたいな買い方
    • 「リソースに対して」 前払いをするイメージ

おさらい｜Savings Plans（SP）

  • https://aws.amazon.com/jp/savingsplans/
    • おなじみ一定期間継続して利用することを前提に（ｒｙ
  • コンピューティング系サービス（EC2, Fargate, Lambda）と SageMaker が対象
    • RI と異なり、Billing and Cost Management から購入する
  • RI よりもかなり柔軟に適用できる
    • 「一時間あたり 5 USD 分は確実に使います！」みたいな買い方
    • 「コミット額に対して」 前払いをするイメージ

おさらい｜RI/SP の割引共有

  • https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/ri-turn-off.html
  • 一括請求を利用・共有設定を有効にすると Organizations 内で RI/SP を共有できる
  • まず購入したアカウント内で RI/SP の適用を試みるが、もし未使用のものが
    残ってしまったら、Organizations 内の他のアカウントで適用を試みるもの
    • このとき、削減額が最も大きいアカウントが優先される
  • 共有設定は AWS アカウント単位で ON/OFF の制御のみ可能
    • 「特定の Organizational Unit でのみ共有」は出来ない

RI か SP, どっちがいいのか

  • Management Console いわく、どっちも使えるシチュエーションなら SP を推奨

  • 「SP は RI より割引率が渋い」と言われがちだけど、Compute SP ではなく
    EC2 Instance SP を選んだり、柔軟性を捨てれば RI 同等の割引率にはなるはず
    • 多くのケースでそのはず

RI/SP を運用する際の課題

  • RI や SP のサービスの使い分けを理解したり、
    様々な適用条件を理解して最適な購入条件を探すのは結構たいへん

    • 特に専任 SRE のような存在が居ない弊社では、プロダクト開発者への負担になる
    • 悩んだ人件費 > 節約額 となっては本末転倒

  • 一方、組織の管理者に役割を集約しすぎると、コスト最適化の力学が働きづらい

    • まとめて代理購入してもいいんだけど、一時的なスペックアップといった
      各サービスの事情を加味しきれない
    • そもそもサイズの大きすぎるインスタンスなどは、開発者側で気づいてほしい

そして、弊社ではこうなった

ベストよりも、まずは大失点を防ぐ方針

  • 「一定額以上節約できる」とレコメンドされたら RI/SP を買う
    • SP 対象のサービスは SP を優先する。種別は Compute Savings Plans を標準とする
    • 節約額のしきい値は 200 USD/月 程度に決め打ち
      • 低予算で運用されがちなインスタンスは、管理のオーバーヘッドが勝ると判断
  • いずれも購入時は「全額前払い、1 年利用」に統一する

→ "RIfactor" という自前ツールでこれを機械的に運用する

RIfactor

RI/SP のレコメンド・リマインドを月初に Issue 化して通知くん

  • RI + factor
    • これが通知された時点でリソースの棚卸しなりもされてほしいので、
      refactor とのダブルミーニング（かもしれない）
  • 開発者は購入判断 + Issue close でタスク完了となる
center

RIfactor の仕組み｜レコメンド

  • 「RI/SP のレコメンデーション API」 の結果を一定の節約額が見込めるものに
    絞り、読みやすく整形して GitHub Issue として起票 + Slack 通知している
    • RI なら $ aws ce get-reservation-purchase-recommendation
      • --service は EC2 以外 を対象
    • SP なら $ aws ce get-savings-plans-purchase-recommendation
      • --savings-plans-type COMPUTE_SP に統一
    • いずれも --account-scope LINKED --lookback-period-in-days THIRTY_DAYS \
      --term-in-years ONE_YEAR --payment-option ALL_UPFRONT
  • 実装が楽だったので Payer アカウントから実行している

RI をレコメンドしている例

center

RIfactor の仕組み｜リマインド

  • 「今持っている RI/SP の利用状況を確認する API」 の結果から、
    期限切れが近づいたものに対してレコメンド同様の操作をしている
    • RI なら $ aws ce get-reservation-utilization ,
      SP なら $ aws ce get-savings-plans-utilization
    • UtilizationPercentage が低ければ継続購入しない

SP をリマインドしている例

center

「購入の手引き」ドキュメント

  • 損益分岐点や Size flexibility、割引共有の概念、適用状況の確認方法、
    間違って買った時のキャンセル方法などを説明している
    • 情報を集約しつつ、購入に対する恐怖心をケア
    • 個人的にもよく書けていると思うんだけど、業務近接なため公開しづらい

center

モニタリング

  • 組織の管理者として、RI/SP の適用状況を定期的に確認している
  • Billing and Cost Management サービスで特に見ておきたいのは、以下 2 つ
    • Utilization report: 持っている RI/SP が使われているか
      • できるだけ 100% を目指したい
      • これが下がると「買ったけど使われていない理由」を調べることになる
    • Coverage report: RI/SP 対象サービスについて、どれだけカバー出来ているか
      • できるだけ高い割合を目指したいが、ここの割合は金額基準ではなく
        時間基準 なので、割合そのものの深追いはしなくていいと思う
        • 安い T 系インスタンスをいっぱい並べるだけで割合が下がってしまう
      • Reservations coverage breakdown は見るべき

Coverage report の Reservations coverage breakdown

  • 各インスタンスクラスのグルーピングで、Average coverage や
    On-Demand cost（いくら分オンデマンド料金で払っているか） が確認できる
    • On-Demand cost でソートすると伸びしろが分かりやすい
  • 画像は RDS の RI の例
    • 弊社の RI/SP 運用では、t4g や t3 のような安価で小さい開発系インスタンスは、
      まだ RI/SP の追加購入による削減余地がある、ということが分かる

運用してみて、どうだった？

「全員が安定して 60 点は取れる」ぐらいにはなった

  • 「購入する基準」を定めるなど画一的な運用に倒したことで、開発者の
    ハードルを下げ、「余地があるのに買ってない」ようなケースを大幅に減らせた
  • レコメンド機能により、たまにある「スペックアップしたけど戻し忘れ」に
    別の角度から気づけるようになった
  • 思ったより RI/SP の Utilization は下がらないので、もっとアグレッシブに
    買っていってもいいかもしれない
    • RDS などはそもそもインスタンスタイプの選択肢が少ないので、
      うっかり余っても共有されるチャンスがある

これ以上を望むなら？

  • コスト削減額が少額なものは見逃しているんだけど、
    Payer アカウントからまとめ買いしてしまってもいいかもしれない
    • だいたいは t4g や t3 のような開発用途で、RDS なら t4g あたりは安牌な気がする
    • 特に SP なら 3 年単位でガバッと買えると思う
  • 今回の運用設計はあくまでベースラインであり、
    RIfactor のレコメンドを無視して買ってもいいことになっている
    • チーム内に「分かる人」が居るなら、Compute SP ではなく意図して EC2 Instance SP を買ってもいい。どっちにしろレコメンドはされなくなれば OK

おまけ: 細かいハマリポイント

  • RI の Size flexibility の対応状況

    • RDS: 2017 年ごろから対応している
    • ElastiCache: 2024/10 から対応するようになったので、古い情報に注意
    • OpenSearch と Redshift: 対応していない

  • 子アカウントで買った RI/SP は、子アカウントを完全に削除すると、
    割引共有をしていようが、その利用権も一緒になくなってしまう

    • あくまで子アカウントに紐づいた権利だから
    • All Upfront で買ったあとにそのアカウントを削除すると、払い損なので注意

おわり

  • 具体的なお金の話とかは懇親会でやりましょう