TaggingによるCost Allocation / Reportingを改善する

ゴール

既存環境について、

AWS総コスト
↓
Application
Team
Environment
ごとの配賦結果
↓
配賦済みコスト
+
共有コスト
+
未配賦コスト
↓
配賦済みコスト率を算出
↓
不足額の大きい軸を特定
↓
コスト集計の精度を改善

できることがゴールです。

TagやCost Allocation Tag、Showback / Chargebackは既存の仕組みとして利用し、このページではその結果の品質を評価します。

1. タグ数ではなく「コストをどこまで説明できるか」を見る

既存環境で、

100リソース中
90リソースに
Application Tagあり

だったとします。

これだけを見ると、

タグ付け率
90%

なので十分に見えるかもしれません。

しかし、未タグの10リソースが高額で、

タグあり90リソース
65万円

未タグ10リソース
35万円

だった場合、Applicationへ帰属できているのは、

65万円 / 100万円
=
65%

です。

つまり、

リソース数ベース
90%

配賦済みコスト率
65%

未配賦コスト率
35%

となります。

コスト配賦の品質を評価するときは、

何個のリソースにTagがあるかだけでなく、いくらのコストを配賦できているか

を確認します。

2. 配賦済みコストと未配賦コストを分ける

例えば次のように整理できます。

対象コスト
100万円

├─ Applicationへ配賦済み
│   82万円
│
└─ Application未配賦
    18万円

この場合、

配賦済みコスト率
82%

未配賦コスト率
18%

です。

重要なのは、

Tagが存在するか

だけではありません。

この100万円のうち
何万円を
Applicationへ説明できるか

という金額ベースの視点で評価します。

3. 利用可能な配賦軸について実績を測る

ここでは、必要なCost Allocation Tagがすでに利用可能であることを前提とします。

確認するのは有効化手順ではなく、

Application

Team

Environment

などの各配賦軸について、

対象コストのうち
実際に何万円へ
値を付けて説明できているか

です。

例えばApplication Tag自体が多く存在していても、高額な使用に値が付いていなければ、Application別のコスト集計には大きな未配賦額が残ります。

したがって、

Tag設定の有無ではなく、そのTagで実際に配賦できた金額を測定します。

4. Application / Team / Environmentは別々に測る

1つのリソースへ、

Application = Checkout
Team        = Payments
Environment = production

が設定されている場合、それぞれ異なる配賦軸として利用できます。

しかし、すべてのTagが同じ割合で存在しているとは限りません。

なら、

Application
配賦済みコスト率 96%

Team
配賦済みコスト率 68%

Environment
配賦済みコスト率 92%

です。

この場合、Application別では比較的広いコストを説明できますが、

Team

では32万円が帰属できません。

つまり、

タグ付け全体を一括評価せず、配賦軸ごとに配賦済みコスト率を測定します。

5. 複数軸では「すべてそろったコスト」を見る

次のような集計を作りたいとします。

Application
×
Team
×
Environment

このとき、

Application
配賦済みコスト率 98%

Team
配賦済みコスト率 76%

Environment
配賦済みコスト率 95%

だからといって、

3軸すべてへ
帰属できるコスト率
=
76%

とは限りません。

例えば実データでは、

3つすべての値を持つコスト
72%

かもしれません。

Applicationあり
Teamあり
Environmentなし

や、

Applicationあり
Environmentあり
Teamなし

のコストが存在するためです。

したがって複数軸で集計するときは、

必要なすべての配賦情報が同じコストにそろっている範囲

を確認します。

6. 技術的なコストドライバーと配賦結果を接続する

詳細分析によって、

i-aaaa
75万円

がコストドライバーと分かったとします。

既存の配賦情報によって、

i-aaaa
↓
Application = Checkout
Team = Payments
Environment = production

と対応付けられれば、

技術分析
i-aaaa = 75万円

↓

組織別集計
Checkout
Payments
production

へ接続できます。

ここで確認するのは、Application / Team / Environmentという概念自体ではありません。

高額な技術的コストドライバーが、必要な配賦軸へ正しく接続できているか

です。

高額なコストドライバーほど配賦情報が欠けている場合、集計結果への影響も大きくなります。

7. 高額な未配賦コストから改善する

未配賦コストが複数ある場合、件数だけで優先順位を付けません。

例えば、

未配賦リソース
40個

合計
40万円

で、その内訳が、

4リソース
28万円

残り36リソース
12万円

だったとします。

リソース数だけを見ると40個すべてが同じに見えます。

しかし金額では、

4リソース
=
未配賦コストの70%

です。

したがって、

金額影響の大きい未配賦対象から確認する

ことで、配賦済みコスト率を効率的に改善できます。

8. 未配賦コストを総額から消さない

配賦できないコストが存在しても、

集計対象から除外

してはいけません。

例えば、

AWS総コスト
100万円

Application配賦済み
78万円

共有コスト
12万円

未配賦
10万円

だった場合、Applicationへ配賦できた78万円だけを表示して、

総コスト
78万円

と扱うと、実際のAWS支出と一致しません。

集計では、

Application配賦済み
78万円

共有コスト
12万円

未配賦
10万円

────────
合計
100万円

のように、

配賦できないコストも含めて対象総額へ突き合わせられる状態

を維持します。

9. コスト可視化では配賦不足も明示する

既存のShowback用集計などで、

Application A
30万円

Application B
25万円

Application C
23万円

だけを表示すると、

78万円

しか説明できません。

対象総コストが100万円なら、

共有コスト
12万円

未配賦
10万円

も合わせて確認できる必要があります。

配賦済みコスト
+
共有コスト
+
未配賦コスト
=
対象総コスト

となることで、

現在どこまで説明でき、どこに配賦不足が残っているか

を可視化できます。

ここではShowback自体の仕組みではなく、利用する集計結果の完全性を評価します。

10. 費用配賦へ使う前に未配賦額を明確にする

Chargebackなど、コスト集計結果を実際の費用配賦へ利用する場合は、特に未配賦額の扱いが重要です。

例えば、

総コスト
100万円

明確に配賦済み
78万円

共有コスト
12万円

未配賦
10万円

なら、まず、

78万円
→ 明確に帰属

12万円
→ 共有として識別

10万円
→ 未配賦として識別

できる状態にします。

ここでは具体的なChargeback方式を設計するのではありません。

費用配賦へ利用する前に、根拠を持って配賦できている金額と、追加判断が必要な金額を区別できているか

を確認します。

11. 集計結果をAWS総コストへ突き合わせる

コスト配賦の品質確認では、

各Applicationのコストを足したら
請求総額より小さい

状態を放置しません。

例えば、

Application A
20万円

Application B
30万円

Application C
25万円

合計
75万円

に対し、

AWS対象総コスト
100万円

なら、

差額
25万円

があります。

この差額について、

Tag値なし

共有コスト

リソースへ直接帰属できないコスト

集計対象条件の違い

などを確認します。

重要なのは、

Application別集計が出せた

ことではなく、

その集計が対象コスト全体を説明できているか

です。

12. 改善優先度は未配賦額で決める

例えば、

なら、最も大きい配賦不足は、

Team
36万円

です。

この場合、

Applicationをさらに改善する

よりも、

Teamの配賦不足

を先に調査した方が、全体への効果が大きい可能性があります。

つまり、

Tagの数

ではなく、

配賦できていないコスト

を改善優先度として使います。

13. 複数軸では最終的な有効範囲を見る

次の状態だったとします。

Application
配賦済みコスト率 96%

Team
配賦済みコスト率 64%

Environment
配賦済みコスト率 92%

3軸すべてへ
帰属できるコスト率 60%

Application単独集計なら、

96%

を説明できます。

しかし、

Application
×
Team
×
Environment

で費用を分析する場合、現時点で3軸すべてへ帰属できるコストは、

60%

です。

したがって、

ApplicationのTag品質が高い

という事実だけで、

多軸集計も十分

とは判断しません。

14. コスト配賦品質の診断フロー

既存のコスト配賦結果を改善するときは、

対象AWSコストを固定
↓
Application別
Team別
Environment別
に配賦済みコストを集計
↓
配賦済みコスト率と
未配賦コスト率を確認
↓
複数軸なら
全軸がそろうコストも確認
↓
高額な未配賦領域を特定
↓
集計総額を
対象AWSコストへ突き合わせ
↓
利用目的に必要な
配賦精度へ改善

と進めます。

混同ポイント

SAP-C02での判断

既存環境でTaggingによるコスト配賦結果を改善する場合、

Tagがある？

だけでは判断しません。

対象コストはいくら？
↓
Applicationへ
いくら配賦できる？

Teamへ
いくら配賦できる？

Environmentへ
いくら配賦できる？
↓
複数軸に必要な値が
すべてそろうコストはいくら？
↓
未配賦コストはどこに集中？
↓
集計合計は
AWS総コストと一致する？
↓
利用目的へ
十分な配賦精度がある？

と分析します。

決定打は、

タグ付けされたリソースの割合ではなく、実際に説明できるコストの割合と、説明できないコストの大きさ

です。

まとめ

TaggingによるCost Allocation / Reportingでは、既存のTagを使って、実際のコストがどこまで組織上の軸へ帰属できているかを確認します。

Application、Team、Environmentは別々の配賦軸なので、それぞれについて配賦済みコスト率を測定します。

複数軸で集計する場合は、

すべての必要な値を持つコスト

を確認します。

リソース数ベースのタグ付け率が高くても、高額なリソースが未配賦ならコスト配賦の精度は低いままです。

そのため、

未配賦リソース数

よりも、

未配賦コスト

を重視します。

また、配賦済みコストだけを表示し、未配賦コストを消してはいけません。

最終的には、

配賦済みコスト
+
共有コスト
+
未配賦コスト
=
対象AWSコスト

を確認し、

Application
Team
Environment

など必要な軸で説明できないコストを減らしていきます。