Cloud Run と Supabase。
どちらも 「無料枠が大きい」 という評判をよく耳にするサービスだ。
実際、自分も
「うまく組み合わせれば、ほぼ無料で Web サービスを運営できるのでは？」
と考え、低コスト運用を目的にこの構成を選んだ。
結論から言うと、思っていたほど低コストにはならなかった。
むしろ、いくつかの点で 「これは相性が良くない」 と感じる部分すらあった。
この記事では、
なぜ Cloud Run × Supabase という “強そうな構成” が、
自分の想定した 「低コスト運用」 からズレていったのか、
実際にハマったポイントを正直に書いていく。
同じように
「無料枠でなんとかしたい」
「個人開発だからコストは極力かけたくない」
と考えている人の参考になれば幸いだ。
やりたかったこと
Supabase の無料枠
| 項目 | 内容 |
|---|---|
| API リクエスト | 無制限 |
| 月間アクティブユーザー | 50,000 MAU |
| データベース容量 | 500 MB |
| 実行環境 | Shared CPU / 500 MB RAM |
| データ転送（egress） | 5 GB |
| キャッシュ付き egress | 5 GB |
| ファイルストレージ | 1 GB |
| サポート | Community support |
Cloud Run の無料枠
| 項目 | 内容 |
|---|---|
| リクエスト数 | 200 万リクエスト / 月 |
| メモリ使用量 | 360,000 GB 秒 / 月 |
| vCPU 使用量 | 180,000 vCPU 秒 / 月 |
| アウトバウンド通信 | 1 GB / 月（北米） |
| 備考 | その他の制限は Cloud Run の料金表に準拠 |
当初の目論見
これら 2 つの 無料枠を組み合わせることで、
- 最大 200 万リクエスト / 月
- DB サイズ 〜 5 GB 程度
- アプリケーションサーバーは Cloud Run
- DB・認証・ストレージは Supabase
という構成を、ほぼ 0 円で運営することを狙っていた。
現実
Supabase に関して押さえておきたい前提条件
- Cloud Run などのバックエンドサーバーからアクセスする場合は、Data API を使わずに DB へ直接アクセスするのが望ましい
Supabase が提供している Data API（PostgREST）は手軽に使える一方で、
バックエンドサーバー経由のアクセスでは レイテンシやオーバーヘッドが増えやすい。
このため、Cloud Run などのサーバーサイドから利用する場合は
Data API ではなく 直接 DB に接続する構成を選ぶのが一般的になる。
これに関して詳しくこちらの記事にまとめた。
- Supabase の無料枠では Database Connection の上限が 42 本と比較的厳しい
Supabase の無料プランでは、利用できる 同時接続数（Database Connection）に明確な上限がある。
デフォルトでは 15 本 に制限されており、
設定を変更することで最大 42 本 まで引き上げることは可能だが、
それでも スケーラブルなバックエンド構成としてはかなり少なめである。
特に Cloud Run のように 同時に複数のインスタンスが起動する環境では、
接続数の管理を意識せずに使うとすぐに上限に達する。
これに関して詳しくこちらの記事にまとめた。
- DB へ直接アクセスする場合、接続元 IP アドレスでアクセス制限をかけたい
Supabase の DB をインターネット越しに直接公開する以上、
誰でも接続できる状態にしておくのはセキュリティ的に避けたい。
そのため、実運用では- 接続元 IP アドレスを限定する
- 想定外のアクセスを遮断する
といった対策を取るのが前提になる。
Cloud Run に関して押さえておきたい前提条件
-
セキュリティの都合上、Cloud Run の前段に Load Balancer を置く必要がある
Cloud Run はインターネットから直接公開することも可能だが、
実運用を考えると その構成はあまり推奨されない。
例えば、- WAF による攻撃対策
- アクセス制御やレート制限
- HTTPS 証明書の一元管理
といった要件を満たそうとすると、
Cloud Load Balancer を前段に置く構成が事実上の前提になる。
特に、不特定多数からアクセスされる Web サービスでは、
Load Balancer を置かない選択肢は取りづらい。
-
複数の VM を起動して水平スケールできるのが Cloud Run の強み
Cloud Run の大きなメリットは、
トラフィックに応じて 自動的にインスタンス数を増減できる点にある。
リクエストが増えれば複数の VM が起動し、
負荷が下がれば自動的にスケールダウンする。
これにより、インフラ管理をほとんど意識せずに
高いスケーラビリティを実現できる。ただし、この仕組み上、
Cloud Run 単体では送信元の IP アドレスを固定できない。
インスタンスが増減するたびに IP が変わるため、
接続元 IP による制限を前提とした構成とは相性が悪い。
これらを考慮した実際の構成
上記の前提条件をすべて満たそうとすると、構成は次のようになる。
- Load Balancer（固定 IP）
- Cloud Run
- Cloud NAT（固定 IP）
- Supabase
※ 実際には DNS、証明書、Cloud Router などの設定も必要になるが、話を簡単にするためここでは省略する。
Cloud NAT を置いている理由は、
Supabase 側で接続元 IP アドレスを制限するためである。
この構成のデメリット
1. コストが思ったより高い
少なく見積もっても
- Load Balancer: 約 18 ドル / 月
- Cloud NAT: 約 7 ドル / 月
合計 25 ドル / 月程度 は発生する。
これが、
「Cloud Run と Supabase で低コスト運用しようと思ったら無理だった」
と感じた 最大の理由 である。
2. Supabase と Cloud Run の相性が悪い（セキュリティ面）
Cloud Run はリクエストに応じて 複数の VM を動的に起動する。
そのため、
- 接続元 IP を制限したい
- 固定 IP を使いたい
という要件を満たすために、
本来不要な Cloud NAT を挟まざるを得ない構成になる。
もし固定の VM（例: Compute Engine）であれば、
この問題は発生しない。
3. Supabase と Cloud Run の相性が悪い（パフォーマンス面）
Cloud Run の最大のメリットは、
高いスケーラビリティを簡単に実現できることにある。
しかし Supabase の無料枠では、
- Database Connection 数に厳しい上限がある
- 同時接続数を考慮すると VM 数を増やせない
結果として、
Cloud Run のスケール性能を意図的に制限せざるを得ない。
つまり、
Cloud Run の良さを ほとんど活かせていない構成になってしまった。
Cloud Run と Supabase を使いながら回避する方法はないのか？
結論から言うと、現実的な回避策はない。
- Load Balancer を置かない
- Cloud NAT をやめて接続元 IP 制限をかけない
といった選択肢も考えられるが、
どちらも セキュリティ上好ましくない構成になる。
特に、
- バックエンドサーバーを直接インターネットに公開する
- DB を IP 制限なしで外部公開する
といった状態は、
個人開発であっても避けるべきである。
そのため、
セキュリティをある程度真面目に考えるなら、この構成を簡略化することはできない。
結果として、Cloud Run × Supabase での「低コスト運用」は成立しなかった。
代替案
コストをかけられる場合
コストを許容できるのであれば、
DB も含めてすべて Google Cloud 上に寄せる構成の方が、
ネットワーク設計・セキュリティ設計ともにシンプルになる。
Cloud SQL や AlloyDB を使えば、
- VPC 内通信
- IP 制限や IAM ベースの制御
- Cloud Run との親和性
といった点で扱いやすい。
ただし、
個人開発用途としてはコストが高いのが正直なところだ。
個人開発向けの現実的な選択肢
そのため筆者は、
Cloudflare を活用した構成を検討している。
Cloudflare Workers や D1 などを使えば、
- 低コスト
- セキュリティを意識した構成
- 運用負荷の低さ
といった点で、
個人開発用途にはより現実的な選択肢になり得ると考えている。
まとめ
Cloud Run × Supabase は安くない。
無料枠だけを見ると相性が良さそうに見えるが、
セキュリティや実運用を考慮すると
追加コストを避けられない構成になる。
「無料枠が大きい」という理由だけで構成を選ぶと、
思った以上にコストがかかることもある。
この経験が、
これから同じ構成を検討している人の参考になれば幸いだ。
