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統合あり）

コスト監視の現状課題

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

設計目標

主要目標

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

非機能要件

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

アーキテクチャ設計

全体アーキテクチャ

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  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週間)

Week 1-2: Tagging戦略実装
- 既存リソースへの統一タグ適用
- Terraformモジュールのタグ標準化
- タグコンプライアンス監視設定
Week 3-4: AWS Cost Services設定
- Cost and Usage Report設定
- 基本的なBudgets設定
- Cost Anomaly Detection有効化

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

Week 5-6: Datadog統合強化
- コストメトリクス収集設定
- 基本ダッシュボード作成
- アラート設定
Week 7: 自動化機能
- 基本的なLambda関数実装
- CloudWatch Events設定

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

Week 8-9: 高度な分析機能
- 詳細なコスト分析ダッシュボード
- 使用率分析・rightsizing提案
- 予算管理プロセス確立
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-connect	913831226605	毎週必ず送信
production	967691968827	毎週必ず送信
develop	900176301532	全体コストが前週比10%以上増加時のみ
staging	301608970378	全体コストが前週比10%以上増加時のみ
~~infra-dev~~	~~853790572692~~	~~送信なし（除外）~~

主要機能:

前週比コスト増減分析
サービス別コスト内訳（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" 全サービス

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

通知ポリシー:

本番環境（amazon-connect, production）: 毎週必ず送信
開発環境・ステージング環境（develop, staging）: オンライン分類の総コストが前週比10%以上増加時のみ送信
インフラ開発環境（infra-dev）: 送信なし（除外）

主要機能:

オンライン分類の前週比増減分析
オンライン分類内のサービス別コスト（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通知（オンライン分類専用フォーマット）

本番環境でのKPI連携分析（将来的な拡張）:

コスト増減の要因を事業部のKPI（ユーザー数、診療件数等）と照らし合わせて評価し、ビジネス成長に伴う正常なコスト増加なのか、異常なコスト増加なのかを判断する。

KPIデータソース:

Googleスプレッドシート: 事業部KPIダッシュボード
バックエンドデータソース: BigQuery（生データ）

実装アプローチの検討:

アプローチ	メリット	課題
1. Googleスプレッドシート直接参照	- 加工済みデータで即利用可能 - 実装が比較的シンプル	- サービスアカウント配置場所の決定が必要 - スプレッドシートの共有設定変更が必要 - スプレッドシート変更の影響を受けやすい
2. BigQuery直接参照	- 生データから柔軟に集計可能 - データの一貫性が高い	- BigQuery管理者への権限申請が必要 - データ加工パイプラインの実装が必要 - クエリ実行コストが発生

段階的実装計画:

Phase 1（直近の対応）:

KPI連携の自動化は実装せず、コストモニタリング機能の実装・運用を優先
Slackレポートに事業部KPIダッシュボードのリンクを含める
コストの大幅増加が見られた場合、レポート受信者が手動でKPIを確認し、コスト増減を評価
- 対象環境: 本番環境（amazon-connect, production）のみ

Phase 2（実装方針の検討・設計） ✅ 完了:

✅ GCPサービスアカウント配置場所の決定: fastdoctor-data-platform プロジェクト
✅ Workload Identity Federationの設計・検証完了
✅ データアクセス方式の選定: BigQuery（fd_system_prod データセット）
⏳ BigQueryの場合: データ加工パイプラインの設計
✅ セキュリティ要件とアクセス制御の設計完了
⏳ KPIとコストの相関分析ロジックの設計

Workload Identity Federation実装詳細

GCPプロジェクト: fastdoctor-data-platform（本番環境）

認証アーキテクチャ:

GitHub Actions (terraform_for_aws)
    ↓ OIDC Token
Workload Identity Pool: fdp-github-actions
    ├── Provider 1: fdt-data-analysis (既存)
    ├── Provider 2: github (既存)
    └── Provider 3: terraform-for-aws ⭐️NEW
        ↓ Workload Identity Federation
Service Account: cost-monitoring-bq-reader@fastdoctor-data-platform.iam.gserviceaccount.com
    ↓ Dataset-level IAM
BigQuery Dataset: fd_system_prod (read-only)

Terraform構成 (gcp/services/fastdoctor-data-platform/production/):

workload_identity_provider.tf: 新規Provider追加

hcl

resource "google_iam_workload_identity_pool_provider" "terraform_for_aws" {
  workload_identity_pool_id          = "fdp-github-actions"
  workload_identity_pool_provider_id = "terraform-for-aws"

  # developブランチのみ許可
  attribute_condition = <<-EOT
    assertion.repository == "fastdoctor-jp/terraform_for_aws" &&
    assertion.ref == "refs/heads/develop"
  EOT
}

service_account_bigquery.tf: サービスアカウントとWIF権限

hcl

resource "google_service_account" "cost_monitoring_bq_reader" {
  account_id   = "cost-monitoring-bq-reader"
  display_name = "Cost Monitoring BigQuery Reader"
}

# Workload Identity Federation権限
resource "google_service_account_iam_member" "workload_identity_user" {
  role = "roles/iam.workloadIdentityUser"
}

# BigQueryクエリ実行権限
resource "google_project_iam_member" "bigquery_job_user" {
  role = "roles/bigquery.jobUser"
}

bigquery_iam.tf: データセットレベルの読み取り権限

hcl

resource "google_bigquery_dataset_iam_member" "fd_system_prod_viewer" {
  dataset_id = "fd_system_prod"
  role       = "roles/bigquery.dataViewer"
}

セキュリティ設計:

項目	設定内容	理由
認証方式	Workload Identity Federation (OIDC)	サービスアカウントキー不要、セキュアな認証
リポジトリ制限	`fastdoctor-jp/terraform_for_aws` のみ	特定リポジトリからのみアクセス可能
ブランチ制限	`develop` ブランチのみ	本番ブランチからの実行のみ許可
権限スコープ	Dataset-level (fd_system_prod)	他のデータセットにはアクセス不可
権限レベル	Read-only (dataViewer)	書き込み・削除権限なし
プロジェクト権限	bigquery.jobUser のみ	クエリ実行に必要な最小権限

検証結果 (sre-dev環境):

✅ ワークフロー実行: Run #23471389160
✅ 認証成功: Workload Identity Federationによる認証が正常動作
✅ BigQueryアクセス: データセット一覧、テーブル一覧、クエリ実行、スキーマ取得が全て成功
✅ 既存Provider影響なし: 同一Pool内の既存Provider (fdt-data-analysis, github) は影響を受けない
✅ ブランチ制限動作確認: feature ブランチからのみアクセス可能

GitHub Secrets設定 (本番環境用):

以下のシークレットをリポジトリシークレットとして fastdoctor-jp/terraform_for_aws に登録する必要があります。

Secret名	説明	取得方法
`GCP_WORKLOAD_IDENTITY_PROVIDER_FDP_PROD`	Workload Identity ProviderのフルパスID	`terraform output workload_identity_provider` で取得
`GCP_SERVICE_ACCOUNT_EMAIL_FDP_PROD`	BigQuery読み取り用サービスアカウントのメールアドレス	`terraform output service_account_email` で取得

注意事項:

GCPプロジェクトID (fastdoctor-data-platform) とデータセットID (fd_system_prod) はセキュアな情報ではないため、シークレットに保存する必要はありません。これらはワークフロー内にハードコードして問題ありません。
Terraform apply後に terraform output コマンドで上記の値を取得し、GitHubリポジトリ設定画面からシークレットとして登録してください。

KPI連携の設計方針:

週次コストモニタリングに事業部KPIデータを統合し、コスト増減がビジネス成長に伴うものかを判断可能にする。

週の定義:

コスト集計: 月曜始まり（GitHub Actionsの日付計算ロジック）
BigQuery週集計: date_trunc(date, week(monday)) による月曜始まり
評価対象期間: 前週（7日間）と前々週（7日間）の計14日間
実行タイミング: 毎週月曜 09:00 JST

週の定義が一致しているため、データの整合性が保たれる。

取得するKPIメトリクス:

BigQuery fd_system_prod データセットから以下を取得：

メトリクス名	説明	用途
`online_total_reception_cnt`	オンライン診療確定数（合計）	コスト効率の主要指標
`online_total_appointment_cnt`	オンライン診療申込数（合計）	需要トレンドの把握

データ集計期間:

前々週: 14日前の月曜日〜 8日前の日曜日（7日間）
前週: 7日前の月曜日〜 1日前の日曜日（7日間）

KPI増減傾向の記述方針:

コスト増加の要因分析はAWSサービスベースで行うため、KPIとコストの相関分析は行わない。あくまでもビジネスKPIの増減傾向のみをコメントとして分析結果に含める。

対象環境:

KPI連携あり: amazon-connect (913831226605), production (967691968827)
- 本番環境のため、ビジネスKPIの増減傾向把握が重要
KPI連携なし: develop, staging
- 開発環境のため、KPI連携は不要

データ鮮度の要件:

fd_system_prod テーブルの更新頻度は厳密にコスト集計と揃える必要はない
月曜09:00時点で前週（月〜日）のデータが概ね揃っていることを期待
数時間〜1日程度の遅延は許容（傾向・推移が掴めれば十分）

エラーハンドリング:

BigQueryアクセス失敗時: KPIなしでコスト分析を継続し、分析結果のコメントに「BigQueryへのアクセスに失敗したため、KPIデータを取得できませんでした」と明記する
KPIデータ不足時（該当週のレコードなし）: 分析結果のコメントに「該当期間のKPIデータが存在しませんでした」と記載する
いずれの場合も、コスト分析自体は正常に実行し、KPI関連の情報のみを省略する

注意:

KPIセクションではコストとの比較や効率指標は記載しない
あくまでKPIの実数値と増減率、傾向のみを客観的に記述
コスト増加の要因はAWSサービスベースで別途分析

Phase 3（自動化実装）:

⏳ GCPサービスアカウント作成とWorkload Identity Federation設定（検証環境で完了、本番環境は実装待ち）
⏳ BigQueryアクセス権限設定（fd_system_prod データセット読み取り専用）
⏳ データ取得・加工パイプラインの実装
⏳ Claude Code ActionへのKPIデータ注入機能の実装
⏳ KPIとコストの相関分析を自動実行

本番環境への展開準備:

Terraform apply（本番環境リソース作成）
GitHub Secrets設定
ワークフロー実装（週次コスト監視 + KPIデータ取得）
動作確認とモニタリング

環境別の分析スコープ:

環境	KPI連携分析	理由
amazon-connect	Phase 2以降で実装	本番環境、ビジネスKPIの増減傾向把握が重要
production	Phase 2以降で実装	本番環境、ビジネスKPIの増減傾向把握が重要
develop	実装しない	開発環境、KPI連携の必要性なし
staging	実装しない	ステージング環境、KPI連携の必要性なし

技術的考慮事項:

GCPサービスアカウント管理
- サービスアカウント作成場所の選定（どのGCPプロジェクトに配置するか）
- IAMロール設計（最小権限の原則）
- Workload Identity Federationによるキーレス認証
GitHub Actions → GCP認証
- Workload Identity Federationの設定
- GitHub ActionsからGCPへの安全な認証
- シークレット管理（GitHub Secrets - Workload Identity Provider情報のみ）
データアクセス方式
- Googleスプレッドシート: Google Sheets API
- BigQuery: BigQuery API
データ加工とフォーマット
- KPIデータの正規化
- Claude Code Actionへの適切なフォーマットでの提供
- 週次データの時系列整形

セキュリティ考慮事項:

サービスアカウントキーは使用せず、Workload Identity Federationを使用
KPIデータへのアクセスはread-onlyに制限
Cloud Audit Logsでのアクセス監査
機密性の高いKPIデータの取り扱い方針の明確化

出力例:

✅ 週次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 + MCP	Python + Cost Explorer API
按分処理	なし	あり（事業部別按分・ECS按分）
出力	Slackサマリー + 詳細ログ	CSV（S3保存）+ Slack通知
目的	週次トレンド把握・異常検知	事業部別コスト按分・稟議申請

次のステップ

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

最終更新日: 2026-03-24 作成者: Claude Code 更新履歴:

2026-03-24: オンライン分類版のWorkload Identity Federation実装詳細とKPI連携の設計方針を追加
- Terraform構成詳細とセキュリティ設計を追加
- KPI連携の設計方針を明確化
2026-03-04: オンライン分類版の通知ポリシーとKPI連携分析を追加
- オンライン分類版の環境別通知ポリシーを明記
- 本番環境でのKPI連携分析の実装計画（Phase 1-3）を追加
- GCP Workload Identity Federationの技術的考慮事項を追加
2026-02-27: 週次コストモニタリングの通知ポリシーを変更
- develop/stagingは全体コストが前週比10%以上増加時のみ通知
- infra-devはコストモニタリングから除外
2026-02-19: 初版作成

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

概要 ​

現状分析 ​

既存インフラの特徴 ​

コスト監視の現状課題 ​

設計目標 ​

主要目標 ​

非機能要件 ​

アーキテクチャ設計 ​

全体アーキテクチャ ​

主要コンポーネント ​

1. AWS Cost & Billing Services ​

2. Tagging戦略 ​

3. Datadog統合 ​

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

実装フェーズ ​

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

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

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

技術仕様 ​

必要なAWSサービス ​

Terraformモジュール構造 ​

監視メトリクス定義 ​

セキュリティ考慮事項 ​

アクセス制御 ​

データ保護 ​

運用考慮事項 ​

アラート設定 ​

継続的改善 ​

コスト見積もり ​

初期構築コスト ​

期待される効果 ​

週次コストモニタリング ​

概要 ​

アーキテクチャ ​

運用方針 ​

環境別の通知ポリシー ​

対象環境一覧 ​

オンライン分類版（新規） ​

Workload Identity Federation実装詳細 ​

週次と月次の違い ​

次のステップ ​

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

概要

現状分析

既存インフラの特徴

コスト監視の現状課題

設計目標

主要目標

非機能要件

アーキテクチャ設計

全体アーキテクチャ

主要コンポーネント

1. AWS Cost & Billing Services

2. Tagging戦略

3. Datadog統合

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

実装フェーズ

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

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

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

技術仕様

必要なAWSサービス

Terraformモジュール構造

監視メトリクス定義

セキュリティ考慮事項

アクセス制御

データ保護

運用考慮事項

アラート設定

継続的改善

コスト見積もり

初期構築コスト

期待される効果

週次コストモニタリング

概要

アーキテクチャ

運用方針

環境別の通知ポリシー

対象環境一覧

オンライン分類版（新規）

Workload Identity Federation実装詳細

週次と月次の違い

次のステップ