AWS Cost Optimization Vol1｜Cost Explorer×Budgets×Savings Plans

なぜ Cost Optimization Vol1 か — コスト最適化5層アーキテクチャ概観

AWSの月次コスト請求書を見て「なぜここまで費用がかかるのか」と困惑した経験はないでしょうか。クラウドのコスト管理はオンプレミス時代の固定費管理と根本的に異なります。従量課金モデル・数百種類のサービス・マルチアカウント構成・リザーブドキャパシティのコミットメント判断 — これらを統合的に把握・制御するには体系化されたフレームワークが不可欠です。

AWSが提供するコスト最適化ツールは強力ですが、個別のツールを点で使うだけでは真の最適化に届きません。Cost ExplorerでコストのWHYを可視化し、BudgetsでHOW MUCHを制御し、Savings PlansでIT支出をコミットして割引を確保し、Compute Optimizerでリソース単体のムダを検出し、Cost Anomaly Detectionで異常支出を早期に捉える — この5層が連携することで、FinOps実践の真の価値が引き出されます。

本記事では、AWSコスト最適化5層フレームワークを本番運用レベルで実装・運用するための実践知識を体系的に解説します。AWS CLIコマンド・boto3コード例・アーキテクチャ図を交えながら、手を動かしながら習得できる構成です。

FinOps 3サイクルと5層フレームワークの対応

クラウドコスト最適化の業界標準フレームワーク FinOps は、Inform（可視化）→ Optimize（最適化）→ Operate（運用） の3サイクルで継続的に実践されます。本記事の5層フレームワークはこのFinOpsサイクルと直接対応しています。

FinOpsの核心は「コスト情報を組織全体で共有し、責任の所在を明確にすること」です。Cost ExplorerによるInform（可視化）が全ての出発点となり、可視化なくして最適化は始まらず、最適化なくして継続的運用は成立しません。

AWSにおけるFinOps実践の3つの柱

FinOpsをAWS環境で実践するには、ツール・プロセス・組織文化の3つの柱が揃う必要があります。

• ツール（本記事の主題）: Cost Explorer / Budgets / Savings Plans / Compute Optimizer / Cost Anomaly DetectionによるコストのInform→Optimize→Operateサイクルの技術基盤
• プロセス: 月次コストレビュー・Savings Plans購入サイクル・Right Sizing定期実施・異常検知対応フロー等の標準化されたオペレーション手順
• 組織文化: エンジニアがコストを意識する「FinOps文化」の醸成 — 個人/チームへのコスト配分・KPI設定・コスト最適化成果の可視化と共有

本記事はツール層の実装に集中しますが、プロセスと組織文化の整備なしにツールだけ導入しても継続的な効果は限定的です。ツール実装と並行して、週次コストレビューの場を設け、チーム内でコスト情報を共有する習慣を構築することを強く推奨します。

クラウドコスト最適化の現場課題

FinOps Foundationの調査によれば、クラウドコストの約30%が最適化可能な状態にあると言われています。本番環境でよく見られる課題と、5層フレームワークでの対処方針を整理します。

これらの課題は独立していません。例えば「コスト不可視（タグ未整備）」は「予算超過の発覚遅れ」にも「コミットメント未活用」にも連鎖します。5層フレームワークを基盤として整備することで、課題の連鎖を断ち切ることができます。

対象読者と前提知識

本記事は以下のロールを主な対象とします。

FinOps Engineer

• AWSの複数アカウント管理経験あり
• コスト削減施策を主導・設計したい
• Savings Plans / RIの購入額判断に迷っている
• コスト可視化・配分の仕組みをゼロから構築したい

Cloud Architect / Platform Engineer

• 新規サービス設計時のコスト見積もり精度を向上させたい
• Compute Optimizerの推奨をどこまで信頼するか判断したい
• 予算超過アラートを自動化してオペレーション負荷を削減したい
• マルチアカウント環境でのコスト配分ルールを整備したい

前提知識として、AWSマネジメントコンソールの基本操作とEC2・RDS・S3の基礎知識を想定しています。Savings Plans・RIの基本概念（コミットメント型割引）を理解していると、より深く読み進められます。

なお、コスト最適化の施策によっては権限が必要な場合があります。マネジメントアカウントへのアクセス権限（Cost Explorer・Budgets・Savings Plans管理）と、各リソースの変更権限（Compute Optimizerの推奨適用時）を事前に確認してから作業を開始してください。

本記事の読み方ガイド

本記事は §2〜§5を独立したリファレンスとして活用できる構成です。課題に応じて必要なセクションへジャンプしながら参照してください。

各セクションではAWS CLIコマンド・boto3コード例・Mermaidアーキテクチャ図を組み合わせ、本番環境に直接適用できる実装ガイドとして構成しています。§6の詰まりポイント7選と§7のアンチパターン演習は、本番適用時のトラブルを事前に回避するための実践内容です。

コスト最適化成熟度モデルと本記事の位置付け

AWSのコスト最適化には段階的な成熟度があります。組織の現在地を把握し、次のステップに向けた優先施策を決定するための参考として、以下の成熟度モデルを示します。

本記事は レベル2〜4の達成を目的として設計されています。レベル1相当の組織でも、§2（Cost Explorer）から順に読み進めることでレベル4に到達できる実践内容を網羅しています。

5層フレームワークのサービス間連携

5層の各サービスは独立して機能しますが、連携させることで相乗効果が生まれます。特に重要な連携パターンを以下に示します。

Cost Explorer → Budgets: Cost Explorerの予測データをBudgetsのアラート閾値設計に活用。季節性を考慮した予測上限値を予算閾値として設定することで、誤報アラートを削減しながら実質的な予算超過を確実に検知できます。

Cost Explorer → Savings Plans: Cost ExplorerのSP推奨機能が、購入すべきSP種別・金額・期間の最適案を自動計算します。購入前に必ずSP推奨を確認し、推奨額の70〜80%から開始して段階的に追加購入するアプローチが安全策です。

Compute Optimizer → Cost Explorer: Compute OptimizerのRight Sizing推奨を実施後、Cost ExplorerのRight Sizing機能で削減効果を実績データとして確認します。推奨適用前後のコスト比較により、最適化効果を定量化できます。

Cost Anomaly Detection → Budgets: Cost Anomaly Detectionが検知したコスト異常はSNSで通知されます。Budget Actionsと組み合わせることで、異常検知時に自動的にコスト制御アクション（IAMポリシー適用・リソース停止等）を発動させる高度な自動化が実現できます。

これら5層の連携を設計段階から意識することで、個々のツールを点で使う状態から「統合されたコスト最適化基盤」へと進化させることができます。各セクションの実装手順を読み進めながら、自社環境での連携設計を検討してください。

AWS Cost Explorer 本番運用

%% Mermaid01: Cost Explorer 分析フロー
graph LR
 CUR[Cost & Usage Report] --> CE[Cost Explorer]
 CE --> Filter[フィルタ/グループ化]
 Filter --> Analyze[分析/可視化]
 Analyze --> Forecast[コスト予測]
 Analyze --> RS[Right Sizing]
 RS --> Action[最適化アクション]
 Forecast --> Budget[Budgets連携]

分析ダッシュボード — コスト可視化の起点

Cost Explorerはマネジメントコンソールから直接アクセスできるコスト分析ツールです。初回有効化後24〜48時間でデータが反映され、過去12ヶ月分のコストデータを最大日次粒度で参照できます（月次/週次/日次切り替え可能）。有効化コストは無料ですが、API呼び出しは1,000リクエストあたり$0.01の課金が発生するため、Lambda等での自動取得設計では呼び出し頻度の最適化が必要です。

日次・月次コスト推移ビュー

日次コスト推移グラフは、コストスパイクの発生タイミングを特定するための基本ビューです。棒グラフ（積み上げ/グルーピング）と折れ線グラフを切り替えながら、サービス別・アカウント別の寄与を視覚的に確認できます。

典型的な分析手順は以下のとおりです。

1. 「月次コスト推移」で前月比変化率の高いサービスを特定する
2. 対象サービスを選択して「日次」粒度に切り替える
3. スパイク発生日の前後でCloudTrailの操作ログと照合する
4. 根本原因（新規リソース作成・想定外のデータ転送・APIコール増加等）を特定する

サービス別ビューとアカウント別ビュー

AWS Organizationsを使用したマルチアカウント環境では、管理アカウント（Management Account）からLinked Account別のコストを統合参照できます。各アカウントのコスト責任者に個別ビューを共有する際は、IAMポリシーでCost Explorerへのアクセスを制御します（ce:GetCostAndUsage アクションを該当アカウントに付与）。

カスタムビューの活用

Cost Explorerのカスタムビューを使用すると、繰り返し確認するフィルタ条件を保存して再利用できます（1アカウント最大50件）。本番環境で有効なカスタムビューの例を以下に示します。

• 本番環境コスト: Environment=production タグでフィルタし、開発・ステージングのコストを除外
• プロジェクト別コスト: Project=<project-name> タグでフィルタし、チャージバックの根拠データとして活用
• EC2 On-Demand vs SP/RI: Purchase TypeでOn-Demand/Spot/Reserved/Savings Plans分類し、コミットメント活用率を確認

# Cost Explorerのサービス別月次コストデータ取得 (AWS CLI)
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics "BlendedCost" "UnblendedCost" "UsageQuantity" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[*].[Keys[0],Metrics.BlendedCost.Amount]' \
  --output table

フィルタ・グループ化 — コストの多次元分析

Cost Explorerのフィルタとグループ化は、コスト分析の精度を左右する最重要機能です。複数の次元を組み合わせることで、コストの原因を高精度に絞り込めます。

主要フィルタ次元

タグによるコスト配分

タグによるコスト配分は、Cost Explorerを最大限に活用するための前提条件です。AWSコンソールの「Cost Allocation Tags（コスト配分タグ）」でアクティベートしたタグのみが、Cost Explorerのフィルタ次元として使用可能になります。アクティベート後、反映まで24時間かかることに注意してください。

{
  "Filter": {
 "And": [
{
  "Dimensions": {
 "Key": "SERVICE",
 "Values": ["Amazon Elastic Compute Cloud - Compute"]
  }
},
{
  "Tags": {
 "Key": "Environment",
 "Values": ["production"]
  }
}
 ]
  },
  "Granularity": "MONTHLY",
  "TimePeriod": {
 "Start": "2026-05-01",
 "End": "2026-06-01"
  },
  "Metrics": ["BlendedCost"],
  "GroupBy": [
 {"Type": "TAG", "Key": "Project"}
  ]
}

タグ未付与リソースは「No tag key」としてグルーピングされ、コスト配分の精度を低下させます。新規リソース作成時のタグ付与強制（AWS Config + SCP）は、Cost Explorerを有効活用するための必須施策です。具体的には、AWS Configのルールとして required-tags を設定し、必須タグ（Environment・Project・Owner等）が付与されていないリソースに対してSCPでアクション制限をかけるパターンが推奨されます。

コスト予測 — 12ヶ月先の支出計画

Cost Explorerのコスト予測機能は、過去のコストパターン（季節性・トレンド・異常値）を機械学習モデルで分析し、今後12ヶ月のコストを信頼区間付きで予測します。Budgetsと組み合わせることで、予測コストが予算上限に近づいた時点でアラートを発報する「予測ベースアラート」が実現できます。

予測精度と信頼区間

予測精度は過去データの蓄積量に大きく依存します。

信頼区間（80%信頼区間）は予測値の上下限を示します。上限値をBudgetsのアラート閾値設計に活用すると、「季節性の高いアクセス集中期」の予算オーバーを事前に検知できます。

季節性への対応

ECサイトや年度末処理など、季節性のあるワークロードでは、前年同期比でのコスト推移を参照することが重要です。Cost Explorerのカスタム期間設定を使用して前年同月と比較し、季節性によるコスト増加を「想定内」として予算に組み込む設計が推奨されます。

# コスト予測取得 — 今後6ヶ月の月次予測 (AWS CLI)
aws ce get-cost-forecast \
  --time-period Start=2026-06-01,End=2026-12-01 \
  --metric BLENDED_COST \
  --granularity MONTHLY \
  --query 'ForecastResultsByTime[*].[TimePeriod.Start,MeanValue,PredictionIntervalLowerBound,PredictionIntervalUpperBound]' \
  --output table

APIによるプログラム予測取得

import boto3
from datetime import datetime, timedelta

ce = boto3.client('ce', region_name='us-east-1')

# 今後3ヶ月のコスト予測
today = datetime.today()
forecast_end = today + timedelta(days=90)

response = ce.get_cost_forecast(
 TimePeriod={
  'Start': today.strftime('%Y-%m-%d'),
  'End': forecast_end.strftime('%Y-%m-%d')
 },
 Metric='BLENDED_COST',
 Granularity='MONTHLY',
 Filter={
  'Dimensions': {
'Key': 'LINKED_ACCOUNT',
'Values': ['123456789012']
  }
 }
)

total = response['Total']
print(f"3ヶ月コスト予測合計: {float(total['Amount']):.2f} {total['Unit']}")

for month in response['ForecastResultsByTime']:
 start = month['TimePeriod']['Start']
 mean = float(month['MeanValue'])
 lower = float(month['PredictionIntervalLowerBound'])
 upper = float(month['PredictionIntervalUpperBound'])
 print(f"  {start}: 予測={mean:.2f} (下限={lower:.2f} 〜 上限={upper:.2f})")

Right Sizing推奨 — 過剰スペックリソースの自動検出

Cost Explorer Right Sizing推奨は、EC2・RDSインスタンスの過去14日間（デフォルト）または過去30・60日間の実際の利用率を分析し、ダウンサイジングまたは停止の推奨を提供します。月額数万〜数十万円規模の削減機会が自動的にリストアップされるため、本番環境で定期的に確認すべき最重要機能の一つです。

利用率閾値の設計

Right Sizing推奨では、CPU利用率・メモリ利用率（CloudWatch Agent連携時）・ネットワーク利用量を総合的に分析します。

本番環境でのRight Sizing適用は、ピーク時利用率70%以上を安全マージンとして設定し、推奨のフィルタに活用します。一括適用は避け、ステージング環境でパフォーマンステストを実施してから段階的に本番適用することが鉄則です。

Graviton推奨

Cost Explorer Right SizingはGraviton（Arm64）インスタンスへの移行推奨も提供します。同等性能でコスト10〜20%削減が見込める場合、推奨リストに表示されます。

Graviton移行の主な考慮点は以下のとおりです。

• x86バイナリはGraviton（arm64）上でそのまま動作しないため、コンテナイメージのマルチアーキテクチャビルドが必要
• Amazon Linux 2023はGraviton最適化済みのため、新規構築時はGravitonを優先検討
• RDS Aurora はGraviton2対応（db.r6g・db.m6g系）でコスト削減効果が高い
• Java・Go・Python・Node.jsはGraviton上でも互換性が高く、移行リスクが低い

CloudWatch Agent連携による推奨精度の向上

デフォルトのRight Sizing推奨はCPU利用率のみを分析します。CloudWatch Agentをインストールしてメモリ利用率をCloudWatchに送信すると、メモリ制約のあるワークロードの推奨精度が大幅に向上します。Cost ExplorerのRight Sizing設定で「CloudWatch Agentメモリメトリクスを含める」を有効化します。

# Right Sizing推奨を取得 — 同一インスタンスファミリー内での推奨 (AWS CLI)
aws ce get-rightsizing-recommendation \
  --service "AmazonEC2" \
  --configuration \
 '{"RecommendationTarget":"SAME_INSTANCE_FAMILY","BenefitsConsidered":true}' \
  --query 'RightsizingRecommendations[*].{
ResourceId:CurrentInstance.ResourceId,
CurrentType:CurrentInstance.ResourceDetails.EC2ResourceDetails.InstanceType,
Action:RightsizingType,
TargetType:ModifyRecommendationDetail.TargetInstances[0].ResourceDetails.EC2ResourceDetails.InstanceType,
MonthlySavings:ModifyRecommendationDetail.TargetInstances[0].EstimatedMonthlySavings.Value}' \
  --output table

カスタムレポート — 定期配信とCUR連携

Cost Explorerのカスタムレポートは、保存したビュー設定をベースに定期的なコスト報告を自動化し、ステークホルダーへの情報共有コストを削減します。

レポートの保存と共有

Cost Explorerで作成したビューは「保存済みレポート」として保存できます（1アカウント最大50件）。マネジメントコンソールから直接アクセスできるほか、IAMで制御されたメンバーアカウントへのアクセス共有も可能です。

スケジュール配信の自動化パターン

Cost Explorer単体のスケジュール配信機能は限定的です。本番環境では以下の組み合わせで定期レポートを自動化します。

1. EventBridge + Lambda + Cost Explorer API: 毎週月曜日にLambdaが週次コストレポートを生成し、SES/SNSでメール送信する
2. AWS Cost and Usage Report (CUR) + S3 + Athena: 詳細レポートをS3に自動出力し、AthenaでSQLクエリを実行してQuickSightで可視化する
3. Budgets Reports（§3で詳説）: 予算の週次/月次レポートをS3に自動配信する

Cost Explorer API活用

import boto3

ce = boto3.client('ce', region_name='us-east-1')

# タグ別・サービス別の月次コスト取得
response = ce.get_cost_and_usage(
 TimePeriod={'Start': '2026-05-01', 'End': '2026-06-01'},
 Granularity='MONTHLY',
 Metrics=['BlendedCost', 'UsageQuantity'],
 GroupBy=[
  {'Type': 'DIMENSION', 'Key': 'SERVICE'},
  {'Type': 'TAG', 'Key': 'Environment'}
 ],
 Filter={
  'Dimensions': {
'Key': 'RECORD_TYPE',
'Values': ['Usage']
  }
 }
)

# 上位5サービスのコストを出力
groups = response['ResultsByTime'][0]['Groups']
groups.sort(
 key=lambda x: float(x['Metrics']['BlendedCost']['Amount']),
 reverse=True
)

print("サービス別コスト Top5:")
for group in groups[:5]:
 service = group['Keys'][0]
 env = group['Keys'][1] if len(group['Keys']) > 1 else 'N/A'
 cost = float(group['Metrics']['BlendedCost']['Amount'])
 print(f"  {service} [{env}]: ${cost:.2f}")

CUR（Cost and Usage Report）との使い分け

Cost ExplorerはサマリーレポートやUIベースの分析向け、CURは詳細分析・チャージバック・BI連携向けの使い分けが基本です。

本番環境では、Cost Explorerで日常的なコスト監視と傾向分析を行い、月次のチャージバックや部門別の詳細分析にCUR + Athenaを組み合わせるのが推奨パターンです。CURのデータはパーティション分割されたParquet形式で出力することで、Athenaのクエリコストを大幅に削減できます。

AWS Budgets 本番運用

AWS Budgets の予算タイプ — 5種類の使い分け

AWS Budgetsは5種類の予算タイプを提供しており、監視対象に応じて適切なタイプを選択することが本番運用の起点となる。

コスト予算の設計指針

本番環境でコスト予算を設計する際、予算期間は 月次固定 を基本とし、AWS Organizationsのタグ(CostCenter, Team, Environment等)でフィルタリングすることで、チームごとのコスト責任を明確化できる。予算名には環境・チーム・用途を含めた命名規則を徹底する(例: prod-api-team-monthly)。

{
  "BudgetName": "prod-api-monthly-budget",
  "BudgetLimit": {
 "Amount": "50000",
 "Unit": "USD"
  },
  "BudgetType": "COST",
  "TimeUnit": "MONTHLY",
  "CostFilters": {
 "TagKeyValue": ["user:Environment$production", "user:Team$api"]
  }
}

使用量予算 — EC2/S3個別監視

サービス単位の使用量予算はコスト予算との組み合わせが効果的。EC2インスタンス時間でスパイクを検知し、コスト予算でトータル影響を測定する2段階監視が本番推奨パターン。

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
 "BudgetName": "ec2-usage-hours-budget",
 "BudgetLimit": {"Amount": "10000", "Unit": "Hours"},
 "BudgetType": "USAGE",
 "TimeUnit": "MONTHLY",
 "CostFilters": {
"Service": ["Amazon Elastic Compute Cloud - Compute"]
 }
  }'

RI利用率・SPカバレッジ予算の活用

RI利用率予算は閾値を80%以上に設定することで、未使用RI(利用率低下=損失)を早期検知できる。SPカバレッジ予算は「このOn-Demand費用のうちSPで何%カバーできているか」を監視するため、SP追加購入の判断材料になる。RI利用率が3ヶ月連続で90%を超える場合はSP移行のシグナルとして捉えることができる。

アラート閾値設計 — 多段階通知の実装

単一閾値(100%のみ)では対応が遅れるため、本番環境では 4段階アラート が標準設計。各段階で通知先と対応アクションを明確に定義することで、コスト超過の早期対応体制を構築できる。

予測ベースアラートの精度と活用

FORECASTEDアラートはCost Explorerの機械学習予測を活用するが、月初から8日以上経過しないと精度が安定しない特性がある。月初5日間はACTUALアラートのみを信頼し、FORECASTEDアラートは月中旬以降の判断指標として活用する運用設計が本番向け。予測が実績より先行して超過を示した場合は、コスト削減着手のシグナルとして活用できる。

{
  "NotificationsWithSubscribers": [
 {
"Notification": {
  "NotificationType": "ACTUAL",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 80,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "EMAIL", "Address": "team@example.com"},
  {"SubscriptionType": "SNS",
"Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-alert-warning"}
]
 },
 {
"Notification": {
  "NotificationType": "ACTUAL",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 100,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "SNS",
"Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-alert-critical"}
]
 },
 {
"Notification": {
  "NotificationType": "ACTUAL",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 120,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "SNS",
"Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-alert-emergency"},
  {"SubscriptionType": "EMAIL", "Address": "cto@example.com"}
]
 },
 {
"Notification": {
  "NotificationType": "FORECASTED",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 100,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "EMAIL", "Address": "manager@example.com"}
]
 }
  ]
}

AWS Chatbot統合 — Slack連携通知

SNSトピックをAWS Chatbotに連携することで、Slack/Amazon Chimeチャンネルへのリアルタイム通知を実現できる。Chatbotの通知メッセージにはコスト詳細とCost Explorerへのリンクが自動付与され、担当者が即座にコスト分析画面に遷移できる。

import boto3

def create_budget_with_sns_alert(
 account_id: str,
 budget_name: str,
 amount: str,
 sns_arn: str
) -> dict:
 client = boto3.client('budgets', region_name='us-east-1')

 return client.create_budget(
  AccountId=account_id,
  Budget={
'BudgetName': budget_name,
'BudgetLimit': {'Amount': amount, 'Unit': 'USD'},
'BudgetType': 'COST',
'TimeUnit': 'MONTHLY'
  },
  NotificationsWithSubscribers=[
{
 'Notification': {
  'NotificationType': 'ACTUAL',
  'ComparisonOperator': 'GREATER_THAN',
  'Threshold': 80,
  'ThresholdType': 'PERCENTAGE',
  'NotificationState': 'ALARM'
 },
 'Subscribers': [
  {'SubscriptionType': 'SNS', 'Address': sns_arn}
 ]
}
  ]
 )

Budget Actions — 自動コスト制御の実装

Budget Actionsは3種類のアクションタイプを提供しており、コスト超過の深刻度と対象環境に応じて組み合わせる設計が本番で有効。

IAMポリシーアクションの実装例

新規リソース作成を制限するIAMポリシーをBudget Actions用に事前作成し、予算超過時に自動適用する設計が最も安全な起点。ポリシーは事前にテスト環境で動作を確認してから本番の承認ワークフローに組み込む。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "BudgetActionDenyNewResources",
"Effect": "Deny",
"Action": [
  "ec2:RunInstances",
  "rds:CreateDBInstance",
  "eks:CreateCluster",
  "lambda:CreateFunction"
],
"Resource": "*"
 }
  ]
}

Budget Actionsの作成(Python)

import boto3

def create_iam_policy_budget_action(
 account_id: str,
 budget_name: str,
 iam_policy_arn: str,
 execution_role_arn: str,
 target_role_arns: list
) -> str:
 client = boto3.client('budgets', region_name='us-east-1')

 response = client.create_budget_action(
  AccountId=account_id,
  BudgetName=budget_name,
  NotificationType='ACTUAL',
  ActionType='APPLY_IAM_POLICY',
  ActionThreshold={
'ActionThresholdValue': 100.0,
'ActionThresholdType': 'PERCENTAGE'
  },
  Definition={
'IamActionDefinition': {
 'PolicyArn': iam_policy_arn,
 'Users': [],
 'Groups': [],
 'Roles': target_role_arns
}
  },
  ExecutionRoleArn=execution_role_arn,
  ApprovalModel='MANUAL',
  Subscribers=[
{
 'SubscriptionType': 'EMAIL',
 'Address': 'admin@example.com'
}
  ]
 )
 return response['ActionId']

承認ワークフロー — 本番環境への安全弁

ApprovalModelにMANUALを指定することで、Actions発動前に管理者が承認コンソールで確認・実行するフローになる。自動実行(AUTOMATIC)は開発環境の非重要インスタンスに限定し、本番ではMANUALで運用することが事故防止の基本。Budget Actionsのロールバックも同じ承認フローで安全に操作できる。

複数アカウント統合 — Organizations連携

マルチアカウント構成でのBudgets管理はOrganizations構造を活用した3層設計が標準パターン。全社、OU単位、Linked Account個別という階層で予算を設定することで、コスト責任の可視化とアラート粒度を両立できる。

3層予算設計の概念図

Organizations Management Account
├── 全社予算: コスト予算 $500,000/月 (全Linked Account合算)
├── OU別予算
│├── Production OU: $300,000/月
│├── Development OU: $100,000/月
│└── Staging OU: $50,000/月
└── Linked Account個別予算
 ├── Account A (API Team): $80,000/月
 ├── Account B (Data Platform): $120,000/月
 └── Account C (ML Platform): $60,000/月

Management AccountからのLinked Account予算作成

Organizations管理アカウントからLinked Accountのコストを対象とした予算を作成する場合、CostFiltersにLinkedAccountを指定する。管理アカウントはすべてのLinked AccountのBudgets設定を一元管理できるため、ガバナンス基盤として機能する。

aws budgets create-budget \
  --account-id MANAGEMENT_ACCOUNT_ID \
  --budget '{
 "BudgetName": "linked-account-api-team",
 "BudgetLimit": {"Amount": "80000", "Unit": "USD"},
 "BudgetType": "COST",
 "TimeUnit": "MONTHLY",
 "CostFilters": {
"LinkedAccount": ["LINKED_ACCOUNT_ID"]
 }
  }'

コスト配分タグとBudgets連携

OrganizationsコンソールでCostCenter, Team, Project等のコスト配分タグを有効化すると、BudgetsのフィルタでタグベースのFine-Grainedな予算管理が可能になる。新規タグはActivateから集計反映まで最大24時間かかるため、月初より前に有効化しておくことが重要。タグ命名規則は全Organization共通で統一し、TerraformなどのIaCで強制適用するとガバナンスが維持しやすい。

import boto3

def activate_cost_allocation_tags(tag_keys: list) -> None:
 client = boto3.client('ce', region_name='us-east-1')
 client.update_cost_allocation_tags_status(
  CostAllocationTagsStatus=[
{'TagKey': key, 'Status': 'Active'}
for key in tag_keys
  ]
 )

Budget Reports — 定期レポート自動配信

Budget ReportsはS3への自動保存とメール配信で、週次・月次のコストレビューを自動化する機能。経営層向けのコスト報告をBudget Reportsで定型化すると、手動レポート作成工数を削減できる。Cost and Usage Report(CUR)と組み合わせることで、BIツールによる詳細分析基盤も構築できる。

aws cur put-report-definition \
  --report-definition '{
 "ReportName": "monthly-cost-report",
 "TimeUnit": "MONTHLY",
 "Format": "Parquet",
 "Compression": "Parquet",
 "AdditionalSchemaElements": ["RESOURCES"],
 "S3Bucket": "cost-reports-bucket",
 "S3Prefix": "cur-reports/",
 "S3Region": "ap-northeast-1",
 "ReportVersioning": "OVERWRITE_REPORT"
  }'

Cost and Usage Report(CUR)はBudgetsの予算実績より詳細なリソースレベルのコストデータを提供する。AtenaやQuickSightと統合することで、プロジェクト別・リソース別の詳細コスト分析を経営ダッシュボードとして可視化できる。

Savings Plans 本番運用

Compute SP vs EC2 Instance SP — 本番での選択基準

Savings Plansには4種類あるが、本番環境で主に検討するのはCompute SPとEC2 Instance SPの2種類。選択基準はインフラの柔軟性要件で決まる。

Compute SP が本番のデフォルト推奨な理由

Compute SPは割引率はEC2 Instance SPより若干低いが、インスタンスファミリー変更・リージョン変更・Fargate移行などに自動的に追随する。本番環境はインフラ構成変更が発生しやすいため、Compute SPで柔軟性を確保したうえで、長期固定が確実なワークロードのみEC2 Instance SPを追加購入するハイブリッド戦略が有効。

SageMaker SP — ML基盤の独立した最適化

SageMaker SPはSageMakerのトレーニング/推論インスタンスに特化したSavings Plans。EC2/FargateのCompute SPとは別枠で購入し、ML基盤のコストを独立して最適化できる。SageMaker利用額が月$10,000を超える場合は個別検討を推奨。

aws savingsplans describe-savings-plans \
  --query 'savingsPlans[*].{Type:savingsPlanType,State:state,Commitment:commitment}'

Lambda SP — サーバーレス基盤向け

Lambda SPはComputeリクエストとDuration(GB-秒)に対して割引を提供。Compute SPはLambdaにも自動適用されるため、Lambdaのみ独立して購入するケースは稀。Fargate + Lambda混在環境ではCompute SPを主軸に、Lambda単独の高負荷ワークロードのみ個別検討する。

カバレッジ分析 — SP購入額の科学的決定

SP購入前のカバレッジ分析は、過剰コミットと過少コミットの両リスクを避けるために不可欠なステップ。Cost Explorerの推奨レポートをそのまま鵜呑みにせず、実態に合わせた調整が本番運用の要点。

SP Utilization Report — 購入済みSPの活用率把握

SP Utilization Reportは購入済みSavings Plansの利用率(Utilization Rate)を時系列で把握する。利用率が80%を下回る状態が継続する場合、購入額を超えた不要なコミットが発生していることを示す。

import boto3

def get_sp_utilization(start_date: str, end_date: str) -> dict:
 client = boto3.client('ce', region_name='us-east-1')

 response = client.get_savings_plans_utilization(
  TimePeriod={
'Start': start_date,
'End': end_date
  },
  Granularity='MONTHLY'
 )

 utilization = response['Total']['Utilization']
 print(f"SP利用率: {utilization['UtilizationPercentage']}%")
 print(f"利用済みコミット: ${utilization['UsedCommitment']}")
 print(f"未利用コミット: ${utilization['UnusedCommitment']}")
 return response

SP Coverage Report — On-Demandコストに対するカバレッジ率

SP Coverage Reportは「SP適用可能なOn-Demand利用のうち、何%をSPでカバーできているか」を示す。カバレッジが低い場合はSP追加購入の余地があり、高い場合は追加購入でさらなる削減が見込める。

def get_sp_coverage(start_date: str, end_date: str) -> dict:
 client = boto3.client('ce', region_name='us-east-1')

 response = client.get_savings_plans_coverage(
  TimePeriod={
'Start': start_date,
'End': end_date
  },
  Granularity='MONTHLY',
  GroupBy=[
{'Type': 'DIMENSION', 'Key': 'LINKED_ACCOUNT'},
{'Type': 'DIMENSION', 'Key': 'SERVICE'}
  ]
 )
 return response

推奨購入額の計算手法

def calculate_recommended_sp_commitment(
 average_ondemand_spend: float,
 coverage_target: float = 0.70,
 safety_margin: float = 0.85
) -> float:
 raw_commitment = average_ondemand_spend * coverage_target
 safe_commitment = raw_commitment * safety_margin
 return round(safe_commitment, 2)

Savings Plans 購入戦略 — FinOpsの最重要決断

支払いオプション(Payment Option)の選択

本番環境では Partial Upfront 1年 が最もバランスの良い起点。All Upfront 3年は割引率は最大だが、インフラ変更リスクを3年間負うため、ワークロードが確実に固定化した後に検討する。

段階的購入戦略 — 四半期レビューサイクル

Month 1-3:  On-Demand利用実績の収集・Cost Explorer推奨確認
Month 3: 第1回購入 — 推奨額の50%(保守的スタート)
Month 6: カバレッジ確認 → 利用率90%超なら追加購入
Month 9: 第2回購入 — カバレッジ75%目標に調整
Month 12:年次レビュー → 更新判断 / 3年プラン検討

aws savingsplans create-savings-plan \
  --savings-plan-offering-id OFFERING_ID \
  --commitment 1000.00 \
  --payment-option PARTIAL_UPFRONT \
  --purchase-time "2026-05-25T00:00:00Z"

import boto3

def purchase_savings_plan(
 offering_id: str,
 commitment: float,
 payment_option: str = 'PARTIAL_UPFRONT'
) -> dict:
 client = boto3.client('savingsplans', region_name='us-east-1')

 response = client.create_savings_plan(
  savingsPlanOfferingId=offering_id,
  commitment=str(commitment),
  paymentOption=payment_option,
  tags={
'PurchasedBy': 'FinOps-Team',
'ReviewDate': '2026-08-25'
  }
 )
 return response

SP vs RI — 判断基準と移行戦略

Savings PlansとReserved Instancesは目的が重なるため、既存のRI環境からSPへの移行戦略が本番運用の重要テーマとなる。

SP vs RI 比較表

RI→SP移行戦略 — 段階的切替

Phase 1: SPとRIの現状把握
  - 既存RI一覧と有効期限を確認
  - SP購入済みの場合はUtilization確認

Phase 2: RI有効期限ベースの切替計画
  - 3-6ヶ月以内に期限切れのRIをリストアップ
  - 期限切れRIをCompute SPで代替 (更新しない)
  - 長期RI(1年以上残存)は満了まで維持

Phase 3: SP購入・移行実施
  - RI満了タイミングでCompute SP追加購入
  - RDS/ElastiCacheはRDS RI継続(SP非対応)

Phase 4: モニタリング
  - SPカバレッジ率を四半期レビュー
  - RDSはRI利用率を監視継続

コンバーティブルRIとの併用

コンバーティブルRIはインスタンスファミリー変更が可能なため、SPとの役割が一部重複する。EC2でコンバーティブルRIとSPを両方保有する場合、SPが優先適用されるため重複投資に注意。既存コンバーティブルRIはSP購入前に利用率を確認し、重複しないよう計画する。

Organizations統合 — SPプーリングと自動共有

Organizations管理アカウントでSavings Plansを購入すると、配下のLinked Account全体にSPが自動的に共有・プーリングされる。この仕組みにより、特定のLinked Accountの利用が低くても他のアカウントが吸収できるため、SPの利用率を組織全体で最大化できる。

SPプーリングの仕組み

Management Account購入: Compute SP $5,000/月コミット
  ↓ 自動プーリング
  ├── Account A (API): $2,000/月利用 → SP適用
  ├── Account B (Data): $1,500/月利用 → SP適用
  ├── Account C (ML): $1,000/月利用 → SP適用
  └── 残り $500 → 未利用 (利用率90%)

アカウント別のSPカバレッジ確認

aws ce get-savings-plans-coverage \
  --time-period '{"Start":"2026-05-01","End":"2026-05-31"}' \
  --group-by '[{"Type":"DIMENSION","Key":"LINKED_ACCOUNT"}]'

Billing Conductor — SPコスト配分のカスタマイズ

AWS Billing Conductorを使うと、SPの割引をLinked Account間でカスタム配分できる。デフォルトではSPの割引恩恵が最も利用したアカウントに帰属するが、Billing Conductorで均等配分や比例配分が可能。マルチアカウントでコストチャージバックを行う組織で活用されるオプション。Billing ConductorはOrganizations管理アカウントで設定し、各アカウントの割引率・コスト配分ルールを一元管理できる。

Savings Plans 運用モニタリング — 継続的な最適化サイクル

SP購入後は購入して終わりではなく、定期的なモニタリングと調整が本番FinOpsの本質。四半期レビューサイクルで利用率・カバレッジを継続評価し、インフラ変化に追随した再購入判断が必要となる。

モニタリング指標と運用アクション

SPの満了・更新管理

import boto3
from datetime import datetime, timedelta

def check_expiring_savings_plans(days_threshold: int = 90) -> list:
 client = boto3.client('savingsplans', region_name='us-east-1')
 response = client.describe_savings_plans(
  states=['active']
 )

 expiring = []
 threshold_date = datetime.now() + timedelta(days=days_threshold)

 for sp in response['savingsPlans']:
  end_date = datetime.fromisoformat(sp['end'].replace('Z', '+00:00'))
  end_date_naive = end_date.replace(tzinfo=None)
  if end_date_naive <= threshold_date:
expiring.append({
 'arn': sp['savingsPlanArn'],
 'type': sp['savingsPlanType'],
 'commitment': sp['commitment'],
 'end_date': sp['end']
})
 return expiring

コスト最適化の自動レポート基盤

import boto3
from datetime import date, timedelta

def generate_monthly_sp_report(account_id: str) -> dict:
 ce = boto3.client('ce', region_name='us-east-1')
 today = date.today()
 start = today.replace(day=1).isoformat()
 end = today.isoformat()

 utilization = ce.get_savings_plans_utilization(
  TimePeriod={'Start': start, 'End': end},
  Granularity='MONTHLY'
 )
 coverage = ce.get_savings_plans_coverage(
  TimePeriod={'Start': start, 'End': end},
  Granularity='MONTHLY'
 )

 total = utilization.get('Total', {}).get('Utilization', {})
 return {
  'period': f"{start} to {end}",
  'utilization_pct': total.get('UtilizationPercentage', 'N/A'),
  'net_savings': total.get('NetSavings', 'N/A'),
  'unused_commitment': total.get('UnusedCommitment', 'N/A')
 }

Savings PlansとBudgetsを組み合わせたFinOpsサイクルは、Cost Explorer分析→SP購入→Budgets予算設定→モニタリング→四半期レビュー→追加購入という継続ループで成熟度を高めていく。FinOps成熟度の指標として、SPカバレッジ率65%以上・Budget Actionsの自動制御基盤整備・タグベースのコスト配分100%達成の3点を中期目標として設定するとよい。

Compute Optimizer + Cost Anomaly Detection 本番運用

%% Mermaid02: コスト最適化5層スタック相関マップ (§8まとめ用)
graph TB
 subgraph Viz["可視化層"]
  CE[Cost Explorer]
 end
 subgraph Ctrl["制御層"]
  BG[Budgets + Actions]
 end
 subgraph Buy["購入最適化層"]
  SP[Savings Plans]
 end
 subgraph Opt["リソース最適化層"]
  CO[Compute Optimizer]
 end
 subgraph Det["異常検知層"]
  CAD[Cost Anomaly Detection]
 end
 CUR[Cost & Usage Report] --> CE
 CE -->|分析結果| BG
 CE -->|SP推奨| SP
 CE -->|Right Sizing| CO
 CAD -->|異常通知| BG
 CO -->|推奨適用| SP
 BG -->|Actions| Lambda[Lambda/SCP]
 CAD -->|SNS| Alert[アラート通知]

Compute Optimizer 対象リソースと推奨タイプ

Compute Optimizerは機械学習で過去14日間(デフォルト)または3ヶ月(Enhanced Metrics時)のメトリクスを分析し、リソース使用効率改善の推奨を提示する。対象リソースはEC2インスタンス・Auto Scalingグループ・EBSボリューム・Lambda関数・ECS on Fargateタスク・RDS(プレビュー)の6種類。

推奨タイプは主に3種類:
– Right Sizing: 現インスタンスタイプより低コストの同世代タイプへ変更。CPUとメモリの両使用率が低い場合に提示。
– Graviton移行: x86からGravitonプロセッサへ変更。同性能帯で最大20%コスト削減。C/M/Rファミリで適用可能。
– EBSボリュームタイプ変更: gp2→gp3移行が代表例。同IOPS/スループットをgp3の方が安価に実現できる場合に推奨。

推奨結果は「High / Medium / Low」の信頼度スコアと「Cost差額 / 月次コスト削減額」で表示される。削減金額が大きい推奨から着手すれば短期間で費用対効果を最大化できる。

Enhanced Infrastructure Metrics — メモリ推奨精度の向上

デフォルトのCompute Optimizerはメモリ使用率を取得しない。EC2エージェント(CloudWatch Agent)が未導入の環境では、CPUのみで推奨が算出されるためメモリ集約型ワークロードで過小スペック推奨が出る危険がある。

Enhanced Infrastructure Metricsを有効化すると、分析期間が14日→3ヶ月に延長され、CloudWatch Agentのメモリメトリクスも活用して推奨精度が向上する。有効化コストは1リソースあたり$0.0025/時間(東京リージョン)。本番環境では推奨の信頼性向上に対して十分小さいコスト。

# Enhanced Infrastructure Metrics を有効化
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# Enhanced Metricsを有効化 (EC2)
aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --scope name=AccountId,value=123456789012 \
  --enhanced-infrastructure-metrics Active

Organizations統合 — 管理アカウントからの一括Opt-in

AWS Organizationsを利用している場合、管理アカウントから全メンバーアカウントをCompute Optimizerに一括Opt-inできる。各アカウントに個別で設定するより確実にカバレッジを確保できる。

# 管理アカウントから全メンバーアカウントを一括Opt-in
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# 全アカウントの推奨サマリを管理アカウントから確認
aws compute-optimizer get-recommendation-summaries \
  --account-ids ALL_ACCOUNTS

Opt-in後は推奨データが管理アカウントのCompute Optimizerコンソールに集約される。Linked Accountごとの削減ポテンシャルを一覧で確認し、対応優先度を決定できる。

API/CLI操作 — 推奨取得・エクスポート・S3出力

Compute OptimizerはAPIで推奨データを取得できる。定期実行スクリプトでSlackレポートやBI連携に活用可能。

# EC2インスタンス推奨取得
aws compute-optimizer get-ec2-instance-recommendations \
  --account-ids 123456789012 \
  --filters name=Finding,values=OVER_PROVISIONED \
  --query 'instanceRecommendations[*].{Instance:instanceArn,CurrentType:currentInstanceType,RecommendedType:recommendationOptions[0].instanceType,MonthlySaving:recommendationOptions[0].estimatedMonthlySavings.value}' \
  --output table

# 推奨データをS3にエクスポート (後続のBI分析用)
aws compute-optimizer export-ec2-instance-recommendations \
  --s3-destination-config bucket=my-cost-optimization-bucket,keyPrefix=compute-optimizer/ \
  --include-member-accounts \
  --filters name=Finding,values=OVER_PROVISIONED

import boto3
import json

def get_overprovisioned_instances():
 client = boto3.client('compute-optimizer', region_name='ap-northeast-1')

 response = client.get_ec2_instance_recommendations(
  filters=[{'name': 'Finding', 'values': ['OVER_PROVISIONED']}]
 )

 savings_list = []
 for rec in response['instanceRecommendations']:
  if rec['recommendationOptions']:
best_option = rec['recommendationOptions'][0]
savings_list.append({
 'instance_arn': rec['instanceArn'],
 'current_type': rec['currentInstanceType'],
 'recommended_type': best_option['instanceType'],
 'monthly_saving_usd': best_option.get('estimatedMonthlySavings', {}).get('value', 0),
 'performance_risk': best_option.get('performanceRisk', 'N/A')
})

 # 削減額の大きい順にソート
 savings_list.sort(key=lambda x: x['monthly_saving_usd'], reverse=True)
 return savings_list

if __name__ == '__main__':
 recommendations = get_overprovisioned_instances()
 total_saving = sum(r['monthly_saving_usd'] for r in recommendations)
 print(f"過剰プロビジョニングインスタンス数: {len(recommendations)}")
 print(f"月次削減ポテンシャル合計: ${total_saving:.2f}")
 for r in recommendations[:10]:
  print(f"  {r['instance_arn'].split('/')[-1]}: {r['current_type']} → {r['recommended_type']} (${r['monthly_saving_usd']:.2f}/月)")

推奨レスポンス例(一部):

{
  "instanceArn": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abc123def456",
  "currentInstanceType": "m5.xlarge",
  "finding": "OVER_PROVISIONED",
  "recommendationOptions": [
 {
"instanceType": "m6g.large",
"estimatedMonthlySavings": {
  "currency": "USD",
  "value": 45.23
},
"performanceRisk": 0.1,
"rank": 1
 }
  ]
}

Cost Anomaly Detection — MLベース異常検知の仕組み

Cost Anomaly Detectionは教師なし機械学習で過去のコストパターン(季節性・週次変動・成長トレンド)を自動学習し、異常なコスト増加を検知する。固定閾値では検知できない「曜日依存のトラフィック増加に起因するコスト増」を正常パターンとして除外し、真の異常(誤設定・セキュリティインシデント・リソースリーク)のみをアラートする。

モニタータイプは4種類:

モニター作成とアラート設定

# AWS Serviceモニターを作成 (EC2コストの異常を監視)
aws ce create-anomaly-monitor \
  --anomaly-monitor '{
 "MonitorName": "EC2-Cost-Monitor",
 "MonitorType": "DIMENSIONAL",
 "MonitorDimension": "SERVICE"
  }'

# アラートサブスクリプション作成 (即時通知 / ドル閾値$100 / SNS連携)
aws ce create-anomaly-subscription \
  --anomaly-subscription '{
 "SubscriptionName": "EC2-Anomaly-Alert",
 "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/ANOMALY_MONITOR_ARN"],
 "Subscribers": [
{
  "Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-anomaly-alerts",
  "Type": "SNS"
}
 ],
 "Threshold": 100,
 "Frequency": "IMMEDIATE"
  }'

アラート設定の主要パラメータ:
– Threshold: 検知閾値。ドル絶対値またはパーセント変化率で指定。本番環境では$50〜$200が実用的。
– Frequency: IMMEDIATE(即時)・DAILY(日次ダイジェスト)・WEEKLY(週次ダイジェスト)から選択。
– Subscribers: SNS TopicまたはEメールアドレスを複数登録可能。

Root Cause分析 — 異常の原因特定

Cost Anomaly Detectionのアラート通知にはRoot Cause分析が含まれる。異常コストを引き起こしたサービス・アカウント・リージョン・使用タイプが自動特定される。

Root Cause分析の出力例:

{
  "AnomalyId": "ANOMALY_123",
  "AnomalyStartDate": "2025-10-15",
  "DimensionValue": "Amazon EC2",
  "RootCauses": [
 {
"Service": "Amazon EC2",
"Region": "ap-northeast-1",
"LinkedAccount": "111122223333",
"UsageType": "APN1-BoxUsage:m5.4xlarge",
"Impact": {
  "MaxImpact": 523.45,
  "TotalActualSpend": 891.23,
  "TotalExpectedSpend": 145.67
}
 }
  ]
}

この情報があれば「どのアカウントの誰が何を誤って起動したか」を数分で特定できる。

SNS→Lambda自動対応パターン

Cost Anomaly DetectionとSNS・Lambdaを組み合わせることで、コスト異常の検知から自動対応まで無人で実行できる。

import boto3
import json
import os

def lambda_handler(event, context):
 """Cost Anomaly Detection → SNS → Lambda 自動対応"""
 sns_message = json.loads(event['Records'][0]['Sns']['Message'])

 anomaly_id = sns_message.get('anomalyId', '')
 anomaly_score = float(sns_message.get('anomalyScore', {}).get('currentScore', 0))
 total_impact = float(sns_message.get('impact', {}).get('totalImpact', 0))

 ce_client = boto3.client('ce')
 anomaly_detail = ce_client.get_anomalies(
  AnomalyIds=[anomaly_id]
 )

 root_causes = anomaly_detail['Anomalies'][0].get('RootCauses', [])
 affected_service = root_causes[0].get('Service', 'Unknown') if root_causes else 'Unknown'
 affected_account = root_causes[0].get('LinkedAccount', 'Unknown') if root_causes else 'Unknown'

 # 重大度判定: $500以上は緊急対応
 if total_impact >= 500:
  _send_pagerduty_alert(anomaly_id, total_impact, affected_service)
  _create_jira_incident(anomaly_id, root_causes)

 # Slackに詳細通知
 _notify_slack(
  f":rotating_light: コスト異常検知\n"
  f"- 異常ID: {anomaly_id}\n"
  f"- 影響額: ${total_impact:.2f}\n"
  f"- 対象サービス: {affected_service}\n"
  f"- アカウント: {affected_account}\n"
  f"- 調査URL: https://console.aws.amazon.com/cost-management/home#/anomaly-detection"
 )

 return {'statusCode': 200, 'body': f'Processed anomaly {anomaly_id}'}

def _notify_slack(message):
 import urllib.request
 webhook_url = os.environ['SLACK_WEBHOOK_URL']
 payload = json.dumps({'text': message}).encode('utf-8')
 req = urllib.request.Request(webhook_url, data=payload,
headers={'Content-Type': 'application/json'})
 resp = urllib.request.urlopen(req)
 return resp.status

def _send_pagerduty_alert(anomaly_id, impact, service):
 # PagerDuty連携 (重大コスト異常時)
 pass

def _create_jira_incident(anomaly_id, root_causes):
 # Jiraチケット自動作成 (調査トラッキング)
 pass

# 過去の異常検知履歴を取得
aws ce get-anomalies \
  --date-interval StartDate=2025-10-01,EndDate=2025-10-31 \
  --max-results 20 \
  --query 'Anomalies[*].{ID:AnomalyId,Start:AnomalyStartDate,Impact:Impact.TotalImpact,Service:RootCauses[0].Service}' \
  --output table

詰まりポイント 7選 図解

# Inactive状態のタグキーを確認
aws ce list-cost-allocation-tags \
  --status Inactive \
  --query "CostAllocationTags[*].TagKey"

詰まりポイント7選を通じて、Cost Explorer / Budgets / Savings Plans / Compute Optimizer / Cost Anomaly Detectionの各サービスで本番運用に潜む落とし穴を解説しました。以下に7選の共通パターンと優先整備ガイドをまとめます。

アンチパターン → 正解パターン変換演習

問題1: 月末手動コストレポート → Cost Explorer API + Lambda自動レポート

アンチパターン: 毎月末に担当者がCost Explorerを手動確認しExcelにまとめて経営陣にメール送信。担当者の休暇中はレポートが遅延し、タイムリーなコスト把握ができない。

正解パターン: Lambda + Cost Explorer APIで月次コストレポートを自動生成。EventBridgeで毎月1日に自動実行し、SESでメール配信。

import boto3
from datetime import datetime
from dateutil.relativedelta import relativedelta

def lambda_handler(event, context):
 ce = boto3.client('ce', region_name='us-east-1')
 ses = boto3.client('ses', region_name='ap-northeast-1')

 today = datetime.today()
 start = (today.replace(day=1) - relativedelta(months=1)).strftime('%Y-%m-%d')
 end = today.replace(day=1).strftime('%Y-%m-%d')

 response = ce.get_cost_and_usage(
  TimePeriod={'Start': start, 'End': end},
  Granularity='MONTHLY',
  Metrics=['BlendedCost'],
  GroupBy=[
{'Type': 'DIMENSION', 'Key': 'SERVICE'},
{'Type': 'TAG', 'Key': 'Project'}
  ]
 )

 groups = response['ResultsByTime'][0]['Groups']
 sorted_groups = sorted(
  groups,
  key=lambda x: float(x['Metrics']['BlendedCost']['Amount']),
  reverse=True
 )

 lines = [f"=== 月次コストレポート {start[:7]} ==="]
 for g in sorted_groups[:20]:
  service = g['Keys'][0]
  project = g['Keys'][1] if len(g['Keys']) > 1 else 'タグなし'
  amount = float(g['Metrics']['BlendedCost']['Amount'])
  lines.append(f"  {service} / {project}: ${amount:,.2f}")

 ses.send_email(
  Source='aws-cost@example.com',
  Destination={'ToAddresses': ['finops-team@example.com']},
  Message={
'Subject': {'Data': f"月次AWSコストレポート {start[:7]}"},
'Body': {'Text': {'Data': '\n'.join(lines)}}
  }
 )
 return {'statusCode': 200, 'items': len(lines)}

ポイント: GroupByでサービス×プロジェクトタグの二軸集計を実施し、コスト上位20件を自動ソートして配信する。EventBridge SchedulerルールでLambdaを毎月1日9:00に自動実行する。

問題2: Budget閾値一律100% → 多段階閾値 + Budget Actions段階制御

アンチパターン: 月次予算の100%超過時にのみメール通知。コスト超過が実際に起きてから気づくため月途中での制御が不可能。

正解パターン: 多段階閾値でエスカレーション。80%=早期警告メール、100%=Budget Actions(IAMポリシー適用)、120%=予測アラート(緊急エスカレーション)。

{
  "BudgetName": "monthly-ec2-budget",
  "BudgetLimit": {"Amount": "100000", "Unit": "USD"},
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST",
  "NotificationsWithSubscribers": [
 {
"Notification": {
  "NotificationType": "ACTUAL",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 80,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "EMAIL", "Address": "finops-team@example.com"},
  {"SubscriptionType": "SNS", "Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-alert-warning"}
]
 },
 {
"Notification": {
  "NotificationType": "ACTUAL",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 100,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "SNS", "Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-alert-critical"}
]
 },
 {
"Notification": {
  "NotificationType": "FORECASTED",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 120,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "SNS", "Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-alert-emergency"}
]
 }
  ]
}

ポイント: ACTUAL(実績)とFORECASTED(予測)の両方に閾値を設定。80%実績=早期警告、100%実績=Budget Actions発動のトリガー、120%予測=先手エスカレーション。Actions設定は別途CLIまたはCDKで追加する。

問題3: RI一括3年購入 → Savings Plans段階購入 + 四半期カバレッジ見直し

アンチパターン: 年間コスト削減を急いでEC2 Instance RI(3年All Upfront)を一括購入。翌月インスタンスファミリ変更でRIが無効化、数百万円のコミットメントが宙に浮く。

正解パターン: Compute SPを段階購入し、四半期ごとにカバレッジと利用率をCLIで確認して追加購入可否を判断する。

#!/usr/bin/env bash
# savings_plans_quarterly_review.sh — SP利用率・カバレッジ四半期確認

set -euo pipefail

START_DATE=$(python3 -c "
from datetime import date
from dateutil.relativedelta import relativedelta
print((date.today().replace(day=1) - relativedelta(months=3)).strftime('%Y-%m-%d'))
")
END_DATE=$(python3 -c "
from datetime import date
print(date.today().replace(day=1).strftime('%Y-%m-%d'))
")

echo "=== Savings Plans 利用率 ($START_DATE 〜 $END_DATE) ==="
aws ce get-savings-plans-utilization \
  --time-period "Start=${START_DATE},End=${END_DATE}" \
  --query 'Total.{利用率:Utilization.UtilizationPercentage,純節約額:Savings.NetSavings,未利用額:Savings.UnusedCommitment}' \
  --output table

echo ""
echo "=== Savings Plans カバレッジ (月次) ==="
aws ce get-savings-plans-coverage \
  --time-period "Start=${START_DATE},End=${END_DATE}" \
  --granularity MONTHLY \
  --query 'SavingsPlansCoverages[*].{月:TimePeriod.Start,カバレッジ率:Coverage.CoveragePercentage,OnDemand費用:Coverage.OnDemandCost}' \
  --output table

echo ""
echo "=== SP購入推奨 (1年 NoUpfront) ==="
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS \
  --query 'Recommendations[0].{推奨月額:RecommendedSPStandard,予測ROI:EstimatedROI}' \
  --output table 2>/dev/null || echo "推奨データなし"

ポイント: 利用率80%未満はSP追加購入を一時停止するシグナル。利用率90%超なら追加購入余地あり。このスクリプトを四半期末に実行し段階的なSP拡張判断の根拠データとして使う。

問題4: 全インスタンスそのまま → Compute Optimizer推奨 + Graviton移行

アンチパターン: Compute Optimizerの「Over-provisioned」推奨を3ヶ月放置。50インスタンスで月額15万円の削減機会を継続して見逃す。

正解パターン: Compute Optimizer推奨をAPI取得し、ダウンサイジング候補・Graviton移行候補を自動リスト化して月次FinOpsレビューに提出する。

#!/usr/bin/env bash
# compute_optimizer_report.sh — ダウンサイジング・Graviton移行候補レポート

set -euo pipefail

echo "=== Over-provisioned EC2 インスタンス + 推奨タイプ ==="
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[?finding==`OVER_PROVISIONED`].{
 InstanceId:instanceArn,
 現在タイプ:currentInstanceType,
 推奨タイプ:recommendationOptions[0].instanceType,
 推定月次節約USD:recommendationOptions[0].estimatedMonthlySavings.value
  }' \
  --output table 2>/dev/null || echo "注意: Compute Optimizerが未有効化の可能性があります"

echo ""
echo "=== Graviton移行候補 (推奨タイプに g 含む) ==="
aws compute-optimizer get-ec2-instance-recommendations \
  --query "instanceRecommendations[?
 contains(recommendationOptions[0].instanceType, 'g')
  ].{
 InstanceId:instanceArn,
 現在タイプ:currentInstanceType,
 推奨Gravitonタイプ:recommendationOptions[0].instanceType,
 推定月次節約:recommendationOptions[0].estimatedMonthlySavings.value
  }" \
  --output table 2>/dev/null || echo "Graviton移行候補なし"

echo ""
echo "=== Enhanced Infrastructure Metrics 有効化状態 ==="
aws compute-optimizer get-enrollment-statuses \
  --query 'accountEnrollmentStatuses[].{アカウントID:accountId,状態:status}' \
  --output table

ポイント: Over-provisioned推奨とGraviton移行候補を分離してリスト化。推定月次節約の合計が月次削減可能額の目安。Enhanced Metricsが未有効化の場合は先に有効化してから推奨を再評価する。

問題5: コスト異常手動監視 → Cost Anomaly Detection + SNS + Lambda自動通知

アンチパターン: 担当者が週次でCost Explorerを手動確認するだけでコスト異常を監視。深夜のEC2暴走が1週間検出されず、月次コストが前月比+150%になってから発覚。

正解パターン: Cost Anomaly Detectionでサービス別モニターを設定し、閾値超過時にSNS → Lambda → Slack自動通知。

{
  "AnomalyMonitor": {
 "MonitorName": "service-anomaly-monitor",
 "MonitorType": "DIMENSIONAL",
 "MonitorDimension": "SERVICE"
  },
  "AnomalySubscription": {
 "SubscriptionName": "production-anomaly-alert",
 "Threshold": 0,
 "ThresholdExpression": {
"And": [
  {
 "Dimensions": {
"Key": "ANOMALY_TOTAL_IMPACT_ABSOLUTE",
"Values": ["100"],
"MatchOptions": ["GREATER_THAN_OR_EQUAL"]
 }
  },
  {
 "Dimensions": {
"Key": "ANOMALY_TOTAL_IMPACT_PERCENTAGE",
"Values": ["20"],
"MatchOptions": ["GREATER_THAN_OR_EQUAL"]
 }
  }
]
 },
 "Subscribers": [
{
  "Address": "arn:aws:sns:ap-northeast-1:123456789012:cost-anomaly-production",
  "Type": "SNS"
}
 ],
 "Frequency": "DAILY"
  }
}

Lambda関数でSNS受信 → Slackへ転送:

import json
import urllib.request

def lambda_handler(event, context):
 message = json.loads(event['Records'][0]['Sns']['Message'])
 anomaly = message.get('anomalyDetails', {})
 impact = anomaly.get('impact', {})
 root_causes = anomaly.get('rootCauses', [{}])

 slack_text = (
  f":money_with_wings: *コスト異常検知*\n"
  f"サービス: {root_causes[0].get('service', '不明')}\n"
  f"影響額: ${float(impact.get('totalActualSpend', 0)):,.2f}\n"
  f"前週比: {float(impact.get('totalImpactPercentage', 0)):.1f}%増加\n"
  f"確認: https://console.aws.amazon.com/cost-management/home"
 )

 req = urllib.request.Request(
  'https://hooks.slack.com/services/YOUR_WEBHOOK_TOKEN',
  data=json.dumps({"text": slack_text}).encode(),
  headers={'Content-Type': 'application/json'}
 )
 urllib.request.urlopen(req)
 return {'statusCode': 200}

ポイント: ThresholdExpressionで「絶対額$100以上 かつ 前週比20%以上」の複合条件を設定し誤検知を削減。サービス別モニターで異常の根本原因サービスを自動特定。Lambdaに渡されるSNSメッセージ内のrootCauses配列で異常サービスをSlack通知に含める。

まとめ — Cost Optimization Vol1 起点 × 56記事化達成

本記事ではAWSコスト最適化を 5層フレームワーク として体系化し、Cost Explorer(可視化)・Budgets+Budget Actions(制御)・Savings Plans(購入最適化)・Compute Optimizer(リソース最適化)・Cost Anomaly Detection(異常検知)の本番運用ノウハウを解説しました。

単一サービスの使い方を知っているだけでは本番コスト管理は機能しません。5層を統合的に運用してはじめて「コスト可視化 → 予算制御 → コミットメント最適化 → リソース最適化 → 異常の早期発見」というFinOpsサイクルが回ります。

各層の最重要ポイント振り返り

§6で学んだ詰まりポイント7選の要点

本記事で解説した詰まりポイントは、実際の本番運用で発生頻度が高いものを厳選しています。特に重要なのは以下の3点です。

1. タグ管理の基盤整備が最優先: 詰まり①と⑦は同根の問題です。コスト配分タグを活性化し命名規則を統一することが、Cost Explorer精度向上の前提条件になります。タグなしでは「どのプロジェクトがいくら使っているか」が分からず、コスト削減の責任者を特定できません。

2. Budget Actionsは本番と開発を必ず分離: 詰まり②は承認ワークフローの有無だけで本番SLA違反を防げます。自動実行アクションは開発環境限定、本番環境は承認ワークフローありが絶対ルールです。

3. Compute Optimizer推奨に「誰が実施するか」を決める: 詰まり⑤の本質は技術ではなく運用フローの欠如です。月次FinOpsレビューで推奨を確認し担当者を割り当てるだけで、月額数万円の削減が実現します。

§7で学んだアンチパターン変換の要点

5つの演習問題を通じて、手動運用から自動化への変換パターンを習得しました。共通するテーマは「繰り返し作業をEventBridge + Lambdaで自動化し、人間は例外処理と意思決定に集中する」という設計思想です。Cost Explorer APIの活用とCost Anomaly Detection + SNS + Lambdaの組み合わせが、FinOps自動化の核心になります。

FinOps実践への接続

本記事で解説した5層フレームワークは、FinOps Foundation のコアサイクル「Inform(情報収集) → Optimize(最適化) → Operate(運用)」に対応しています。

月次FinOpsレビューにこの5層の状態確認を組み込むことで、継続的なコスト改善サイクルを自組織に定着させることができます。Cost Optimization本番運用シリーズのVol2では、Reserved Instances・Spot Fleet・Graviton移行・Right Sizing・Pricing Calculatorによる実行層を詳説しています。

%% Mermaid02: コスト最適化5層スタック相関マップ
graph TB
 subgraph Viz["可視化層 — Cost Explorer"]
  CE[Cost Explorer\nダッシュボード・予測・Right Sizing]
 end
 subgraph Ctrl["制御層 — Budgets"]
  BG[Budgets\n多段階アラート・Actions]
 end
 subgraph Buy["購入最適化層 — Savings Plans"]
  SP[Savings Plans\nCompute SP・カバレッジ分析]
 end
 subgraph Opt["リソース最適化層 — Compute Optimizer"]
  CO[Compute Optimizer\nリソース推奨・Graviton]
 end
 subgraph Det["異常検知層 — Cost Anomaly Detection"]
  CAD[Cost Anomaly Detection\nML異常検知・Root Cause]
 end
 CUR[Cost and Usage Report\nS3] -->|コストデータ| CE
 CE -->|予算計画| BG
 CE -->|SP購入推奨| SP
 CE -->|Right Sizing推奨| CO
 CAD -->|異常アラート| BG
 CO -->|適正化後の利用量| SP
 BG -->|Actions発動| Lambda[Lambda / SCP\n自動制御]
 CAD -->|SNS通知| Alert[Slack / Email\nオンコール通知]

本記事でAWS Cost Optimization Vol1を完走しました。FinOps実践の第一歩として、まず Cost Explorer のコスト配分タグ活性化 と Budgets の多段階アラート設定 から着手することをお勧めします。この2点を整備するだけで、コスト管理の可視化と制御の基盤が一気に整います。

次のステップとして、Compute OptimizerのEnhanced Infrastructure Metricsを有効化し、Over-provisioned推奨の月次レビューを定例化しましょう。月次削減可能額がダッシュボードに可視化されることで、FinOpsの価値を組織内に示す具体的な数字が得られます。

Savings PlansはCompute SPから小額で段階的に購入を開始し、カバレッジ60〜70%の目標に向けて四半期ごとに拡張するアプローチが安全です。一括大量購入の誘惑に抗い、データドリブンな段階的コミットメントを徹底することが本番FinOps運用の鉄則です。

Cost Anomaly Detectionは設定後すぐに価値を発揮します。サービス別モニターと複合条件閾値を設定することで、深夜のコスト暴走を翌朝のSlack通知で察知できる体制が整います。Cost Optimizationの5層フレームワークを組み合わせることで、AWSコストを継続的に最適化するFinOpsエンジニアリング基盤が完成します。

AWS本番運用シリーズの他の記事もあわせてご活用ください。

FinOps導入 実践アクションチェックリスト

本記事で学んだ5層フレームワークを実際の本番環境に適用するための、優先度順アクションリストです。

Week 1: 可視化基盤の整備

• コスト配分タグの設計・活性化 (プロジェクト/環境/チームの3軸最低限)
• Cost Explorerでサービス別・タグ別コスト実態の初回把握
• Budgets初期設定 (月次予算 + 80%/100%の2段階アラート)
• Cost Anomaly Detectionのサービス別モニター作成 + SNS通知設定

Month 1: 制御層と異常検知の確立

• Budget Actionsの段階設定 (開発環境への適用から開始し本番は承認ワークフローを維持)
• Compute OptimizerのEnhanced Infrastructure Metrics有効化 (14日分のCloudWatchデータ収集)
• Over-provisioned Top 10リストの月次レビュー定例化 (30分/月で年間数十万円削減の実績あり)
• SNS + Lambdaによるコスト異常Slack通知の自動化 (on-callエンジニアへの即時エスカレーション)

Quarter 1: 購入最適化の開始

• Savings Plansカバレッジ分析の実施 (現状カバレッジをCost Explorerで数値把握)
• Compute SP小額テスト購入 (月次オンデマンドコストの10〜15%相当から開始)
• Right Sizing推奨上位3件の適用 (Graviton移行は検証環境で先行テスト)
• FinOps月次レビュー会議の定例化 (30分でコスト前月比・削減効果・次月施策を確認)

通年: FinOpsサイクルの定着

• 四半期ごとのSavings Plansカバレッジ拡張判断 (カバレッジ60〜70%目標に段階的に引き上げ)
• 年次のRI vs Savings Plans戦略見直し (組織のAWS利用パターン変化に追従)
• コスト削減実績のダッシュボード可視化・経営報告 (FinOpsのROIを定量的に示す)

このチェックリストを組織のFinOpsロードマップの出発点として活用ください。「計測できないものは改善できない」という原則に従い、まず可視化から着手することがCost Optimization本番運用の鉄則です。5層フレームワークの各層を順番に整備することで、AWSコストを継続的に最適化するFinOpsエンジニアリング基盤が確実に構築できます。

前回: Data Analytics本番運用 Vol2

次回: Cost Optimization Vol2 — Reserved Instances × Spot Fleet × Graviton × Right Sizing

AWS本番運用シリーズ 全記事一覧

関連: Data Analytics Vol1

関連: Step Functions本番運用

Cost Optimization本番運用シリーズのVol2（Reserved Instances × Spot Fleet × Graviton × Right Sizing）は公開済みです。Vol3以降ではAWS Organizations統合コスト管理・マルチアカウントFinOps基盤・Cost Intelligence Dashboardを活用した高度な分析基盤の構築まで、FinOpsエンジニアリングの深みを体系的に解説していきます。

本記事のブックマークと各軸クロスリンクを活用し、AWS本番運用の知識体系を継続的に強化してください。AWSコスト最適化の実践は一度で完結するものではなく、FinOpsサイクルを継続的に回すことで組織全体のコスト文化が醸成されます。