AWS Cost Opt Vol3｜Billing Conductor×Categories×Split×Exports

なぜ Cost Optimization Vol3 か — 組織横断コスト管理3層概観

AWS環境でコスト最適化に取り組む組織は、「見える化」だけで終わらない。
予算アラートを設定し、Reserved Instancesで節約し、Gravitonに移行しても、最終的にぶつかる壁がある。
「誰がどのコストを負担するのか」——組織横断のコスト配分問題だ。

Vol1（Cost Explorer / Budgets / Savings Plans / Compute Optimizer）では、コストの可視化と節約自動化を確立した。
Vol2（RI / Spot Fleet / Graviton / Right Sizing）では、実行層の最適化を実装した。
Vol3が担うのは、その上位レイヤ——組織横断コスト管理と高度な配分だ。

FinOps三部作の全体像

FinOpsフレームワーク（FOCUS標準準拠）では、コスト管理サイクルを Inform → Optimize → Operate の3フェーズで定義する。
Vol1が Inform（情報収集・可視化）を担い、Vol2が Optimize（最適化実行）を担う。
Vol3の Operate フェーズでは、最適化済みのコストを組織構造に沿って正確に配分・報告する仕組みを構築する。

マルチアカウント環境が抱える4つの課題

マルチアカウント組織（AWS Organizations）では、コストは Management Account に集約される。
しかし実務では、アカウントの数が増えるにつれ「誰がどのコストを使っているか」を把握するのが困難になる。
タグ付け漏れ、共有リソースの存在、外部顧客への請求計算——これらが組み合わさると手動管理では限界が来る。

課題1: 部門間のコスト配分が困難

アカウントが事業部単位に分かれていない場合、Cost Explorer のタグフィルタだけでは部門別コストを正確に算出できない。
タグ付け漏れが生じるたびに「未分類」コストが膨らみ、責任部門の特定が困難になる。
Cost Categories による自動分類ルールと継承値がこの問題を解決する。

課題2: 共有リソースの按分が手動

ECSクラスター・EKSノードプール・S3バケットなど、複数チームが共有するリソースのコストは、従来は手動のスプレッドシートで按分していた。
更新サイクルが遅く、チーム増減のたびにルールを書き直す必要があった。
Split Cost Allocation が、タスク・Pod単位の使用量に基づく自動按分でこれを解決する。

課題3: MSP・リセラーの請求計算が複雑

AWSリセラー（MSP）は顧客ごとにカスタム料金を設定し、プロフォーマ請求書を作成する必要がある。
Management Console の標準請求画面はそのような用途に対応していない。
Billing Conductor のカスタム請求グループと料金ルール（マークアップ・ディスカウント・ティアリング）が解決策だ。

課題4: 全社コスト分析のパイプラインが整備されていない

Cost Explorer の UI では、大規模データのアドホック分析やカスタムダッシュボード作成に限界がある。
CUR 2.0（Cost and Usage Report 2.0）を S3 → Athena → QuickSight に流すデータパイプラインが必要だが、
設計パターンを知らない組織では毎回ゼロから構築している。
Data Exports がこれを標準化し、Parquet形式・自動パーティショニングで分析コストを削減する。

Vol3 が提供する4つの解決策

対象読者とゴール

本記事の対象読者は、マルチアカウントAWS環境でFinOps実践に取り組むCloud Architect / FinOps Practitionerだ。

読了後の到達目標:

1. Billing Conductor でカスタム請求グループ・料金ルール・マージン管理を本番運用できる
2. Cost Categories で組織構造に合ったコスト分類ルールを設計・維持できる
3. Split Cost Allocation でコンテナワークロードの共有コストをPod・タスク単位で按分できる
4. Data Exports（CUR 2.0）からAthena・QuickSightへのパイプラインを構築できる
5. Vol1（可視化）× Vol2（最適化）× Vol3（配分）の統合FinOpsフローを設計できる

本記事の読み方

§2（Billing Conductor）→ §3（Cost Categories）→ §4（Split Cost）→ §5（Data Exports） の順が推奨だが、各章は独立して読める。

• MSP・リセラーの方は §2 から始め、§3 でコスト分類を補完する
• Platform Engineering・SREチームの方は §4（共有コスト按分）と §5（分析基盤）を優先する
• FinOps Leadの方は §7（統合アーキテクチャ）を先に俯瞰してから各章に戻ることを推奨する

Vol3は三部作の締めくくりであり、組織横断FinOps運用の実践ガイドだ。本記事で FinOps完全体 を完成させよう。

AWS Billing Conductor 本番運用 — カスタム請求グループ / 料金ルール / マージン管理

AWS Billing Conductor は、AWS Organizationsのメンバーアカウントをカスタム請求グループに束ね、
グループごとに独立した「プロフォーマ（仮想）請求書」を生成するサービスだ。
標準のConsolidated Billingでは全アカウントが同一の請求書に含まれるが、
Billing Conductorを使えばアカウントを論理グループに分割し、グループごとに異なる料金ルールを適用できる。

主なユースケースは3つだ:

• MSP・リセラー: 顧客アカウントごとにマークアップを加算したカスタム料金を設定し、プロフォーマ請求書を発行する
• 社内部門課金（チャージバック）: 事業部ごとのコストを隔離し、部門別の仮想請求書で内部チャージバックを実現する
• コスト分析の分離: Billing GroupごとのAthenaビューやCUR出力で、グループ単位のコスト分析を独立させる

前提条件と制約事項

Billing Conductorを使用する前に確認すべき制約がある:

Billing Groupの作成とアカウント割当

Billing Group（請求グループ）はBilling Conductorの基本単位だ。
1つのBilling Groupに複数のメンバーアカウントを割り当て、グループ全体に料金ルールと請求書設定を適用する。

コンソール操作手順:

1. AWS Billing and Cost Management → Billing Conductor を開く
2. Billing groups → Create billing group を選択
3. Primary account を選択（このアカウントがプロフォーマ請求書の宛先）
4. Linked accounts で追加するメンバーアカウントを選択
5. Pricing plan を設定（後述の料金ルールを紐付ける）
6. Create で作成完了

AWS CLIでBilling Groupを作成する例:

aws billingconductor create-billing-group \
  --name "TeamA-BillingGroup" \
  --primary-account-id 123456789012 \
  --computation-preference \
 '{"PricingPlanArn":"arn:aws:billingconductor::123456789012:pricingplan/team-a-plan"}' \
  --account-grouping \
 '{"LinkedAccountIds":["234567890123","345678901234"]}'

Billing Groupへのアカウント追加（後から追加する場合）:

aws billingconductor associate-accounts \
  --arn "arn:aws:billingconductor::123456789012:billinggroup/TeamA-BillingGroup" \
  --account-ids '["456789012345"]'

Billing Group内のアカウント一覧確認:

aws billingconductor list-account-associations \
  --filters \
 '{"Association":"BILLING_GROUP","Value":"arn:aws:billingconductor::123456789012:billinggroup/TeamA-BillingGroup"}'

アカウント割当の設計原則:

• 1つのメンバーアカウントは同時に1つのBilling Groupにのみ所属できる
• Billing Groupに割り当てていないアカウントは「Default Billing Group」に自動分類される
• Primary AccountはManagement Accountとは別のLinked Accountを指定できる（顧客のPayer Accountを指定するMSPパターン）
• Billing Groupを削除する前にすべてのメンバーアカウントを解除する必要がある

料金ルール（Pricing Rules）の設定

料金ルール（Pricing Rule）は、Billing Groupに適用するカスタム価格設定だ。
Billing Conductorでは3種類の料金ルールを組み合わせてPricing Plan（料金プラン）を構成する。

料金ルールの3種類:

Scopeの種別:

マークアップルールの設定例

MSPが顧客アカウントに対してEC2コストに10%マークアップを加算する場合:

aws billingconductor create-pricing-rule \
  --name "ec2-markup-10pct" \
  --scope "SERVICE" \
  --service "AmazonEC2" \
  --type "MARKUP" \
  --modifier-percentage 10.0

JSON設定例（Infrastructure as Codeでの管理用）:

{
  "Name": "ec2-markup-10pct",
  "Scope": "SERVICE",
  "Service": "AmazonEC2",
  "Type": "MARKUP",
  "ModifierPercentage": 10.0,
  "Description": "EC2 10% markup for MSP Customer A"
}

ディスカウントルールの設定例

社内DX推進部門に対してS3ストレージコストを5%割引する場合:

aws billingconductor create-pricing-rule \
  --name "s3-discount-5pct" \
  --scope "SERVICE" \
  --service "AmazonS3" \
  --type "DISCOUNT" \
  --modifier-percentage 5.0

Pricing Plan（料金プラン）の構成

複数の料金ルールをPricing Planに紐付け、そのPlanをBilling Groupに関連付ける:

# 料金プラン作成
aws billingconductor create-pricing-plan \
  --name "msp-customer-a-plan" \
  --description "MSP Customer A - EC2 10% markup, S3 5% discount"

# 料金ルールを料金プランに追加
aws billingconductor associate-pricing-rules \
  --arn "arn:aws:billingconductor::123456789012:pricingplan/msp-customer-a-plan" \
  --pricing-rule-arns \
 '["arn:aws:billingconductor::123456789012:pricingrule/ec2-markup-10pct","arn:aws:billingconductor::123456789012:pricingrule/s3-discount-5pct"]'

料金プランの一覧確認

aws billingconductor list-pricing-plans \
  --query 'PricingPlans[*].{Name:Name,Arn:Arn,Size:Size}' \
  --output table

プロフォーマ請求（Pro Forma Invoice）

プロフォーマ請求書は、Billing Conductorが生成する仮想的な請求書だ。
Billing Groupに適用した料金ルールを反映したコストが月次で計算され、AWS Billing Consoleから参照できる。

プロフォーマ請求書の確認手順:

1. AWS Billing and Cost Management → Bills を開く
2. Billing group ドロップダウンで対象グループを選択
3. Invoice セクションで該当月のプロフォーマ請求書を確認
4. 実請求書（実際のAWS請求）との差額（マージン）を確認

APIでプロフォーマデータを取得する:

# Billing Groupのコスト情報を取得
aws billingconductor list-billing-group-cost-reports \
  --billing-period "2026-05"

# 特定グループの詳細レポート
aws billingconductor get-billing-group-cost-report \
  --billing-period "2026-05" \
  --arn "arn:aws:billingconductor::123456789012:billinggroup/TeamA-BillingGroup"

返却データ例:

{
  "BillingGroupCostReportResults": [
 {
"AWSCost": "1234.56",
"ProformaCost": "1358.02",
"Margin": "123.46",
"MarginPercentage": "10.0",
"Currency": "USD"
 }
  ]
}

AWSCost が実際のAWS請求コスト、ProformaCost がマークアップ後の顧客向けコストだ。
Margin と MarginPercentage で、グループごとの利益額と利益率を即座に把握できる。

カスタムラインアイテム

カスタムラインアイテム（Custom Line Item）は、プロフォーマ請求書に任意の費用項目を追加または控除する機能だ。
AWSサービスコストではない費用（サポート費用・ライセンス費用・サービス利用料など）をプロフォーマ請求書に含める際に使用する。

代表的な用途:

• Premier Supportの月額費用をプロフォーマ請求書に追加する
• ソフトウェアライセンス費用（EDP対象外）を顧客向け請求書に反映する
• 請求調整（クレジット相当の控除）を個別顧客アカウントに適用する
• 管理費用（MSP運用費）を定額ラインアイテムとして追加する

カスタムラインアイテムの作成（追加費用の場合）:

aws billingconductor create-custom-line-item \
  --name "monthly-support-fee" \
  --description "Premier Support Fee - May 2026" \
  --billing-group-arn \
 "arn:aws:billingconductor::123456789012:billinggroup/TeamA-BillingGroup" \
  --billing-period-range \
 '{"InclusiveStartBillingPeriod":"2026-05","ExclusiveEndBillingPeriod":"2026-06"}' \
  --charge-details \
 '{"Flat":{"ChargeValue":500.00},"Type":"FEE"}'

カスタムラインアイテムの作成（クレジット控除の場合）:

aws billingconductor create-custom-line-item \
  --name "discount-credit-may" \
  --description "One-time credit adjustment - May 2026" \
  --billing-group-arn \
 "arn:aws:billingconductor::123456789012:billinggroup/TeamA-BillingGroup" \
  --billing-period-range \
 '{"InclusiveStartBillingPeriod":"2026-05","ExclusiveEndBillingPeriod":"2026-06"}' \
  --charge-details \
 '{"Flat":{"ChargeValue":100.00},"Type":"CREDIT"}'

• Type: FEE: プロフォーマ請求に追加する費用項目
• Type: CREDIT: プロフォーマ請求から控除するクレジット項目

既存ラインアイテムの確認:

aws billingconductor list-custom-line-items \
  --billing-period "2026-05" \
  --query 'CustomLineItems[*].{Name:Name,Charge:ChargeDetails,Arn:Arn}'

マージン管理 — リセラー/MSP向け本番運用パターン

Billing Conductorによるマージン管理は、AWSリセラー（MSP）が複数顧客アカウントを管理しながら利益を確保するための中核機能だ。

標準的なMSPアーキテクチャ:

マージン計算の自動化（全グループ一括取得）:

aws billingconductor list-billing-group-cost-reports \
  --billing-period "2026-05" \
  --query \
 'BillingGroupCostReportResults[*].{Group:BillingGroupArn,AWS:AWSCost,Proforma:ProformaCost,Margin:Margin,Rate:MarginPercentage}' \
  --output table

月次マージンレポート自動生成 — EventBridge + Lambda:

月初2日（請求データ確定後）に自動実行するLambdaをEventBridgeでスケジュールする:

{
  "ScheduleExpression": "cron(0 9 2 * ? *)",
  "Description": "Monthly Billing Conductor margin report - runs on 2nd of each month",
  "Targets": [
 {
"Id": "BillingConductorMarginReport",
"Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:billing-margin-report",
"Input": "{\"billingPeriodOffset\": 1}"
 }
  ]
}

MSP向け本番運用の主要チェックポイント:

1. 請求書確定タイミング: 月末締めの翌月5日頃にプロフォーマ請求書が確定する。顧客への請求書発行は確定後に行う
2. 為替レートの考慮: AWSの請求はUSDベース。顧客請求がJPYの場合は確定為替レートをカスタムラインアイテムで調整する
3. 割引の還元ポリシー: AWS Volume Discount・EDP（Enterprise Discount Program）の割引はManagement Accountに適用される。顧客に還元する場合はDiscountルールで明示的に設定する
4. 監査証跡: Billing Conductorの操作（料金ルール変更・アカウント追加）はCloudTrailに自動記録される。変更承認フローとAuditログを整備する
5. テスト環境での事前検証: 料金ルール変更は翌月適用のため、変更前にテスト用Billing Groupで計算結果を先に確認する

マージン管理でよくある落とし穴:

AWS Cost Categories 本番運用 — 分類ルール / 継承値 / 分割チャージ

sequenceDiagram
 participant CUR as Cost & Usage Report
 participant CC as Cost Categories
 participant Rule as 分類ルール
 participant CE as Cost Explorer
 CUR->>CC: コストデータ入力
 CC->>Rule: ルール評価 (アカウント/サービス/タグ)
 Rule-->>CC: カテゴリ割当
 CC->>CE: 分類済みコスト表示
 Note over CC,Rule: 継承値で子アカウント<br/>カテゴリ自動適用

Cost Categoriesは、AWSコストをビジネス軸（環境・チーム・プロジェクト・製品）で分類し、Cost ExplorerやCURにカテゴリディメンションとして反映させる仕組みだ。タグベースの分類では補えない「アカウント横断分類」「共有コスト按分」を実現できる。コストアロケーションタグと組み合わせることで、最大50個のカテゴリ定義で組織全体のコスト責任を明確化できる。

3-1 分類ルールの構造

Cost Categoriesのルール評価は「上位ルールが優先」の先頭一致方式で動作する。ルールタイプは3種類あり、それぞれ異なる分類ロジックを持つ。

Regular ルールで使用可能なディメンション:

条件の組み合わせには AND / OR / NOT 演算子を使用できる。複合条件は最大10レイヤーのネスト深度まで対応している。

3-2 継承値ルール (Inherited Value)

Inherited Value ルールは、Organizations のアカウント属性を Cost Categories の値として自動継承する。手動ルール定義不要で、組織変更に追随できる利点がある。

継承元として選択可能な属性:
– LINKED_ACCOUNT_NAME: AWSアカウント名をそのままカテゴリ値として使用
– ORGANIZATIONAL_UNIT_ID: OU IDを直接カテゴリ値として使用
– ORGANIZATIONAL_UNIT_NAME: OUの表示名をカテゴリ値として使用

{
  "Name": "AccountEnv",
  "Rules": [
 {
"Value": "Production",
"Rule": {
  "Tags": {
 "Key": "Environment",
 "Values": ["prod", "production"],
 "MatchOptions": ["EQUALS"]
  }
},
"Type": "REGULAR"
 },
 {
"Type": "INHERITED_VALUE",
"InheritedValue": {
  "DimensionName": "LINKED_ACCOUNT_NAME",
  "DimensionKey": "AccountName"
}
 }
  ],
  "DefaultValue": "Unallocated"
}

Inherited Value は Regular ルールと組み合わせて、「明示タグがあればタグを優先、なければアカウント名継承」という fallback 設計が可能だ。

3-3 分割チャージ (Split Charge)

分割チャージは、単一の「共有コスト源カテゴリ」を複数の「分配先カテゴリ」に按分する機能だ。共有ネットワーク費・サポートプラン費・共有データ転送費などの組織横断コストを、受益者ベースで公平に配分できる。

按分メソッド3種:

PROPORTIONAL が最も実態を反映した按分となるケースが多い。各チーム・部門の直接コストを重みとして、共有コストを自動分配する。

{
  "SplitChargeRules": [
 {
"Source": "Shared-Infrastructure",
"Targets": ["Team-A", "Team-B", "Team-C"],
"Method": "PROPORTIONAL",
"Parameters": []
 },
 {
"Source": "Shared-Networking",
"Targets": ["Team-A", "Team-B"],
"Method": "FIXED",
"Parameters": [
  {
 "Type": "ALLOCATION_PERCENTAGES",
 "Values": ["60", "40"]
  }
]
 }
  ]
}

EVEN メソッドは最もシンプルだが、チームごとのリソース利用量差が大きい場合には不公平感を生む。FinOpsチームとの合意形成後、PROPORTIONAL への移行を推奨する。

3-4 Cost Explorer 統合

Cost Categories を有効化すると、Cost Explorer の Group By に新しいディメンションとして表示される。フィルタリングと合わせて使用することで、「Production 環境のEC2コスト推移」のような多軸分析が即座に可能になる。

分類済みコストの活用:

1. Cost Explorer → Group By: Cost Category で時系列グラフ表示
2. カテゴリ値フィルター でチーム・環境・プロダクト単位のコスト抽出
3. “No Cost Category” 表示でルール漏れ（未分類コスト）を把握・改善
4. CUR 2.0 では aws:CostCategory/カテゴリ名 列として自動追加

Cost Categoriesは最大50個まで作成可能で、それぞれ最大100件のルールを持てる。変更反映には最大24時間かかる。過去12ヶ月分のデータへの遡及適用も可能で、--effective-start で遡及期間を指定できる。

3-5 IaC管理

Cost Categories の定義は CloudFormation / Terraform でコード管理できる。バージョン管理・変更追跡・環境間の一貫性を確保するうえで不可欠だ。

AWS CLIでの作成:

aws ce create-cost-category-definition \
  --name "BusinessUnit" \
  --rule-version "CostCategoryExpression.v1" \
  --rules file://cost-category-rules.json \
  --default-value "Unallocated" \
  --split-charge-rules file://split-charge-rules.json

Terraform での管理:

resource "aws_ce_cost_category" "business_unit" {
  name = "BusinessUnit"
  rule_version  = "CostCategoryExpression.v1"
  default_value = "Unallocated"

  rule {
 value = "Platform"
 rule {
dimension {
  key  = "LINKED_ACCOUNT"
  values  = ["123456789012", "234567890123"]
  match_options = ["EQUALS"]
}
 }
 type = "REGULAR"
  }

  rule {
 type = "INHERITED_VALUE"
 inherited_value {
dimension_name = "LINKED_ACCOUNT_NAME"
dimension_key  = "AccountName"
 }
  }

  split_charge_rule {
 source  = "Shared-Networking"
 targets = ["Platform", "Product-A", "Product-B"]
 method  = "PROPORTIONAL"
  }
}

Split Cost Allocation 本番運用 — ECS/EKS共有リソース按分 / S3バケット按分

Split Cost Allocationは、ECS・EKS・S3のような共有リソースモデルで稼働するワークロードのコストを、実際のリソース消費量に基づいて個々のタスク・Pod・プレフィックスに按分する機能だ。コンテナワークロードが急増したマルチアカウント組織では、これなしにコスト責任の帰属を正確に行うことはほぼ不可能だ。

4-1 ECS Split Cost Allocation

ECS Split Cost Allocationは、ECSクラスター上で動作する複数サービスの共有リソース費用を、タスクレベルのCPU/メモリ予約量に基づいて按分する。

有効化手順:

ECS Split Cost Allocationは Cost Management コンソール → Settings → Split cost allocation から組織全体に有効化する。リージョン設定は不要で、Organizations 全体に即時適用される。

コストアロケーションタグを有効化する:

aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status \
 '[{"TagKey":"aws:ecs:serviceName","Status":"Active"},
{"TagKey":"aws:ecs:clusterName","Status":"Active"},
{"TagKey":"aws:ecs:taskDefinitionFamily","Status":"Active"}]'

タスクレベルCPU/メモリ按分のロジック:

Fargate vs EC2バックエンド按分差異:

EC2バックエンドでは、インスタンスコストをそのインスタンス上の全タスクの予約比率で分割する。タスク定義で cpu/memory を未指定にすると按分対象外になるため、必ず明示指定すること。

4-2 EKS Split Cost Allocation

EKS Split Cost Allocationは、EKSクラスター上で動作するPodのコストをPodレベルのリソース要求(requests)に基づいて按分する。名前空間・ラベルによる多次元分類を支援し、Kubernetes ネイティブのコスト可視化を実現する。

前提条件と有効化:

EKS Split Cost Allocationには Amazon EKS Node Monitoring Agent のインストールが必要だ。このエージェントがノードレベルのリソース消費データをCURに送信する。

aws eks update-addon \
  --cluster-name my-eks-cluster \
  --addon-name aws-eks-node-monitoring-agent \
  --resolve-conflicts OVERWRITE

EKSのSplit Cost Allocationも Cost Management → Settings → Split cost allocation で有効化する（ECSと同一設定画面）。

Podレベルリソース按分のロジック:

名前空間・ラベルベース分類:

Kubernetes の namespace と label をコストアロケーションタグとして活用できる:

metadata:
  labels:
 app: order-service
 team: platform
 environment: production
 cost-center: "CC-1234"

上記ラベルは EKS Split Cost Allocation で CUR 2.0 の split_line_item_resource_id にタスク名として反映される。Cost Explorer で namespace 軸・label 軸のコスト分析が可能になる。

コントロールプレーンコスト按分:

EKSコントロールプレーンのコスト（$0.10/時・クラスターごと）は Split Cost Allocation でクラスター全体コストとして集計される。複数の名前空間にコントロールプレーンコストを按分したい場合は、Cost Categories の Split Charge ルールを組み合わせて実現する。

Terraform での EKS コストアロケーションタグ有効化:

resource "aws_ce_cost_allocation_tag" "eks_namespace" {
  tag_key = "kubernetes.io/namespace"
  status  = "Active"
}

resource "aws_ce_cost_allocation_tag" "eks_app_label" {
  tag_key = "eks:pod/label/app"
  status  = "Active"
}

resource "aws_ce_cost_allocation_tag" "eks_team_label" {
  tag_key = "eks:pod/label/team"
  status  = "Active"
}

4-3 S3 Split Cost Allocation

S3 Split Cost Allocationは、S3バケット内のコストをプレフィックスレベルで按分する。複数チームが同一バケットを共有する構成（共有データレイク・ログバケット・アーカイブバケット等）でコスト責任を明確化できる。

プレフィックスレベル按分の仕組み:

有効化手順:

S3 Split Cost Allocation は S3 Analytics の Storage Class Analysis を有効化し、プレフィックス単位でコストデータをS3に出力する設定が必要だ:

aws s3api put-bucket-analytics-configuration \
  --bucket my-shared-data-lake \
  --id "team-a-split-cost" \
  --analytics-configuration '{
 "Id": "team-a-split-cost",
 "StorageClassAnalysis": {
"DataExport": {
  "OutputSchemaVersion": "V_1",
  "Destination": {
 "S3BucketDestination": {
"Format": "CSV",
"Bucket": "arn:aws:s3:::my-cost-analytics-bucket",
"Prefix": "s3-cost-split/team-a/"
 }
  }
}
 },
 "Filter": {
"Prefix": "team-a/"
 }
  }'

ストレージクラス別按分:

S3 Intelligent-Tieringや複数ストレージクラスが混在するバケットでは、クラスごとの料金差を考慮した按分が重要だ:

4-4 按分データのCUR 2.0反映と可視化

Split Cost Allocationの全データはCUR 2.0のテーブルに追記される。主要カラム:

Athena での集計クエリ例:

SELECT
  split_line_item_resource_id,
  split_line_item_split_cost_type,
  SUM(split_line_item_split_cost)AS total_split_cost,
  SUM(line_item_usage_amount) AS total_usage
FROM "cost_usage_report"."cur2_data"
WHERE year = '2026'
  AND month = '05'
  AND split_line_item_split_cost IS NOT NULL
GROUP BY 1, 2
ORDER BY total_split_cost DESC
LIMIT 30;

QuickSight では CUR 2.0 の Athena データセットを直接参照し、サービス別・チーム別・プレフィックス別のコスト内訳ダッシュボードを構築できる。Cost Categories と組み合わせることで、FinOpsの Showback（コスト可視化のみ）から Chargeback（各チームへの実費用請求）への移行を実現できる。

AWS Data Exports 本番運用 — CUR 2.0 / S3パーティショニング / Athena / QuickSight

CUR 1.0 から CUR 2.0 への移行

AWS Cost and Usage Report (CUR) は、AWSコスト・使用量データを最も詳細に把握できるレポート機能です。2023年に登場した CUR 2.0 (AWS Data Exports) は従来のCUR 1.0を刷新し、Parquet形式・カラム体系・配信スケジュールが大幅に改善されました。

移行時の注意点: CUR 1.0 と CUR 2.0 はカラム名が部分的に変更されています。例えば lineItem/ProductCode は line_item_product_code に変わります。既存のAthenaクエリはカラム名の全量確認が必要です。

Data Exports 設定 — エクスポート名 / S3バケット / 粒度 / スケジュール

Data Exports の作成は AWS Management Console の Billing から行います。CLI での作成も可能です。

{
  "ExportName": "cur2-daily-parquet",
  "Description": "CUR 2.0 日次 Parquet エクスポート",
  "DataQuery": {
 "QueryStatement": "SELECT * FROM COST_AND_USAGE_REPORT",
 "TableConfigurations": {
"COST_AND_USAGE_REPORT": {
  "TIME_GRANULARITY": "DAILY",
  "INCLUDE_RESOURCES": "TRUE",
  "INCLUDE_SPLIT_COST_ALLOCATION_DATA": "TRUE"
}
 }
  },
  "DestinationConfigurations": {
 "S3Destination": {
"S3Bucket": "my-cur-exports-bucket",
"S3Prefix": "cur2/",
"S3Region": "ap-northeast-1",
"S3OutputConfigurations": {
  "OutputType": "CUSTOM",
  "Format": "PARQUET",
  "Compression": "PARQUET",
  "Overwrite": "OVERWRITE_REPORT"
}
 }
  },
  "RefreshClosedReports": true,
  "ReportVersioning": "OVERWRITE_REPORT"
}

S3バケットポリシー設定例:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "AllowCURServiceRead",
"Effect": "Allow",
"Principal": {"Service": "billingreports.amazonaws.com"},
"Action": ["s3:GetBucketAcl", "s3:GetBucketPolicy"],
"Resource": "arn:aws:s3:::my-cur-exports-bucket",
"Condition": {"StringEquals": {"aws:SourceAccount": "123456789012"}}
 },
 {
"Sid": "AllowCURServiceWrite",
"Effect": "Allow",
"Principal": {"Service": "billingreports.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-cur-exports-bucket/*",
"Condition": {"StringEquals": {"aws:SourceAccount": "123456789012"}}
 }
  ]
}

S3パーティショニング設計 — Hive形式 / Athena最適化

CUR 2.0 は S3 に Hive形式パーティションで配信されます。Athenaクエリのパーティションプルーニングが有効になりクエリコストを削減できます。

s3://my-cur-exports-bucket/cur2/
  ├── year=2026/
  │└── month=05/
  │ └── 20260501-20260601/
  │  ├── cur2-00001.parquet
  │  └── cur2-00002.parquet
  └── assembly-id/
└── manifest.json

Athena外部テーブル定義 (CUR 2.0 Parquet):

CREATE EXTERNAL TABLE IF NOT EXISTS cur2_daily (
  identity_line_item_id  STRING,
  bill_payer_account_id  STRING,
  line_item_usage_account_idSTRING,
  line_item_line_item_type  STRING,
  line_item_usage_start_dateTIMESTAMP,
  line_item_usage_end_date  TIMESTAMP,
  line_item_product_code STRING,
  line_item_usage_typeSTRING,
  line_item_resource_id  STRING,
  line_item_usage_amount DOUBLE,
  line_item_unblended_cost  DOUBLE,
  line_item_blended_cost DOUBLE,
  product_product_nameSTRING,
  product_regionSTRING,
  cost_category_environment STRING,
  cost_category_team  STRING,
  resource_tags_user_projectSTRING,
  split_line_item_parent_resource_id  STRING,
  split_line_item_net_split_usage_amount DOUBLE
)
PARTITIONED BY (year STRING, month STRING)
STORED AS PARQUET
LOCATION 's3://my-cur-exports-bucket/cur2/'
TBLPROPERTIES ('parquet.compression'='SNAPPY');

パーティション追加 (月次運用):

-- 手動追加
ALTER TABLE cur2_daily ADD PARTITION (year='2026', month='05')
LOCATION 's3://my-cur-exports-bucket/cur2/year=2026/month=05/';

-- 全パーティション自動検出
MSCK REPAIR TABLE cur2_daily;

Athenaクエリ最適化 — コスト分析クエリ例

パーティションプルーニングと列指定を組み合わせることで、Athenaの読取データ量を大幅に削減できます。Athenaの料金は スキャンデータ量 $5.00/TB なので、クエリ最適化は直接コスト削減につながります。

サービス別コスト集計 (月次):

SELECT
  line_item_product_codeAS service,
  SUM(line_item_unblended_cost) AS total_cost,
  COUNT(DISTINCT line_item_usage_account_id)AS account_count
FROM cur2_daily
WHERE
  year  = '2026'
  AND month = '05'
  AND line_item_line_item_type NOT IN ('Tax', 'Credit')
GROUP BY line_item_product_code
ORDER BY total_cost DESC
LIMIT 20;

日別コストトレンド (異常検知用):

SELECT
  DATE_FORMAT(line_item_usage_start_date, '%Y-%m-%d') AS usage_date,
  line_item_product_codeAS service,
  SUM(line_item_unblended_cost) AS daily_cost,
  LAG(SUM(line_item_unblended_cost)) OVER (
 PARTITION BY line_item_product_code
 ORDER BY DATE_FORMAT(line_item_usage_start_date, '%Y-%m-%d')
  )AS prev_day_cost
FROM cur2_daily
WHERE
  year  = '2026'
  AND month = '05'
  AND line_item_line_item_type = 'Usage'
GROUP BY
  DATE_FORMAT(line_item_usage_start_date, '%Y-%m-%d'),
  line_item_product_code
ORDER BY usage_date DESC, daily_cost DESC;

QuickSight ダッシュボード — SPICEデータセット / 自動更新

Amazon QuickSightはAthenaをデータソースとして接続し、コスト分析ダッシュボードを構築できます。SPICE にデータを取り込むことで、Athenaへの都度クエリ実行を回避できます。

QuickSight データセット設定:

DataSource:
  Type: ATHENA
  AthenaParameters:
 WorkGroup: cur-analysis-workgroup
 Database: cost_analysis

DataSet:
  ImportMode: SPICE
  RefreshSchedule:
 ScheduleFrequency:
Interval: DAILY
TimeZone: Asia/Tokyo
TimeOfDay: "06:00"

SELECT
  line_item_usage_start_date,
  line_item_product_code,
  line_item_usage_account_id,
  cost_category_environment,
  cost_category_team,
  line_item_unblended_cost
FROM cur2_daily
WHERE
  year = '2026'
  AND month >= '04'
  AND line_item_unblended_cost > 0.01

FOCUS (FinOps Open Cost and Usage Specification) 対応

FocusはFinOps Foundationが策定したクラウドコストデータの標準仕様です。AWSは2024年よりData ExportsでFOCUS形式のエクスポートをサポートしています。

FOCUS vs CUR 2.0 主要カラム対応表:

FOCUS形式エクスポート作成:

{
  "ExportName": "focus-daily-parquet",
  "DataQuery": {
 "QueryStatement": "SELECT * FROM FOCUS_COST_AND_USAGE_REPORT",
 "TableConfigurations": {
"FOCUS_COST_AND_USAGE_REPORT": {
  "TIME_GRANULARITY": "DAILY"
}
 }
  }
}

マルチクラウド環境では、FOCUS形式でAWS/Azure/GCPのコストデータを統一スキーマで集約することで、クロスクラウドFinOps分析が可能になります。

詰まりポイント7選 + アンチパターン→正解パターン変換

詰まり1: Billing Conductor 料金ルール適用順序ミスでマージン計算が狂う

症状: Billing Conductorでマージン設定をしたにもかかわらず、プロフォーマ請求書の金額が計算と一致しない。

原因: Billing Conductorの料金ルールは 適用順序 (Priority) が重要で、複数ルールが競合した場合に後から適用されるルールが上書きします。ディスカウントとマークアップが混在するルール設定で計算順序を誤ると、最終金額が意図と大きく乖離します。

{
  "Rules": [
 {
"Name": "EC2-discount-10pct",
"Type": "DISCOUNT",
"Scope": "SERVICE",
"Service": "Amazon EC2",
"DiscountedValue": 10.0
 },
 {
"Name": "all-services-markup-5pct",
"Type": "MARKUP",
"Scope": "GLOBAL",
"MarkupPercentage": 5.0
 }
  ]
}

{
  "Rules": [
 {
"Name": "EC2-discount-10pct",
"Type": "DISCOUNT",
"Scope": "SERVICE",
"Service": "Amazon EC2",
"DiscountedValue": 10.0,
"Priority": 1
 },
 {
"Name": "all-services-markup-5pct",
"Type": "MARKUP",
"Scope": "GLOBAL",
"MarkupPercentage": 5.0,
"Priority": 2
 }
  ]
}

詰まり2: Cost Categories 分類ルール優先度誤設定で未分類コスト大量発生

症状: Cost Explorerで「未分類 (No category)」または「Other」のコストが全体の20〜30%を占める。

原因: Cost Categoriesのルールは上から順に評価され、最初にマッチしたルールが適用されます。優先度の高い「汎用ルール」が最上位に配置されていると、より具体的なルールが適用される前に汎用ルールがヒットしてしまい、分類精度が低下します。

{
  "Rules": [
 {
"Value": "SharedInfra",
"Rule": {"And": [{"Tags": {"Key": "Environment", "MatchOptions": ["ABSENT"]}}]}
 },
 {
"Value": "ProductionEC2",
"Rule": {
  "And": [
 {"Tags": {"Key": "Environment", "Values": ["production"]}},
 {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon EC2"]}}
  ]
}
 }
  ]
}

{
  "Rules": [
 {
"Value": "ProductionEC2",
"Rule": {
  "And": [
 {"Tags": {"Key": "Environment", "Values": ["production"]}},
 {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon EC2"]}}
  ]
}
 },
 {
"Value": "SharedInfra",
"Rule": {"And": [{"Tags": {"Key": "Environment", "MatchOptions": ["ABSENT"]}}]}
 }
  ]
}

詰まり3: Split Cost Allocation 未有効化でCURに按分データが未反映

症状: ECS/EKSの共有クラスターを使用しているにもかかわらず、CURの split_line_item_* カラムがすべてNULL。

原因: Split Cost Allocationは Management Account (管理アカウント) で明示的に有効化 しないと機能しません。有効化後はCURへの反映まで最大24〜48時間かかります。

{
  "SplitCostAllocationDataEnabled": true
}

{
  "CostAllocationTagsStatus": [
 {"TagKey": "aws:ecs:clusterName", "Status": "Active"},
 {"TagKey": "aws:eks:cluster-name", "Status": "Active"}
  ]
}

詰まり4: CUR 2.0 Parquetカラム名変更でAthenaクエリが壊れる

症状: CUR 1.0 → CUR 2.0 移行後、既存のAthenaクエリがエラー (COLUMN_NOT_FOUND) を返す。

原因: CUR 2.0 では多くのカラム名が変更されています。特に / で区切られた旧形式 (lineItem/ProductCode) が統一された snake_case (line_item_product_code) に変わっています。

-- CUR 2.0 形式 (正解)
SELECT line_item_product_code, SUM(line_item_unblended_cost)
FROM cur2_daily
WHERE year = '2026' AND month = '05'
GROUP BY line_item_product_code;

詰まり5: QuickSight SPICE データ上限超過でダッシュボード更新失敗

症状: QuickSight のデータセット更新が失敗し、「SPICE capacity exceeded」エラーが出る。

原因: SPICE キャパシティはユーザーあたり有限 (Standard版10GB) で、CUR全量を取り込もうとすると上限を超過します。

-- 全カラム全期間を取込 → SPICE上限超過
SELECT * FROM cur2_daily;

SELECT
  line_item_usage_start_date,
  line_item_product_code,
  line_item_usage_account_id,
  cost_category_environment,
  cost_category_team,
  resource_tags_user_project,
  line_item_unblended_cost,
  product_region
FROM cur2_daily
WHERE
  year = '2026'
  AND month >= '01'
  AND line_item_unblended_cost > 0.001

詰まり6: Cost Categories継承値とタグ値の競合で意図しない分類

症状: タグで Environment=production を設定したリソースが、Cost Categoriesで development に分類されてしまう。

原因: Cost Categoriesの Inherited Value ルール が、タグベースのルールより上位に設定されているためです。継承値は親アカウントの属性を取得するため、アカウント名に「dev」が含まれるとタグに関係なく development に分類されることがあります。

{
  "Rules": [
 {
"Value": "Production",
"Rule": {
  "Tags": {"Key": "Environment", "Values": ["production"]}
}
 },
 {
"Type": "INHERITED_VALUE",
"InheritedValue": {
  "DimensionName": "LINKED_ACCOUNT_NAME",
  "DimensionKey": "Environment"
}
 }
  ]
}

詰まり7: Data Exports S3バケットポリシー不備でエクスポート失敗

症状: Data Exportsの設定は完了しているが、S3バケットにファイルが配信されない。エクスポートステータスが「Failed」になっている。

原因: Data Exports（CUR 2.0）は billingreports.amazonaws.com サービスプリンシパルがS3に書き込みます。s3:GetBucketAcl と s3:GetBucketPolicy の読取権限が欠落しているケースが多いです。

{
  "Statement": [
 {
"Effect": "Allow",
"Principal": {"Service": "billingreports.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-cur-bucket/*"
 }
  ]
}

{
  "Statement": [
 {
"Sid": "AllowCURServiceRead",
"Effect": "Allow",
"Principal": {"Service": "billingreports.amazonaws.com"},
"Action": ["s3:GetBucketAcl", "s3:GetBucketPolicy"],
"Resource": "arn:aws:s3:::my-cur-bucket",
"Condition": {"StringEquals": {"aws:SourceAccount": "123456789012"}}
 },
 {
"Sid": "AllowCURServiceWrite",
"Effect": "Allow",
"Principal": {"Service": "billingreports.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-cur-bucket/*",
"Condition": {"StringEquals": {"aws:SourceAccount": "123456789012"}}
 }
  ]
}

FinOps統合アーキテクチャ — Vol1×Vol2×Vol3 三部作統合

sequenceDiagram
 participant Vol1 as Vol1 可視化・予算
 participant Vol2 as Vol2 実行最適化
 participant Vol3 as Vol3 配分・レポート
 participant CE as Cost Explorer
 participant DA as Data Exports
 Vol1->>CE: コスト可視化 + Budget Alert
 Vol2->>CE: RI/Spot/Graviton削減効果反映
 Vol3->>DA: Billing Conductor + Categories + Split Cost
 DA->>CE: 組織横断コストビュー
 Note over Vol1,Vol3: FinOps完全体<br/>Inform → Optimize → Operate

FinOps 3フェーズ統合 — Inform → Optimize → Operate

FinOpsフレームワークは「Inform（情報収集・可視化）」「Optimize（最適化実行）」「Operate（運用・配分）」の3フェーズで構成される。Cost Optimization三部作はこの3フェーズと完全に対応している。

Vol1（Inform）: Cost Explorerで組織全体コストを可視化し、Budgetsで予算アラートを自動発報。Cost Anomaly Detectionで異常支出を即時検知。Compute Optimizerで未活用リソースを特定する。「何にいくら使っているか」「予算オーバーのリスクはどこか」を把握するフェーズ。

Vol2（Optimize）: Vol1で特定した最適化機会に対して実行施策を展開。Reserved Instancesで安定ワークロードを予約購入し、Spot Fleetで割り込み許容ジョブを70-90%削減。Graviton3移行でコンピュートを最大40%効率化。Right Sizing Recommendationsで過剰プロビジョニングを解消する。「どうやって削減するか」を実行するフェーズ。

Vol3（Operate）: Vol1・Vol2の成果を組織横断で配分・管理。Billing Conductorでカスタム請求グループを構築し、Cost Categoriesで事業部門別・プロジェクト別にコストを分類。Split Cost Allocationで共有ECS/EKSクラスターのコストを按分。Data Exports（CUR 2.0）でAthen・QuickSightパイプラインを自動化する。「誰がいくら使ったか」を正確に配分・報告するフェーズ。

日常運用ワークフロー — 日次・週次・月次サイクル

FinOps運用は単発施策ではなく継続的サイクルである。Vol1〜Vol3の各ツールを日次・週次・月次のリズムで運用することで、コスト管理を組織の文化として定着させる。

日次ワークフロー（所要時間: 10〜15分）

09:00  Data Exports自動取り込み確認
 → S3バケットに前日分CUR 2.0ファイルが着信しているか確認
 → Athena自動クエリ実行（Lambda/EventBridgeトリガー）

09:15  Cost Anomaly Detection アラート確認
 → 前日比+20%超の異常コストがあれば即時調査
 → Slack通知またはメール確認

09:30  Budgets残額確認
 → 月次予算の消化率（残り日数と消化率が整合しているか）
 → 超過リスクあれば担当チームへ連絡

週次ワークフロー（所要時間: 30〜60分）

月曜  Cost Categories分類確認
→ 未分類コスト（"Other"カテゴリ）が増加していないか
→ 新サービス・新アカウント追加時は分類ルールを更新

水曜  Split Cost Allocation按分検証
→ ECS/EKSクラスター按分レポートを事業部門別に確認
→ 按分結果に異議があればタグ設定を修正

金曜  RI/Savings Plans利用率確認
→ Reserved Instance利用率が80%未満なら原因調査
→ Savings Plans未利用分の調整検討

月次ワークフロー（所要時間: 2〜4時間）

月初1〜3日  Billing Conductor 請求レビュー
→ 各請求グループの確定請求額を確認
→ カスタム料金ルール（マークアップ/ディスカウント）の適用確認
→ プロフォーマ請求書の差分確認

月初1〜5日  Cost Explorer 月次レポート作成
→ 事業部門別・プロジェクト別コスト集計
→ 前月比・予算比を可視化
→ QuickSightダッシュボードをステークホルダーに共有

月中旬Trusted Advisor確認
→ コスト最適化カテゴリの推奨事項をレビュー
→ 未対応項目をバックログに追加

月末  翌月予算・購入戦略レビュー
→ RI/Savings Plans追加購入の検討
→ 新規プロジェクト・サービスのコスト見積もり
→ FinOpsレビュー会議（経営層・エンジニアリング・財務合同）

Vol1×Vol2×Vol3 統合アーキテクチャ設計のポイント

三部作を統合してFinOps完全体を構築する際の設計原則を整理する。

1. タグ戦略の一元管理

Vol1〜Vol3の全ツールはタグを共通言語として連携する。Cost Explorerのタグフィルター、Cost Categoriesのタグベースルール、Split Cost AllocationのECSタグ按分、Billing Conductorの請求グループ条件、Data Exports（CUR 2.0）のタグカラム——すべてに同一タグスキーマが使われる。

{
  "必須タグ": {
 "Environment": "production | staging | development",
 "CostCenter": "BU-001 | BU-002 | BU-003",
 "Project": "project-alpha | project-beta",
 "Owner": "team-platform | team-backend | team-frontend",
 "ManagedBy": "terraform | cdk | manual"
  },
  "推奨タグ": {
 "Application": "app-name",
 "DataClassification": "public | internal | confidential",
 "AutoShutdown": "true | false"
  }
}

2. データフロー設計

[AWS使用量] → [CUR 2.0 / Data Exports]
 ↓
[S3 (パーティション: year/month/day)]
 ↓
[Glue Crawler → Athena テーブル自動更新]
 ↓
[Cost Categories ← Athenaクエリ結果]
 ↓
[QuickSight ダッシュボード（リアルタイム集計）]
 ↓
[Billing Conductor プロフォーマ請求書生成]
 ↓
[各事業部門 / 顧客 への請求・報告]

3. アラート階層設計

Level 1: Cost Anomaly Detection (即時通知 — 異常検知)
Level 2: Budgets Alert 80% (予防的通知 — 予算消化警告)
Level 3: Budgets Alert 100% (超過通知 — 予算オーバー)
Level 4: カスタムAthenクエリ (定期分析 — 週次/月次レポート)
Level 5: QuickSight異常値検出 (傾向分析 — トレンド警告)

まとめ — Cost Optimization 三部作完成宣言 + 全軸クロスリンク

§8-1: 4サービス要点まとめ表

本記事で解説した4つのAWSサービスの要点を整理する。各サービスが担う役割・主なユースケース・注意点を一覧で把握することで、自組織への導入検討を効率化できる。

4サービス連携の全体像

• Billing Conductor がカスタム請求グループを定義し、顧客・事業部門ごとの「請求ビュー」を生成する
• Cost Categories がタグ・アカウント・サービス条件に基づいてコストを自動分類する
• Split Cost Allocation が共有コンテナ環境のコストをプロポーショナルに按分する
• Data Exports が全コストデータをS3に出力し、Athena/QuickSightで分析・レポート化する

4サービスを組み合わせることで「誰が・どのリソースで・どれだけ使ったか」を組織横断で正確に把握し、配分・請求・報告の全サイクルを自動化できる。

三部作のサービス全体まとめ

§8-2: 全軸クロスリンク

Cost Optimization三部作は、AWS本番運用シリーズの中でも特に横断的な位置付けを持つ。コストは全サービス・全ワークロードに影響するため、他の軸記事との連携が欠かせない。

Monitoring and Observability との連携

コストの異常検知（Cost Anomaly Detection）とシステム障害の相関分析には、監視基盤との連携が有効だ。CloudWatch Metricsのコストメトリクス・EventBridgeによるコストイベント連携・Lambda自動対応など、ObservabilityとFinOpsは表裏一体の関係にある。

Multi-Account / Organizations との連携

Billing ConductorやCost Categoriesを最大限活用するにはAWS Organizations構成が前提だ。管理アカウント・メンバーアカウントのSCP設計・OU構成・タグポリシーとFinOps設計は密接に連携する。マルチアカウント本番運用シリーズで解説したOrganizations設計のベストプラクティスはVol3実装に直接適用できる。

ECS / EKS コンテナ基盤との連携

Split Cost AllocationのECS/EKS按分を正確に機能させるにはコンテナ基盤のタグ戦略が決定的に重要だ。ECSタスク定義・EKS Podのラベル・Helm values.yamlへのタグ付与設計をコンテナ本番運用シリーズと合わせて確認することを推奨する。

データ分析基盤（Athena / QuickSight）との連携

Data Exports（CUR 2.0）のS3出力をAthenaでクエリし、QuickSightで可視化するパイプラインは、データ分析基盤全般のベストプラクティスと共通する。Glue Data Catalog設計・Athenaクエリ最適化・QuickSightデータセット管理は、データ分析本番運用シリーズと組み合わせて深化できる。

ガバナンス / コンプライアンス との連携

Cost Categories・Data Exportsで生成したコストレポートは、コンプライアンス監査・内部統制の証跡としても活用できる。AWS Config・CloudTrailとの組み合わせで「誰が・何を・いつ・いくら使ったか」の完全な監査ログを構築できる。

タグポリシーと Organizations の連携

Cost Categories・Split Cost Allocationはタグ依存度が高い。Organizations Tag Policyを使えばタグキーの標準化（大文字小文字・スペル統一）を組織レベルで強制できる。また、SCPでタグなしリソース作成を禁止することでタグ漏れを構造的に防止できる。

AWS Trusted Advisorとの連携

Trusted Advisorのコスト最適化カテゴリは、Vol2で実施したRight Sizing・RI活用の結果を定量評価できる。未使用Elastic IP・アイドルロードバランサー・低利用EC2インスタンスの検出をTrusted Advisorに任せ、Cost Explorerで影響額を確認し、Vol2の手法で対処するサイクルが実践的だ。

§8-3: 三部作完成宣言 + シリーズ展望

今後のシリーズ展望

Cost Optimization三部作の完成を受け、次のテーマとしてFinOpsの発展的トピックが候補に挙がる。

• FinOps KPI管理: コスト削減率・RI利用率・タグカバレッジ率・予算達成率など、組織のFinOps成熟度を定量化する指標設計
• マルチクラウドFinOps: AWS + Azure + GCPの横断コスト管理の統合分析
• AI/ML ワークロードのコスト最適化: SageMaker・Bedrock・GPU EC2インスタンスの特性に合わせた最適化戦略
• FinOps自動化: EventBridge + Lambda + Cost Explorer APIによるコスト最適化アクションの完全自動化

FinOps成熟度セルフチェック表

自組織のFinOps成熟度を三部作の軸で自己評価してみよう。「できている」項目にチェックを入れ、現在地を把握する。

§8-4: 読者アクションリスト

本記事で学んだ内容を実際の環境に適用するための具体的なアクションリストを示す。優先度・難易度の目安と合わせて確認されたい。

即日実行できるアクション（難易度: 低）

• [ ] Cost Allocation Tags有効化（AWSコンソール → Billing → Cost allocation tags）
• [ ] Cost Anomaly Detection有効化（モニター1つ作成 + SNSアラート設定）
• [ ] タグ戦略ドキュメント作成（Environment / CostCenter / Project / Owner の4タグ最低限）
• [ ] Cost Explorerで過去3ヶ月のコスト傾向を確認し、最大コスト上位5サービスを特定
• [ ] Trusted Advisorのコスト最適化カテゴリをチェックし、未対応推奨事項を一覧化

1〜2週間で実装できるアクション（難易度: 中）

• [ ] Cost Categories基本ルール設計（事業部門別 or プロジェクト別の分類ルール3〜5個）
• [ ] Data Exports（CUR 2.0）設定 + S3バケット作成 + Glue Crawler設定
• [ ] Athena基本クエリセット作成（月次コスト集計・サービス別コスト・アカウント別コスト）
• [ ] ECS/EKSタグ付与漏れ調査（未タグリソース一覧をCost Explorerで確認）
• [ ] Organizations Tag Policyで必須タグキーを標準化（大文字小文字・スペル統一）

1〜3ヶ月で実装できるアクション（難易度: 高）

• [ ] Billing Conductor請求グループ設計・構築（MSP/社内IT部門でカスタム請求が必要な場合）
• [ ] Split Cost Allocation有効化（ECS/EKSクラスターで共有リソース按分が必要な場合）
• [ ] QuickSightダッシュボード構築（月次FinOpsレポートの自動化）
• [ ] 月次FinOpsレビュープロセス確立（ステークホルダー・議題・KPI設定）
• [ ] コスト最適化バックログ作成（Trusted Advisor推奨事項 + Right Sizing候補一覧）
• [ ] SCPでタグなしリソース作成を禁止するポリシー導入検討

継続的に実施するアクション

• [ ] 週次: Cost Categories未分類コスト（Other）確認 + ルール更新
• [ ] 週次: Split Cost Allocation按分レポート確認 + タグ漏れ修正
• [ ] 月次: RI/Savings Plans利用率確認（目標: 80%以上）
• [ ] 月次: Billing Conductorプロフォーマ請求書レビュー
• [ ] 月次: QuickSightダッシュボードを経営層・財務チームに共有
• [ ] 四半期: FinOps成熟度評価 + 次四半期の優先施策決定

§8-5: 参考リンク集 + CTA

AWS Billing Conductor 公式ドキュメント

AWS Cost and Usage Report 2.0 公式ドキュメント

Cost Optimization本番運用Vol1 — Cost Explorer / Budgets / Savings Plans / Compute Optimizer

Cost Optimization本番運用Vol2 — RI / Spot Fleet / Graviton / Right Sizing

Cost Optimization三部作 完結。

Vol1（可視化）→ Vol2（最適化実行）→ Vol3（配分・統合）の3ステップで、AWSコスト管理の全体像を完全網羅した。本シリーズが、マルチアカウントAWS環境でFinOps実践に取り組む全てのCloud Architect・FinOps Practitionerの実務に貢献できることを願っている。

本記事で得られた3つの核心

1. Billing Conductor — 組織横断のカスタム請求グループと料金ルールにより、MSP・社内IT部門が顧客・事業部門ごとに独立した請求書を発行できる基盤を構築した。プロフォーマ請求とマージン管理で、コストの配分精度を飛躍的に向上できる。

2. Cost Categories + Split Cost Allocation — タグ・アカウント・サービス横断の自動分類ルールと、ECS/EKSコンテナ共有リソースの使用量ベース按分により、手動スプレッドシート管理からの完全脱却が実現できる。チャージバック体制の自動化がFinOps文化定着の鍵だ。

3. Data Exports（CUR 2.0）パイプライン — S3 → Glue → Athena → QuickSightのデータ分析基盤により、Cost Explorer UIの限界を超えた全社横断コスト分析が可能になる。Parquet形式・自動パーティショニングでクエリコストを最小化しながら、リアルタイムに近い更新サイクルを実現できる。

三部作で描いた「Inform → Optimize → Operate」のFinOpsサイクルを、自組織の規模・ステージに合わせて段階的に実装されたい。FinOps成熟度の「Crawl」から「Run」への道のりは、一夜で完成するものではない。しかし、正しい設計と継続的なサイクルがあれば、必ず到達できる。

AWS本番運用シリーズは第24軸以降も継続予定。次のテーマをお楽しみに。

関連記事・シリーズ一覧

本記事が役に立ったと感じたら、ぜひ同シリーズのVol1・Vol2も合わせてお読みいただきたい。三部作を通読することで、FinOpsの全体像がより鮮明に理解できるはずだ。