AWS CUR のデータ量を Glue 事前集計で削減する方法（Athena スキャン課金対策）

CUR（Cost and Usage Report）を Athena でクエリしていて、スキャン量が思ったより多くてびっくりした。調べてたら、Glue ETL で事前に集計しておくと劇的にデータ量を削減できるとわかったのでまとめておく。

CUR の生データがどれだけ大きいか

CUR を Hourly + リソース別で設定している場合、「1リソース × 1時間 × 1課金タイプ = 1行」になる。

EC2 を例にとると、50 インスタンス × 3 課金タイプ（インスタンス時間・EBS・データ転送など）× 24 時間 × 30 日 = 108,000 行、これだけで EC2 だけの数字だ。

さらに CUR にはカラムが 200 列以上あって、タグや製品属性など大半のクエリで使わないカラムが大量に含まれている。実際に試してみたら 1 ヶ月分の CUR が 430MB になっていた。

Glue で事前集計するとどうなるか

account_id・service_code・タグの 3 カラムだけ残して SUM(cost) でまとめると、430MB が 42KB まで圧縮できた。

SELECT
  line_item_usage_account_id AS account_id,
  product_servicecode         AS service_code,
  resource_tags_user_env     AS tag_env,
  SUM(line_item_unblended_cost) AS total_cost
FROM cur_raw
WHERE bill_billing_period_start_date = '2026-02-01'
GROUP BY 1, 2, 3

圧縮が効く理由は 2 つあって、行の集約（数百万行 → 数百行）とカラム削減（200 列以上 → 3〜5 列）が同時に起きる。

パイプライン全体像

CUR（S3 raw）
  └─ Glue Crawler → Glue ETL（GROUP BY）→ S3 aggregated
                                              └─ Athena → QuickSight

生データは S3 Glacier にアーカイブしておいて、詳細分析が必要なときに復元（Restore）してから使う。Glacier からの復元には数分〜数時間かかるので、緊急時のドリルダウンが必要なら Standard のまま残すか S3 Intelligent-Tiering を検討するのもあり。日次ダッシュボードは集計済みデータだけ見るようにすれば十分だった。