こんにちは、AWSグループの長友（アミーゴ）です🙋♀️
（※あだ名は、まだ全然呼ばれておりません。）
今回はAWS re:Inventのワークショップで学んだ「マルチテナントなコンテナ環境のコスト可視化」を、現場でどう使えるかという目線でブログにまとめます。
結論から言うと、Split Cost Allocation Data（SCAD）を使うと、これまで「クラスタ（EC2）単位」でしか追えなかったコストを、ECSのタスク／EKSのPod単位まで落として見える化できます。
「テナント別にいくら？」をちゃんと説明したい人に、かなり刺さるやつです。
背景：いま現場で困ってること
Fargateのコスト、見えなくない？
私が今アサインされたプロジェクトでは、マルチテナントでコンテナ（特にFargate）を運用していて、テナント別の正確な費用配賦が重要な課題になっています。
ただ……Fargateって便利なぶん、「誰がどれだけ使ったか」が請求から追いづらいですよね。
そんなときにre:Inventで、まさに今ほしかった内容のワークショップを見つけたので受講しました。
ワークショップ概要（やったこと）
テーマは マルチテナントコンテナワークロードのコスト可視化。
対象サービスや登場したキーワードは以下の通りでした。
- Amazon ECS（EC2）／EKS
- Split Cost Allocation Data（SCAD）
- AWS Glue
- Amazon Athena
- AWS Config
- Grafana
内容は、「マルチテナントクラスターのコスト観察が難しい問題」をタスク/Podレベルの精緻な可視化で解決していく、という感じでした。
マルチテナント環境で起きがちな3つの課題
ワークショップで整理されていた課題が、まんま現場でして、もう！うなずきすぎて首もげるやつでした。
- コストの帰属が曖昧
テナントごとにタスク数もCPU/メモリ使用率も違うのに、請求はクラスタ全体。割れない。 - タグ付けの不統一
Owner/Environment/CostCenter…あるはずの必須タグがバラバラで、分析が実質詰む。 - 経営層へ説明できない
「どのサービスが、どれだけ、なぜ費用がかかってるの？」に答えられず、意思決定が遅れる。
解決の鍵：Split Cost Allocation Data（SCAD）
Split Cost Allocation Data（SCAD）って何？
そこで登場するのが、SCAD。SCADは、AWSのCost and Usage Report（CUR）に、コンテナレベル（ECSタスク／EKS Pod）のコスト・使用量を追加してくれる仕組みです。 これにより、共有のコンピュート/メモリ（EC2やFargate）を 各タスク/Podの消費割合に応じて按分できるようになります。
ポイント：
- CURに出力 → Athenaでクエリ可能
- CPU/メモリなどの指標で配賦
（例：split_line_item_reserved_usage / split_line_item_actual_usage など） - ECSはFargate含む（ここ重要）
なお、Cost Explorerでは見られないので、基本はCUR×Athena路線です。
実践ラボ：5つのステップ
ワークショップは大きく5ステップでした。
ここからは「自分の環境ならこう読む」寄りでまとめます。
ラボ①：CURデータの探索
まずはデータに慣れる。ということで、
S3に出力されたCURを Glue Crawlerでテーブル化して、Athenaで必要な列を探し当てます。
CURって列が多すぎるので、ここで 必要な項目を絞る筋肉 が鍛えられます
（数千カラム級✊）。
ラボ②：タグ付け戦略
ここがある意味、基礎工事。
タグが崩れてると、可視化も配賦も崩壊します。
ワークショップでは AWS Config＋CloudFormation で「Owner」「Environment」「CostCenter」などの必須タグを強制する仕組みを作っていました。
体感として、タグは「後から整える」が一番しんどいです。
最初にルール化＆強制が、ほんと大事。
ラボ③：Athenaでコスト算出
SCADのメトリクスを使って「どのタスク（Pod）がいくら」を集計します。
イメージとしては、CURの split_line_item_split_cost（按分されたコスト）や、予約/実使用の使用量系カラムを使って集計していく感じです。
（例：考え方のイメージ。実列名はCURのバージョンや出力設定で変わるので、まずはGlue/Athenaで手元のテーブルを確認してください）
SELECT bill_billing_period_start_date, resource_tags_user_tenant as tenant, split_line_item_resource_id as task_or_pod, SUM(split_line_item_split_cost) as allocated_cost FROM cur_table WHERE line_item_product_code IN ('AmazonECS', 'AmazonEKS') GROUP BY 1,2,3 ORDER BY 1,4 DESC;
ラボ④：リソース使用量分析
そして「予約」と「実使用」のギャップを見ます。
個人的には、ここがめちゃ良かったです。
- split_line_item_reserved_usage： タスク/Podに割り当てたvCPU/メモリ量
- split_line_item_actual_usage： タスク/Podが実際に使ったvCPU/メモリ量
この差を見ると、「実際は使ってないのに高く見える」みたいなモヤモヤを潰しやすくなります。運用チームとアプリチームの会話にも効くやつです。
ラボ⑤：Grafanaでダッシュボード化
最後に、見える化は継続が命 ということで、
CURをデータソースにして、テナント別／サービス別／環境別にフィルタできるダッシュボードを作ります。
現場最適化だけじゃなく、予算管理や経営層への説明まで持っていける形になるのが強いなと思いました。
成果と、実務（Fargate）への持ち帰り
ワークショップの学びとしては、ざっくり以下でした。
- SCADでタスク/Podレベルのコスト可視化
- Configでタグ戦略を強制
- Athena & Grafanaでダッシュボード化
- 説明できるコストモデル に落とし込む
そして私の現場はFargate中心なので、手順をFargate向けにカスタマイズした手順書を作って持ち帰りました。
ECSのSCADはFargateも対象なので、スムーズに適用しやすかったです。
余談：SCADを有効化するときの注意
SCADは、まず Cost Management preferencesでオプトインして、その後 CUR側で「Split cost allocation data」を含める設定が必要です。
反映まで最大24時間くらいかかることもあるので、「入れたのに出ない！」で焦らないのも大事です。
ご注意を！
まとめ
最後にまとめます。
- SCADは、マルチテナント環境の“タスク/Pod単位”コスト可視化に効く
- タグ戦略がすべての土台（統一＆強制がないと運用が破綻しがち）
- ダッシュボードは“現場の改善”だけでなく“説明責任”にも効く
re:Inventのワークショップで得た知識を持ち帰ることで、Fargate環境での「誰がいくら問題」に対して、解決の道筋が見えました。
今後もこの仕組みを育てつつ、お客様の意思決定を早くできる“説明できるインフラ”を目指していきます💪
それではまた🙋♀️
