GCP Cloud Run custom domain mapping

Cloud Runへカスタムドメインを割り当てる方法

タグ custom domain

概要

  • Cloud Runの.run.app URLへ独自ドメインを割り当てる機能
  • dashboard.example.comのようなURLを保ったままCloud Runサービスへアクセスできる
  • HTTPリダイレクトではなく、DNS、TLS、Cloud Runのルーティングを組み合わせる
  • cross domain mappingはCloud Runの正式な機能名ではなく、正式名称はcustom domain mapping
  • 2026-07-19時点で直接domain mappingはLimited availabilityかつPreview
  • Googleは本番サービスにGlobal external Application Load Balancerを推奨
  • Cloud Run自体はCloud Run記事、DNSの基本はDNS記事を参照

Route 53で取得したドメインを使う例

Route 53でexample.comを取得し、Cloud Runのサービスをdashboard.example.comで公開するケース

Route 53 domain registration
  |
  v
Route 53 Public Hosted Zone
  |-- TXT   google-site-verification
  |-- CNAME dashboard -> Google指定値
  v
Googleのフロントエンド
  |
  v
Cloud Run service

Route 53でドメインを登録すると、通常は同名のPublic Hosted Zoneと4つのName Serverが自動作成される

この場合はCloud DNSへ移管せず、Cloud Runが返したresourceRecordsをRoute 53のHosted Zoneへ追加すればよい

サブドメインがCNAMEとして返された場合の入力例

Route 53の項目 設定例
Record name dashboard.example.com
Record type CNAME
Value ghs.googlehosted.com.
Alias Off
Routing policy Simple
  • ドメイン所有権確認用のTXTレコードも同じHosted Zoneへ追加する
  • Google CloudとAWSのアカウントを連携する必要はない
  • Route 53はドメイン登録と権威DNSを担当し、Cloud RunはHTTPSの終端とサービスへのルーティングを担当する
  • CNAMEの値を固定せず、resourceRecordsに表示された値を使う
  • ルートドメインでAまたはAAAAが返された場合も、そのレコード種別と値をそのまま登録する
  • Googleの宛先をRoute 53 Aliasレコードへ置き換えない

Route 53のHosted Zoneが実際に権威DNSか確認する

$ dig +short NS example.com

表示されたName ServerがHosted Zoneの4つのName Serverと異なる場合は、現在の権威DNS側へレコードを追加する

用語の違い

用語 対象
Custom domain mapping 独自ドメインをCloud Runへ割り当てる
CORS ブラウザから別オリジンへアクセスできるかを制御する
Cross-region 複数リージョンのサービスを構成する

domain mappingを設定しても、CORS、Cookie、OAuth、IAM認証は別途設定が必要

仕組み

Cloud Runが生成するURLの代わりに独自ドメインを公開する

https://SERVICE-IDENTIFIER.REGION.run.app
                  ↓
https://dashboard.example.com

リクエストの流れ

Browser
  |
  | https://dashboard.example.com
  v
DNS
  |
  | CNAME / A / AAAA
  v
Googleのフロントエンド
  |
  | Host header / TLS SNI
  v
Cloud Run domain mapping
  |
  v
Cloud Run service

ブラウザのURLはdashboard.example.comのままになり、Google側はホスト名から対象サービスを識別する

方式を選ぶ

用途 推奨方式
開発環境、社内画面、検証用URL Cloud Run domain mapping
小規模で停止影響が軽いサービス Cloud Run domain mappingも選択肢
本番顧客向けサービス Global external Application Load Balancer
Cloud ArmorやCloud CDNが必要 Global external Application Load Balancer
パス単位で複数サービスへ振り分ける Global external Application Load Balancer
ワイルドカードやURL maskが必要 Global external Application Load Balancer

直接domain mappingには次の制約がある

  • Previewで本番利用は推奨されていない
  • カスタムドメイン経由の高レイテンシが発生する場合がある
  • 特にasia-northeast1とus-east4で高レイテンシが目立つ可能性がある
  • マッピングできるのは/だけで、/apiなどのパスは指定できない
  • ワイルドカード証明書を利用できない
  • 独自の自己管理証明書をアップロードできない
  • ドメインマッピングは64文字まで
  • TLS 1.0とTLS 1.1を無効化できない

本番向けの推奨構成

DNS A / AAAA
  |
  v
Global external Application Load Balancer
  |-- Google-managed certificate
  |-- URL map
  |-- Cloud Armor
  |-- Cloud CDN
  v
Serverless NEG
  |
  v
Cloud Run

前提

  • Cloud Runサービスがデプロイ済み
  • デフォルトのrun.app URLが有効
  • 対象ドメインのDNSレコードを変更できる
  • gcloudで対象プロジェクトとGoogleアカウントを選択済み
  • 利用リージョンが直接domain mappingへ対応している

2026-07-19時点の対応リージョン

  • asia-east1
  • asia-northeast1
  • asia-southeast1
  • europe-north1
  • europe-west1
  • europe-west4
  • us-central1
  • us-east1
  • us-east4
  • us-west1

ドメイン所有権を確認する

アカウントとプロジェクトを確認する

$ gcloud auth list
$ gcloud config get-value account
$ gcloud config get-value project

検証済みドメインを確認する

$ gcloud domains list-user-verified

dashboard.example.comを使う場合は、通常ベースドメインのexample.comを検証する

$ gcloud domains verify example.com

Search Consoleの検証画面で指定されたTXTレコードをDNSへ追加する

google-site-verification=VERIFICATION_TOKEN

検証したユーザとgcloudのアカウントを合わせる

ドメイン所有権はGoogle CloudプロジェクトのIAMだけでなく、検証したGoogleユーザにも紐づく

Search Consoleで検証したアカウント
alice@example.com

gcloudで有効なアカウント
bob@example.com

bob@example.comがプロジェクトのIAM権限を持っていても、検証済み所有者でなければ新しいマッピングを追加できない場合がある

別のユーザまたはサービスアカウントから操作する場合は、Search Consoleの検証済み所有者へ追加する

Cloud Runへドメインをマッピングする

直接domain mappingのgcloudコマンドは現在もBeta

$ gcloud beta run domain-mappings create \
  --service=SERVICE_NAME \
  --domain=dashboard.example.com \
  --region=asia-northeast1

作成済みマッピングを確認する

$ gcloud beta run domain-mappings describe \
  --domain=dashboard.example.com \
  --region=asia-northeast1

一覧を確認する

$ gcloud beta run domain-mappings list \
  --region=asia-northeast1

別サービスに割り当て済みのドメインを移す場合は--force-overrideを使えるが、既存サービスからマッピングが外れるため注意

DNSレコードを設定する

describe結果のstatus.resourceRecordsにDNSへ追加するレコードが表示される

サブドメインでの出力例

resourceRecords:
- name: dashboard
  rrdata: ghs.googlehosted.com.
  type: CNAME
  • サブドメインではCNAMEになることが多い
  • ルートドメインではAとAAAAが返る場合がある
  • ghs.googlehosted.comを決め打ちせず、resourceRecordsの全レコードをそのまま設定する
  • DNS事業者の入力形式に合わせて末尾の.やホスト名を調整する

CNAMEを確認する

$ dig +short CNAME dashboard.example.com
ghs.googlehosted.com.

ルートドメインでAまたはAAAAが返された場合はそれぞれ確認する

$ dig +short A example.com
$ dig +short AAAA example.com

以前のDNSレコードとTTLによっては反映に数時間かかる場合がある

TLS証明書とHTTPSを確認する

DNSがGoogleへ到達すると、Google-managed certificateが自動発行され、その後も自動更新される

証明書発行は通常約15分で、最大24時間かかる場合がある

マッピング状態を確認する

$ gcloud beta run domain-mappings describe \
  --domain=dashboard.example.com \
  --region=asia-northeast1 \
  --format='yaml(status.conditions,status.resourceRecords)'

HTTPSを確認する

$ curl -Iv https://dashboard.example.com/

SNIを指定して証明書を確認する

$ openssl s_client \
  -connect dashboard.example.com:443 \
  -servername dashboard.example.com </dev/null

-servernameで送るSNIを使い、Google側が対象ホストの証明書とルーティング先を識別する

証明書発行の内部実装をACMEやLet’s Encryptと決めつけず、Google-managed certificateとしてGoogleへ発行と更新を委任すると理解する

CORS、Cookie、OAuthを確認する

domain mappingはDNSとHTTPSの入口を作る機能で、CORSを変更しない

Frontend: https://dashboard.example.com
API:      https://api.example.com

scheme、host、portのいずれかが違う場合は別オリジン

API側で必要なオリジンを許可する

Access-Control-Allow-Origin: https://dashboard.example.com
Access-Control-Allow-Credentials: true
Vary: Origin
  • Cookieを使う場合はDomain、SameSite、Secureを確認する
  • OAuthを使う場合は認証事業者へ新しいredirect URIを登録する
  • Credential付きCORSではAccess-Control-Allow-Origin: *を使わない

IAM認証でcustom audienceを設定する

IAMで保護したCloud Runサービスは、ID tokenのaudが受信サービスのURLと一致する必要がある

クライアントがrun.app URLではなく独自ドメインをaudienceとして使う場合は、custom audienceを追加する

$ gcloud run services update SERVICE_NAME \
  --add-custom-audiences=https://dashboard.example.com \
  --region=asia-northeast1

この設定変更では新しいリビジョンが作成される

トラブルシューティング

ドメインを作成できない

  • gcloud config get-value accountとSearch Consoleの検証済み所有者を比較する
  • プロジェクトIAMだけで解決しない場合は、操作ユーザまたはサービスアカウントを検証済み所有者へ追加する
  • サブドメインではなくベースドメインを検証しているか確認する

証明書が発行されない

  • resourceRecordsの全レコードを設定したか確認する
  • 古いA、AAAA、CNAMEが競合していないか確認する
  • デフォルトのrun.app URLが有効か確認する
  • DNSのTTLと伝播を確認する
  • CDNやプロキシが証明書検証リクエストを遮断していないか確認する
  • Cloudflareを使う場合はAlways use HTTPSが検証を妨げていないか確認する
  • 最大24時間までは証明書発行を待つ

カスタムドメインだけ遅い

  • run.app URLとカスタムドメインの応答時間を比較する
  • asia-northeast1またはus-east4では既知の高レイテンシ問題を確認する
  • 本番用途ではGlobal external Application Load BalancerとServerless NEGへ移行する

IAM認証で401または403になる

  • ID tokenのaudを確認する
  • 独自ドメインをcustom audienceへ追加する
  • 呼び出し元にroles/run.invokerがあるか確認する

マッピングを削除する

$ gcloud beta run domain-mappings delete \
  --domain=dashboard.example.com \
  --region=asia-northeast1

削除後は不要になったDNSレコードも削除する

参考