
FinOps & クラウドコスト関連ナレッジ - 2025年6月
近年、クラウドコストに関する課題が注目を集めています。私自身も注目し、キャッチアップしているテーマです。そんな中で、同じ関心ごとをお持ちの方のお役に立てればと思い、個人的に気になった記事をシェアしています。
6月は FinOps X や AWS Summit Japan などのイベントが開催され、各イベントでクラウドコストに関するセッションがありました。
FinOps X 2025 / FinOpx X Day Tokyo 2025
- FinOps X 2025 Day 1 Keynote: Evolution of FinOps: Cloud+ Scopes, SaaS, FOCUS™ 1.2, Cloud VP Panel
- FinOps X 2025 Day 2 Keynote: FinOps for AI + AI for FinOps, Cloud Feature Launches
- FinOps X 2025 期間中の各社ニュースを日本語でまとめる。
- 【FinOps X Day Tokyo 】参加レポート
AWS Summit Japan
- 【登壇レポート】 "そのAWSコスト、もっと下げられるかも? 150社超のコスト分析で見えた「鉄板」削減Tips"というタイトルでミニセッションをしました #AWSSummit
- 【セッションレポート】クラウドストレージのコスト最適化戦略 - AWS ストレージの賢い活用法(AWS-05)#AWSSummit
- 【セッションレポート】 組織全体で AWS コスト最適化を加速する(AWS-06)#AWSSummit
CCoE Summit ’25
Japan Community Day at KubeCon + CloudNativeCon Japan 2025
続いて、2025年6月頃に見かけた記事を紹介していきます。
[アップデート] Compute Optimizer が Aurora I/O 最適化のレコメンデーションを表示できるようになりました
AWS Compute Optimizer で Aurora ストレージに関するレコメンデーションが追加されました。従来 Aurora I/O-Optimized を検討するには CloudWatch などのメトリクスから試算する必要がありましたが、今回のアップデートにより直近の利用状況からレコメンデーションが表示されるため、対象選定の目安が容易になります。
関連記事:
Cost Optimization Hub が Amazon Aurora の推奨事項に対応
Cost Optimization Hub に Aurora DBインスタンスとストレージに関する推奨事項が追加されました。追加された項目はドキュメントにて確認が可能です。
Should I use Savings Plans or Reserved Instances for my EC2 instance?
(EC2 インスタンスには Savings Plans と Reserved Instances のどちらを使用すればよいですか?)
コミットメントによるコスト最適化のご相談をいただく際に、よく聞かれる質問の一つでもある「RI と SP はどっちを購入すれば良いですか?」に対する一つの回答が記載されています。
Savings Plans とリザーブドインスタンスのどちらかを選択するには、ワークロードの柔軟性ニーズを特定してください。インスタンスタイプを変更したり、複数の AWS コンピューティングサービスを利用したり、コストの自動最適化を希望するワークロードには、Savings Plans をご利用ください。安定性と予測可能性が求められるワークロード、特定のアベイラビリティゾーンでキャパシティー予約が必要なワークロード、または特定のインスタンス構成を持つワークロードには、リザーブドインスタンスをご利用ください。
ベストプラクティスとしては、安定したワークロードにはリザーブドインスタンスを、変動の激しいワークロードにはSavings Plansを活用するなど、複数の戦略を組み合わせることが挙げられます。
また別で、それぞれにおける使用率とカバレッジに関する記事が公開されていました。二つともコミットメントの管理する際に重要な指標となるため、理解するのにお薦めです。
関連記事:
- Optimizing with AWS Savings Plans: Demystifying Utilization and Coverage
- Optimizing AWS Reserved Instances: Understanding Utilization and Coverage
[アップデート] Amazon Q Developer に AWS アカウントのコスト分析と最適化提案をしてもらえるようになりました
マネジメントコンソールから自然言語でコスト最適化の相談が出来るようになりました。(25/07/01 時点では日本語は未対応)
以前は Cost Explorer をソースとしたコスト分析が可能でしたが、今回 Cost Optimization Hub などから最適化も対応されました。
プロンプト集も公開されているため、試しに一つをお手元の環境で実施してみるのが良いかもしれません。
[アップデート] Amazon Athenaのクエリ実行結果の保存先にAWSマネージドストレージを指定できるようになりました
追加料金なしで Athena のクエリ結果の保存先にマネージドストレージが追加されました。今まで、クエリ結果はS3バケットを用意する必要があり、ライフサイクルルールを設定し忘れると、予期せぬコスト増加につながってしまうことがありました。保存期間などのトレードオフはありますが、特別な要件がない限りマネージストレージが良さそうです。
関連記事:
Simple cloud cost management: Grafana Labs integrates open standard FOCUS specification for cloud billing data
(シンプルなクラウドコスト管理:Grafana Labsはクラウド課金データ用のオープンスタンダードFOCUS仕様を統合)
Grafana Cloud の請求データが FOCUS に対応しました。同時期(FinOps X 2025)に Alibaba Cloud, Databricks も対応しています。
FinOps and DevOps: Changing Soft Language to Hard Risks
(FinOpsとDevOps:ソフトな言語をハードなリスクに変える )
ソフトな「推奨事項」をハードな「リスク」として議論することは、適切な緊急性を伝えるだけでなく、説明責任を促進することにもつながります。
コストに関する情報も「実施すること望ましい(推奨事項)」ではなく「実施するべき(リスク)」として扱うことでセキュリティのように積極的に対応がなされるという内容でした。確かに推奨事項では後回しになるケースもあるため、最適化の機会や改善点に関して優先度を設け、クリティカルなものはリスクと表現することも時には必要ではないかと感じました。
年間AWSコストを数千万削減したやつが語る、コスト削減のすゝめ
洗い出した最適化アクションに対して、3つの軸(組織受入体制, 技術的容易性, 削減見込コスト)を設けて評価を行い、コスト削減を実行された内容が紹介されています。組織内で活動を推進するには、このように明確な評価軸で整理をしておくことは関係者への説明やどこまで対応するのかという判断も行いやすくて、とても有効な手段ではないかと思います。
Amazon Verified Permissions の料金が 2025 年 6 月 12 日から大幅に値下げされました
値下げがされています。最大97%はすごいですね。他にも Amazon SageMaker AI GPU アクセラレーションインスタンスも値下げされました。
関連記事:
New Relic、クラウドコスト最適化のための新機能を発表 AWS・Kubernetesに対応しFinOpsを実現
オブザーバビリティプラットフォームを提供されている New Relic から 「Cloud Cost Intelligence」 「Pipeline Control」を発表されました。既に New Relic を利用中の方は要チェックな機能ではないでしょうか。
ウェルスナビのSREチームの歩みとこれから
FinOps を含めた SRE チームのこれまでの取り組みが紹介されています。各分野において目的と短期、中期の目標が設定されている点や発生した過去の事象を Notion へ記録し、ナレッジをして蓄積されており、それを今後は AI に活用していくという次の展開まで計画されている点がとても素晴らしいですね。
また開発者の方向けにクラウドコストの勉強会を実施されたとのことでとても興味深いですし、こういったコミュニケーションが大切なのだろうなと改めて感じました。
Amazon Q のコスト最適化
(Amazon Qの導入コストの最適化)
最近、個人的にも注目している Amazon Q(Business と Developer) に関するコストの要素と最適化の TIPS が紹介されています。これから AI 活用が加速する中で、誰かがしっかり管理もしなければいけません。そんな誰かのためにお役立ちになる記事ではないかと思います。
Create a multicloud FinOps dashboard with Amazon QuickSight using AWS services
(AWS サービスを使用して Amazon QuickSight でマルチクラウド FinOps ダッシュボードを作成する)
Cloud intelligence dashboard (CID) をベースにマルチクラウド向けのダッシュボード CloudSPARCC (Cloud Service Performance Analytics and Resource Cost Control)を作成して記事となります。
サンプルを見るととても良さそうです。Github で公開されていないかなと期待をしたのですが、見つけることは出来ませんでした...
Prompt Compression using Amazon Bedrock :: Reduce RAG costs
(Amazon Bedrock を使用した迅速な圧縮:: RAG コストの削減)
大きなプロンプトに対するプロンプト圧縮のソリューションの紹介記事です。元のプロンプトを圧縮用のLLMを間に挟むことでプロンプトを最適化するようです。画像アップロード時に圧縮や変換するのに近いアプローチかなと思いましたが、複数の LLM を利用する方がコストが最適になるケースもあることに驚きました。
ぜひ経営者に知ってほしい新常識「FinOps」とは?クラウドコストを価値に変える!
FinOps という言葉自体(考え方は以前からあれど)が新しいため、その説明が必要なシーンは多くあります。そんな時にシェアしたい記事です。平易な言葉で、イメージしやすい例えも含め、とてもわかりやすく説明をしてくれています。
Advanced analytics with AWS Cost and Usage Reports
(AWS コストと使用状況レポートによる高度な分析)
CUR 2.0 を用いて以下の4つのユースケースでのクエリの解説がされています。どれも最初から思い付きもしない内容で非常に参考になります。2つ目の SPs に関して動画を見ながらクエリを手元で再現してみましたが、良い感じでした。他のクエリも含めてテキストで公開されたら嬉しいです。
- 不完全なマルチパートアップロードの特定
- Savings Plans 節約額の再配分
- EC2 インスタンスタイプの分析
- Amazon Bedrock 使用量のコスト配分
Savings Plans 節約額の再配分(CUR2.0 編):
※ 公開用に変更を加えているため、エラーとなった場合は適宜修正をお願いします。
resource_tags_['name']
は任意のコスト配分タグに置き換え${table_name}
は CUR2.0 のテーブルに置き換えSPLIT(billing_period,'-')[2] = '04' and SPLIT(billing_period,'-')[1] = '2025'
は任意の年月に置き換え
with spend as (select resource_tags_['name'] as user_fin_ops, SPLIT(billing_period,'-')[2] as month, SPLITSPLIT(billing_period,'-')[1] as year, sum(line_item_unblended_cost) as sum_line_item_unblended_cost, sum(Case when resource_tags_['name'] is not null then line_item_unblended_cost else 0 end) as tagged_spend,
round(
sum(
CASE
when "line_item_line_item_type" = 'SavingsPlanCoveredUsage' then "savings_plan_savings_plan_effective_cost" - "line_item_unblended_cost"
else 0
end
),
2
) as sum_savings
from ${table_name}
where SPLIT(billing_period,'-')[2] = '04' and SPLIT(billing_period,'-')[1] = '2025'
group by 1,2,3)
select *,
sum(sum_savings) over (partition by month, year) as total_saving,
sum(tagged_spend) over (partition by month, year) as total_tagged,
CASE when user_fin_ops is not null then tagged_spend/sum(tagged_spend) over (partition by month, year) else 0 end as percent,
CASE when user_fin_ops is not null then tagged_spend/sum(tagged_spend) over (partition by month, year) else 0 end * sum(sum_savings) over (partition by month, year) + sum_line_item_unblended_cost as charge_amount
from spend
Savings Plans 節約額の再配分(レガシーCUR 編):
resource_tags_name
は任意のコスト配分タグに置き換え${table_name}
は レガシーCUR のテーブルに置き換えyear = '2025' AND month = '4'
は任意の年月に置き換え
with spend as (select "resource_tags_name" as user_fin_ops,month, year,sum(line_item_unblended_cost) as sum_line_item_unblended_cost, sum(Case when "resource_tags_name" is not null then line_item_unblended_cost else 0 end) as tagged_spend,
round(
sum(
case
when "line_item_line_item_type" = 'SavingsPlanCoveredUsage' then "savings_plan_savings_plan_effective_cost" - "line_item_unblended_cost"
else 0
end
),
2
) as sum_savings
from ${table_name}
where year = '2025' AND month = '4'
group by 1,2,3)
select *,
sum(sum_savings) over (partition by month, year) as total_saving,
sum(tagged_spend) over (partition by month, year) as total_tagged,
Case when user_fin_ops is not null then tagged_spend/sum(tagged_spend) over (partition by month, year) else 0 end as percent,
Case when user_fin_ops is not null then tagged_spend/sum(tagged_spend) over (partition by month, year) else 0 end * sum(sum_savings) over (partition by month, year) + sum_line_item_unblended_cost as charge_amount
from spend
How to Set Up Automated Alerts for Newly Purchased AWS Savings Plans
(新しく購入したAWS Savings Plansの自動アラートを設定する方法)
Savings Plans は購入したコミットメントが意図通りに適用されているかが非常に重要です。もし有効に利用されていない場合、かえって余分なコスト増となってしまうことがあるため、早期に検知して対応を取る必要があります。この記事で紹介されているソリューションでは過去7日間と当月中に購入された SPs について使用率を評価し、閾値を下回った際にアラートを通知してくれるようです。定期的に複数の SPs を購入されている方は検討してみるのも良いかもしれません。
さいごに
今月は大型のイベントが複数開催され、機能やサービスリリースも続きました。そして国内で初めて FinOps X Day が開催されたことはとても素晴らしく、来年もまた開催されることを期待しています。