SaaSインフラは、基本的にマルチテナントで構築されているケースがほとんどです。1つのAWSアカウント、1つのEKSクラスター、1つのRDSインスタンスを、数百から数千の顧客で共有する。稼働率は高く保てますが、その一方で「顧客Xを動かすのに実際いくらかかっているのか?」という問いに答えるのはほぼ不可能になります。
この問いは繰り返し取り上げられていますが、返ってくる答えは「タグ付けできるものだけタグ付けして、残りは推測」から「諦めてシート単価の平均を使っている」まで、どれも似たようなものです。ユニットエコノミクスを真剣に見るなら、いずれも十分とは言えません。
本記事では、代表的なアプローチとそれぞれのトレードオフ、そしてどこで破綻するのかを実務目線で整理します。
本質的な課題:共有リソースはきれいにタグ付けできない
AWS Cost Explorerをはじめとする請求ベースのツールは、アカウント、リージョン、サービス、タグ単位でコストを見せてくれます。顧客ごとに専用アカウントやネームスペースを割り当てる専用テナント方式なら、これで十分です。しかし共有インフラでは、そうはいきません。
400顧客に提供している単一のRDSクラスターに、400行分のコスト明細は存在しません。あるのは1行だけです。十数の製品チームで使うKafkaクラスターも、共有コストセンター1つとして計上されます。混在workloadsを動かすEKSノードプールは「コンピュート」として課金されるだけで、「顧客A: $142k、顧客B: $89k」と分かれて出てくることはありません。
タグベースのアプローチは、ここで3つの理由から破綻します。
- タグは共有リソースの内側までは届かない。 EC2インスタンスにチームやサービスのタグを付けることはできても、共有データベースに投げられるクエリにタグを付けることはできません。
- タグ運用には継続的なエンジニアリング工数がかかる。 新しいリソース、新しいサービス、新しいデプロイのたびにタグが必要です。動きの速い組織ほど、カバレッジはあっという間に劣化します。
- タグが示すのは「リソースの正体」であって「使われ方」ではない。 タグの付いたRDSインスタンスから分かるのは、それが「payments」サービスに属していることだけ。今月その負荷の60%が特定の1顧客から来ていたことは、タグからは読み取れません。
アプローチ1:ランタイムのトラフィック分析(推奨)
仕組み: 請求データのエクスポートやアプリケーション計装に頼るのではなく、ネットワークとシステムのレイヤーで実際に起きていることを観測します。どのサービスがどのデータベースを呼び出しているか、どのクエリにどの顧客IDが含まれているか、各顧客が共有リソースに対してどれだけの負荷を発生させているか——こうした情報を直接掴みにいくアプローチです。
重要なのは、請求システムに見えているのは「課金」だけであり、ランタイムシステムが見ているのは「消費」だという点です。
実際、RDS、Kafka、Elasticsearchのような共有システムを、アプリケーション改修や完璧なタグ運用に頼らず個別顧客に紐付けられる方法は多くありません。この手法はその数少ない選択肢の1つです。
さらに、CURエクスポートの遅延に縛られないリアルタイムな配分が可能で、AWSの請求データにはきれいに出てこない自己管理型インフラもカバーできます。
トレードオフ: ネットワークトラフィックとシステムコールを観測するコンポーネントが必要になります。かつて本番でここまでのランタイムデータを取ることは運用上とても重い作業でしたが、eBPFの登場で状況は一変しました。Cilium、Falco、Pixieといったツールの基盤となっているプリミティブは、そのままランタイムのコスト配分にも使えます。違いは、セキュリティやオブザーバビリティのイベントではなく、リソース消費のシグナルを抽出している、という点だけです。
アプローチ2:テナントごとにアカウント(またはネームスペース)を分ける
仕組み: 顧客ごとに専用のAWSアカウントまたはKubernetesネームスペースを割り当て、請求もそれに合わせて分離します。
有効なケース: コンプライアンス要件の厳しい業種(医療、金融)、契約上の分離要件があるエンタープライズ案件、専用インフラが経済的に見合うほどの大口顧客。
破綻するケース: 中小企業の顧客が数百社規模になると、スケールしません。数百のAWSアカウントを回す運用負荷は無視できず、Reserved Instanceのカバレッジも分散してしまいます。加えて、ログパイプライン、オブザーバビリティ基盤、データプレーンなど、テナント別アカウントの外側に存在する共有サービスは依然として残ります。
アプローチ3:全リソースにタグを付けてCost Explorerで集計する
仕組み: 全リソースに対してタグ付け基準を徹底します。customer-id、team、service、environmentといったタグを付与し、Cost Explorer APIまたはAWS Cost and Usage Reports(CUR)経由でタグ付きのコストデータを取得し、その上に集計ロジックを組み立てます。
有効なケース: 初日からタグ付け基準を徹底できるグリーンフィールドの構成。リソースと顧客の対応関係が明確な専用コンピュート(EC2、EKSノードグループ、Lambda)であれば、そこそこ機能します。
破綻するケース:
- 複数の顧客が同じステートフルシステムを共有し始めた瞬間に、この方式は成立しなくなります。共有のRDSクラスターやKafkaデプロイメントは、構造的に「請求は1本、利用者は多数」だからです。
- 実際のところ、成熟した組織でクリーンなタグカバレッジを長期間維持できているケースはほとんどありません。オーナーは変わり、サービスは増え、タグは劣化します。
- CURデータは24〜48時間の遅延を伴って届くため、常に過去を振り返る形にしかなりません。
- 共有リソース(自己管理型Kafka、EC2上のElasticsearchなど)は、請求エクスポートにはそもそも姿を現しません。
この方式を使っているチームの多くは、大きな盲点があることを自覚したうえで受け入れているのが実情です。
アプローチ4:アプリケーション層での計装
仕組み: アプリケーションコードに計装を仕込み、実行クエリ数、読み書きバイト数、消費コンピュート時間といった指標を顧客別に出力します。これらの指標をAWS支出に対応付けるコストモデルを構築し、消費量に単価を掛け合わせて顧客別コストを算出します。
有効なケース: オブザーバビリティ文化が根付いているチーム、リソース消費が少数の測定しやすい操作に集約されているアプリケーション、近似値で十分な製品プライシングチーム。
破綻するケース:
- 計装のカバレッジは定義上、常に不完全です。計測すると決めたものしか計測されません。
- 共有インフラ(コネクションプーリング、クラスターのオーバーヘッド、アイドル容量)は、特定の操作に配分しようがありません。
- コストモデルは料金改定のたびに継続的なキャリブレーションを要します。
- 自己管理型インフラ(EC2上のKafka、EC2上のElasticsearchなど)については、技術ごとに個別の計装が必要になります。
- この方式で分かるのは「消費の比率」であって、「実際のコスト」ではありません。
社内向けの可視化を目的とした近似としては悪くありませんが、本格的なコスト・トゥ・サーブ分析には向きません。
まとめ
マルチテナントAWS環境における顧客別コスト配分は、専用テナントモデルでは解決済みの問題であり、共有インフラではデフォルトでは未解決の問題です。標準的なFinOpsツールチェーン(CUR、Cost Explorer、タグ付け)から得られるのはサービス別・チーム別のコストであって、顧客別のコストではありません。
そこに到達するには、共有度の低いアーキテクチャに寄せる(運用コスト大)、アプリケーション層に計装する(本質的に不完全)、あるいはランタイムの挙動を直接観測する(包括的にカバー可能)、のいずれかが必要になります。
消費量ベースの価格モデルを回している、あるいは規模のなかで採算の合わないアカウントを特定したい——そういう目的であれば、不完全なアプローチではゴールに届きません。社内レポート向けの大まかな配分で足りるなら、タグ付けと多少のモデリングでほぼ賄えます。
多くのチームは「方向性としては役立つが、厳密ではない」と分かったうえで、その配分モデルに落ち着いています。
そもそもFinOpsツールはクラウドの請求を軸に組み立てられており、共有ランタイムの挙動を軸に設計されているわけではありません。それで十分な間はよいのですが、深く共有されたシステムの内部までコスト配分を突き詰めようとした途端、機能しなくなります。
そこで壁になるのは、たいていAWSの請求データではありません。共有インフラが実際にどう使われているのか、その可視性の欠如です。
Attribute™は、まさにマルチテナント環境におけるランタイム配分レイヤーに特化したプロダクトです。