AWSコスト利用状況レポート（CUR）とは
AWSコスト利用状況レポート（AWS Cost and Usage Reports、以下CUR）は、AWSがS3バケットに配信するもっとも詳細な料金・利用状況データです。CSVまたはParquet形式で1日最大3回、月初からの累積として出力されます。最新のCUR 2.0ではAWS Data Exportsを介してスキーマが分析向きに整備されており、Amazon Athena、Amazon Redshift、Amazon QuickSightからそのままクエリできるため、ETLを組まなくても分析基盤として利用できます。
CURには identity、bill、lineItem といった必須カラム群に加えて product、pricing、resourceTags などが含まれます。セキュリティ分析で重要なのは次のカラムです。
line_item_usage_account_idはリソースを使ったアカウントを示します。line_item_usage_typeはBoxUsage:p4d.24xlargeやEU-DataTransfer-Out-Bytesのような利用種別を表します。line_item_operationはRunInstancesやCreateBucketのようなAPI操作名を保持します。line_item_resource_idはインスタンスIDやARNなどのリソース識別子です。product_regionはリソースが配置されたリージョンです。line_item_unblended_costはそのラインアイテムの課金額（USD）です。
これらは料金分析だけでなく、誰が・どこで・何を使ったかを横断的に追跡できるセキュリティ証跡として機能します。CURは過去数年分の蓄積が可能なため、ベースラインを取ったうえでの異常検出に向いています。
コストデータをセキュリティ監視に使う発想
請求データはこれまでFinOpsや予算管理の文脈で語られてきました。しかし2025年11月2日にAWS Security Blogが報告した大規模クリプトマイニング事案では、攻撃者は漏えいしたIAM資格情報で侵入し、10分以内に最大999台のEC2インスタンスと50を超えるECSクラスタを立ち上げました。直接の検知はAmazon GuardDutyの拡張脅威検知が担いましたが、被害規模を裏付けたのはCURに残された膨大な BoxUsage:p4d.* と BoxUsage:g4dn.* のラインアイテムでした。
つまりコストデータは、CloudTrailのようなリアルタイム監査ログより遅行する一方で、攻撃の影響範囲（どのアカウントが、どのリージョンで、何台分の請求を発生させたか）を一意に集計できる強力な裏付け証跡です。攻撃者にCloudTrailを停止された場合や、ログ保管期間を超えた古い侵害の事後分析でも、CURが残っていれば被害の輪郭をたどれます。
CURで検出できるセキュリティ異常の主要ユースケース
AWS Cloud Financial Managementチームは2026年4月27日、CURデータを使ったセキュリティリスク特定の公式ブログを公開しました。そこで紹介された5つのユースケースに、IAMや大型インスタンスの観点を加えると、現場で押さえておきたい異常の輪郭が見えてきます。
- 想定外リージョンの利用。日本のワークロードを ap-northeast-1 と global に限定しているのに、突如 us-east-1 や sa-east-1 でEC2やS3が動き始めるパターンです。
- 新規大型インスタンスの突発利用。
BoxUsage:p*やBoxUsage:g*といったGPU/ML系の利用が、通常使わない部門のアカウントから現れたら侵害を疑います。 - 異常なAPIコール増加。
line_item_operation単位で日次集計し、RunInstancesやCreateRoleが前日比10倍など極端な増加を示す場合に警報を上げます。 - データ転送コストの異常スパイク。
%DataTransfer-Out%usageType に課金が突発的に乗るのは、データ持ち出しやC2通信の兆候となり得ます。 - 構造的リスク。CloudFrontの
HTTP-Static・HTTP-Dynamicによる未暗号化通信、AWS Shield Advanced未適用の境界、Extended Supportで稼働し続ける旧バージョンRDSやEKSも、CURの利用量で見える化できます。
CURではIAMユーザー作成そのものに課金が発生しないため、新規IAMユーザー作成イベントの一次検知はCloudTrailの CreateUser イベントが本筋になります。一方で、新規ユーザーがすぐに使う STS 呼び出し量や KMS-Keys-* の使用量はCURに現れるため、CloudTrailとCURを突き合わせると侵害の起点と被害規模を同時に把握できます。
Athenaで書くCURセキュリティクエリ実例
CURをAthenaから直接参照する場合、まずAWS Glue DataカタログにCUR 2.0のテーブルを定義します。以下では「許可リスト外リージョンの利用」「大型インスタンスの急増」「アカウント別日次コスト前日比」の3つのSQLを示します。いずれもsnake_case表記のCUR 2.0カラム名を前提としています。
まず、想定外リージョンの利用を抽出するクエリです。
SELECT
line_item_usage_account_id,
product_region,
product_product_name,
SUM(line_item_unblended_cost) AS cost_usd
FROM "cur"."cur_table"
WHERE billing_period = '2026-04'
AND product_region NOT IN ('ap-northeast-1', 'us-east-1', 'global', '')
GROUP BY 1, 2, 3
HAVING SUM(line_item_unblended_cost) > 1
ORDER BY cost_usd DESC;許可リストは社内ポリシーに合わせて NOT IN の中身を調整します。HAVING でしきい値を入れておくと、わずかなテスト利用は無視できます。次は、GPU・ML系の大型インスタンスやFargateの急増を見るクエリです。
SELECT
DATE_TRUNC('day', line_item_usage_start_date) AS usage_day,
line_item_usage_account_id,
line_item_usage_type,
SUM(line_item_usage_amount) AS hours,
SUM(line_item_unblended_cost) AS cost_usd
FROM "cur"."cur_table"
WHERE billing_period = '2026-04'
AND (line_item_usage_type LIKE 'BoxUsage:p%'
OR line_item_usage_type LIKE 'BoxUsage:g%'
OR line_item_usage_type LIKE '%Fargate%')
GROUP BY 1, 2, 3
ORDER BY cost_usd DESC;2025年11月の事案を踏まえると、GPU系インスタンスの突発利用は最優先で警戒したい指標です。最後に、アカウント別の日次コスト前日比を計算し、急増を浮かび上がらせるクエリを示します。
WITH daily AS (
SELECT line_item_usage_account_id,
DATE_TRUNC('day', line_item_usage_start_date) AS d,
SUM(line_item_unblended_cost) AS cost_usd
FROM "cur"."cur_table"
WHERE billing_period IN ('2026-03', '2026-04')
GROUP BY 1, 2
)
SELECT line_item_usage_account_id, d, cost_usd,
LAG(cost_usd) OVER (PARTITION BY line_item_usage_account_id ORDER BY d) AS prev_cost,
cost_usd / NULLIF(LAG(cost_usd) OVER (PARTITION BY line_item_usage_account_id ORDER BY d), 0) AS ratio
FROM daily
ORDER BY ratio DESC NULLS LAST;ratio が10倍を超えるアカウントは、CloudTrailの RunInstances や CreateRole と即時付き合わせて初動を判断します。SQLの結果は単独で意思決定するのではなく、必ず操作ログと突き合わせる二段構えが現実的です。
QuickSightとCUDOSによる可視化と運用設計
SQLだけで運用するとアラートが個人依存になりがちです。Amazon QuickSightと、AWSが公式に提供するCloud Intelligence Dashboards（CID）、なかでもCUDOSを使うと、リージョン別マップやアカウント別異常をチームで共有できる形になります。CUDOSはCUR 2.0のサマリビューを前提としており、セキュリティ視点のフィルタを追加するだけで「許可外リージョンの請求」や「GPU利用の前日比」を定常的にウォッチできます。
運用ではAWS Cost Anomaly Detectionとの併用が現実的です。機械学習で1日3回スキャンを行い、サービスやアカウント単位のコスト異常をAmazon SNSやAWS Chatbot経由で通知します。CURの定点クエリで「想定外リージョンの請求が0でない」などの条件を満たしたときだけAmazon EventBridgeを介してSlackへ飛ばすと、ノイズを抑えながら精度の高い気づきが得られます。Amazon GuardDutyやAWS Security Hubと組み合わせれば、攻撃検知から影響範囲確定、全社可視化までを一連のビューでつなげられます。
実際のインシデントから学ぶ運用上の教訓
2025年11月2日のクリプトマイニング事案は、CURでセキュリティを見るうえでいくつかの教訓を残しました。攻撃者は侵入から10分でEC2やECSのリソースを稼働させ、API terminationの無効化やAuto Scaling Group最大999台といった「止めにくい構成」を取りました。CURの観点ではus-east-1の BoxUsage:g4dn.* や BoxUsage:p4d.* が一気に出現したわけですが、CURの遅延（最大24時間）を考えると、CUR単独で初動検知を担うのは現実的ではありません。
そこで、リアルタイムの検知はGuardDutyとCloudTrail、AWS Configに任せ、CURは「影響範囲の確定」と「再発防止後のレビュー」の二段で使うのが現実的な分担になります。具体的には、攻撃者が無効化したAPI terminationやAuto Scaling Groupの構成変更をCloudTrailで時系列に追い、同時刻帯の請求発生をCURの line_item_usage_account_id と line_item_resource_id で突合します。これによりCloudTrailのログ保管期間を超えても、CURさえ残っていれば被害の輪郭は再現可能です。
セキュリティとFinOpsを別チームで分けている組織でも、CURという共通データ基盤を介して両者が会話できる設計にしておくと、平時の最適化と有事の対応の両面で価値を発揮します。コストはセキュリティの隣にある指標であり、両者を同じダッシュボードで見る運用が、これからのAWSオペレーションの標準像になっていくはずです。
