optimizing-costs

コスト最適化

目的

クラウドコストの最適化では、FinOps のライフサイクル（可視化、最適化、運用）を通じて、制御されていない支出を戦略的なリソース配分へと変えます。このスキルでは、コミットメントベースの割引（リザーブドインスタンス、Savings Plans）、適正サイズ化の戦略、Kubernetes のコスト管理、マルチクラウド環境全体にわたる自動コストガバナンスのための意思決定フレームワークを提供します。

このスキルを使用するタイミング

次のような場合に cost-optimization を呼び出してください。

• 体系的な最適化により、クラウド支出を 15～40％削減する場合
• コスト可視化ダッシュボードと配賦状況の追跡を導入する場合
• 予算アラートと異常検知を確立する場合
• Kubernetes のリソースリクエストとクラスター効率を最適化する場合
• リザーブドインスタンス、Savings Plans、または Committed Use Discounts を管理する場合
• アイドル状態のリソースのクリーンアップと適正サイズ化の推奨を自動化する場合
• 社内チーム向けのショーバック／チャージバックモデルを設定する場合
• CI/CD のコスト見積もり（Infracost）を通じてコスト超過を防ぐ場合
• クラウドコスト削減に関する財務チームの依頼に対応する場合

FinOps の原則

FinOps のライフサイクル

┌─────────────────────────────────────────────────────┐
│  INFORM → OPTIMIZE → OPERATE (continuous loop)      │
│    ↓         ↓           ↓                          │
│ Visibility  Action   Automation                     │
└─────────────────────────────────────────────────────┘

可視化フェーズ： コストを可視化します

• コスト配賦タグ（Owner、Project、Environment）を有効にします
• エンジニアリングチーム向けにリアルタイムのコストダッシュボードを導入します
• クラウドの請求データ（AWS CUR、Azure Consumption API、GCP BigQuery）を統合します
• Kubernetes のコスト監視（Kubecost、OpenCost）を設定します

最適化フェーズ： コスト要因に対処します

• コミットメントベースの割引を購入します（40～72％の節約）
• 過剰にプロビジョニングされたリソースを適正サイズ化します（利用率の目標：60～80％）
• 耐障害性のあるワークロードにスポット／プリエンプティブルインスタンスを導入します
• アイドル状態のリソース（未アタッチのボリューム、古いスナップショット）をクリーンアップします

運用フェーズ： 自動化とガバナンスを行います

• 段階的な通知を伴う予算アラートを設定します（50％、75％、90％、100％）
• アイドル状態のリソースをクリーンアップするスクリプトを自動化します
• 予想外のコスト増加を防ぐために、CI/CD のコストを見積もります
• 異常検知を利用して継続的に監視します

FinOps の基本原則

1. コラボレーション： 部門横断チーム（財務、エンジニアリング、運用、プロダクト）
2. 説明責任： 各チームが担当サービスのコストを管理します
3. 透明性： すべてのコストを関係者が把握し、理解できるようにします
4. 最適化： コスト効率を継続的に改善します

FinOps の成熟度モデルと組織構造の詳細については、references/finops-foundations.md を参照してください。

コスト最適化の戦略

1. コミットメントベースの割引

リザーブドインスタンス（RI）： 1～3 年の契約で 40～72％の割引

• スタンダード RI： インスタンスタイプが固定され、割引率が最も高くなります（3 年契約で 60％）
• コンバーティブル RI： インスタンスタイプに柔軟性があり、割引率は中程度です（3 年契約で 54％）
• 用途： データベース（RDS、ElastiCache）、安定稼働する本番環境の EC2 ワークロード

Savings Plans： 柔軟なコンピューティングのコミットメント

• Compute Savings Plans： EC2、Fargate、Lambda に適用されます（3 年契約で 54％の割引）
• EC2 Instance Savings Plans： インスタンスファミリーに紐づきます（3 年契約で 66％の割引）
• 用途： インスタンスタイプやリージョンが変わるワークロード

GCP Committed Use Discounts（CUDs）： 25～70％の割引

• リソースベースの CUD： vCPU、メモリ、GPU を対象にコミットします
• 支出ベースの CUD： 金額を指定してコミットします（柔軟）
• 継続利用割引： 継続利用に対して自動で 20～30％の割引が適用されます（コミットメント不要）

意思決定フレームワーク：

Reserve when:
├─ Workload is production-critical (24/7 uptime required)
├─ Usage is predictable (stable baseline over 6+ months)
├─ Architecture is stable (unlikely to change instance types)
└─ Financial commitment acceptable (1-3 year lock-in)

Use On-Demand when:
├─ Development/testing environments
├─ Unpredictable spiky workloads
├─ Short-term projects (<6 months)
└─ Evaluating new instance types

コミットメント戦略と RI のカバレッジ分析の詳細については、references/commitment-strategies.md を参照してください。

2. スポットインスタンスとプリエンプティブルインスタンス

割引： オンデマンド料金から70～90％割引（中断時は2分前に通知）

スポットインスタンスの用途： CI/CD ワーカー、バッチジョブ、ML トレーニング（チェックポイント機能を使用）、Kubernetes ワーカー、データ分析 スポットインスタンスを避ける用途： ステートフルデータベース、リアルタイムサービス、チェックポイント機能のない長時間実行ジョブ

ベストプラクティス：

• インスタンスタイプを分散し、複数のアベイラビリティーゾーンに配置します
• グレースフルシャットダウンのハンドラーを実装します
• 容量が利用できない場合は、オンデマンドに自動で切り替えます
• Kubernetes：スポットノード70％＋オンデマンドノード30％を、taints/tolerations とともに組み合わせます

3. 適正なサイズへの調整戦略

目標利用率： 平均60～80％（急増に備えて余裕を残します）

コンピューティングの適正サイズへの調整：

• 30日以上にわたる実際のCPU／メモリ利用率を分析します
• 平均利用率が40％未満のインスタンスを縮小します
• 利用率の低いワークロードを統合します
• インスタンスファミリーを切り替えます（コンピューティング最適化型とメモリ最適化型）

データベースの適正サイズへの調整：

• 接続プールの使用状況を分析します（最大接続数と割り当て数を比較）
• 利用率が50％未満の場合は、ストレージのIOPSを引き下げます
• 読み取りレプリカが必要かどうかを評価します（キャッシュで代替できるか）
• サーバーレスオプション（Aurora Serverless、Azure SQL Serverless）を検討します

Kubernetes の適正サイズへの調整：

• requests を平均使用量（ピーク時ではなく）に設定します
• limits を requests の2～3倍に設定します（バーストを許容）
• 自動化された推奨事項には Vertical Pod Autoscaler（VPA）を使用します
• CPU使用率が0％のPodを特定します（統合の候補）

ストレージの適正サイズへの調整：

• アタッチされていないボリューム（EBS、Azure Disks、GCP Persistent Disks）を削除します
• 古いスナップショット（90日超で、保持ポリシーが不要なもの）を削除します
• ライフサイクルポリシー（S3 Intelligent-Tiering、Azure Blob Lifecycle）を実装します
• データを圧縮／重複排除します

適正サイズへの調整ツール：

• AWS Compute Optimizer： ML ベースの EC2、Lambda、EBS に関する推奨事項
• Azure Advisor： VM の適正サイズへの調整、リザーブドインスタンスに関するアドバイス
• GCP Recommender： VM、ディスク、コミットメントに関する推奨事項
• VPA（Vertical Pod Autoscaler）： コンテナのリソース要求を自動化

4. Kubernetes のコスト管理

リソース要求と制限：

# Set requests = average usage (enables efficient bin-packing)
resources:
  requests:
    cpu: 500m        # 0.5 CPU cores (average usage)
    memory: 1Gi      # 1 GiB memory (average usage)
  limits:
    cpu: 1500m       # 1.5 CPU cores (3x requests, allows bursting)
    memory: 3Gi      # 3 GiB memory (3x requests)

Namespace Quotas： リソースの過剰な消費を防ぎます

• ResourceQuota：Namespace ごとのCPU／メモリ総量を制限します
• LimitRange：Pod ごとのデフォルト／最大要求を設定します
• PriorityClass：重要なPodにリソースが確保されるようにします

クラスターのオートスケーリング：

• アイドル状態のノードを縮小し、コストを削減します
• 開発用クラスターを営業時間外にゼロまでスケールします
• 複数のノードプール（スポットとオンデマンドの組み合わせ）を使用します
• 過剰な支出を防ぐため、ノードの最大数を設定します

コストの可視化：

• Kubecost または OpenCost をデプロイし、Namespace 単位でコストを追跡します
• ラベル（チーム、プロジェクト、環境）に基づいてコストを配分します
• アイドルコスト（ワークロードに割り当てられていないクラスター容量）を追跡します
• ショーバック／チャージバックレポートを生成します

Kubernetes のコスト最適化パターンの詳細については、references/kubernetes-cost-optimization.mdを参照してください。

コストの可視化とモニタリング

コスト配分のためのタグ付け

必須タグ：

• Owner または Team - 責任を負うチーム／部門
• Project または Application - 事業部門またはアプリケーション名
• Environment - prod、staging、dev、test
• CostCenter - 財務コストセンターコード

コスト配分タグの有効化：

• AWS： Cost Allocation Tags コンソールでタグを有効化します
• Azure： Azure Policy の適用によりタグを付与します
• GCP： すべてのリソースでラベルを使用し、BigQuery にエクスポートします

包括的なタグ付け戦略については、references/tagging-for-cost-allocation.mdを参照してください。

モニタリングとダッシュボード

ネイティブのクラウドツール：

• AWS Cost Explorer： 支出パターンの分析、コストの予測
• Azure Cost Management + Billing： 予算の追跡、コスト分析
• GCP Cloud Billing： カスタム分析向けの BigQuery エクスポート

サードパーティプラットフォーム：

• Kubecost： Kubernetes のコスト可視化と最適化
• CloudZero： ユニットコストの経済性、異常検知
• CloudHealth： マルチクラウドのコスト管理
• Infracost： CI/CD における Terraform のコスト見積もり

追跡する主な指標：

• クラウドの月間総支出（経時的な傾向）
• サービス／チーム／プロジェクトあたりのコスト（配賦の精度）
• ユニットコスト指標（顧客あたり、トランザクションあたりのコスト）
• リザーブドインスタンス／Savings Plan の利用率（目標：>95%）
• アイドル状態のリソースによる無駄（目標：総支出の<5%）
• 予算との差異（予測値と実績値）

予算アラートと異常検知

段階的な予算アラート：

50% of budget  → Email to team lead (informational)
75% of budget  → Email + Slack to team (warning)
90% of budget  → Email + Slack + PagerDuty (urgent)
100% of budget → Automated shutdown (non-prod only) or escalation

異常検知： 予期しないコストの急増を通知します

• 週ごとのコスト増加率が>20%
• 予期しない日次コストの急増が>$500
• 新しいリソースタイプ（通常とは異なる支出パターン）

予算の粒度：

• 組織レベル（クラウドの総支出）
• 部門レベル（エンジニアリング、データ、マーケティング）
• プロジェクトレベル（アプリケーション／サービスごと）
• 環境レベル（本番環境と開発／ステージング環境）

意思決定フレームワーク

フレームワーク 1：コミットメント割引の意思決定ツリー

Should we purchase Reserved Instances / Savings Plans?

STEP 1: Analyze Historical Usage (6-12 months)
├─ Identify steady-state baseline (minimum usage)
├─ Exclude spiky/seasonal workloads
└─ Calculate: (baseline usage) / (total usage) = commitment %

STEP 2: Choose Commitment Type
├─ RESERVED INSTANCES
│   ├─ Pros: Highest discount (up to 72%)
│   ├─ Cons: Instance type locked (unless convertible)
│   └─ Use for: Databases, stable production workloads
│
├─ SAVINGS PLANS
│   ├─ Pros: Flexible (across instance types, regions)
│   ├─ Cons: Slightly lower discount than RI
│   └─ Use for: Compute workloads, Lambda, Fargate
│
└─ COMMITTED USE DISCOUNTS (GCP)
    ├─ Resource-based: vCPU/memory commitments
    └─ Spend-based: Dollar amount commitments

STEP 3: Determine Commitment Period
├─ 1-year commitment
│   ├─ Lower discount (40-50%)
│   └─ Less risk if architecture changes
│
└─ 3-year commitment
    ├─ Higher discount (60-72%)
    └─ Only for mature, stable workloads

STEP 4: Monitor and Optimize
├─ Target >95% RI/Savings Plan utilization
├─ Sell unused RIs on AWS Reserved Instance Marketplace
└─ Adjust commitments quarterly based on usage trends

フレームワーク 2：適正サイズ化の優先度マトリックス

コストへの影響と作業量：

影響大、作業量小（最初に実施）：

• アイドル状態のリソース（無駄率100%）：停止中のインスタンス、未接続のボリューム、古いスナップショット
• 未使用の NAT Gateway（各$32/月）
• 過剰にプロビジョニングされたデータベース（30日間、CPU使用率が<20%）
• リソースリクエストが設定されていない Kubernetes ポッド

影響大、作業量中（次に実施）：

• 過剰にプロビジョニングされたコンピューティングリソース（30日間、CPU／メモリ使用率が<40%）
• 最大メモリが使用メモリの>2倍に設定された Lambda 関数
• ストレージの最適化（S3 Intelligent-Tiering、gp3 と gp2 の比較）

影響小、作業量大（最後に実施）：

• アプリケーションコードの最適化（プロファイリング、リファクタリングが必要）
• アーキテクチャの再設計（サーバーレスへの移行、マルチリージョンの最適化）

毎週の最適化ルーティン：

1. アイドル状態のリソースを削除する（自動化スクリプト）
2. コスト要因の上位10項目を確認する（手動分析）
3. 週に3～5個のインスタンスを適正サイズ化する（段階的なアプローチ）
4. 効果をモニタリングする（4週間のコスト傾向）

フレームワーク 3：スポットとオンデマンドの選択

Should this workload use Spot/Preemptible instances?

├─ Is the workload fault-tolerant?
│   ├─ NO → Use On-Demand
│   └─ YES → Continue
│
├─ Is the workload stateless (or has checkpointing)?
│   ├─ NO → Use On-Demand (data loss risk)
│   └─ YES → Continue
│
├─ Can the workload handle interruptions gracefully?
│   ├─ NO → Use On-Demand
│   └─ YES → Continue
│
└─ Workload Type Assessment:
    ├─ Batch Jobs / CI/CD → ✅ Use Spot (70-90% savings)
    ├─ ML Training → ✅ Use Spot (with checkpointing)
    ├─ Kubernetes Workers → ✅ Use Spot (mixed with on-demand)
    ├─ Production API Servers → ⚠️ Mixed fleet (70% spot, 30% on-demand)
    ├─ Databases → ❌ Use On-Demand (or Reserved)
    └─ Real-time Services → ❌ Use On-Demand (or Reserved)

ツール選定ガイド

プラットフォーム別

プラットフォーム	コストの可視化	適正サイズ化	自動化
AWS	Cost Explorer、CUR	Compute Optimizer	AWS Budgets、Lambda のクリーンアップ
Azure	Cost Management	Azure Advisor	Azure Policy、Automation
GCP	Cloud Billing	Recommender	Budget Alerts、Cloud Functions
Kubernetes	Kubecost、OpenCost	VPA	Cluster Autoscaler
マルチクラウド	CloudZero、CloudHealth	Densify	ParkMyCloud

ユースケース別

ユースケース	推奨ツール	主な機能
K8s のコスト可視化	Kubecost	名前空間ごとのリアルタイムなコスト配賦
Terraform のコスト見積もり	Infracost	コスト差分を含む PR コメント
マルチクラウドの集約	CloudHealth	AWS／Azure／GCP 全体の統合コストビュー
最適化の自動化	nOps（AWS）、CAST AI（K8s）	ML ベースの自動化
ユニットコストの経済性	CloudZero	顧客／トランザクションあたりのコスト追跡
スポットインスタンスの管理	Spot.io	スポット利用のオーケストレーションを自動化

詳細なツール比較と選定基準については、references/tools-comparison.md を参照してください。

クラウド固有の戦術

AWS の最適化戦略

1. Cost & Usage Reports（CUR）を有効にする： 詳細な請求データを S3 にエクスポートします
2. AWS Compute Optimizer を使用する： ML ベースの EC2 適正サイズ化の推奨事項を活用します
3. Savings Plans を導入する： Reserved Instances よりも柔軟です
4. S3 Intelligent-Tiering： ストレージクラスを自動で最適化します
5. Lambda の適正サイズ化： メモリ割り当てを調整します（CPU は比例して拡張されます）
6. EBS gp3 への移行： 同等のパフォーマンスで gp2 より 20% 安価です

Azure の最適化戦略

1. Azure Advisor を有効にする： VM の適正サイズ化と Reserved Instances の推奨事項を活用します
2. Azure Hybrid Benefit： Windows Server ライセンスを持ち込んで割引を受けます
3. Dev/Test の料金設定： 本番環境以外のワークロードに割引料金を適用します
4. Azure Spot VMs： 中断可能なワークロードで最大 90% の割引を受けられます
5. Storage Lifecycle Management： BLOB をクール層／アーカイブ層に自動で移行します

GCP の最適化戦略

1. 請求データを BigQuery にエクスポートする： SQL によるカスタムコスト分析を行います
2. Sustained Use Discounts： 自動で 20～30% の割引が適用されます（契約不要）
3. Committed Use Discounts： 3 年契約で 52～70% のコストを削減できます
4. Preemptible VMs： バッチワークロードで最大 91% の割引を受けられます
5. GCP Recommender： アイドル状態の VM の検出と適正サイズ化のアドバイスを受けられます

クラウド固有の詳細については、references/cloud-specific-tactics.md を参照してください。

実装チェックリスト

フェーズ 1：可視性の確立（第 1～2 週）

• コスト配分タグを有効にします（Owner、Project、Environment）
• クラウドの請求コンソールでコスト配分タグを有効化します
• Kubernetes のコスト可視化のために Kubecost をデプロイします（K8s を使用している場合）
• コストダッシュボードを作成します（Grafana、CloudWatch、Azure Monitor、GCP）
• 週次コストレポートを設定します（チームリーダーにメールで送信）

フェーズ 2：ガバナンスの設定（第 2～3 週）

• 予算アラートを作成します（しきい値：50%、75%、90%、100%）
• 異常検知を有効にします（前週比で 20% を超える増加）
• タグ付けポリシーの適用を実装します（Azure Policy、AWS Config、GCP Org Policy）
• ショーバックレポートを確立します（チーム／プロジェクトごとのコスト）
• コストの所有者を文書化します（各サービスの担当者）

フェーズ 3：すぐに実施できる改善（第 3～4 週）

• アイドル状態のリソースを削除します（未接続のボリューム、古いスナップショット）
• 使用していない開発インスタンスを停止／終了します
• 過剰にプロビジョニングされた上位 10 件のインスタンスを適正サイズ化します（使用率 40% 未満）
• S3 Intelligent-Tiering またはライフサイクルポリシーを導入します
• Reserved Instance／Savings Plan のカバレッジを評価します

フェーズ 4：契約割引（第 2 か月）

• 過去 6～12 か月の使用履歴を分析します
• 契約規模を決めるためにベースライン使用量を算出します
• データベース用に Reserved Instances を購入します
• コンピューティングワークロード用に Savings Plans を購入します
• RI／SP の利用率を監視します（目標：95% 超）

フェーズ 5：自動化（第 2～3 か月）

• 自動クリーンアップスクリプトをデプロイします（週次スケジュール）
• Infracost を CI/CD パイプラインに統合します
• 開発／テスト環境の自動シャットダウンを実装します（営業時間外）
• K8s の適正サイズ化のために Vertical Pod Autoscaler（VPA）を有効にします
• Spot インスタンスの自動化を設定します（Spot.io、CAST AI、またはネイティブ機能）

フェーズ 6：継続的な最適化（継続）

• エンジニアリングチームと週次でコストをレビューします
• 月次の最適化スプリントを実施します（上位コスト要因を対象）
• 四半期ごとに契約内容を調整します（RI／SP のカバレッジ）
• 年次の FinOps 成熟度評価を実施します

よくある落とし穴

落とし穴 1：コストが可視化されていない

❌ 問題： 財務チームが月末にクラウド料金を確認するため、予想外のコストが多発します ✅ 解決策： リアルタイムのコストダッシュボードを導入し、エンジニアリングチームに毎日 Slack でレポートを送信します

落とし穴 2：Reserved Instance の利用率が低い

❌ 問題： RI を 100 件購入したものの、使用しているのは 60 件のみです（契約の 40% が無駄になります） ✅ 解決策： RI の利用率を毎週監視し（目標：95% 超）、未使用の RI をマーケットプレイスで売却します

落とし穴 3：Kubernetes のリソースリクエストが設定されていない

❌ 問題： リクエストが設定されていない Pod → ビンパッキングが非効率 → ノードが無駄になります ✅ 解決策： VPA を使用して推奨事項を自動生成し、アドミッションコントロールで適用します

落とし穴 4：アイドル状態のリソースがクリーンアップされない

❌ 問題： 停止した EC2 インスタンスが 50 台（EBS の料金は引き続き発生）、未アタッチのボリュームが 200 個 ✅ 解決策： 7 日以上アイドル状態のリソースを週次で自動クリーンアップします

落とし穴 5：予算アラートがない

❌ 問題： テストクラスターを誤って稼働したままにし、1 万ドルの請求に驚く ✅ 解決策： 予算の 50％、75％、90％、100％でアラートを設定し、Slack／PagerDuty 通知を送信します

関連スキル

• resource-tagging： コスト配分タグにより、showback／chargeback モデルを実現します
• kubernetes-operations： コスト最適化のための K8s の適正化、VPA、クラスターのオートスケーリング
• infrastructure-as-code： Terraform のコスト見積もりとポリシー・アズ・コードに Infracost を使用します
• aws-patterns： AWS 固有のコスト最適化手法（EC2、RDS、S3、Lambda）
• gcp-patterns： GCP 固有の最適化（Compute Engine、BigQuery、Cloud Storage）
• azure-patterns： Azure 固有の最適化（VM、Storage、App Service、Functions）
• platform-engineering： 社内 FinOps プラットフォームとセルフサービス型のコストダッシュボード
• disaster-recovery： コストと RTO／RPO のバランス（ウォームスタンバイとコールドスタンバイ）

例

以下の内容については、examples/ ディレクトリを参照してください。

• terraform/：AWS、Azure、GCP のコスト最適化インフラストラクチャ（予算、アラート）
• kubernetes/：Kubecost のデプロイ、リソースクォータ、VPA 設定
• ci-cd/：Infracost の GitHub Actions、コスト承認ワークフロー
• dashboards/：Grafana のコストダッシュボード、CloudWatch アラーム

スクリプト

以下の内容については、scripts/ ディレクトリを参照してください。

• cleanup_idle_resources.py： AWS／Azure／GCP のアイドル状態のリソースを自動クリーンアップします
• ri_coverage_report.py： リザーブドインスタンスのカバレッジ分析
• cost_allocation_report.py： showback／chargeback レポートを生成します
• spot_savings_calculator.py： スポットインスタンスによる削減額を見積もります
• k8s_rightsizing_audit.py： リソースリクエストが設定されていない K8s ポッドを特定します

主なポイント

1. FinOps は文化です： 財務、エンジニアリング、運用の連携が必要です
2. まず可視化： 測定できないものは最適化できません（タグとダッシュボードは必須です）
3. コミットメント＝節約： リザーブドインスタンス／Savings Plans により 40～72％の割引が得られます
4. 継続的に適正化： 使用率 60～80％を目標にします（急増に備えて余裕を残します）
5. クリーンアップを自動化： アイドル状態のリソースは 100％の無駄です（週次で削除を自動化します）
6. Kubernetes のコストは見えにくい： 名前空間単位で可視化するには Kubecost／OpenCost を使用します
7. コスト意識をシフトレフト： CI/CD で Infracost を使用し、予期しないコスト増加を防ぎます
8. 予算アラートで超過を防止： 50％、75％、90％、100％の段階的な通知を設定します
9. 耐障害性のあるワークロードにはスポットを使用： 70～90％の割引（CI/CD、バッチジョブ、ML トレーニング）
10. ユニットコスト指標で価値を向上： 顧客あたりのコスト、トランザクションあたりのコストを追跡します