AWS Cost and Usage Report (CUR)

解決する課題

Cost Explorer のダッシュボードは傾向把握に向く一方、集計済みのため「どのリソースが、どの時間帯に、どの料金体系で、いくら課金されたのか」という行レベルの精緻な分析には向きません。割引や前払いの按分、複数アカウントをまたぐ部門別の配賦、独自ロジックでのチャージバックといった要件では、加工前の明細データが必要になります。

AWS Cost and Usage Report (CUR) は請求情報を最も詳細な粒度で出力し、次のような価値を提供します。

• 使用量と費用を行レベル・時間単位で出力し、リソース単位の内訳まで追える
• レポートを S3 に定期出力し、Athena・Redshift・各種 BI ツールから SQL で分析できる
• リザーブドインスタンスや Savings Plans の割引・償却の内訳を明細として確認できる
• コスト配分タグやアカウントを軸に、独自の按分・配賦ロジックを組み立てられる

主要概念と用語

• CUR（Cost and Usage Report）: AWS が提供する最も詳細な請求明細レポート。使用量と費用を行レベルで S3 に出力する
• CUR 2.0（Data Exports）: 新しい出力の枠組みである Data Exports から作成する標準的なデータエクスポート。従来の CUR を置き換える位置づけ
• レポート定義: 出力先 S3 バケット、含める項目、粒度、フォーマットなどを定めた設定
• 粒度（Granularity）: 集計の時間単位。時間・日次・月次などを選べ、時間単位が最も細かい
• 行レベルデータ: 1 つの利用イベントや課金項目を 1 行で表したレコード。リソース ID や料金体系の列を持つ
• コスト配分タグ: リソースに付けたタグをコスト分析の軸として有効化したもの。CUR の列として現れ、按分の鍵になる
• 償却コスト（Amortized Cost）: 前払いやコミットメント割引を利用期間に按分して表した費用。CUR では非ブレンド・ブレンド・償却などの費用列が用意される
• リソース ID 付き出力: 各行に課金対象のリソース識別子を含めるオプション。リソース単位の深掘りに必須

仕様・制限・クォータ

• 出力先は利用者が用意した S3 バケットで、AWS が書き込めるようバケットポリシーを設定する必要がある
• 出力フォーマットは Parquet や CSV などから選べ、クエリ用途では列指向の Parquet が分析効率に優れる
• 粒度は時間・日次・月次を選択でき、時間単位は行数が大きくなるため保存・クエリのコストを意識する
• レポートは定期的に更新され、当月分は確定までの間に内容が複数回上書きされることがある
• リソース ID やコスト配分タグなどの列は有効化してから出力に反映されるため、過去分にさかのぼってすべてが埋まるわけではない
• 1 アカウントあたりのレポート定義数などにクォータがある。具体的な上限値は変動しうるため、最新の公式ドキュメントで確認する

内部の仕組み

CUR は請求・課金パイプラインで生成された明細データを、利用者が指定した S3 バケットへ定期的に書き出す仕組みです。利用者がエージェントを入れたり集計基盤を構築したりする必要はありません。

• AWS 側で集計した行レベルの請求データを、レポート定義に従って整形し S3 に配置する
• 当月のデータは確定前のため、同じ期間のファイルが日次などで更新・上書きされる。月が締まると最終的な内容に確定する
• リソース ID やコスト配分タグを有効にしていると、各行に対応する列が追加される
• Athena 連携を有効にすると、出力に合わせてテーブル定義やパーティションを更新する仕組みが用意され、クエリ可能な状態を保てる

設計パターン / ベストプラクティス

• Parquet と時間粒度の選択: 大規模分析では列指向の Parquet を選び、必要な粒度を見極めてクエリ効率と保存コストを両立する
• タグ設計の前倒し: チーム・環境・プロジェクトのコスト配分タグを早期に整備し、按分や配賦の軸を CUR の列として使えるようにする
• Athena でのクエリ基盤: CUR を Athena でクエリできるようにし、必要に応じて QuickSight などの BI で可視化する
• 集約アカウントへの一元出力: 組織で複数アカウントを運用する場合は、管理アカウント側で連結請求の CUR を出力し、横断的に分析する
• ライフサイクル管理: 古いレポートファイルは S3 のライフサイクルルールで安価なストレージへ移行・削除し、保存コストを抑える
• 役割分担の明確化: 傾向把握や予算管理はそれぞれ専用ツールに任せ、CUR は行レベルの精緻な分析・配賦に使い分ける

運用・監視

• 出力先 S3 のオブジェクト更新を確認し、レポートが想定どおり定期的に届いているかを監視する
• Athena 連携を使う場合は、新しい月のパーティションが認識されているか、テーブル定義が最新かを定期的に点検する
• 月次のコストレビューでは、CUR をもとにした配賦結果を関係部門と突き合わせ、按分ロジックのズレを早期に補正する
• レポートのスキーマ（列構成）は機能追加で変わりうるため、新しい列の追加に耐えられるクエリやパイプラインにしておく
• 当月の暫定データと確定後データの違いを運用ルールとして明文化し、レポートの基準時点を関係者で揃える

コスト

CUR の生成自体に対する直接の利用料は基本的にかかりませんが、出力先の S3 や分析に使うサービスの費用が関わります。利用形態に応じて総コストを見積もります。

• レポートを保存する S3 のストレージ・リクエスト費用が発生する。時間粒度や Parquet 以外の選択で行数・サイズが増えると影響が大きい
• Athena でのクエリはスキャン量に応じて課金されるため、パーティションや列指向フォーマットでスキャン範囲を絞ると費用を抑えられる
• Redshift や QuickSight など他サービスで分析・可視化する場合は、それぞれの料金体系が加算される

セキュリティ

• 出力先 S3 バケットには AWS が書き込むためのバケットポリシーが必要だが、外部への公開は避け、アクセスは必要な範囲に限定する
• CUR には課金やリソース構成に関する機微情報が含まれるため、閲覧・クエリできる利用者を IAM の最小権限で統制する
• バケットの暗号化（保管時の暗号化）を有効にし、転送経路も保護する
• 組織で連結請求の CUR を扱う場合、メンバーアカウントの支出明細が含まれるため、アクセス範囲を組織のポリシーに沿って設計する
• 請求情報へのアクセス自体をアカウント設定で管理し、コスト管理機能を使える利用者を限定する

関連サービス・比較

コスト管理でよく対比されるのが AWS Cost Explorer です。Cost Explorer は集計済みデータの可視化と傾向分析が主目的、CUR は行レベルの明細出力による精緻な分析・配賦が主目的、という役割の違いを押さえます。

ハンズオン / CLI例

# Data Exports（CUR 2.0）で作成済みのエクスポート定義を一覧する
aws bcm-data-exports list-exports

# 特定エクスポートの定義（出力先や対象テーブルなど）を確認する
aws bcm-data-exports get-export \
  --export-arn <エクスポートのARN>

# 従来の Cost and Usage Report の定義一覧を確認する
aws cur describe-report-definitions

# CUR を出力した S3 バケットの内容を確認する（出力プレフィックス配下）
aws s3 ls s3://<出力先バケット名>/<プレフィックス>/ --recursive