AWS Cost Categories入門｜プロジェクト・環境・チーム別にクラウドコストを自動分類するFinOps実践ガイド

AWSでクラウドコストを管理しようとすると、必ずといっていいほど壁にぶつかる。「EC2にタグを付けているが、ネットワーク転送料金やSupport費用はタグで分類できない」「複数のAWSアカウントをまたいでプロジェクトごとの費用を合算したい」「開発・本番の環境コストを各チームに按分したいが、Cost Explorerのタグ集計では難しい」といった問題だ。

コスト配分タグだけで解決しようとすると、全リソースへのタグ付けを完璧に維持しなければならない。タグを付け忘れたリソースの費用は「Untagged」として宙に浮き、月次の部門別コスト報告が不正確になる。

AWS Cost Categoriesは、このような課題を解決するために設計されたコスト分類エンジンだ。タグの有無に関わらず、アカウント・サービス・タグ・リンクアカウントなどの複数条件をルールで組み合わせて費用を自動分類し、共有コストの按分まで一元管理できる。

この記事では、AWS Cost Categoriesの仕組みと作成手順、Split Charge Rulesによる共有コスト按分の設定方法、そしてAWS BudgetsやCost Explorerとの活用シナリオを実践的に解説する。

AWS Cost Categoriesとは何か

AWS Cost Categoriesは、AWS Cost Explorerのコンソールから設定できるコスト分類サービスだ。独自のルールエンジンを使ってAWSのコスト・使用量データを任意のカテゴリに振り分け、Cost Explorer・AWS Budgets・CURのレポートに反映させる。

オンプレミス時代に使っていた費用管理の考え方で言えば、「部門コードでの仕訳」に近い。AWSリソースがどのアカウント・サービス・タグを持っていても、定義したルールに従って自動的にカテゴリへ分類してくれる。

コスト配分タグとの根本的な違い

コスト配分タグはリソース1つ1つにキーと値を付けて費用を分類するもので、タグが付いていないリソースは集計から漏れる。一方、Cost Categoriesは以下の点で上位互換の機能を持つ。

Cost Categoriesの仕組み

Cost Categoriesは「カテゴリ名」と「値（Value）」の2層構造で成り立っている。

・カテゴリ名: 分類の軸（例：Department、Project、Environment）
・値（Value）: カテゴリ内の分類先（例：Development、Production、Shared）
・ルール: 各Valueに費用を振り分けるための条件（Dimension + 条件式）
・Default Value: どのルールにも当てはまらないコストの受け皿

Cost Categoriesが参照できるDimension（分類軸）は次の通りだ。

・Service: Amazon EC2・Amazon S3など、AWSサービス単位
・Linked Account: AWSアカウントID（マルチアカウント管理に有効）
・Tag: コスト配分タグの値
・Cost Category: 別のCost Categoryの値（ネスト可能）
・Charge Type: Usage・Tax・Support・Creditなど料金の種類
・Region: AWSリージョン
・Usage Type Group: データ転送・リクエスト数など使用量の種類

ルールは上から順に評価され、最初に一致したルールのValueに費用が振り分けられる。優先度はルールの並び順で決まるため、より具体的な条件を上位に置くのが設計のコツだ。

Cost Categoriesの作成手順

1. Cost Explorerを開く

AWSマネジメントコンソールにサインインし、「AWS Cost Management」→「Cost Explorer」に移動する。左ペインの「Cost categories」を選択し、「Create cost category」をクリックする。

2. カテゴリ名と分類ルールを設定する

「Category name」に管理しやすい名称を入力する（例：`ProjectCode`）。続いて「Define rules」で各Valueとルールを追加する。

実務でよく使うルールの設計例を示す。

# カテゴリ名: ProjectCode
# Value 1: alpha-project
#   条件: Tag(project) = alpha-project
#      OR Linked Account = 123456789012（alpha専用アカウント）
#
# Value 2: beta-project
#   条件: Tag(project) = beta-project
#      OR Linked Account = 234567890123（beta専用アカウント）
#
# Value 3: shared
#   条件: Service = AWS Support
#      OR Service = AWS Marketplace
#      OR Linked Account = 345678901234（共有インフラアカウント）
#
# Default Value: unclassified
#   → 上記ルールに当てはまらなかった費用の受け皿

「Add rule」ボタンで条件を追加し、AND/OR条件を切り替えながら複数の条件を組み合わせる。タグが付いているリソースと、アカウント単位でしか管理できないリソース（Support、Marketplace等）を同一Valueにまとめられる点がコスト配分タグにはない強みだ。

3. Default Valueを設定する

「Default value」には「unclassified」や「other」など、ルールに当てはまらなかった費用の受け皿となる値を設定する。これを設定しておくことで、タグ付け忘れのリソース費用も漏らさず集計できる。Default Valueに集まった費用を定期的に確認してルールを追加することで、徐々に分類精度を上げていける。

4. 作成後の反映タイミング

Cost Categoriesの設定は即時保存されるが、Cost ExplorerやBudgetsへのデータ反映には最大24時間のラグがある。遡及適用は過去12か月分まで対応しており、翌月初めから完全に反映された状態になる。月の途中で作成した場合は当月分が部分的な適用になるため、月初に設定するのが理想だ。

Split Charge Rules（共有コスト按分）の設定

「AWS Enterprise Support」「共有NATゲートウェイ」「全チームが使うセキュリティ監視アカウントの費用」など、特定チームだけに帰属しないコストを各Value（チーム・プロジェクト）に分配する機能がSplit Charge Rulesだ。

Split Charge Rulesの3つの按分方法

・均等（Even）: Targets内のValueに均等に按分する（2チームなら各50%）。シンプルだが費用規模の差があるチームには不公平になりやすい
・比率（Proportional）: Sourceではなく、Targetsの直接費用比率に応じて按分する。費用が多いチームにより多くの共有コストを負担させるFinOps原則に近い方法
・固定比率（Fixed）: 各Targetに手動で按分比率（%）を指定する。事前に合意した固定比率がある場合に使う

# Split Charge Rules 設定例（按分方法: Proportional）
# Source:  shared（AWS Support + 共有インフラアカウント費用）
# Targets: alpha-project, beta-project
#
# 当月の直接費用
#   alpha-project: $8,000
#   beta-project:  $2,000
#   合計:          $10,000
#
# shared の費用が $1,000 の場合
#   alpha-project へ按分: $1,000 × (8,000 / 10,000) = $800
#   beta-project  へ按分: $1,000 × (2,000 / 10,000) = $200

AWS Budgetsと組み合わせたアラート設定

Cost Categoriesで分類したValueは、AWS Budgetsでの予算設定に使えるようになる。たとえば「ProjectCode = alpha-project の月額が $10,000 を超えたらアラートを送る」という設定が可能だ。

さらにAWS Budget Actionsと組み合わせれば、閾値超過時に自動でIAMポリシーを適用してリソースのプロビジョニングを制限するといった自動制御も実現できる。

また、AWS Cost Anomaly Detectionでは、Cost Categoryの値をモニター対象として設定できるため、プロジェクト別・チーム別にコスト異常を検知できるようになる。「先月と比べてalpha-projectのコストが急増している」といった異常を自動検知してアラートを受け取れる。

料金の仕組み

AWS Cost Categories自体の利用は無料だ（2026年9月時点）。ただし以下の制限がある。

・最大カテゴリ数: Organizationsの管理アカウントにつき50カテゴリ
・最大Value数: 1カテゴリあたり500値
・最大ルール数: 1カテゴリあたり100ルール
・遡及適用: 過去12か月分まで
・反映ラグ: 設定変更後、最大24時間

組織全体でのコスト集計を行う場合は、AWS Organizations管理アカウントから設定を行い、メンバーアカウントのデータも一元的に取り込む。

FinOps実践での活用パターン

FinOps実践においてCost Categoriesが最も威力を発揮するのは、「チャージバック（Chargeback）」と「ショーバック（Showback）」の設計だ。

ショーバックは、各チームに自分たちのクラウドコストを可視化させる仕組みで、請求は一元管理のまま行う。Cost Categoriesで分類し、Cost Explorerの閲覧権限を各チームのIAMユーザーに付与することで実現できる。チームが自分のコストを把握することで、無駄なリソースの積極的な削除やスポットインスタンスの活用など、コスト意識が高まる。

チャージバックは、実際に部門や子会社に費用を按分請求する仕組みだ。Split Charge Rulesで共有コストまで含めた正確なコストを算出し、月次レポートをCUR（Cost and Usage Report）から抽出して経理部門に連携する。

既存のコスト配分タグとの使い分けのポイントは明確だ。タグは「リソース単位の細かい追跡」に使い、Cost Categoriesは「プロジェクト・部門・環境といった集計軸の定義」に使うのが現場のベストプラクティスだ。両者を組み合わせることで、Cost Categoriesのルール内でタグを条件として参照しながら、タグのない費用（Support・Marketplace等）を Default Valueで補完する設計が実現できる。

よくあるトラブルと対処法

「設定したのにCost Explorerに反映されない」
Cost Categoriesの設定変更はリアルタイムではなく最大24時間のラグがある。翌日のデータを確認するまで待つこと。月次レポートの作成が急ぐ場合は、CURのデータをS3経由でAthenaに取り込んで手動で集計する方法もある。

「過去のデータにカテゴリが反映されていない月がある」
Cost Categoriesを月の途中で作成した場合、当月分は作成日以降の費用にのみ適用される。完全な月次データが揃うのは翌月以降になる。遡及データは過去12か月分まで再処理されるが、当月の月初分は遡及されない点に注意する。

「Default Valueに大量のコストが集まってしまう」
ルールの条件が不足しているサインだ。Cost ExplorerでDefault Valueの内訳を確認し、どのサービス・アカウント・タグが未分類になっているかを特定してルールを追加する。AWS Cost Optimization Hubと組み合わせて未タグリソースの一覧を確認するのも有効だ。

「Split Charge RulesでSourceが$0の月に按分結果がおかしい」
Sourceのコストが$0の場合、Proportional按分はゼロ除算にならず単純に$0が按分される。挙動は問題ないが、月次レポートで按分値が0になる点を事前に経理担当へ説明しておくと混乱を防げる。

本記事のまとめ

AWS Cost Categoriesは、タグ管理だけでは解決できないクラウドコスト分類の課題を解決するFinOpsの要となるサービスだ。

・タグなしリソースの処理: Default Valueで漏れなく集計できる
・複数条件での分類: アカウント・サービス・タグをAND/OR条件で組み合わせ可能
・共有コストの按分: Split Charge Rulesで均等・比率・固定比率を選択できる
・Budgets連携: Value単位の予算アラートとBudget Actionsによる自動制御が可能
・費用: 無料（最大50カテゴリ・100ルール）

コスト配分タグを「リソース追跡」に使い、Cost Categoriesを「集計軸の定義」に使う2層構造で設計することで、マルチアカウント環境のチャージバック・ショーバックを正確に実現できる。月次のコスト報告に「タグ漏れ」や「按分計算の手作業」が残っているなら、Cost Categoriesの導入を検討してほしい。