Skip to content

AWSコストモニタリング設計書

概要

FastDoctorのAWS環境における包括的なコストモニタリングシステムの設計書です。既存のDatadog監視基盤と連携し、コスト可視化、異常検知、予算管理を実現します。

現状分析

既存インフラの特徴

  • マイクロサービスが4つの環境(infra-dev、develop、staging、production)に展開
  • 高コストAWSサービスを広範囲に利用
    • ECS Fargate: 複数のサービスで大規模運用
    • RDS Aurora: MySQL/PostgreSQL両方を運用
    • ElastiCache: Redis/Memcached両方を運用
    • Application Load Balancer: サービス毎に配置
    • NAT Gateway: 高可用性構成
  • Datadog監視基盤が既に構築済み(AWS統合あり)

コスト監視の現状課題

  1. AWSネイティブなコスト監視ツールが未実装
    • AWS Budgets: 未設定
    • Cost Anomaly Detection: 未設定
    • Cost and Usage Report: 未設定
  2. サービス・チーム別のコスト可視化が不十分
  3. 開発環境のコストガバナンス不足
  4. コスト最適化機会の見逃し

設計目標

主要目標

  1. リアルタイムコスト可視化: サービス・環境・チーム別のコスト把握
  2. 予算管理・異常検知: 閾値設定とアラート機能
  3. コスト最適化支援: 使用率分析とリソース効率化提案
  4. 開発環境コストガバナンス: 開発環境の無駄コスト削減

非機能要件

  • 高可用性: 監視システム自体の障害耐性
  • セキュリティ: コスト情報への適切なアクセス制御
  • 拡張性: 新サービス追加時の自動対応
  • 運用効率: 監視システムの運用負荷最小化

アーキテクチャ設計

全体アーキテクチャ

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  AWS Services   │    │ AWS Cost Services│    │    Datadog      │
│                 │    │                  │    │                 │
│ ├─ ECS Fargate  │    │ ├─ Cost Explorer │    │ ├─ Dashboards   │
│ ├─ RDS Aurora   │◄───┤ ├─ Budgets       │◄───┤ ├─ Monitors     │
│ ├─ ElastiCache  │    │ ├─ CUR (S3)      │    │ ├─ Alerts       │
│ ├─ ALB/NLB      │    │ ├─ Anomaly Detect│    │ └─ Metrics      │
│ └─ Others       │    │ └─ RI/SP Advisor  │    │                 │
└─────────────────┘    └──────────────────┘    └─────────────────┘
          │                       │                       │
          └───────────────────────┼───────────────────────┘

                    ┌──────────────────┐
                    │   Cost Tagging   │
                    │                  │
                    │ ├─ Service       │
                    │ ├─ Environment   │
                    │ ├─ Team          │
                    │ ├─ Project       │
                    │ └─ CostCenter    │
                    └──────────────────┘

主要コンポーネント

1. AWS Cost & Billing Services

  • Cost and Usage Report (CUR)

    • S3バケット: fd-cost-usage-reports-{environment}
    • 日次でのコスト・使用量データ収集
    • Athenaでのクエリ分析対応
  • AWS Budgets

    • 環境別・サービス別の予算設定
    • 閾値: 80%, 100%, 120%での段階的アラート
    • 月次・四半期予算管理
  • Cost Anomaly Detection

    • 機械学習ベースの異常検知
    • サービス単位での異常コスト検知
    • Slack/メール通知連携

2. Tagging戦略

hcl
# 統一タグ戦略
default_tags = {
  Environment   = "production"         # infra-dev, develop, staging, production
  Service      = "user-management"     # サービス名
  Team         = "platform"           # チーム名  
  Project      = "fastdoctor-core"     # プロジェクト名
  CostCenter   = "engineering"        # コストセンター
  ManagedBy    = "terraform"          # 管理方法
}

3. Datadog統合

  • AWS Integration強化

    • Cost Explorerメトリクスの収集
    • 既存のAWS統合にコスト監視機能を追加
  • カスタムダッシュボード

    • 環境別コスト推移
    • サービス別コスト分析
    • チーム別予算対実績
    • 異常コスト検知状況

4. 自動化とオーケストレーション

  • Lambda関数群
    • cost-anomaly-processor: 異常検知結果の処理・通知
    • resource-rightsizing: リソース使用率分析・推奨
    • unused-resource-scanner: 未使用リソース検知
    • cost-optimization-advisor: RI/SP購入推奨

実装フェーズ

Phase 1: 基盤構築 (4週間)

  1. Week 1-2: Tagging戦略実装

    • 既存リソースへの統一タグ適用
    • Terraformモジュールのタグ標準化
    • タグコンプライアンス監視設定
  2. Week 3-4: AWS Cost Services設定

    • Cost and Usage Report設定
    • 基本的なBudgets設定
    • Cost Anomaly Detection有効化

Phase 2: 監視・アラート構築 (3週間)

  1. Week 5-6: Datadog統合強化

    • コストメトリクス収集設定
    • 基本ダッシュボード作成
    • アラート設定
  2. Week 7: 自動化機能

    • 基本的なLambda関数実装
    • CloudWatch Events設定

Phase 3: 最適化・運用 (3週間)

  1. Week 8-9: 高度な分析機能

    • 詳細なコスト分析ダッシュボード
    • 使用率分析・rightsizing提案
    • 予算管理プロセス確立
  2. Week 10: 運用プロセス構築

    • 運用手順書作成
    • チーム向けトレーニング
    • 継続的改善プロセス確立

技術仕様

必要なAWSサービス

yaml
Core Services:
  - Cost Explorer API
  - AWS Budgets
  - Cost Anomaly Detection
  - Cost and Usage Reports

Data Storage:
  - S3 (CURデータ保存)
  - Athena (CURクエリ分析)

Automation:
  - Lambda (自動化処理)
  - CloudWatch Events (スケジューリング)
  - SNS (通知)

Security:
  - IAM Roles/Policies
  - KMS (データ暗号化)

Terraformモジュール構造

fastdoctor-template/template_modules/
├── cost_monitoring/
│   ├── budgets/                 # AWS Budgets設定
│   ├── anomaly_detection/       # Cost Anomaly Detection
│   ├── cur/                     # Cost and Usage Reports
│   ├── lambda_functions/        # 自動化Lambda群
│   └── datadog_integration/     # Datadog統合設定
└── common_tags/                 # 統一タグモジュール

監視メトリクス定義

yaml
Primary Metrics:
  - aws.cost_explorer.service_cost        # サービス別コスト
  - aws.cost_explorer.environment_cost    # 環境別コスト
  - aws.cost_explorer.team_cost          # チーム別コスト
  - aws.cost_explorer.monthly_forecast    # 月次コスト予測

Secondary Metrics:
  - aws.cost_explorer.unused_resources    # 未使用リソース
  - aws.cost_explorer.rightsizing_opps   # サイジング最適化機会
  - aws.cost_explorer.ri_utilization     # RI利用率
  - aws.cost_explorer.sp_utilization     # SP利用率

セキュリティ考慮事項

アクセス制御

hcl
# IAM Policy例
data "aws_iam_policy_document" "cost_monitoring" {
  statement {
    effect = "Allow"
    actions = [
      "ce:GetUsageReport",
      "ce:GetCostAndUsage",
      "ce:GetDimensions",
      "ce:GetReservationCoverage",
      "ce:GetReservationPurchaseRecommendation",
      "ce:GetReservationUtilization",
      "budgets:ViewBudget",
      "budgets:DescribeBudgets"
    ]
    resources = ["*"]
  }
}

データ保護

  • 暗号化: CURデータのS3暗号化(KMS)
  • アクセス制限: VPC Endpoints使用によるプライベート通信
  • ログ管理: CloudTrailでのAPI使用監査

運用考慮事項

アラート設定

yaml
Budget Alerts:
  - Warning: 80%予算消化時
  - Critical: 100%予算超過時
  - Emergency: 120%予算超過時

Anomaly Alerts:
  - Service Level: 個別サービスでの異常コスト
  - Environment Level: 環境全体での異常コスト
  - Team Level: チーム予算での異常コスト

継続的改善

  • 月次レビュー: コスト分析・予算見直し
  • 四半期レビュー: 最適化施策・RI/SP計画見直し
  • 年次レビュー: 監視戦略・アーキテクチャ見直し

コスト見積もり

初期構築コスト

  • AWS Cost Services: 基本無料(CURは小額のS3利用料のみ)
  • Lambda実行コスト: 月額 $10-20
  • 追加S3ストレージ: 月額 $5-10
  • Datadog追加メトリクス: 月額 $50-100

期待される効果

  • コスト可視化: 10-15%のコスト削減機会発見
  • 異常検知: インシデント対応時間50%削減
  • 予算管理: 予算超過リスク80%削減
  • 最適化: RI/SP活用によるコスト10-20%削減

週次コストモニタリング

概要

週次でのコスト異常検知と最適化機会の早期発見を目的とした、Claude Code Action + MCP Serverベースの自動分析システム。

アーキテクチャ

┌─────────────────────────────────────────────────┐
│ GitHub Actions (毎週月曜 09:00 JST)             │
├─────────────────────────────────────────────────┤
│ 1. AWS CLI + jq でコスト総額を事前計算         │
│ 2. Claude Code Actionで分析(MCP Server使用)  │
│ 3. Slack通知                                    │
└─────────────────────────────────────────────────┘

運用方針

コストモニタリング及び通知については、ノイズになるのを避けるため対象の環境ごとに方針を定める。

環境別の通知ポリシー

本番環境(amazon-connect, production)

  • 通知条件: 毎週必ず送信
  • 理由: リソース数が多くコストが高い傾向にあるため、週次で継続的にモニタリングする

開発環境・ステージング環境(develop, staging)

  • 通知条件: 全体コストが前週比10%以上増加時のみ送信
  • 理由: 想定外のコスト上昇による異常検知をしたいため閾値を設けて通知する

インフラ開発環境(infra-dev)

  • 通知条件: レポート送信なし
  • 理由: SRE管理の検証環境であり想定外のコスト上昇は想定されないため、コストモニタリングから除外する

対象環境一覧

環境アカウントID通知条件
amazon-connect913831226605毎週必ず送信
production967691968827毎週必ず送信
develop900176301532全体コストが前週比10%以上増加時のみ
staging301608970378全体コストが前週比10%以上増加時のみ
infra-dev853790572692送信なし(除外)

主要機能:

  • 前週比コスト増減分析
  • サービス別コスト内訳(TOP10)
  • コスト異常検知(50%以上増加)
  • 最適化提案(未使用リソース、RI/SP利用率)

実装:

  • ワークフロー:
    • .github/workflows/amazon-connect@cost-monitoring-weekly.yml
    • .github/workflows/production@cost-monitoring-weekly.yml
    • .github/workflows/develop@cost-monitoring-weekly.yml(条件付き通知)
    • .github/workflows/staging@cost-monitoring-weekly.yml(条件付き通知)
  • プロンプト: .github/prompts/claude-cost-monitoring-weekly.md
  • カスタムアクション:
    • calculate-costs: AWS CLI + jqで総コスト計算
    • run-cost-monitoring: Claude Code Action実行
    • notify-slack: Slack通知

技術スタック:

  • AWS CLI + jq: Cost Explorer APIからコスト取得・集計
  • Claude Code Action: Bedrock経由でClaude呼び出し
  • MCP Server: AWS Billing & Cost Management MCP Server

オンライン分類版(新規)

対象: categories.yamlの department: "online" 全サービス

目的: オンライン診療事業部のコストのみに特化した週次分析

主要機能:

  • オンライン分類の前週比増減分析
  • オンライン分類内のサービス別コスト(TOP10)
  • オンライン特有の最適化提案

実装:

  • ワークフロー: .github/workflows/*@cost-monitoring-weekly-online.yml(環境別×5)
  • プロンプト: .github/prompts/claude-cost-monitoring-weekly-online.md
  • カスタムアクション:
    • calculate-costs-filtered: カテゴリ判定 + オンライン分類フィルタリング
    • run-cost-monitoring: 既存を再利用
    • notify-slack: 既存を再利用

カテゴリ判定ロジック:

python
# 月次スクリプトの categorize_service() を再利用
# 1. TAG:Service によるパターンマッチング(部分一致)
# 2. AWS Service名でのマッチング(TAG:Serviceがない場合)
# 3. department='online' のみを集計

共通ライブラリ:

  • .github/scripts/cost_monitoring_common/category_matcher.py
    • 月次・週次で共通のカテゴリ判定ロジック
    • categorize_service() 関数
    • load_categories() 関数

データフロー:

1. Cost Explorer API呼び出し(TAG:Service別)
2. category_matcher.py でカテゴリ判定
3. department='online' のみ抽出・集計
4. Claude Code Actionで詳細分析
5. Slack通知(オンライン分類専用フォーマット)

出力例:

✅ 週次AWSコストレポート(オンライン分類) - production環境

対象: オンライン診療事業部のサービスのみ
今週の総コスト: $485.23
前週の総コスト: $452.18
前週比増減: +$33.05(+7.3%)

主要な増減要因(TOP3):
1. chronic-general: +$18.50(+12.5%)
2. payment-service: +$8.75(+9.2%)
3. fd-app-bff: +$5.80(+6.1%)

週次と月次の違い

項目週次月次
実行頻度毎週月曜日毎月2日
分析ツールClaude Code Action + MCPPython + Cost Explorer API
按分処理なしあり(事業部別按分・ECS按分)
出力Slackサマリー + 詳細ログCSV(S3保存)+ Slack通知
目的週次トレンド把握・異常検知事業部別コスト按分・稟議申請

次のステップ

  1. ステークホルダー承認: 設計書レビュー・承認
  2. 実装計画策定: 詳細なタイムライン・リソース計画
  3. Terraformモジュール開発: Phase 1の実装開始
  4. パイロット運用: staging環境での先行実装・検証

最終更新日: 2026-02-27 作成者: Claude Code 更新履歴:

  • 2026-02-27: 週次コストモニタリングの通知ポリシーを変更
    • develop/stagingは全体コストが前週比10%以上増加時のみ通知
    • infra-devはコストモニタリングから除外
  • 2026-02-19: 初版作成 レビュー: 要承認