FinOps

FinOps とは

FinOps は Finance と DevOps を組み合わせた語で、クラウドコストの可視化・最適化・ガバナンスを、エンジニアリング・財務・ビジネスの組織横断で実践するフレームワークである。Financial Operations の略と紹介されることがあるが、FinOps Foundation 自身は Finance と DevOps のかばん語だと説明している。財務部門が単独でコストを絞る活動ではなく、「クラウドのコストはエンジニアリングの責任」という考え方が核にある。

2026 年 8 月時点の FinOps Foundation の定義は「クラウド」ではなく「テクノロジーの事業価値を最大化する」と書かれており、対象は SaaS やデータセンターなど公共クラウド以外の支出にも広がっている。クラウド請求書だけを見る活動として理解すると、現行のフレームワークとはずれる。

FinOps の 3 フェーズ

FinOps Foundation のフレームワークは Inform (可視化)、Optimize (最適化)、Operate (運用) の 3 フェーズを置く。一度通せば終わる工程ではなく、対象を替えながら回し続けるループとして設計されている。

フェーズ	目的	アクション
Inform (可視化)	コストを見える化	タグ付け、ダッシュボード
Optimize (最適化)	無駄を削減	リザーブド、Savings Plans
Operate (運用)	継続的な改善	予算アラート、ポリシー

同じフェーズでも到達度には段階があり、フレームワークは Crawl (まず着手する)、Walk、Run の順で成熟させる進め方を示している。全リソースへのタグ付けや厳密な単位あたり原価を初手から求めると、たいてい可視化の途中で止まる。

AWS でのコスト可視化

AWS でのコスト可視化を以下にまとめる。

ツール	用途
Cost Explorer	コストの分析・予測
AWS Budgets	予算の設定・アラート
Cost and Usage Report (CUR)	詳細なコストデータ
タグ	リソースのコスト配分

コスト最適化の手法

コスト最適化の手法を以下にまとめる。

手法	削減率の目安	対象
未使用リソースの削除	100%	放置された EBS, EIP
適切なインスタンスサイズ	20〜50%	EC2, RDS
Savings Plans	最大 66% / 最大 72%	EC2, Lambda, Fargate
スポットインスタンス	最大 90%	バッチ処理、CI/CD
S3 ライフサイクル	50〜80%	古いデータを Glacier に

Savings Plans に 2 つの数字が並ぶのは種類の違いである。Lambda と Fargate まで自動適用される Compute Savings Plans はオンデマンド比で最大 66%、対象を 1 リージョンの 1 インスタンスファミリーに絞る EC2 Instance Savings Plans が最大 72% (いずれも 2026 年 8 月時点の公表値)。「Savings Plans は 72% 引き」と覚えると、Lambda や Fargate を含む見積もりが過大になる。スポットインスタンスの最大 90% も上限であり、AWS が容量を回収するときに中断される前提の価格なので、途中で落ちても困らない処理に限って使う。

サーバーレスのコスト特性

サーバーレスは使った分だけの課金だが、規模が大きくなると従量課金が不利に転じる。代表的な 2 サービスの課金の型を示す。

Lambda: リクエスト数 × 実行時間 × メモリ
  → トラフィックが少ない時はほぼ無料
  → トラフィックが多い時は EC2 より高くなる場合がある

DynamoDB (オンデマンド): リクエスト数課金
  → 予測不能なトラフィックに最適
  → 安定したトラフィックならプロビジョンドが安い

コストをチーム・プロジェクト・環境ごとに配分する土台はタグだが、リソースにタグを付けただけでは請求データに現れない。Billing and Cost Management コンソールでコスト配分タグとして有効化する操作が別に必要で、タグキーが一覧に出るまで最大 24 時間、有効化されるまでさらに最大 24 時間かかる。可視化の着手が思ったより遅れる原因はここにある。

より深く学ぶには関連書籍が役立つ。