App Engine がアプリに提供するデフォルトのアドレスではなく、カスタム ドメインを使用できます。
カスタム ドメインを使用するには、ドメインをアプリにマッピングしてから、DNS レコードを更新します。example.com のようなネイキッド ドメインや、subdomain.example.com のようなサブドメインをマッピングできます。ワイルドカードを使用してサブドメインをマッピングすることもできます。
デフォルトでは、ドメインをアプリにマッピングすると、App Engine は HTTPS 接続用のマネージド SSL 証明書を発行します。独自の SSL 証明書の使用方法をはじめとするカスタム ドメインでの SSL の使用法の詳細は、SSL によるカスタム ドメインの保護をご覧ください。
カスタム ドメインを使用すると、一部のリージョンで App Engine がアプリのユーザーに送信するレスポンスに、著しいレイテンシが発生することがあります。リージョンは以下のとおりです。
- us-west2
- us-east4
- northamerica-northeast1
- southamerica-east1
- europe-west2
- europe-west3
- asia-south1
- asia-northeast1
- australia-southeast1
App Engine のカスタム ドメインは、すべてのアプリケーションに共有 IP アドレスのプールを使用します。ドメインにのみマッピングする IP アドレスを使用する場合は、App Engine でロードバランサを設定する必要があります。これにより、SNI 証明書内のアプリケーション A へのリクエストが HTTP Host ヘッダー内のアプリケーション B にルーティングされる可能性がある、ドメイン フロンティングの問題が軽減されます。
始める前に
ドメインをお持ちでない場合は、ドメインを購入してください。任意のドメイン名登録事業者を使用できますが、Google Domains を使用する場合は、App Engine のドメインが自動的に検証されるため、ドメイン検証プロセスを行う必要はありません。
Cloud Load Balancing とサーバーレス NEG を使用して App Engine アプリにトラフィックをルーティングする場合は、カスタム ドメインをアプリに直接マッピングするのではなく、ロードバランサにマッピングし、ロードバランサ用に作成された SSL 証明書を使用することを推奨します。これにより、サーバーレス アプリごとに個別の SSL 証明書を管理する必要がなくなります。さらに、Cloud Load Balancing を使用すると、ロードバランサがクライアントとネゴシエートする際に使用する SSL の機能を制御する SSL ポリシーを設定できます。詳しくは次のページをご覧ください。
次の制限に注意してください。
- アプリがロードバランサ（および使用している場合は VPC）から送信されたリクエストのみを受信するように、上り（内向き）制御を使用することをおすすめします。使用しない場合、ユーザーはアプリの App Engine URL を使用して、ロードバランサ、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、ロードバランサを経由して渡される秘密鍵をバイパスできます。
カスタム ドメインをアプリにマッピングする
Google Cloud Console で、App Engine の [設定] ページの [アプリケーションの設定] タブに移動します。
デフォルトの Google Accounts API リファラーを変更する必要がない場合は、次の手順に進みます。
カスタム ドメインで G Suite 認証を有効にする必要がある場合は、[編集] をクリックして、Google Accounts API リファラーを変更します。[Google Authentication] プルダウン メニューで [G Suite ドメイン] を選択し、空のフィールドに
example.comなどのドメインを追加します。Google Cloud Console で、App Engine の [設定] ページの [カスタム ドメイン] タブに移動します。
[カスタム ドメインを追加してください] をクリックします。
ドメインがすでに確認済みの場合、[使用するドメインを選択する] セクションにドメインが表示されます。プルダウン メニューからドメインを選択して、[続行] をクリックします。
まだドメインを確認していない場合は、次の手順を行います。
- プルダウン メニューから [新しいドメインの所有権を証明] を選択します。
ネイキッド ドメイン名（example.com など）を入力し、[確認] をクリックします。
www.example.com などのサブドメインのみをマッピングする場合でも、ネイキッド ドメイン名を入力して所有権を確認します。
ドメイン名は 64 バイト未満にする必要があります。
表示されるウェブマスター セントラル ウィンドウに情報を入力します。ウェブマスター セントラルの使用方法については、ウェブマスター セントラルのヘルプをご覧ください。
ウェブマスター セントラルで手順を完了したら、Google Cloud Console の [新しいカスタム ドメインの追加] ページに戻ります。
[ドメインを [project-ID] に指定する] セクションで、マッピングするドメインとサブドメインを指定します。
ネイキッド ドメインと
wwwサブドメインをマッピングすることをおすすめします。サブドメインは必要に応じて追加できます。必要なマッピングをすべて追加したら、[マッピングを保存] をクリックします。
ドメインの DNS レコードを確認するには、[続行] をクリックしてください。
これらのレコードは、App Engine の [設定] ページの [カスタム ドメイン] タブでいつでも取得できます。
ドメイン登録事業者のウェブサイトにログインし、前の手順で表示されたレコードを使用して DNS レコードを更新します。
ドメイン登録事業者で DNS レコードを更新する
App Engine でサービスをカスタム ドメインにマッピングしたら、ドメイン登録事業者で DNS レコードを更新する必要があります。利便性のため、入力に必要な DNS レコードは、App Engine によって生成され、表示されます。
ドメイン マッピングの DNS レコード情報を取得します。
Google Cloud Console で、App Engine の [設定] ページの [カスタム ドメイン] タブに移動します。このページには、アプリにマッピングされているすべてのドメインの DNS レコードが一覧表示されます。
ドメイン登録事業者のアカウントにログインし、DNS 構成ページを開きます。
ドメインの構成ページのホストレコード セクションを見つけ、ドメインをアプリにマッピングしたときに取得した各 DNS レコードを追加します。
レコード フィールドに次の情報を入力します。
- レコードタイプ: Google が作成した DNS レコードに表示されるレコードタイプ（
A、AAAA、CNAME）を入力します。 - レコード名:
AまたはAAAAレコードに、「@」を入力します。CNAMEレコードに、第 3 レベルのドメイン名を入力します。たとえば、www.example.comサブドメインをマッピングするには「www」と入力します。
- TTL: 必要に応じて、TTL を指定します。
- データ: Google が作成した DNS レコードに表示されるレコードデータ（rrdata）を入力します。
AまたはAAAAレコードでは、レコードデータは IP アドレスです。CNAMEレコードでは、レコードデータはドメイン名です。
- レコードタイプ: Google が作成した DNS レコードに表示されるレコードタイプ（
ドメインのアカウントの DNS 構成ページで変更を保存します。通常、この変更が反映されるまでに数分しかかかりませんが、登録事業者やドメインの以前の DNS レコードに設定されている有効期間（TTL）によっては、数時間かかることもあります。このオンラインの
digバージョンなどのdigツールを使用して、DNS レコードが正常に更新されたことを確認できます。新しい URL（
https://www.example.comなど）でサービスを閲覧して、成功したかどうかをテストします。自動 SSL 証明書の発行には数分かかる場合があるので注意してください。
他の Google Cloud ユーザーまたはサービス アカウントに所有権を委任する
ドメインの所有権を他のユーザーまたはサービス アカウントに委任する必要がある場合は、ウェブマスター セントラルのページで権限を追加できます。
ウェブマスター セントラル確認ページを開きます。
[プロパティ] で、ユーザーまたはサービス アカウントを追加するドメインをクリックします。
[Verified owners] リストの最後にある [Add an owner] をクリックし、Google アカウントのメールアドレスまたはサービス アカウント ID を入力します。
サービス アカウントのリストを表示するには、Cloud Console の [サービス アカウント] ページを開きます。
サブドメインを使用する
カスタム ドメインにワイルドカード サブドメイン マッピングを設定すると、アプリケーションは、一致するサブドメインに対するリクエストを処理します。
- アプリケーションのバージョン名またはサービス名と一致するドメインが参照されると、アプリケーションはそのバージョンを提供します。
- サービス名と一致するドメインが参照されると、アプリケーションはそのサービスを提供します。
- マネージド SSL 証明書には上限（ベースドメインごとに週あたり 20 個）があります。上限に達した場合、App Engine はすべてのリクエストの処理が完了するまで、マネージド証明書を発行しようとし続けます。
ワイルドカード マッピング
ワイルドカードを使用すると、第 3 レベル以降であればどのレベルのサブドメインでもマッピングできます。たとえば、使用するドメインが example.com の場合、ウェブアドレス フィールドにテキストを入力すると次のような結果になります。
- 「
*.example.com」と入力すると、example.comのすべてのサブドメインがアプリにマッピングされます。 - 「
*.private.example.com」と入力すると、private.example.comのすべてのサブドメインがアプリにマッピングされます。 - 「
*.nichol.sharks.nhl.example.com」と入力すると、nichol.sharks.nhl.example.comのすべてのサブドメインがアプリにマッピングされます。 - 「
*.excogitate.system.example.com」と入力すると、excogitate.system.example.comのすべてのサブドメインがアプリにマッピングされます。
dispatch.yaml ファイルを使用して、特定のサービスに対するリクエストのルーティングを定義すると、App Engine のサービスでワイルドカード マッピングを使用できます。
sites や mail など、ドメイン内のその他のサブドメインで Google Workspace を使用する場合、これらのマッピングの優先順位が高くなり、ワイルドカード マッピングが行われる前に最初に照合されます。また、他の App Engine アプリを他のサブドメインにマッピングしている場合にも、これらのマッピングはワイルドカード マッピングよりも優先順位が高くなります。
DNS プロバイダによってはワイルドカード サブドメイン マッピングに対応していないことがあります。特に、CNAME ホストエントリでのワイルドカードの使用が許可されているかどうかに注意が必要です。
ワイルドカード ルーティング ルールは、App Engine のサービス ルーティング ルールに従って、サービス、バージョン、インスタンスのコンポーネントを含む URL に適用されます。
トラブルシューティング
G Suite ドメイン認証を使用してカスタム ドメインを構成した後に認証エラーが表示される場合は、カスタム ドメイン マッピングを削除し、カスタム ドメインとアプリのマッピング手順をやり直します。App Engine でカスタム ドメイン マッピングを構成する前に、G Suite ドメイン認証を構成します。