業務で、ある Google API のキーに送信元 IP 制限をかけようとしたところ、設定しても一向に効かない、という現象にハマりました。原因を追っていくと、Cloud Run のネットワーク経路、特に Private Google Access（PGA）の挙動に行き着きました。
同じところでハマる人がいそうなので、備忘録もかねて整理しておきます。少しでも同じような状況の方の参考になれば幸いです。
何が起きたか
やりたかったのは、漏洩時の被害を抑えるために、Google API のキーへ送信元 IP 制限をかけることでした。「Cloud Run の egress IP を許可リストに入れればいいだろう」と考えていたのですが、設定しても弾かれません。Cloud NAT の固定 IP を許可リストに入れているのに、なぜか効かないのです。
結論から言うと、PGA が有効なサブネットでは、Google API 宛のトラフィックが Cloud NAT を経由していなかった、というのが原因でした。
Private Google Access（PGA）とは
PGA（Private Google Access）は、外部 IP を持たない VM やサービスが、VPC 内部の経路を通って *.googleapis.com などの Google API へ直接到達できる仕組みです。インターネットへ出ずに Google サービスへアクセスできるのが利点で、サブネット単位で有効化します。
Terraform では、サブネットの1行で有効になります。
resource "google_compute_subnetwork" "egress" {
name = "sb-egress-example"
private_ip_google_access = true # ← これが PGA
# ...
}
そして Cloud Run は Direct VPC Egress でこのサブネットに接続します。
metadata:
annotations:
run.googleapis.com/network-interfaces: '[{"network":"...","subnetwork":".../sb-egress-example"}]'
run.googleapis.com/vpc-access-egress: all-traffic
vpc-access-egress: all-traffic は、すべての egress を VPC 経由にする設定です。ここまではよくある構成に見えます。
Google API 宛は NAT を通らない
重要なのは、PGA が有効なサブネットでの Google API 宛トラフィックの経路です。図にすると、次のように分岐しています。
[PGA 有効サブネットのとき]
Cloud Run ──┬─ *.googleapis.com 宛 ──▶ 内部網経由（PGA）で直接 Google へ
│ ※ Cloud NAT を通らない
│ ※ 送信元は内部 IP
│
└─ それ以外のインターネット宛 ──▶ Cloud NAT ──▶ NAT の固定外部 IP
つまり、こういうことが起きていました。
- インターネット宛の一般的な通信は Cloud NAT を経由するので、送信元は NAT の固定外部 IP になる
- ところが
*.googleapis.com宛は PGA の内部経路を通るため、NAT を経由しない - その結果、Google API 側から見た送信元は、NAT の外部 IP ではなく内部 IP になる
API キーの IP 制限は、公開 IP（パブリック IP）でのみ受け付ける性質のものです。そのため、内部 IP でやってくる PGA 経由のリクエストには、そもそも IP 制限が効きようがなかったわけです。「外部 IP で固定できない」というのは、この意味でした。
この挙動は Cloud NAT の公式ドキュメントにも明記されています。
Note: Traffic sent to Google APIs and services are routed through Private Google Access even if the VM instance initiating the connections uses Public NAT. For more information, see Private Google Access interaction.
つまり「Public NAT を使っていても、Google API 宛だけは PGA 経由で流れる」ということが、仕様としてはっきり書かれています。
ちなみに Cloud NAT 側は、固定の外部 IP を割り当てる構成にしてあります。
resource "google_compute_router_nat" "nat" {
name = "nat-example"
nat_ip_allocate_option = "MANUAL_ONLY" # 手動で固定 IP を割り当て
nat_ips = [google_compute_address.nat.self_link]
source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}
NAT 経由で出れば送信元はこの固定 IP になるのですが、PGA が有効なかぎり Google API 宛だけはこの NAT を通らない、というのが落とし穴です。
対策：IP 制限を効かせたいなら PGA を無効にする
Google API への送信元 IP を固定して、API キーの IP 制限を効かせたい場合は、そのサブネットの PGA を無効化します。
resource "google_compute_subnetwork" "egress" {
private_ip_google_access = false # PGA を無効化
}
PGA を無効にすると、Google API 宛のトラフィックも Cloud NAT を経由して、インターネット側から Google へ出るようになります。送信元が NAT の固定外部 IP になるので、ようやく API キーの IP 制限が原理的に機能するようになります。
経路が NAT に変わったことの確認は、Cloud NAT のフローログで *.googleapis.com 宛（Google の ASN 15169）のエントリが出現するかどうかで取れます。PGA が有効なときは、ここに Google 宛が現れません（NAT を通らないためです）。
どちらを選ぶか
整理すると、次のような違いになります。
| 観点 | PGA 有効 | PGA 無効（NAT 経由） |
|---|---|---|
| Google API への到達 | 内部網経由で直接 | インターネット経由（NAT） |
| 送信元 IP | 内部 IP（固定不可） | NAT の固定外部 IP |
| API キーの IP 制限 | 効かない | 効く |
| インターネットへの露出 | 少ない | NAT 経由で出る |
セキュリティの観点だけ見れば、「インターネットに出ない」PGA のほうが望ましく見えます。ですが、API キーの IP 制限という別のガードを効かせたい場合は、あえて NAT 経由にする選択が必要になる、というのが今回の学びでした。
おわりに
Cloud Run で Google API 宛の送信元 IP がうまく固定できないときは、まず PGA の有効・無効を疑ってみると良いでしょう。同じところでハマっている方の参考になれば幸いです。