- 公開日
- 最終更新日
AWS FinOps Agent を有効化して未使用リソースを洗い出してみた
この記事を共有する
目次
はじめに
「使っていない AWS リソースがあるのはわかっているけれど、洗い出すのが面倒」と感じたことはないでしょうか。
私はコスト最適化を進めたいと思いつつ、どこから手をつけるかで止まってしまうことがよくありました。
先日参加した AWS Summit Japan 2026 で、この課題にアプローチする AWS FinOps Agent（以下、FinOps Agent）が紹介されていました。
ちょうどプレビューで試せるようになっていたので、実際に有効化して触ってみました。
結論
有効化は数クリック、自然言語で聞くだけで未使用リソースを検出できます。
しかも「なぜ未使用と判断したのか」という根拠まで示してくれるため、結果を鵜呑みにせず最終判断を自分で下せます。
プレビュー中は追加料金もかからないので、まず触ってみるハードルはかなり低いです。
試す前の前提
FinOps Agent はパブリックプレビューで提供されています。
公式ブログによると、利用にあたっては以下を押さえておくとよさそうです。
- エージェント自体は US East（バージニア北部）リージョンで実行されます。
- プレビュー期間中は追加料金なしで使用できますが、月単位の使用制限があります。
- FinOps Agent に関連して使用される他の AWS サービスには、標準料金が適用されます。
参考：AWS FinOps Agent のパブリックプレビュー提供開始のお知らせ
検証
有効化してみる
有効化はとても簡単でした。
- マネジメントコンソールで「FinOps Agent」を検索します。
- エージェント名と利用するロールを設定します。ロールは自動生成できるので、今回はそれをそのまま使いました。
- Jira や Slack などのサードパーティ統合も、オプションとして選べるようになっていました（今回は使いません）。
特別な準備はほとんど必要なく、迷うところはありませんでした。
未使用リソースを問い合わせてみる
エージェントを立ち上げて、「使っていないリソースを洗い出して」と自然言語で問い合わせてみました。
すると、使っていない Amazon Elastic Block Store（以下、EBS）ボリュームを見つけてくれました。
コンソールを自分で見て回らなくても、聞くだけで候補が挙がってくるのは思った以上に快適でした。
検出理由を深掘りしてみる
検出されたリストをそのまま信じてよいのか気になったので、「なぜ未使用と判断したのか」と追加で聞いてみました。
返ってきた回答は、おおむね次のような内容でした。
- 両方の EBS ボリュームはアタッチ済みの状態で、Amazon EC2（以下、EC2）インスタンスに接続されている可能性が高い。
- ただし「アイドル状態」と表示されているのは、過去 14 日間の読み書きアクティビティが 1 日あたり 1 IOPS 未満だったため。
単に「使っていなさそうなリストです」と返すのではなく、判断の根拠まで示してくれる点に好感を持ちました。
これなら結果を鵜呑みにせず、最終的な削除可否は自分で判断できます。
コストの内訳も聞いてみる
ついでに、「先月のコスト内訳を教えて」と聞いてみました。
AWS Cost Explorer（以下、Cost Explorer）で確認できるような内訳がそのまま返ってきたうえに、「先月は Amazon Bedrock（以下、Bedrock）の検証をしていたので、全体の 59% が Bedrock です」というサマリまで添えてくれました。
数字を並べるだけでなく、要点をまとめてくれるので、コストレポートのたたき台としても使えそうだと感じました。
自動生成されたロールの中身を確認する
AI エージェントに何かを任せるとき、私が一番気になるのは「どこまでの権限を渡しているのか」です。
そこで、自動生成されたロールの中身を確認してみました。
ロールは 2 種類用意されていました。
- AgentRole：マネージドポリシー FinOpsAgentAgentPolicy がアタッチされている
- Operator role：マネージドポリシー FinOpsAgentOperatorPolicy がアタッチされている
エージェントが実際に使う FinOpsAgentAgentPolicy には、以下のような権限が含まれていました。
- コスト・最適化系：Cost Explorer、AWS Budgets（以下、Budgets）、Cost Optimization Hub の読み取り系権限など
- 主要リソース系：EC2、AWS Lambda（以下、Lambda）、Amazon EC2 Auto Scaling、Amazon Relational Database Service の読み取り系権限など
- 調査系：AWS CloudTrail（以下、CloudTrail）、Amazon CloudWatch（以下、CloudWatch）の読み取り権限、CloudWatch Logs の StartQuery 権限など
- 定期実行系：Amazon EventBridge のルール作成・削除権限など
中身を見るかぎり、基本は Cost Explorer・Budgets・Cost Optimization Hub の情報を起点にしつつ、必要に応じて EC2 や Lambda などの主要リソースを確認し、さらに CloudTrail や CloudWatch Logs Insights のクエリで深掘り調査もできる、という設計に見えました。
いずれも読み取りが中心で、勝手にリソースを削除・変更されるような権限ではなさそうだったので、ひとまず安心して使えると感じました。
なお、もう一方の FinOpsAgentOperatorPolicy は FinOps Agent そのものを操作するための権限が中心でした。
まとめ
有効化から未使用リソースの検出まで、本当に数分で試せました。
「ここまでなら誰でもできる」レベルの手軽さで、コスト最適化の最初の一歩としては十分だと感じています。
特に、検出理由の根拠を示してくれる点と、渡している権限が読み取り中心で把握しやすい点は、運用に組み込むうえで安心材料になりました。
また、支払いアカウント（Payer アカウント）で設定すれば、マルチアカウント環境でもまとめてコストを扱えるのが魅力だと感じました。
プレビューのうちは追加料金なしで触れるので、気になっている方はぜひ試してみてください。
この記事は私が書きました
野間 太一
記事一覧猫とCloudFormationが好きです。
