cost-optimization-review

コスト最適化レビュー

ステップ 1：コンテキストを収集する

ユーザーに次のように尋ねます。

コスト最適化のレビュー対象となるワークロードまたは AWS 環境を教えてください。以下の情報を共有してください。

• ワークロード名と、分析対象のコードパッケージ／ディレクトリ
• トラフィックパターン（一定、急増、予測可能な増加、季節性）
• 月間支出の見積もり（任意。リスクの深刻度の判断に役立ちます）
• 予算の制約または目標（任意）

すでにコンテキストが提供されている場合、または IaC を含むコードベースを扱っている場合は、そのまま次に進みます。

ステップ 2：コンピューティングコストを調査する

すべてのコンピューティングリソースの構成を分析します。

必ず以下を確認してください。

• ASG／起動テンプレートの EC2 インスタンスタイプとサイズ
• ECS タスク定義（CPU／メモリの割り当て）
• Lambda のメモリとタイムアウトの構成
• Fargate タスクのサイズ
• EKS ノードグループの構成
• Batch コンピューティング環境

各コンピューティングリソースについて、以下を記録してください。

• ファイルパスと行番号
• 構成されているインスタンスタイプ／サイズ
• スケーリング構成（最小／最大／希望数）
• Graviton の使用状況（または Graviton が利用可能な場合の x86 の使用）
• 料金モデルへの影響（オンデマンドのみ、Spot の利用対象、または予約の利用対象）

必ず以下を高リスクとして指摘してください。

• 可変ワークロードに対する固定サイズのコンピューティング（オートスケーリングなし）
• 過剰にプロビジョニングされた Lambda（単純な処理で 1024MB 超）
• Graviton 相当のインスタンスタイプが存在する場合の x86 インスタンスタイプの使用（コストと持続可能性の観点）
• 水平スケーリングで小さいインスタンスを使用できるワークロードに対する大型インスタンスタイプの使用
• 本番環境と同規模のリソースを使用する開発／テスト環境
• 明確な営業時間外の時間帯がある環境でのスケジュールスケーリングの欠如

ステップ 3：ストレージとデータのコストを調査する

ストレージ構成を分析します。

必ず以下を確認してください。

• S3 バケットの構成（ストレージクラス、ライフサイクルポリシー、バージョニング）
• EBS ボリュームのタイプとサイズ
• RDS ストレージの構成（タイプ、割り当てサイズ、オートスケーリング）
• DynamoDB のキャパシティモードとプロビジョニング
• ElastiCache のノードタイプとクラスターサイズ
• EFS の構成（スループットモード、ライフサイクル）
• バックアップの保持ポリシー（AWS Backup、RDS スナップショット）
• ログの保持設定（CloudWatch ロググループ）

必ず以下を高リスクとして指摘してください。

• ライフサイクルポリシーがなく、データが際限なく蓄積する S3 バケット
• 保持期間が「無期限」の CloudWatch ロググループ
• オンデマンドキャパシティを利用できる（またはパターンに応じてプロビジョニング済みキャパシティを利用できる）DynamoDB におけるプロビジョニング済みキャパシティの使用
• EBS／RDS での過剰な IOPS プロビジョニング
• gp3 を使用していない EBS ボリューム（同等のパフォーマンスでは gp2 のほうが高コストです）
• ビジネス上の根拠がない、35 日を超えるバックアップ保持期間
• 古いバージョンを期限切れにするライフサイクルルールがない状態での S3 バージョニングの有効化

ステップ 4：データ転送コストを調査する

ネットワークとデータ転送のパターンを分析します。

必ず以下を確認してください。

• NAT Gateway の使用状況（VPC エンドポイントで置き換えられるか）
• リージョン間のデータ転送パターン
• VPC エンドポイントの構成（または S3／DynamoDB 用のエンドポイントの欠如）
• CloudFront ディストリビューション（または静的コンテンツ用ディストリビューションの欠如）
• AZ 間のトラフィックパターン（複数 AZ のサービス間で AZ をまたいで通信しているか）
• API Gateway の構成（REST API と HTTP API の料金比較）

必ず以下を高リスクとして指摘してください。

• NAT Gateway 経由の S3／DynamoDB アクセス（VPC エンドポイントを使用すれば無料です）
• 静的コンテンツ配信に CloudFront がない
• HTTP API で十分な場合に REST API Gateway を使用している（70％割高です）
• ビジネス上の根拠がないリージョン間レプリケーション
• CloudFront によって転送コストを削減できる場合に、インターネット経由で S3 にパブリックアクセスしている

ステップ 5：料金モデルを評価する

料金モデルが使用パターンに適合しているかを分析します。

必ず以下を評価してください。

• 安定したコンピューティング負荷 → Savings Plans または Reserved Instances の利用機会
• 変動する／バッチのコンピューティング負荷 → Spot Instance の利用機会
• サーバーレスとプロビジョニングの適合性（急増する負荷には Lambda／Fargate、安定した負荷には EC2／ECS）
• DynamoDB のオンデマンドとプロビジョニングの比較（予測不能な負荷にはオンデマンド、安定した負荷にはプロビジョニング）
• Aurora Serverless v2 とプロビジョニング済みの比較（データベース負荷が変動する場合）
• アクセスパターンが不明な場合の S3 Intelligent-Tiering

ステップ 6：環境とライフサイクルの管理

本番環境以外の環境設定を分析します。

以下を必ず調査してください。

• 開発／テスト／ステージング環境の規模と本番環境との比較
• 本番環境以外の環境でのスケーリングまたは停止のスケジュール設定
• リソースのライフサイクルポリシー（テスト用リソースの TTL）
• リソースのコスト配分タグ
• 予算および異常検出の設定

以下を必ず「改善の機会」として指摘してください。

• 本番環境以外の環境が本番環境と同じ規模で 24 時間 365 日稼働している
• リソースにコスト配分タグがない
• AWS Budget または Cost Anomaly Detection が設定されていない
• テスト用／一時的なリソースにライフサイクルポリシーがない

---STOP--- チェックポイント：調査完了 — WA フレームワークに照らした評価の準備ができました

発見したコンピューティングリソース（{X} 個のインスタンス／関数）、ストレージ設定（{Y} 個のバケット／ボリューム／テーブル）、データ転送パターン、料金モデルとの整合性、および {packages analyzed} 全体の環境ライフサイクル設定。

これらの調査結果を WA コスト最適化の柱に関する質問に照らして評価し、節約額の見積もりを算出してもよろしいですか？

ユーザーが明示的に確認するまで、この地点を越えて先に進まないでください。

ステップ 7：WA フレームワークの質問に照らして評価する

各質問について、ステータス、証拠（ファイル:行）、不足事項、リスクを提示してください。

COST 1 — クラウド財務管理をどのように実施していますか？

• 証拠：コスト配分タグ、予算設定、異常検出ルール

COST 2 — 使用状況をどのように管理していますか？

• 証拠：インスタンスタイプを制限する SCP、クォータ、リソース制約

COST 3 — 使用状況とコストをどのように監視していますか？

• 証拠：予算アラーム、Cost Anomaly Detection の設定、請求アラーム

COST 4 — リソースをどのように廃止していますか？

• 証拠：ライフサイクルポリシー、TTL 設定、クリーンアップの自動化、保持ルール

COST 5 — サービスを選択する際、コストをどのように評価していますか？

• 証拠：変動する負荷にはサーバーレス、安定した負荷にはプロビジョニング済み、バッチ処理には Spot

COST 6 — リソースのタイプ、サイズ、数を選択する際、コスト目標をどのように達成していますか？

• 証拠：インスタンスタイプ、スケーリングの最小値／最大値、メモリ割り当て、適正サイジングの証拠

COST 7 — コスト削減のために料金モデルをどのように利用していますか？

• 証拠：Savings Plan の設定、予約済みキャパシティ、Spot フリートの設定

COST 8 — データ転送料金にどのように備えていますか？

• 証拠：VPC エンドポイント、CloudFront ディストリビューション、リージョンの配置

ステップ 8：節約額の見積もりを算出する

各調査結果について、以下を見積もってください。

• 現在のコスト指標：コストを左右するリソース設定（インスタンスタイプ、プロビジョニング済みキャパシティ、保持期間）
• 最適化後の設定：リソースに適した設定
• 相対的な節約額：そのリソースカテゴリにおける削減率
• 労力：実施に必要な労力（低／中／高）
• リスク：信頼性またはパフォーマンスへの影響

ステップ 9：リスク評価

各所見について、影響度 × 発生可能性で評価します。

影響度：軽微（カテゴリ内のコスト削減率が 10％ 未満） | 中程度（カテゴリ内のコスト削減率が 10～30％） | 深刻（カテゴリ内のコスト削減率が 30％ 超、または料金モデルとの根本的な不整合）

発生可能性（無駄が続く可能性）：低（最適化の計画がある） | 中（計画はないが、増加は緩やか） | 高（増加が抑制されず、可視性もない）

影響度	発生可能性	リスクレベル
深刻	高	重大
深刻	中	高
深刻	低	高
中程度	高	高
中程度	中	中
中程度	低	中
軽微	高	中
軽微	中	低
軽微	低	低

---STOP--- チェックポイント：リスク評価が完了しました — 最終レポートを作成できます

コンピューティング、ストレージ、データ転送、料金モデル、環境管理にわたる {N} 件の所見を評価しました。リスクの内訳：重大 {X} 件、高 {Y} 件、中 {Z} 件、低 {W} 件。削減効果の高い機会を、工数の見積もりとともに特定しました。

優先順位付けした改善計画を含む、コスト最適化の完全なレポートを作成しますか？

ユーザーが明示的に確認するまで、この時点より先に進まないでください。

ステップ 10：レポートを作成する

# Cost Optimization Review: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Cost Efficiency**: {1-5} — {one-line justification}
- **Top 3 Savings Opportunities**: {brief list}

## Cost Optimization Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Compute Right-Sizing | {score} | {strength} | {gap} |
| Storage Lifecycle | {score} | {strength} | {gap} |
| Data Transfer | {score} | {strength} | {gap} |
| Pricing Models | {score} | {strength} | {gap} |
| Environment Management | {score} | {strength} | {gap} |
| Cost Visibility | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), cost impact, recommendation, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Savings Summary
| Category | Finding | Current Config | Optimized Config | Relative Savings | Effort |
|----------|---------|---------------|-----------------|-----------------|--------|
| Compute | {title} | {current} | {recommended} | {%} | {effort} |
| Storage | {title} | {current} | {recommended} | {%} | {effort} |
| Transfer | {title} | {current} | {recommended} | {%} | {effort} |

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Savings Impact | Effort | Risk |
|---------|--------|---------------|--------|------|
{Switch gp2→gp3, add lifecycle policies, set log retention, add VPC endpoints}

### Foundation (1-4 weeks)
| Finding | Action | Savings Impact | Effort | Dependencies |
|---------|--------|---------------|--------|--------------|
{Right-size instances, implement auto-scaling, schedule non-prod, add Graviton}

### Strategic (1-3 months)
| Finding | Action | Savings Impact | Effort | Dependencies |
|---------|--------|---------------|--------|--------------|
{Savings Plans commitment, serverless migration, architecture optimization}

## Next Steps
{Top 5 concrete cost-saving actions the team should take this week}

ステップ 11：フォローアップを提案する

レポートを提示した後、次の内容を提案します。

次のいずれかをご希望ですか？

• すぐに実施できる最適化のための IaC の変更を生成する
• ご利用状況に応じて Savings Plans と Reserved Instances を比較する
• 非本番環境向けのスケジュールされたスケーリングポリシーを設計する
• コスト配賦タグを使った FinOps タグ付け戦略を作成する
• アーキテクチャの代替案（サーバーレス、コンテナ）のコストを見積もる
• 特定したバケットに S3 ライフサイクルポリシーを実装する

評価の指針

• 自動スケーリング、ライフサイクルポリシー、VPC エンドポイント、コスト配賦タグを備えたワークロードは成熟しています — 高度な最適化（Savings Plans、Spot、アーキテクチャの代替案）に重点を置いてください
• すべての所見にコード上の根拠が必要です — 実際の設定を確認せずに「過剰にプロビジョニングされている」と指摘しないでください
• 絶対的な支出額が不明な場合、削減見積もりは相対値（削減率）で示してください
• 必ずトレードオフを評価してください。コスト最適化によって、明示的な説明なしに信頼性リスクを招いてはなりません
• コスト最適化によって信頼性やパフォーマンスの水準が低下する場合は、その点を指摘してください
• IaC だけでは実際の利用状況を評価できない場合、「判断不能」は妥当な回答です（Compute Optimizer、Cost Explorer の利用を推奨してください）
• 無駄を列挙する前に、優れたコスト管理の取り組みを認めてください