この記事はで読むことができます。
当ブログでは商品・サービスのリンク先にプロモーションを含みます。
Google Cloudの請求書に身に覚えのない料金がある
Cloud Runが無料枠のはずなのに課金されている
Artifact Registryの料金が何なのか、なぜ発生するのかわからない
ソースコードが軽いのにストレージ料金がかかる理由が知りたい
Google Cloudを使い始めたけれど、ある日届いた請求書を見て「あれ？」と思ったことはありませんか？
Cloud Runは無料枠があると思っていたのに、請求が来てる…。Artifact Registryって何だろう？
その気持ち、よくわかります。私も実務でクラウドを使い始めた頃は、料金体系の複雑さに頭を悩ませたものです。
特にCloud RunやArtifact Registryは、知らないうちに料金が発生しやすいポイントがいくつか潜んでいます。
しかし、一度仕組みを理解してしまえば、無駄なコストをしっかり抑えることができます。
この記事では、Google Cloudの請求でよくある疑問を解消し、具体的なコスト削減方法までを分かりやすく解説します。
- Cloud Runで意図しない料金が発生する原因
- Artifact Registryの役割と料金の仕組み
- 軽量なソースコードでもストレージ料金がかさむ本当の理由
- 具体的なコスト削減のためのイメージ削除・自動化手順
Cloud Runの料金、なぜ無料枠を超える？
Cloud Runに無料枠があるのは事実です。しかし、料金が発生するにはちゃんと理由があります。
まず、Cloud Runの無料枠はCPUやメモリ、リクエスト数に適用されますが、それを超過した分は当然課金されます。
そして、もう一つ見落としがちなのが「最小インスタンス数」の設定です。
この設定を1以上にしていると、リクエストが全くないアイドル状態でもインスタンスが常に起動し続けるため、料金が発生してしまいます。
コールドスタートを避けたい場合などを除き、開発段階や個人利用では最小インスタンス数は0にしておくのがコスト削減の基本です。
謎の料金「Artifact Registry」の正体とは？
Cloud Runとセットで請求される「Artifact Registry」って一体何なんですか？
良い質問ですね。Artifact Registryは、Cloud Runを動かすための「設計図」を保管しておく倉庫のようなものです。
この「設計図」のことを、専門用語で「コンテナイメージ」と呼びます。
Cloud Runでアプリを動かすには、このコンテナイメージが不可欠です。そして、そのコンテナイメージを保存しておく場所がArtifact Registryなのです。
Artifact Registryの料金は、主に保管しているコンテナイメージのデータ量（ストレージ料金）に応じて発生します。毎月最初の0.5GBまでは無料ですが、それを超えると課金が始まります。
なぜ？ソースは軽量なのに0.5GBの無料枠を超える理由
GitHubにあるソースコードはすごく軽いのに、0.5GBも超えるのはなぜですか？ファイルサイズじゃないんですか？
非常に鋭いポイントです。その理由は、Artifact Registryに保存されているのがソースコードそのものではなく、「コンテナイメージ」だからです。
コンテナイメージは、あなたのソースコードに加えて、プログラムを動かすためのOSや必要なライブラリなどをすべて含んだパッケージです。そのため、元のソースコードよりはるかにサイズが大きくなります。
コンテナイメージのサイズ ＝ ベースイメージ(OS等) + 依存関係(ライブラリ) + ソースコード
そして、無料枠を超える最大の原因は、デプロイするたびに新しいコンテナイメージが作られ、古いものが自動では削除されずにどんどん蓄積されていくからです。
例えば、300MBのイメージを2回デプロイしただけで、合計600MBとなり、0.5GB（512MB）の無料枠を超えてしまいます。これが、意図しない料金が発生するカラクリです。
【実践】Artifact Registryのコストを削減する2つのステップ
原因がわかったところで、次は具体的なコスト削減策を実践しましょう。安全にコストを削減するための重要なステップは、現在使用中のイメージを正確に把握することです。
ステップ1：現在使用中のイメージを特定する
どれが古いイメージで、どれが今使っているものか分からなくなってしまいました…！
大丈夫です。日付だけで判断するのは危険なので、確実に使用中のイメージを調べる方法があります。
現在稼働中のCloud Runサービスがどのイメージを利用しているかを確認しましょう。このリストにないイメージは、安全に削除できる候補となります。
Google Cloudコンソールで「Cloud Run」に移動します。
確認したいサービスの名前をクリックします。
サービス詳細ページの上部にある「リビジョン」タブをクリックします。
トラフィックが100%になっているリビジョンの詳細を開き、「コンテナイメージのURL」を確認します。これが現在使用中のイメージです。
この作業を稼働中のすべてのサービスで行い、使用中のイメージリストを作成してください。
ステップ2：不要なイメージを削除する（手動・自動）
使用中のイメージが特定できたら、いよいよ不要なイメージを削除します。手動での削除と、将来のコスト発生を防ぐための自動削除設定があります。
手動での削除
すぐに不要なイメージを消したい場合は手動が便利です。
- コンソールで「Artifact Registry」を開く
- リポジトリ → 削除したいイメージ名 をクリック
- 使用中でないと確認したバージョンのチェックボックスを入れ、「削除」をクリック
一度削除したイメージは元に戻せません。ステップ1の確認を慎重に行ってください。
自動での削除（クリーンアップポリシー）
今後の手間とコストを考えれば、こちらの設定を強く推奨します。
「クリーンアップポリシー」機能を使えば、「最新のX個のバージョンだけを残す」といったルールで古いイメージを自動で削除できます。
- Artifact Registryのリポジトリ一覧で、ポリシーを設定したいリポジトリの右側メニュー（︙）から「クリーンアップ ポリシーを編集」を選択
- 「ポリシーを追加」をクリック
- 条件タイプで「バージョン数」を選び、「保持する最新バージョンの数」に5や10など任意の数を入力
- 「保存」をクリック
「バージョン数で制限」する方法が、意図せず必要なイメージを消すリスクが低く、管理も簡単でおすすめです。
よくある質問：GitHub連携とCloud Storageの関係
- GitHubからデプロイしている場合、`run-sources-….`という名前のCloud Storageバケットは不要ですか？
- いいえ、必要です。GitHubからデプロイする際、Google Cloudはそのソースコードを一時的にこのバケットに保存してからビルド処理を行います。したがって、このバケットはGitHub連携に不可欠です。
- では、このCloud Storageバケットの料金を抑えるには？
- バケット自体は削除せず、中身のファイルが自動で削除されるように「ライフサイクル管理」を設定するのが最適です。「作成から30日経過したオブジェクト（ファイル）を削除する」といったルールを設定すれば、バケットの中が不要なファイルでいっぱいになるのを防ぎ、ストレージコストを最小限に抑えられます。
まとめ：仕組みを理解して賢くコスト削減しよう
今回は、Google Cloudで意図しない料金が発生する原因と、その対策について解説しました。
1. Artifact Registryの料金は古いイメージの蓄積が原因
2. 削除前にはCloud Runで「使用中のイメージ」を必ず確認
3. 「クリーンアップポリシー」で古いイメージの削除を自動化するのが最善策
最初は複雑に感じるかもしれませんが、一度設定してしまえば安心です。ぜひこの機会に見直してみてください。