未活用リザベーションという見えないコスト漏れ

AWSリザベーションとは

AWSリソースを1年または3年の期間で利用することを確約する代わりに、大幅な割引(通常はオンデマンド料金から30〜72%オフ)が受けられる仕組み。それがAWSリザベーションです。使った分だけ支払うオンデマンドとは違い、リザベーションは金銭的なコミットメントにあたります。ワークロードが実際に使うかどうかに関係なく、コストは発生し続けます。

AWSは幅広いサービスでリザベーションを提供しています。

• Amazon EC2 – コンピュートワークロード向けのリザーブドインスタンス(RI)
• Amazon RDS – リレーショナルデータベース(MySQL、PostgreSQL、SQL Server、Oracle、MariaDB、Aurora)向けのリザーブドDBインスタンス
• Amazon ElastiCache – RedisおよびMemcachedクラスター向けのリザーブドキャッシュノード
• Amazon OpenSearch Service – 検索・分析ドメイン向けのリザーブドインスタンス
• Amazon Redshift – データウェアハウス用途向けのリザーブドノード
• Amazon DynamoDB – 読み込み/書き込みスループット向けのリザーブドキャパシティ
• AWS Elemental MediaConvert – メディア処理向けのリザーブドトランスコードスロット

いずれも仕組みは同じです。予約したキャパシティに対して全額前払い、一部前払い、または月額で支払い、AWSは該当する使用量を検出したときに割引レートを適用します。使用量がなければ、リザベーションはアイドル状態のまま、支払いだけが残ります。

課題:未活用リザベーションは見えないコスト漏れ

リザベーションは、購入時点の現在のワークロードを前提に選ばれます。しかし、クラウド環境は常に変化します。チームはサービスを縮小し、ワークロードを移行し、アプリケーションを廃止し、あるいはアーキテクチャそのものを見直します。その結果、かつては最適だったリザベーションが、いつの間にか宙に浮いたコストへと姿を変えてしまうのです。

大規模環境で深刻な問題となる理由は次のとおりです。

発生タイミングに気づきにくい。 AWSはCost Explorerで利用率メトリクスを提供していますが、これは何が起きたかを示すにとどまります。自動ワークフローを能動的にトリガーしたり、担当チームに文脈のあるアラートを届けたりはしてくれません。

財務インパクトはあっという間に膨らむ。 us-east-1のNo Upfrontレートで、r5.4xlargeのRDSリザーブドインスタンスが1台未活用のまま置かれるだけで、年間5,000ドル超の出費になり得ます。利用率が10%なら、実質4,500ドルを何の見返りもなく支払っている計算です。これが複数のAWSアカウントやリージョンにまたがる数十のリザベーションで起きれば、無駄は容易に数十万ドル規模に達します。

多くの業界のお客様と関わってきた経験から言えば、これは最もよく目にするFinOpsの失敗パターンの一つです。未活用のリザベーションにチームが気づくのは数週間、あるいは数カ月後ということが多く、その頃には無駄はすでに積み上がり、交換や変更のタイミングも過ぎてしまっているのです。

DoiT CloudFlowによる解決

DoiT CloudFlowは、DoiTコンソールに組み込まれた、GenAI搭載のノーコードFinOps/CloudOps自動化プラットフォームです。ワークフロー(フローと呼びます)を作成して、AWS APIの呼び出し、条件ロジックによるデータ評価、Slack通知やメールアラートの送信、承認リクエスト、さらなる自動化のトリガーといったアクションを実行できます。

リザベーションの利用率監視において、CloudFlowはAWS単体では実現できないもの、すなわちスケジュール実行・自動化・複数サービス横断のチェックとアラート連携を、カスタム開発なしで提供します。

「Identify Underused AWS Reserved Instances Across Services」テンプレート

DoiTは、このユースケース専用のCloudFlowテンプレート Identify underused AWS Reserved Instances across services を提供しています。

このテンプレートは、そのままカスタマイズして数分で公開できる完成済みのワークフローです。動作の流れは次のとおりです。

ステップ1:スケジュールトリガー

フローは任意のスケジュールで起動します。たとえば毎日午前9時、あるいは毎週月曜日といった具合です。チームがリザベーションの健全性をどれくらいの頻度で確認したいかに合わせて、自由に設定できます。手動チェックは一切不要です。

ステップ2:AWSにリザーブドインスタンスの利用率を照会

フローはAWS Cost Explorer APIのGetReservationUtilization APIを、対象のAWSサービスにわたって呼び出します。これにより、接続されたすべてのAWSアカウントとリージョンについて、EC2、RDS、ElastiCache、Redshift、OpenSearchなど各リザベーションタイプの実際の利用率を取得できます。

ステップ3:未活用リザベーションを抽出

Filterノードが利用率データを評価し、指定した閾値を下回るリザベーションを抽出します。デフォルトのベストプラクティスは、**利用率80%**を下回るものをフラグ付けする設定です。AWS自身もこれを健全性の下限と位置づけています。この閾値は、組織の基準に合わせて自由に調整できます。

ステップ4:健全 vs. 要注意

• すべてのリザベーションが健全(閾値以上)であれば、フローは結果をログに記録するだけで終了します。
• 未活用リザベーションが見つかれば、フローはアラート経路に進みます。

ステップ5:適切な担当者に通知

フローは、サービス種別、アカウント、リージョン、利用率、金額インパクトを含む未活用リザベーションのサマリーを通知として送信します。通知先は次のように振り分けられます。

• Slackチャンネル(例: #finops-alerts やチーム別チャンネル)
• 担当チームやFinOps担当者へのメール

公開後は、フローはスケジュールに沿って自動実行され、リザベーションが閾値を下回った際にはチームへ自動で通知が届きます。誰かがチェックを忘れないよう気を配る必要はありません。