この記事はZOZO Advent Calendar 2025 シリーズ 6 の 13 日目の記事です。

はじめに

Cloud Storage（以下 GCS）の料金は、おおまかに次の 3 つの要素で決まります。

ストレージ料金
ネットワーク料金
データ処理（オペレーション）料金

詳細は公式ドキュメントの料金ページを参照してください

Cloud Storage の料金は、次のコンポーネントに基づいています。
データストレージ: バケットに格納されているデータの量。ストレージ料金は、データのストレージクラスとバケットのロケーションによって異なります。
データ処理: Cloud Storage による処理。これには、オペレーション料金、適用される取得料金、リージョン間のレプリケーションが含まれます。
ネットワーク使用量: バケットから読み取られたデータ量、またはバケット間で移動したデータ量。
Anywhere Cache: バケットの一時ストレージレイヤ。

これらの料金の詳細はCloud Billing から確認できます。

しかし、バケット単位でどの程度料金が発生しているか確認することはできません。

そこで本記事では、Cloud Monitoring の Metrics explorer で PromQL を用いてメトリクスを集計することで

ストレージ使用量
ネットワーク送信量
API オペレーション回数

を GCS バケット単位 で確認する方法を紹介します。

バケット単位で料金を確認することができれば GCS のコスト削減施策の削減見積もりや、実施後の効果検証を正確に行うことができます。

事前準備（Metrics explorer）

まずは Metrics Explorer を PromQL で使える状態にします。

GCP　コンソールのメニューから、[Monitoring] > [Metrics Explorer] をクリック
プロジェクトを、料金を確認したいプロジェクトに切り替える
「クエリの入力方法」で PromQL を選択（コードエディタのタブ）

PromQL の記法は公式ドキュメントから確認ください。

ここまで設定できたら、以降のサンプルクエリを貼り付けて実行していくだけです。

ストレージ使用量

使用するメトリクス

バケットに格納されているデータ量は storage_googleapis_com:storage_v2_total_bytes で確認できます。

こちらはライフサイクルの設定などでオブジェクトの増減が発生するので、avg_over_time() を用いて一定期間で取得したバケットサイズの平均値 = その期間に使用した総バイト数を取得します。

サンプルクエリ

直近1ヶ月（31日間）のストレージ使用量を バケット × ロケーション単位 で集計する例

sum by (bucket_name, location) (
  avg_over_time(storage_googleapis_com:storage_v2_total_bytes{monitored_resource="gcs_bucket"}[31d])
)/ 1024 / 1024 / 1024

sum by (bucket_name, location)
→ バケット名 & ロケーション単位で集計

avg_over_time(...[31d])
→ 直近 31 日間の平均バイト数を計算

monitored_resource="gcs_bucket"
→ GCS バケット由来のメトリクスだけに絞り込む

/ 1024 / 1024 / 1024
→ Byte を GiB に変換

結果の見方

テーブル表示に切り替えることで

bucket_name … バケット名
location … バケットのロケーション
value … 直近 31 日間の合計ストレージ使用量（GiB）

の一覧が確認できます。

ここで value の降順ソートをかけると、

ストレージ使用量が特に大きいバケット
コスト最適化のインパクトが大きそうな候補

をすぐに確認できます。

ネットワーク送信量

GCS では、HTTP レスポンスで GCS からデータが送信されるときに料金が発生します。
ただし、以下の場合は無料になります

同じロケーション内でのデータ移動
デュアルリージョンにある Cloud Storage バケットから、そのデュアルリージョンにある別の Google Cloud サービスへのデータの移動

使用するメトリクス

ネットワーク経由で送信されたデータ量は storage_googleapis_com:network_sent_bytes_count で確認できます。

こちらは累積値となるので、increase() を用いて一定期間の増加分 = その期間に送信された総バイト数を取得します。

サンプルクエリ

直近 1 か月（31 日間）のバケットから外部へ送信されたデータ量をバケット単位で集計するクエリ例

sum by (bucket_name) (
  increase(storage_googleapis_com:network_sent_bytes_count{monitored_resource="gcs_bucket"}[31d])
)/ 1024 / 1024 / 1024

sum by (bucket_name, location)
→ バケット単位で集計

increase(...[31d])
→ 直近 31 日間に送信された総バイト数を計算

monitored_resource="gcs_bucket"
→ GCS バケット由来のメトリクスだけに絞り込む

/ 1024 / 1024 / 1024
→ Byte を GiB に変換

ネットワーク料金の単価は
送信元ロケーション × 宛先ロケーション の組み合わせで変わります。
ここではまず「どのバケットの 送信量 が多いか」を押さえるのが目的です。

結果の見方

value 列は、

直近 31 日で、そのバケットから外部に送られたデータ量（GiB）

を表します。

ここで value の降順ソートをかけると、

ネットワーク送信量が多いバケット

が見えてきます。

オペレーション回数

使用するメトリクス

API オペレーション回数は storage_googleapis_com:api_request_count で確認できます。

こちらも累積値となるので、increase() を用いて一定期間の増加分 = その期間に呼び出された回数を取得します。

サンプルクエリ

直近 1 か月（31 日間）のAPIオペレーション回数を バケット × ロケーション × メゾッド単位 で集計するクエリ例

sum by (bucket_name, method) (
  increase(storage_googleapis_com:api_request_count{monitored_resource="gcs_bucket"}[31d])
)

sum by (bucket_name, method)
→ method ラベルには GetObject, WriteObject など、API の種類が入ります
→ バケットごとに 読み取り系が多いのか、書き込み系が多いのか見えやすくなる

increase(...[31d])
→ 直近 31 日間に測定された API リクエスト数

料金表上は、メソッドがクラス A / クラス B などに区分され、クラスごと、ストレージクラスごとに単価が異なります。
本記事では、「どのバケットにどのメソッドが多いか」を把握するところまでを扱います。

結果の見方

このクエリの結果は、たとえば次のような観点でみることができます。

bucket_name ごとに method の比率を見る
→ 読み取りが中心か、書き込みが中心か
特定のバケットに対して、特定のメソッドだけ極端に多くないか
→ アプリ側のアクセスパターンを見直すヒントになる

クラスタイプ別の料金を厳密に出す場合は、

この結果を用いて「クラス A / B に該当するメソッド群」に集計し直す
単価を掛け合わせて見積もる
Cloud Billing で GCS 料金を SKU でグループ化して集計した値と比較する

といった流れになりますが、
「どのバケットのオペレーション回数が怪しいか」を探すだけなら、Metrics Explorer 上の可視化でも十分有用です。

以上の指標から「重いバケット」を見つける

ここまでで、バケット単位に

ストレージ使用量（GiB）
ネットワーク送信量（GiB）
API オペレーション回数

の 3 つを把握できるようになりました。

あとは、料金ページと見比べながら、

ストレージ単価が高いロケーション × ストレージ使用量が大きいバケット
ネットワーク単価が高い組み合わせ × 送信量が多いバケット
クラス A 単価が効いているメソッド × リクエスト回数が多いバケット

といった観点で眺めることで、

このバケットのストレージを削るのが一番効きそう
このバケットのリージョンを変更すれば、ネットワーク料金が下がりそう
このバケットへの API アクセスを見直したい

といった “最初の一手” を決めやすくなります。

まとめ

本記事では、Metrics explorer の PromQL を利用して

storage_v2_total_bytes の合計から バケットごとのストレージ使用量
network_sent_bytes_count の合計から バケットごとのネットワーク送信量
api_request_count の合計から バケットごとの API オペレーション回数

を確認する方法を紹介しました。

Cloud Billing だけを見ていると

どのバケットがストレージ料金の多くを占めているのか
どのバケットのトラフィックがネットワーク料金を押し上げているのか
どのバケットへのアクセスがオペレーション料金を増やしているのか

といった粒度での把握が難しいですが、Metrics explorer でバケットごとのメトリクスを可視化しておくと、

どのバケットでどの要素のコストが大きいのか
どの料金を削減すればコスト削減に大きく寄与するのか

をデータに基づいて判断できるようになります。

ぜひ、ここで紹介したクエリをベースに

コスト削減施策の優先順位付け
実施後の効果検証
チーム内での「コストの見える化」

といった形で、日々の運用に組み込んでみてください。

最後まで読んでいただきありがとうございました。