AWSの請求額をサービス別に眺めるだけならCost Explorerで十分です。ところが「このプロジェクトタグの費用を、リソースIDの単位で、毎月自動で集計したい」となった途端、画面操作では追いつかなくなります。そこで使うのがCUR（Cost and Usage Report）です。この記事では2026年9月30日時点のAWS公式ドキュメントをもとに、現行の出し方であるData ExportsのCUR 2.0を、CLIで作成してAthenaで集計するまでを手順として示します。画面での可視化はCost Explorerの仕組みと使いどころを扱った記事に譲ります。
まとめ：CURはData ExportsのCUR 2.0で出しAthenaで集計するのが現行の型
先に結論です。いまCURを新しく作るなら、旧来の「Cost and Usage Reports」画面ではなく、Billing and Cost ManagementのData ExportsからCUR 2.0を選びます。AWS公式のData Exportsの概要は、CUR 2.0を詳細なコストと使用量のデータを受け取る「新しく推奨される方法」と位置づけています。
作業は3段です。S3バケットにData Exports用のポリシーを付ける、aws bcm-data-exports create-export でエクスポートを作る、届いたParquetをAthenaのテーブルにしてSQLで集計する。注意点は、粒度やリソースIDの有無といったテーブル設定が作成後に変えられないことです。ここだけは最初に決め切る必要があります。
CURとは何かとCost Explorerでは足りなくなる明細単位の分析の境目
CURは、AWSの利用料金を明細行の単位でS3に書き出すレポートです。旧CURの公式説明は、これを「利用可能な最も包括的なコストと使用量のデータ」と表現しています。1行が「どのアカウントの、どのサービスの、どの使用タイプを、いつ、いくら使ったか」を表し、時間・日・月の粒度を選べます。
Cost Explorerで済む分析とCURが要る分析の違い
Cost Explorerはグラフと表で集計済みの値を見る道具で、サービス別やタグ別の推移なら画面で完結します。CURが要るのは、集計の軸を自分で決めたいときです。たとえばリソースIDごとの費用、社内の按分ルールに沿った部門別の請求、BIツールや社内システムへの取り込みがそれに当たります。生の明細を持つ以上、どんな切り口でも後から作れる。この自由度が、S3とAthenaを用意する手間と引き換えになります。
CURの料金はS3の保存料とAthenaのスキャン料で決まる
CURの費用を決めるのは、置き場所と読み方の2つです。S3バケットの設定を説明した公式ページは、エクスポートの保存にはS3の標準料金がかかると明記しています。集計のたびにAthenaのスキャン量課金も乗るため、Parquet形式と請求期間のパーティションで読む量を絞るのが前提です。スキャン量の数え方はAthenaの料金を費目ごとに分解した記事で扱っています。
旧CURとCUR 2.0の違い：固定スキーマ・ネスト列・SQLによる列の絞り込み
古い記事の手順どおりに進めると、旧CURを作ってしまいがちです。公式の移行ガイドが挙げる違いを表にまとめます。
| 観点 | CUR 2.0 | 旧CUR |
|---|---|---|
| スキーマ | 列が固定 | 利用状況で月ごとに変動 |
| 出力内容の指定 | SQLで列選択と行の絞り込み | 不可 |
| タグの持ち方 | resource_tags列にキーと値で格納 | タグごとに別の列 |
| 追加の列 | アカウント名の列など | なし |
| 出力形式 | ZIP・GZIP・Parquet | ZIP・GZIP・Parquet |
実装への効き目が大きいのはスキーマの固定です。旧CURはタグを1つ有効にするたびに列が増え、翌月からAthenaのテーブル定義とずれました。CUR 2.0では resource_tags、cost_category、product、discount の4列がキーと値の組で中身を持つため、列そのものは増えません。旧CURの resource_tags_user_creator は、CUR 2.0では resource_tags 列の user_creator キーに入ります。
Data Exportsが出せる5種類のテーブルとFOCUSの位置づけ
Data ExportsのテーブルはCUR 2.0だけではありません。公式の概要ページは、標準エクスポートの表として、CUR 2.0、Cost Optimization Hubのコスト削減推奨、FOCUS 1.2、FOCUS 1.0、炭素排出量を挙げています。FOCUSは複数クラウドの請求データを共通の列名で扱うための仕様で、AzureやGoogle Cloudの明細と並べて集計する組織ならこちらが候補です。AWSだけを細かく見るなら、列の多いCUR 2.0が向いています。
S3バケットポリシーからcreate-exportまでCLIでCUR 2.0を出力する手順
ここから手を動かします。コンソールのData Exports画面でも作れますが、CLIで書いておくと設定がコードとして残り、別アカウントへの展開も楽になります。
手順1：Data Exportsが書き込めるS3バケットポリシーを付ける
公式が必須とするポリシーは次の形です。bcm-data-exports.amazonaws.com に s3:PutObject だけを許し、送信元アカウントを条件で縛ります。SourceArn のリージョンが us-east-1 で固定されている点に注意してください。バケットを東京リージョンに置いても、エクスポート自体はus-east-1のリソースとして作られます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnableAWSDataExportsToWriteToS3",
"Effect": "Allow",
"Principal": {"Service": ["bcm-data-exports.amazonaws.com"]},
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::example-cur-bucket/*",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:bcm-data-exports:us-east-1:111122223333:export/*"
},
"StringEquals": {"aws:SourceAccount": "111122223333"}
}
}
]
}
このポリシーは書き込みだけを許すもので、AWS側に読み取りや削除の権限は与えません。作成後にポリシーやバケットの所有者を変えると配信が止まり、コンソールには「Invalid bucket」が出ます。
aws s3api put-bucket-policy \
--bucket example-cur-bucket \
--policy file://cur-bucket-policy.json
手順2：create-exportでCUR 2.0のエクスポートを作成する
エクスポートの定義は、SQL文とテーブル設定と出力先の3つで決まります。CLIリファレンスのcreate-exportに沿って、日次粒度・リソースIDあり・Parquetの例を示します。
aws bcm-data-exports create-export --region us-east-1 --export '{
"Name": "cur2-daily",
"DataQuery": {
"QueryStatement": "SELECT bill_billing_period_start_date, line_item_usage_account_id, line_item_usage_account_name, line_item_product_code, line_item_line_item_type, line_item_usage_start_date, line_item_resource_id, line_item_unblended_cost, resource_tags, product FROM COST_AND_USAGE_REPORT",
"TableConfigurations": {
"COST_AND_USAGE_REPORT": {
"TIME_GRANULARITY": "DAILY",
"INCLUDE_RESOURCES": "TRUE",
"INCLUDE_SPLIT_COST_ALLOCATION_DATA": "FALSE"
}
}
},
"DestinationConfigurations": {
"S3Destination": {
"S3Bucket": "example-cur-bucket",
"S3Prefix": "cur",
"S3Region": "ap-northeast-1",
"S3OutputConfigurations": {
"OutputType": "CUSTOM",
"Format": "PARQUET",
"Compression": "PARQUET",
"Overwrite": "OVERWRITE_REPORT"
}
}
},
"RefreshCadence": {"Frequency": "SYNCHRONOUS"}
}'
SQLで書けるのは SELECT、FROM、WHERE、LIMIT だけです。公式のデータクエリの説明によれば、ネスト列の中身は product.from_location のようにドットで取り出せ、AS で列名も変えられます。一方で SUM や GROUP BY は使えません。Data Exportsの側は「どの列と行を出すか」を決める場所で、集計はAthenaでやります。
手順3：S3に届くParquetファイルの配置とマニフェストの中身を確認する
公式の配信仕様では、データは data/BILLING_PERIOD=YYYY-MM/ の下に請求期間ごとに置かれ、同じ期間の更新は上書きされます。更新は少なくとも1日1回。請求期間が終わった後も2週間以内に前月分が書き換わる場合があります。初回配信について、AWSのCloud Intelligence Dashboardsの導入手順は通常24時間ほど、長いと72時間かかるとしています。作成直後にバケットが空でも慌てる必要はありません。
aws s3 ls s3://example-cur-bucket/cur/cur2-daily/ --recursive
# cur/cur2-daily/data/BILLING_PERIOD=2026-09/cur2-daily-00001.snappy.parquet
# cur/cur2-daily/metadata/BILLING_PERIOD=2026-09/cur2-daily-Manifest.json
どのファイルを読むべきかは Manifest.json に一覧があり、公式もファイル名を決め打ちせずマニフェストから取得する方法を推奨しています。データが減った月は余った分割ファイルが空で上書きされるため、ファイル数を固定で数える処理は誤集計の元になります。
Athenaでテーブルを作りサービス別・タグ別のコストを集計するSQL例
届いたParquetをAthenaで読みます。公式の処理手順は、Parquet形式と上書き設定で出力し、Glueクローラを data フォルダに向けてテーブルを作る方法を示しています。Athena自体の使い方はAthenaの仕組みとクエリの書き方を参照してください。
請求期間のパーティションで絞ってAWSサービス別の月額コストを集計する
クローラが作るテーブルには、請求期間のパーティション列 billing_period が付きます。これを必ず WHERE に入れてください。入れないと全期間を読みにいき、スキャン量がそのまま請求に乗ります。
SELECT
line_item_product_code,
ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd
FROM cur_db.cur2_daily
WHERE billing_period = '2026-09'
AND line_item_line_item_type NOT IN ('Tax', 'Credit', 'Refund')
GROUP BY line_item_product_code
ORDER BY cost_usd DESC
LIMIT 20;
税・クレジット・返金を外しているのは、利用の実態を見るためです。請求書の総額と突き合わせる用途なら、この条件を外します。
タグ別の集計は resource_tags 列から値を取り出します。キーが無い行で落ちないよう、Athenaでは element_at を使うのが安全です。キー名は正規化された形（user_ で始まり記号は下線）になるので、実際の名前はマニフェストの列一覧で確かめてください。
SELECT
COALESCE(element_at(resource_tags, 'user_project'), '(untagged)') AS project,
line_item_usage_account_name,
ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd
FROM cur_db.cur2_daily
WHERE billing_period = '2026-09'
GROUP BY 1, 2
ORDER BY cost_usd DESC;
(untagged) の金額が大きければ、それがタグ付け漏れの規模です。この数字を月次で追うだけでも、タグ運用の改善が進んでいるかを測れます。ここで出た集計を社内の按分や改善の会議に回す流れは、FinOpsの3フェーズを整理した記事の「可視化」から「改善」への橋渡しに当たります。SDKからこのクエリを定期実行する実装はAthenaをSDKで組み込む記事で扱いました。
CUR 2.0の設定で後から変えられない項目と出力が失敗する原因の見分け方
CUR 2.0でつまずく箇所は、ほとんどが作成時の選択に集まっています。
作成後に変えられない6つのテーブル設定と1アカウント5本までの作成上限
公式のデータクエリの説明は、SQL文は後から変更できる一方、選んだテーブルとテーブル設定は作成後に変えられないと明記しています。CUR 2.0のテーブル辞書に並ぶ設定は次のとおりです。
TIME_GRANULARITY：時間・日・月の粒度INCLUDE_RESOURCES：リソースID単位の明細にする（行数とファイルサイズが大きく増える）INCLUDE_SPLIT_COST_ALLOCATION_DATA：コンテナ単位の按分データを加えるINCLUDE_CAPACITY_RESERVATION_DATA：キャパシティ予約の列を加える（2025年11月1日以降のデータのみ）INCLUDE_IAM_PRINCIPAL_DATA：Bedrockの推論費用に呼び出し元IAMの列を加える（2026年4月8日以降のデータのみ）INCLUDE_MANUAL_DISCOUNT_COMPATIBILITY：割引を旧来の別行の形で表示する（割引の自動計算の対象顧客のみ）
粒度を変えたくなったら、エクスポートを作り直すしかありません。そして公式のクォータでは、1アカウントで作れるCUR 2.0のエクスポートは5本までです。試行錯誤で本数を使い切らないよう、検証用は1本に決めて使い回すのが無難でしょう。生成AIの費用を利用者単位で見たいなら、IAMプリンシパルの列は最初から有効にしておく価値があります。
Organizationsの管理アカウントで作るか各メンバーアカウントで作るか
テーブル辞書によれば、Organizationsの一括請求を使っている場合、管理アカウントで作ったCUR 2.0には組織内の全メンバーアカウントの明細が入り、メンバーアカウントで作ると自分の分しか入りません。全社の集計は管理アカウントで1本、部門ごとに渡すデータは WHERE line_item_usage_account_id IN (...) で絞った別エクスポートを作る、という分け方が素直です。一括請求の仕組み自体はOrganizationsのマルチアカウント管理を扱った記事にまとめています。
作成から1日経ってもS3にファイルが届かないときに確認する3つの原因
作成から丸1日経ってもファイルが無いときは、次の順で確かめます。1つ目はバケットポリシーの SourceAccount と SourceArn のアカウントIDが、エクスポートを作ったアカウントと一致しているか。2つ目は、作成後にバケットポリシーや所有者を変えていないか。3つ目は、SQL文の列名の大文字小文字です。公式はキーワードの大文字小文字は問わない一方、列名とテーブル名は区別すると定めています。
CURを自前で組むべき条件とCost Explorerで止めておくべき場面の線引き
ここは判断の章です。条件を示したうえで言い切ります。
CUR 2.0とAthenaを組むべきなのは、次のどれかに当てはまるときです。リソースID単位や社内独自の按分で費用を割り振る必要がある。複数アカウントの明細を社内の請求処理やBIへ毎月取り込む。Bedrockの推論費用のように、利用者単位で配賦したい費目がある。どれも画面の集計では答えが出ず、明細を手元に持つしかない要件です。
逆に、月の請求を数十万円程度のアカウントで、サービス別とタグ別の推移が見られれば十分なら、CURは作りません。Cost Explorerの画面と予算アラートで足ります。S3とAthenaとGlueクローラの面倒を見る運用が、得られる情報に見合わないからです。削減の打ち手を探すだけなら、Compute Optimizerのレコメンデーションを先に読むほうが早く効きます。
迷うのは、今は画面で足りているが半年後に部門別の配賦が始まる、という段階でしょう。この場合はCUR 2.0だけ先に作っておきます。作成前の期間は自動では埋まらず、遡るにはサポートケースでの申請が要るため、置いておくだけでも将来の集計の元手になるからです。マルチアカウントのコスト基盤をAthenaやBIまで含めて設計する場合は、AWSを含むクラウドインフラの構築支援で要件整理から引き受けています。
よくある質問
CURについて検索されやすい質問のうち、公式ドキュメントで答えられるものを5つ挙げます。
CURとCUR 2.0はどちらを使えばよいですか？
新しく作るならCUR 2.0です。AWS公式はCUR 2.0を詳細なコストデータを受け取る推奨の方法と位置づけており、列が固定されるためAthenaのテーブル定義が月ごとに崩れません。旧CURの形式に依存した既存の処理があるなら、公式の移行ガイドにある「旧CURと同じ列名になるようSQLで別名を付ける方法」で、処理側を変えずにCUR 2.0へ移せます。
CURの利用に料金はかかりますか？
公式のS3バケット設定のページは、エクスポートの保存にS3の標準料金がかかると記載しています。集計をAthenaで行うなら、クエリごとのスキャン量に応じた料金も発生します。Parquet形式で出力し、請求期間のパーティションで読む範囲を絞って、スキャン量を小さく抑えるのが定石です。
CUR 2.0は過去の月の明細も出力できますか？
作成前の期間は自動では出力されず、AWSサポートへのケース起票で遡及出力（バックフィル）を依頼する形になります。公式のトラブルシューティングは、レポート名と対象の請求期間を書いて申請するよう案内し、アカウント作成前の期間や、Organizationsの組織構造を変える前の構造のデータは戻せないとしています。AWSのCloud Intelligence Dashboardsの導入手順によれば、遡れる範囲は最大14か月です。
CURのデータはどのくらいの頻度で更新されますか？
公式の配信仕様では、CUR 2.0は元データが更新されるたびに再出力され、その頻度は少なくとも1日1回です。当月分は請求期間の終わりまで更新が続き、期間終了後も2週間以内に前月分が更新される場合があります。月次の確定値として扱うなら、翌月の中旬以降に集計するのが確実です。
Data ExportsのSQLで集計まで済ませられますか？
できません。Data Exportsのクエリで使えるのは列の選択と別名、WHERE による行の絞り込み、LIMIT に限られ、公式の処理ガイドも集計関数は非対応と明記しています。SUM や GROUP BY を使う集計は、S3に届いたデータをAthenaやRedshiftに読み込んでから行います。
関連記事
- AWS Cost Explorerとは？コスト可視化・分析の仕組みと料金・使いどころを実装者目線で解説：画面で足りる範囲の可視化はこちらです
- FinOpsとは？クラウドコスト管理の仕組み・3フェーズと導入判断を解説：集計結果を組織の改善に回す進め方です
- Amazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減：CURを読むときのスキャン量の抑え方です
- AWS Athenaの実装：SDKでのクエリ実行とフェデレーテッドクエリ・Iceberg更新：集計クエリを定期実行する実装です
- AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説：管理アカウントのCURに全アカウントが入る前提です
