Cost and Usage Reportを詳細分析する

ゴール

既存のコスト分析結果から、

高コスト領域
↓
AWS CUR
↓
Line Item
↓
Usage Type
↓
Resource
↓
Cost
↓
Cost Driver

と掘り下げられることがゴールです。

例えば、

Amazon EC2
月額 300万円

という結果だけではなく、

どの使用タイプか

どのリソースか

どの時間帯か

どの明細が
どれだけコストを発生させたか

まで確認します。

1. AWS CURは集約結果を明細まで掘り下げる

AWS Cost Explorerでは、

サービス
アカウント
リージョン
使用タイプ

などを使ってコストを分析できます。

一方、さらに細かく、

請求明細単位
+
使用タイプ
+
リソースID
+
使用量
+
コスト

をデータとして調査したい場合、AWS CURを利用できます。

イメージとしては、

集約されたコスト

Amazon EC2
300万円
        │
        ▼
AWS CUR
        │
        ├─ 明細A
        ├─ 明細B
        ├─ 明細C
        └─ 明細D

のように掘り下げます。

ここでの目的は、

AWS CURを使うこと

そのものではありません。

集約値では見えなかったコストドライバーを明細から見つけることです。

2. 現在のAWSではCUR 2.0も理解する

現在のAWSでは、AWS Data Exportsの CUR 2.0 が詳細なAWSコスト・使用状況データを取得する推奨方式です。

CUR 2.0では、例えば、

時間粒度
HOURLY
DAILY
MONTHLY

を設定できます。

また、

INCLUDE_RESOURCES

を有効にすることで、対応する使用についてリソースレベルの情報を含められます。

ここで重要なのは列名そのものを暗記することではありません。

SAP-C02では、

時間単位の分析が必要か

個別リソースまで
特定する必要があるか

のように、

必要な分析粒度に合わせて取得する情報を選ぶ

ことが重要です。

3. Line Itemは「1リソース」を意味しない

AWS CURでは、コストと使用状況が Line Item（明細項目） として記録されます。

重要なのは、

1 Line Item
=
1 Resource

ではないことです。

同じEC2インスタンスでも、

コンピューティング使用

データ転送

関連する料金

割引が適用された使用

などが別の明細として現れる場合があります。

逆に、

データ転送
APIリクエスト
割引
クレジット
税

など、個別リソースへ直接結び付かない明細もあります。

したがって、

行数
=
リソース数

とは判断しません。

4. LineItemTypeで「何の明細か」を先に確認する

明細を分析するときは、コスト値だけを見るのではなく、

この行は
何の種類の明細なのか

を確認します。

AWS CURには、

Usage
DiscountedUsage
Fee
Credit
Refund
Tax

など、異なる種類の明細が存在します。

例えば、

-5,000円

という値があっても、それが通常使用のマイナスコストとは限りません。

Credit
Refund

などである可能性があります。

そのため、

Cost
↓
LineItemType
↓
Usage Type

のように、明細の意味を確認してからコストドライバーを分析します。

5. Usage Typeで「何を使用した結果の料金か」を確認する

Usage Typeは、

その明細がどの種類の使用を表しているか

を確認する重要な項目です。

例えば、

EC2インスタンス稼働

データ転送

ストレージ

NAT Gatewayデータ処理

など、同じサービスに関連するコストでも使用内容が異なる場合があります。

例えばサービス別集計では、

Amazon EC2
300万円

だったとしても、明細へ掘り下げると、

Usage Type A
170万円

Usage Type B
90万円

Usage Type C
40万円

となっているかもしれません。

この場合、

Amazon EC2が高い

から、

Usage Type Aが
EC2関連コストの
主要なCost Driver

まで絞れます。

6. Usage Typeごとの使用量は、Cost Driver判定の補助情報として使う

Usage Typeごとに使用量の単位が異なることは前提とします。

そのため、詳細分析では、

UsageAmountが最大
=
Cost Driver

とは判断しません。

例えば、

Usage Type A
Cost 12万円

Usage Type B
Cost 28万円

Usage Type C
Cost 4万円

であれば、

同じCost指標で
金額への寄与を比較

します。

UsageAmountは、

なぜそのCostが発生したか

使用量が増えたためか

単価や課金条件によるものか

を追加で調べるための情報として使います。

ここで重要なのは、

Usage Typeごとの使用量を並べることではなく、明細を共通のCost指標へ集約してCost Driverを特定すること

です。

7. ResourceIdで特定リソースまで掘り下げる

リソースレベルのデータが含まれている場合、ResourceIdを利用できます。

例えばAmazon EC2なら、

i-xxxxxxxx

のようなインスタンスIDまで特定できる場合があります。

これにより、

EC2全体
300万円
↓
特定Usage Type
170万円
↓
i-aaaa
70万円

i-bbbb
55万円

i-cccc
45万円

のように掘り下げられます。

ここまで分かれば、

EC2全体が高い

ではなく、

このUsage Typeの
このリソース群が
Cost Driver

と判断できます。

8. ResourceIdは常に存在するとは限らない

ResourceIdには重要な注意点があります。

まず、リソースレベルの情報を含む設定が必要です。

さらに、リソースレベルデータを有効にしていても、

すべての明細に
ResourceIdが入る

わけではありません。

例えば、

データ転送
APIリクエスト
割引
クレジット
税

などでは、ResourceIdが空欄になる場合があります。

したがって、

ResourceIdが空
↓
AWS CURが壊れている

とは判断しません。

その場合でも、

Usage Type
Operation
Account
Region / AZ
Cost

など、利用できる別の情報を使って分析できます。

9. Granular Analysisでは必要な粒度を先に決める

詳細分析では、

細かければ細かいほど良い

とは限りません。

必要なのは、

調査したいコストドライバーを識別できる粒度

です。

例えば、

どの月に増えたか

だけなら月次でも分析できます。

一方、

毎日数時間だけ
コストが急増する

のであれば、月次集計では原因を隠してしまいます。

月次
↓
1か月に集約

日次
↓
日ごと

時間単位
↓
時間帯ごと

と、調査目的に合わせます。

同様に、

サービス単位で十分

なのか、

個別Resourceまで必要

なのかも分けます。

CUR 2.0では時間粒度やリソース情報の有無を、必要な分析に合わせて設定します。

10. 月次データから時間単位の原因は復元できない

例えば、

月額
100万円

という月次データだけを保持していて、

毎週火曜日
02:00〜04:00
だけコスト急増

という原因を調べたい場合があります。

しかし月次に集約された後では、

どの時間に
どの明細が増えたか

を後から復元できません。

したがって、

必要な分析粒度
↓
レポートの時間粒度

を合わせます。

これは、

データ量を増やすために
常にHOURLY

という意味ではありません。

必要な原因分析ができる最小粒度を選びます。

11. Costは分析目的に合わせて同じ指標で比較する

AWS CURには複数のコスト関連項目があります。

例えば、

Unblended Cost
Blended Cost

などです。

さらにReserved InstancesやSavings Plansを含む分析では、それぞれに関連するコスト項目も存在します。

ここで重要なのは、

ある明細はUnblended Cost

別の明細はBlended Cost

のように異なる尺度を混在させて順位付けしないことです。

分析目的に応じてコスト指標を選び、

対象期間
+
対象範囲
+
Cost指標

をそろえて比較します。

このページの例では、特に断りがない限り、

同じCost指標で比較済み

として扱います。

12. サービス総額からCost Driverまで掘り下げる

例えば、ある月に、

Amazon EC2関連コスト
300万円

だったとします。

詳細分析すると、

Usage Type A
170万円

Usage Type B
80万円

Usage Type C
50万円

でした。

さらにUsage Type AをResourceIdで見ると、

i-aaa
90万円

i-bbb
50万円

i-ccc
30万円

だったとします。

すると、

Amazon EC2
300万円
↓
Usage Type A
170万円
↓
i-aaa
90万円

まで絞れます。

この場合、

Amazon EC2

というサービス名だけより、

Usage Type A
+
i-aaa

の方が、改善対象を検討するための具体的な情報になります。

13. ResourceIdだけで分析を終わらせない

個別リソースを特定できても、

i-aaaが高い

だけでは原因分析として不十分な場合があります。

同じリソースに、

Usage Type A
Usage Type B
Usage Type C

という複数の明細がある可能性があるからです。

したがって、

ResourceId
+
Usage Type
+
Cost

を組み合わせます。

例えば、

i-aaa
総額90万円

を、

Usage Type A
75万円

Usage Type B
10万円

Usage Type C
5万円

へ分解すれば、

リソースが高い理由

まで特定できます。

14. Line ItemからCost Driverを特定する流れ

詳細分析では、次のように段階的に絞ります。

既存の高コスト領域
↓
対象期間を固定
↓
Line Itemを取得
↓
LineItemTypeを確認
↓
Usage Typeで分類
↓
必要ならResourceIdで分類
↓
同じCost指標を集計
↓
寄与度を比較
↓
Cost Driverを特定

例えば、

Amazon EC2が高い

という状態から始めても、

最終的には、

特定Usage Type
+
特定Resource
+
特定期間

まで絞り込めます。

15. 詳細分析では複数の切り口で集計する

AWS CURを使う詳細分析では、

対象期間
↓
対象Service
↓
Usage Type
↓
ResourceId
↓
Cost

のように、必要な切り口で集計します。

重要なのは特定の分析ツールやSQL構文ではなく、

大きな集約値
↓
明細データ
↓
複数の切り口で再集計
↓
Cost Driver

という分析アプローチです。

16. 集約値と明細値を混同しない

例えばAWS Cost Explorerで、

Amazon EC2
300万円

と表示されたとしても、

AWS CURで確認すると、

Usage
DiscountedUsage
Fee
Credit
Refund

など、異なる種類のLine Itemが関係している場合があります。

そのため、

Cost Explorerのサービス総額
=
CURの任意の1種類の行を
そのまま合計

とは限りません。

詳細分析では、

どのLineItemTypeを含めているか

どのCost指標を使っているか

どの期間を集計しているか

を明確にします。

17. 集約されたコスト領域から明細へ掘り下げる

前段の分析で、

Inter-AZ
42%

NAT Gateway関連
30%

のように、総コストへの影響が大きい領域まで絞れている場合があります。

さらに原因を特定する必要があれば、

そのコストを
構成する明細は何か

どのUsage Typeか

どのResourceか

へ掘り下げます。

つまり、

コスト領域を特定
↓
明細へ分解
↓
Cost Driverを特定

という流れです。

18. Cost Driverを特定したところで分析を区切る

AWS CURで、

i-aaa
75万円

のように、具体的なResource・Usage Type・Costまで特定できれば、技術的なコストドライバーの分析は一段階完了です。

ここでは、

Resource
+
Usage Type
+
Cost

までを明確にします。

その後、このコストを組織や業務上の単位へ整理する必要がある場合は、別のコスト管理情報と組み合わせて分析します。

この詳細分析では、まずどの技術的な使用がコストを発生させているかを確定させることに集中します。

混同ポイント

SAP-C02での判断

既存環境で、

コストが高い

という集約結果だけでは改善対象を絞れない場合、

より詳細な課金データが必要？
        ↓
AWS CUR / CUR 2.0

何の明細？
        ↓
LineItemType

何を使用した？
        ↓
Usage Type

どのリソース？
        ↓
ResourceId
※利用可能な場合

いくら発生した？
        ↓
同じCost指標

どれが総額を動かしている？
        ↓
Cost Driver

と考えます。

決定打は、

AWS CURを取得することではなく、Line Itemを適切な粒度で集計し、具体的なCost Driverまで掘り下げること

です。

まとめ

AWS Cost and Usage Reportは、AWSのコストと使用状況を明細レベルで分析するために利用できます。

現在のAWSでは、AWS Data ExportsのCUR 2.0が詳細なAWSコスト・使用状況データを取得する推奨方式です。

Line Itemは1リソースそのものではなく、1つの課金・使用状況明細です。

Usage Typeから、その明細がどのような使用を表すか確認できます。

リソースレベルデータが利用可能な場合はResourceIdを使って個別リソースまで掘り下げられます。

ただしResourceIdはすべての使用タイプで存在するわけではありません。

Usage Typeごとの使用量はCost Driver判定の補助情報として利用し、主要なコスト寄与は同じCost指標で比較します。

Granular Analysisでは、

時間粒度
+
使用タイプ
+
リソース粒度
+
Cost

を分析目的に合わせます。

最終的には、

サービス総額
↓
Line Item
↓
Usage Type
↓
Resource
↓
Cost
↓
Cost Driver

まで掘り下げます。