【GoogleCloud】Secret Managerで課金が発生しているので対策する

こんにちは、みるちゃ( @milcha_on)です！！

前回はArtifact Registryでの課金対策の記事を書いたけど、今回はSecret Managerでコストがかかっており、後々さらに膨らむ可能性もあるので早めに対策していこうかなと思って書いています。

なんかクレジットカードの明細を見ていたら、Google Cloudから153円請求されてたので焦って何で課金されているのか確認したところ、Secret ManagerとArtifact Registry（前回対策済み）でした。

Artifact RegistryはCloud Runでのデプロイでエラーが解決できず、何回もビルドしていたのが原因です。その都度、消せばよかったけど、面倒で溜め込んでいたらこうなりました。

Secret Managerはシンプルにアプリケーションで利用しているキーが多いからですね。これは仕方ない。と言ってもシークレットキーとして登録しているのは大体10件くらいで125円請求されているので個人としては高いですよね。

今回はこれも対策していきます。

Secret Managerとは？

Google Cloudの Secret Manager は、APIキーやパスワード、証明書などの「秘密情報（シークレット）」を安全に保存・管理するためのサービスです。

クラウド環境では、アプリケーションのソースコードに直接キーやパスワードを書き込んでしまうと、GitHubなどで流出した際にセキュリティリスクが非常に高まります。

Secret Managerを使えば、それらの重要情報を暗号化して一元管理でき、必要なときにだけ安全に取り出すことができます。

Secret Managerの特徴としてはこんな感じです。

Secret Managerには暗号化して登録することができ、新しいバージョンで登録するとCloud Runなど再デプロイせずに最新のシークレットキーを利用できるようです。

セキュリティ対策でシークレットキーのローテーションも可能です。

Secret Managerの料金体系

Secret Managerも完全無料のプロダクトではありません。

無料枠

注意が必要なのが、シークレットキー6件までではなく、シークレットキーのバージョンを含めて6件になります。なので、１シークレットの中に6件バージョンを登録しているとそれだけで無料枠を使い切ります。

アクセス操作は1万回アクセスまで無料です。これは1件のシークレットキーにアクセスすると1アクセスとしてカウントされるようです。

なので、１つの処理に２つのシークレットキーにアクセスするロジックの場合は、2アクセスとしてカウントされるみたいです。

さらに詳しく調べたところ、CloudRunなどの場合はデプロイ時とインスタンスが起動する際にSecret Managerから読み込むので、最低でも1インスタンス=1アクセスとなります。

なので、シークレットキーの数が多く、シークレットキーにアクセスするロジックが多いほどアクセス数は多くなります。

課金対象

料金体系はこんな感じで2025年9月時点のレートです。基本的にはコストもそこまでかからないかと思いますが、今回僕が費用発生させたのが、シークレットバージョンのコストなので、ここだけ抑えれば想定内の料金かと思います。

アクセス操作は1万アクセス単位の課金なので2万アクセスまでは0.03ドルで済みます（僕の解釈が正しければ…）。かなり安いですよね。

ただ、シークレットキーが多いとそれなりに無料枠の消費も早いのでこれの対策をしていこうかなと思います。

Secret Managerのコスト対策

コスト対策としてはこの辺りが挙げられるかと思います。

１つは単純にシークレットキーの数を減らすことですね。最初僕もやっていましたが、開発環境、ステージング環境、本番環境で分けている場合、変数にした方がいいと思い、細かく分けていました。

しかし、ドメインなどはわざわざ環境変数などにする必要はないので、ファイルを分けて直接定義し、ビルド時に使うファイルを選択するようにすればいいだけでした。

なので、環境変数に登録するのではなく、露出しても問題ない情報は環境ごとに分けたファイルに定義していく方が管理しやすいです。sample.comとdev.sample.comをわざわざ環境変数などにする必要はないですからね。。。

２つ目ですが、今まで1シークレット＝１件で登録していたので、10件シークレットキーがあれば10件分追加していました。GUIからだと追加するのも大変。そしてCloud Runデプロイ時にも10件分選ばないといけないので面倒。

これが、1シークレットにJSONで複数の値を登録できるようなので、JSON形式にしてアプリケーション側でそのJSONを読み込むようにすれば1インスタンス＝1アクセスで済みます。

1シークレットにJSONで複数の値を追加する

こんな感じで複数の値をJSON形式で定義していきます。これをアプリケーション側でJSONの中身を読み取る形で利用することで、インスタンス起動時に一括でシークレットキーを読み取ることが出来ます。

import os, json

# JSON文字列を環境変数からロード
secrets_json = os.getenv("SAMPLE_KEY", "{}")
secrets = json.loads(secrets_json)

# 安全に参照
SAMPLE1 = secrets.get("SAMPLE1")
SAMPLE2 = secrets.get("SAMPLE2")
SAMPLE3 = secrets.get("SAMPLE3")

僕がPythonを利用するので今回はPythonで書いてみましたが、このように書くことで一括で取得することが出来ます。

コード修正後、CloudRunに先ほどのSAMPLE_KEYを追加してデプロイします。

まとめ：Secret Managerはバージョンに注意すれば低コスト！

Secret Managerはシークレットキーの数とバージョンの数に注意すれば、アクセス数は1万回ごとの課金なので、そこまで気にする必要はないかと思います。

インフラをGoole Cloudで固めると、いろいろなコストがかかってくるので注意が必要ですが、やり方次第で低コストを維持できますね。