Azure 料金計算ツール「Number of K8s per cluster」とは？Container Insights コスト見積もりの実務ポイント

Azure で AKS や Kubernetes クラスタを監視していると、「Azure Monitor の料金っていくらかかるの？」という質問は必ず出てきます。そのとき多くの人を悩ませるのが、料金計算ツールの「Number of K8s per cluster」という謎フィールドです。本記事では、この項目が何を意味しているのか、公式情報とコミュニティの議論を踏まえて整理し、実務ではどう扱うべきかを、コスト見積もりの考え方とセットで解説します。

Azure 料金計算ツールの「Number of K8s per cluster」とは？

どこに出てくる項目なのか

問題のフィールドは、Azure 料金計算ツールで Azure Monitor → Log Data Ingestion → Estimate Data Volume → Estimate data volume using Container Insights を選んだときに表示される入力項目です。
このウィザードは、Container Insights が Kubernetes クラスタから収集するメトリクスとインベントリの取り込み量をざっくり見積もるためのものです。

公式ドキュメントでは、このカテゴリについて次のように説明されています（意訳）。

Kubernetes クラスタから収集されるデータ量を、クラスタ数と構成に基づいて推定する。
あくまで メトリクスとインベントリが対象で、コンテナログ（stdout/stderr・環境変数）は含まない。
コンテナログのボリュームはワークロード依存なので、別途 Analytics Logs カテゴリで見積もってほしい。

ところが、このウィザードに謎の項目 「Number of K8s per cluster」 が存在します。直訳すると「クラスタごとの K8s の数」ですが、Kubernetes を普段触っている人ほど「何を数えろというの？」と首をかしげるラベルです。

Microsoft Q&A 上での公式っぽい回答

この疑問は 2024 年に Microsoft Q&A に投稿されており、Microsoft の社員・モデレーターから次のような回答がついています（要約）。

「Number of K8s per cluster」は、1 クラスタ内の Kubernetes ノード数を意味する。
一方、「Number of clusters」はクラスタの個数を指す。
説明不足でわかりにくいラベルになっているのは事実。

つまり Q&A 上では、「Number of K8s per cluster ＝ノード数」 という解釈が「公式見解」に近い形で示されています。

しかし UI にはすでに「Number of nodes per cluster」がある

ところが実際のウィザードには、次のような項目が並んでいます。

Number of clusters
Number of nodes per cluster
Number of disks per node
Number of pods per cluster
Number of K8s per cluster

ここで 「Number of K8s per cluster ＝ノード数」 と言われても、すでに 「Number of nodes per cluster」 が存在しており、フィールドが完全に重複してしまうため、コミュニティ側からも「説明が矛盾しているのでは？」というコメントがついています。

現時点では、このフィールドに対して 明確な公式仕様や追加説明は公開されていません。そのため、

「Number of K8s per cluster」は何らかの内部計算の名残
あるいは UI ラベルの誤記・重複

とみなしている実務者が多いのが実情です。

Kubernetes / Container Insights の用語整理

混乱の原因の一つは、「何を数えるべきか」という単位がイメージしにくい点です。一度、用語と数え方を整理しておきます。

用語	説明	普通はどう数える？
Kubernetes（K8s）	コンテナオーケストレーションのプラットフォーム全体を指す総称	「Kubernetes クラスタの数」として数えるのが一般的
Kubernetes クラスタ	複数ノードで構成される Kubernetes の実行環境ひとかたまり	Number of clusters（クラスタ数）
ノード（Node）	実際に Pod を動かす VM / 物理マシン	Number of nodes per cluster（クラスタ単位の台数）
Pod	1 つ以上のコンテナを含む最小の実行単位	Number of pods per cluster（クラスタ内の総 Pod 数）
ディスク / ボリューム	永続ボリュームとしてマウントされるディスク	Number of disks per node（ノードあたりの本数）

この表から分かるように、「K8s」という単位をクラスタの中でさらに数える、という用語は存在しません。そのため「Number of K8s per cluster」というラベルは、言葉としてはかなり不自然です。

料金計算ウィザードの各項目と意味の整理

代表的な入力項目と意味

Container Insights ベースの見積もりウィザードで表示される項目を、一般的な理解で整理すると次のようになります。

項目名	想定される意味	コメント
Number of clusters	監視対象にする Kubernetes クラスタの個数	ステージング・本番など環境ごとに分けている場合は、その総数を入力
Number of nodes per cluster	1 クラスタあたりのノード台数（平均値）	ノードがオートスケールする場合は「よく出る平均値」か「ピーク値」で見積もる
Number of disks per node	各ノードに接続されたデータディスクの本数（平均）	永続ボリュームのメトリクスやインベントリに影響
Number of pods per cluster	1 クラスタ内で稼働する Pod 数（平均）	DaemonSet などノード数に比例する Pod も含めたざっくり総数
Number of K8s per cluster	仕様上の意味は曖昧	Q&A では「ノード数」と説明されているが、すでに同名の項目があるため重複・誤記の可能性が高い

なぜ「誤記・冗長項目」とみなしてよいのか

「Number of K8s per cluster」が 誤記や冗長な項目だろうと考えられる理由は、次の 3 点です。

通常の Kubernetes 用語として意味が通らない（K8s 自体はプラットフォーム名であり、クラスタ内でさらに「K8s の数」を数えない）。
UI 上に「Number of nodes per cluster」が別途存在し、Q&A の回答と整合しない。
公式ドキュメントでは、Container Insights の見積もりは「クラスタ数とその構成」に基づくとしか書かれておらず、このフィールド固有の説明は存在しない。

もちろん、内部実装では何らかの係数として使われている可能性を完全には否定できません。しかし、公式情報から逆算できる範囲では、このフィールドに固有の意味や必然性は読み取れないのが現状です。

そのため本記事では、実務的には「誤記／冗長な入力」とみなし、見積もり精度に影響しない範囲で無視するという立場をとります。

Container Insights のコスト構造を理解する

メトリクス／インベントリ vs ログ

Azure Monitor（Container Insights）のコストは、ざっくり次の 2 つの塊で考えると整理しやすくなります。

メトリクス・インベントリ系
- ノード・Pod・コンテナ・ボリュームなどの状態・性能メトリクス
- KubeNodeInventory / KubePodInventory / InsightsMetrics / Perf などのテーブル
- 料金計算ツールの「Estimate data volume using Container Insights」が対象にしている部分
ログ（特にコンテナログ）
- コンテナの stdout / stderr、Kubernetes イベントなど
- ContainerLogV2 / KubeEvents などのテーブルに格納
- アプリケーションのログ出力量によって大きく変動し、別途 Analytics Logs / Basic Logs として課金される

公式ドキュメントも、Container Insights のコスト最適化でまず見るべきは、どのテーブルがどれだけデータを食っているかだと明言しています。

ざっくりした式でイメージする

かなりラフではありますが、Container Insights 関連の 1 日あたり取込量は次のようなイメージで分解できます（係数は環境依存なのであくまでイメージ用です）。

総取り込み量 ≒
  （クラスタ数 × クラスタ固定分）
＋（ノード数 × ノード系メトリクス量/ノード）
＋（Pod 数 × Pod/コンテナ系メトリクス量/Pod）
＋（ディスク数 × ストレージ系メトリクス量/ディスク）
＋（コンテナログ行数 × 平均行サイズ）
＋（Kubernetes イベント数 × 平均サイズ）

料金計算ツールのウィザードに入力する値は、この式のうち 太字にした「クラスタ数」「ノード数」「Pod 数」「ディスク数」の部分に対応しています。その意味で、少なくとも 「Number of K8s per cluster」だけが特別な意味を持つ、ということは考えにくいと言えます。

実務での対処方針：この項目をどう扱うか

方針 1：この項目は無視する／既定値のままにする

コスト見積もりをするうえで最も重要なのは、次の 4 項目です。

Number of clusters（クラスタ数）
Number of nodes per cluster（クラスタあたりノード数）
Number of pods per cluster（クラスタあたり Pod 数）
Number of disks per node（ノードあたりディスク数）

Container Insights が収集するメトリクス／インベントリは、実質的にこれらの組み合わせで決まるため、この 4 つが現実に近い値になっていれば、残りの曖昧な項目は既定値のままでも大勢に影響しないと考えるのが実務的です。

そのため、

「Number of K8s per cluster」は既定値のまま
その他の項目を実際の構成にできるだけ寄せて入力

という扱いで十分です。もし気持ち悪ければ、「Number of nodes per cluster」と同じ値を入れてもかまいません（どのみち計算式的に意味が重複していると推定されるため）。

方針 2：実測ベースで「係数」を補正する

より精度の高い見積もりが欲しい場合、実際の Log Analytics ワークスペースのデータ量から逆算するのが最も確からしい方法です。Azure Monitor のコスト見積もりガイドでも、小規模環境で実際にデータを取ってからスケールさせるアプローチを推奨しています。

おおまかなステップは以下のとおりです。

既存の AKS クラスタ（または開発用クラスタ）で Container Insights を有効化
数日〜数週間運用し、Log Analytics ワークスペースの「Usage and estimated costs」から 1 日あたりの取り込み量を確認
テーブル別の取り込み量をクエリして、Container Insights 関連のテーブルだけを合計
そのクラスターの「ノード数」「Pod 数」「ディスク数」などを記録しておき、クラスタ規模とデータ量の関係をメモ
本番で想定する規模に合わせて、線形にスケールさせて見積もる

例えば、Log Analytics では以下のようなクエリで Container Insights 関連テーブルの 1 日あたり取り込み量をざっくり把握できます（例なので適宜調整してください）。

// 直近 7 日の Container Insights 主要テーブル別のデータ量 (MB)
union isfuzzy=true
  InsightsMetrics,
  Perf,
  KubeNodeInventory,
  KubePodInventory,
  ContainerLogV2,
  KubeEvents
| where TimeGenerated &gt;= ago(7d)
| summarize TotalMB = sum(_BilledSize) / 1024 / 1024 by $table
| order by TotalMB desc

ここで得られた 1 日平均の合計値を、料金計算ツールの結果と見比べながら、「だいたい何ノード・何 Pod で何 GB/日くらいになるか」という感覚値をつかんでおくと、本番環境の構成を変えたときにも応用しやすくなります。

方針 3：ログ主体のワークロードは別枠で見積もる

料金計算ツールの Container Insights 見積もりは、あくまで メトリクスとインベントリにフォーカスしています。コンテナログ（ContainerLogV2）や Kubernetes イベント（KubeEvents）は、実際には大きなコスト要因ですが、ウィザードの計算からは除外されています。

そのため、次のように分けて考えると整理しやすくなります。

Container Insights（メトリクス／インベントリ）：料金計算ツールのウィザードでざっくり見積もる
コンテナログ：開発／本番環境での実測値や、ログ出力ポリシー（ログレベル・行数・保持期間）から個別に見積もる

コンテナログについては、公式ドキュメントがかなり詳細にコスト削減テクニックを紹介しています。代表的なものを挙げると：

ログプリセット（Logs presets）を使って、コストが高いテーブルの収集を抑える
ConfigMap で特定の namespace / Pod / コンテナのログ収集をフィルタする
ContainerLogV2 を Basic Logs にして、クエリ料金と引き換えに取り込み単価を下げる
Ingestion-time transformation を使って log level などでログをフィルタする

ログの出方はアプリケーション次第なので、「Number of K8s per cluster」のような抽象的な項目で一括見積もりするよりも、実測＋ログ収集ポリシー設計で管理する方が現実的です。

方針 4：UI ラベルの不備としてフィードバックする

最後に、どうしても気になる場合は、次のどちらかで Microsoft 側にフィードバックを送るのも有効です。

料金計算ツールの画面右側にある Feedback 機能から、ラベルの意味が分かりづらい旨を送る
Azure サポート経由で、「Number of K8s per cluster」と「Number of nodes per cluster」の違いを確認する

前述のとおり、現状の Q&A では ノード数とされている一方で、UI の他項目との整合性がとれていないことから、ラベル改善の余地がある UI であることは間違いありません。

規模別：イメージしやすい簡易シミュレーション例

ここからは、あくまで 説明用の仮の数字として、クラスタ規模と Container Insights の取り込み量の関係をイメージするための簡単な例を示します（実際の値はワークロードや設定で大きく変動します）。

パターン	クラスタ数	ノード/クラスタ	Pod/クラスタ	ディスク/ノード	メトリクス＋インベントリの仮想取り込み量（例：GB/日）
小規模開発	1	3	60	1	約 1 GB/日
中規模本番	3	8	200	2	約 10 GB/日
大規模マルチクラスタ	10	20	800	2	約 80 GB/日

このように、「ノード数」「Pod 数」「クラスタ数」が増えると、ほぼ線形にメトリクス／インベントリの取り込み量が増えていくことがイメージできます。ここにさらに、

1 コンテナあたりのログ行数
ログの平均行サイズ
イベントの発生頻度

といった要素が乗ってくるため、コンテナログの取り込み量はメトリクスよりも変動幅が大きくなります。この部分はウィザードだけでは読み切れないので、実測値で補正することが重要です。

AKS / Container Insights 監視全体で押さえておきたいポイント

Azure Monitor 側のベストプラクティスを踏まえる

AKS 監視の公式ガイドラインでは、Container Insights や Prometheus、Application Insights など、複数の監視サービスを組み合わせることを前提に設計されています。

インフラ／クラスタレベル：Container Insights + Managed Prometheus
アプリケーションレベル：Application Insights / OpenTelemetry
ネットワークレベル：Network Watcher / Traffic Analytics

この構成を前提にすると、「Container Insights の料金見積もり」はあくまで AKS 監視全体の一部でしかありません。
そのため、ひとつのラベル（Number of K8s per cluster）の意味にこだわりすぎるより、全体としてどこにコストが集中しているかを把握する方が、トータルコスト最適化には効いてきます。

Log Analytics の設計と一緒に考える

Azure Monitor のコスト最適化ガイドでは、Log Analytics ワークスペースの設計や価格レベルの設定も重要な要素として扱われています。

ワークスペースを環境別に分けるか、共通にするか
Pay-as-you-go / コミットメントプラン / クラスタプランのどれを選ぶか
どのテーブルを Basic Logs にするか
データ保持期間（Retention）の設定

Container Insights が出すデータも、最終的には Log Analytics の料金体系の上に乗るため、「Number of K8s per cluster」単体ではなく、ワークスペース設計とセットで見直すのがおすすめです。

まとめ：ラベルに振り回されず、実測＋設計でコストを抑える

ここまでの内容を整理すると、Azure 料金計算ツールの「Number of K8s per cluster」については、次のように捉えると実務上スッキリします。

用語としては不自然で、明確な仕様説明も公開されていない。
Microsoft Q&A では「ノード数」と説明されているが、UI 上に「Number of nodes per cluster」が別に存在し、冗長・誤記である可能性が高い。
Container Insights の取り込み量は、主に「クラスタ数」「ノード数」「Pod 数」「ディスク数」とログ出力量で決まるため、このフィールド単体の影響は限定的と考えられる。

そのうえで、実務でやるべきことは次の 4 つです。

「Number of K8s per cluster」は無視するか、ノード数と同じ値にしておく。
別環境の Log Analytics 実績から「1 クラスタあたりの GB/日」を測り、そこからスケールさせる。
コンテナログは別枠で見積もり、ログプリセットや ConfigMap・Basic Logs などでコストを調整する。
違和感があれば、料金計算ツールへのフィードバックやサポート問い合わせで改善を促す。

ラベルの曖昧さに悩まされるよりも、実際にどれだけデータを入れているか、どのテーブルにコストが集中しているかを Log Analytics で定期的に確認し、収集範囲とワークスペース設計を調整していく方が、Azure Monitor / Container Insights のコスト削減には確実に効いてきます。

「Number of K8s per cluster」は割り切って扱い、本当に効くコストコントロールのレバー（ノード数・Pod 数・ログ収集ポリシー・ワークスペース設計）に集中していきましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。