このページは Cloud Translation API によって翻訳されました。

インターネットネットワークエンドポイントグループの概要

Cloud Load Balancing は、Google Cloud の外部にあるバックエンドへのトラフィックのプロキシをサポートしています。ロードバランサの外部バックエンドを定義するには、インターネットネットワークエンドポイントグループ（NEG）と呼ばれるリソースを使用します。

このタイプのデプロイは、外部バックエンドからコンテンツを提供し、Google Cloud ロードバランサをフロントエンドにする場合に使用できます。これにより、次のことが可能になります。

Google Edge インフラストラクチャを使用してユーザー接続を終了できます。
接続を外部バックエンドに転送できます。
グローバルロードバランサでは、Cloud CDN を使用して外部バックエンドのコンテンツをキャッシュに保存できます。
Google のプライベートバックボーンを通じてパブリックエンドポイントへトラフィックを転送することで、信頼性が向上し、クライアントとサーバー間のレイテンシが減少します。

図 1 は、複数の種類のバックエンドを使用する外部アプリケーションロードバランサを示しています。バックエンドの 1 つは外部バックエンドで、インターネット NEG を使用して構成されています。

ロードバランシングでのインターネットネットワークエンドポイントグループ。 — **図 1.** ロードバランシングでのインターネットネットワークエンドポイントグループ（クリックして拡大）

インターネット NEG バックエンドは、さまざまなグローバルロードバランサとリージョンロードバランサでサポートされています。ロードバランサ（グローバルまたはリージョン）によって、インターネット NEG のサポートは、DNS、ヘルスチェック、使用可能なエンドポイント数、トラフィックルーティング動作の点で異なります。

以降のセクションでは、Cloud Load Balancing で外部バックエンドを使用する方法について説明します。Traffic Director で外部バックエンドを使用する場合は、インターネットネットワークエンドポイントグループを使用する Traffic Director をご覧ください。

用語

次の用語は、同じ意味または類似の意味を持つため、区別されずに使われることがよくあります

外部バックエンド: Google Cloud の外部にあり、インターネット経由で到達可能なバックエンド。インターネット NEG 内のエンドポイント。
カスタムの送信元: 外部バックエンドと同じです。CDN では、ウェブコンテンツを配信するバックエンドインスタンスを表す標準用語として「送信元」が使用されます。
インターネットネットワークエンドポイントグループ（NEG）: 外部バックエンドの指定に使用する Google Cloud API リソース。
外部エンドポイント: 外部バックエンドと同じです。

このドキュメントでは、インターネット NEG API リソースを指す場合を除いて、外部バックエンドという用語を使用します。

ロードバランサコンポーネント

このセクションでは、外部バックエンドを使用するロードバランサの構成に必要なロードバランシングアーキテクチャとリソースについて説明します。ロードバランサには、バックエンドサービス専用の特別な構成が必要です。フロントエンドの構成は他のロードバランサと同じです。

次の図は、外部バックエンドを使用するロードバランサを設定するために必要な Google Cloud リソースを示しています。

グローバル外部

この図は、外部バックエンドを使用するグローバル外部アプリケーションロードバランサの設定に必要な Google Cloud リソースを示しています。

リージョン外部

この図は、外部バックエンドを使用するリージョン外部アプリケーションロードバランサの設定に必要な Google Cloud リソースを示しています。

この図は、外部バックエンドを使用するリージョン外部プロキシネットワークロードバランサの設定に必要な Google Cloud リソースを示しています。

リージョン内部

この図は、外部バックエンドを使用するリージョン内部アプリケーションロードバランサの設定に必要な Google Cloud リソースを示しています。

次の図は、外部バックエンドを使用するリージョン内部プロキシネットワークロードバランサの設定に必要な Google Cloud リソースを示しています。

インターネット NEG はプレミアムネットワークサービスティアでのみ使用できます。

フロントエンドの構成

インターネット NEG バックエンドを使用するロードバランサを作成する場合、特別なフロントエンド構成は必要ありません。転送ルールは、IP アドレス、ポート、プロトコルに基づいてトラフィックをターゲットプロキシに転送するために使用されます。ターゲットプロキシはクライアントからの接続を終端します。また、Envoy ベースのロードバランサにはプロキシ専用サブネットが必要です。

また、アプリケーションロードバランサは、URL マップを使用して、適切なバックエンドサービスへのリクエストの URL ベースの転送を設定します。

これらの各コンポーネントの詳細については、各ロードバランサのアーキテクチャセクションをご覧ください。

インターネット NEG

インターネット NEG は、ロードバランサの外部バックエンドを定義するために使用されるリソースです。インターネット NEG で参照される外部バックエンドは、インターネット経由でアクセス可能である必要があります。エンドポイントには、Cloud VPN または Cloud Interconnect 経由以外でも接続できる必要があります。外部バックエンドが Google API または Google サービスを参照している場合、サービスは HTTP、HTTPS、または HTTP/2 プロトコルを使用して、TCP ポート 80 か 443 経由で接続可能である必要があります。

NEG によって参照される外部エンドポイントを構成する場合、INTERNET_FQDN_PORT と INTERNET_IP_PORT の 2 つの方法があります。さらに、これらの各エンドポイントは、グローバルまたはリージョンの 2 つのスコープで使用できます。

次の表を使用して、2 つのエンドポイントの違いと、グローバルスコープとリージョンスコープでの動作について確認してください。

ロードバランサ	エンドポイントのタイプ	エンドポイントの定義	スコープ	ヘルスチェック
グローバル外部アプリケーションロードバランサ従来のアプリケーションロードバランサ	`INTERNET_FQDN_PORT`	公開で解決可能な完全修飾ドメイン名とオプションのポート。例: `backend.example.com:443`¹ ドメイン名は、Google のパブリック DNS インフラストラクチャで解決可能である必要があります。 NEG ごとに使用できるエンドポイントは 1 つだけです。	グローバル	非対応
グローバル外部アプリケーションロードバランサ従来のアプリケーションロードバランサ	`INTERNET_IP_PORT`	パブリックルーティングが可能な IP アドレスとオプションのポート。例: `8.8.8.8:443`¹ IP アドレスを RFC 1918 アドレスにすることはできません。 NEG ごとに使用できるエンドポイントは 1 つだけです。	グローバル	非対応
リージョン外部アプリケーションロードバランサリージョン内部アプリケーションロードバランサリージョン外部プロキシネットワークロードバランサリージョン内部プロキシネットワークロードバランサ	`INTERNET_FQDN_PORT`	公開で解決可能な完全修飾ドメイン名とオプションのポート。例: `backend.example.com:443`² ドメイン名は、Cloud DNS または Google のパブリック DNS インフラストラクチャによって解決可能である必要があります。 NEG あたりの最大エンドポイント数は 256 です。	リージョン	Envoy の分散ヘルスチェック
	`INTERNET_IP_PORT`	パブリックルーティングが可能な IP アドレスとオプションのポート。例: `8.8.8.8:443`² IP アドレスを RFC 1918 アドレスにすることはできません。 NEG あたりの最大エンドポイント数は 256 です。	リージョン	Envoy の分散ヘルスチェック

¹ エンドポイントを追加するときにポートを指定しないと、NEG のデフォルトポートが使用されます。NEG のデフォルトポートが指定されていない場合は、バックエンドプロトコルの既知のポートが使用されます（HTTP の場合は 80、HTTPS と HTTP/2 の場合は 443）。

² リージョンインターネット NEG では、ポートを指定する必要があります。デフォルトポートの指定は、NEG の作成時だけでなく、NEG にエンドポイントを追加するたび行うことができます。エンドポイントを追加するときにポートを指定しないと、NEG のデフォルトポートが使用されます。

リージョン `INTERNET_FQDN_PORT` エンドポイントの DNS 解決

ドメインがインターネット経由で解決できる場合は、DNS の設定に他の構成は必要ありません。ただし、プライベート FQDN を解決する場合は、DNS の解決が容易になるように Cloud DNS を構成する必要があります。この名前は Cloud DNS でホストされているか、Cloud DNS からオンプレミス DNS への DNS 転送によって解決できる必要があります。

まず、プロジェクトで DNS レコードをホストする Cloud DNS ゾーンを作成します。次に、DNS レコードを追加します。具体的な構成手順については、Cloud DNS のドキュメントをご覧ください。

共有 VPC を使用している場合は、具体的なネットワーク要件に注意してください。転送ゾーンなど、Cloud DNS の他の機能を使用して、オンプレミスの DNS サーバーからレコードを取得することもできます。

グローバル `INTERNET_FQDN_PORT` エンドポイントの IP アドレスの解決

INTERNET_FQDN_PORT エンドポイントが複数の IP アドレスを返す DNS レコードを指す場合、IP アドレスは次のように解決されます。

ロードバランサは、インターネット上のクライアントに最も近い Google Cloud リージョンの DNS リゾルバを使用します。INTERNET_FQDN_PORT エンドポイントの DNS レコードがクライアントのロケーションに応じて異なる IP アドレスを返す場合は、ロードバランサが各 IP アドレスにアクセスできることを確認します。
ロードバランサは、DNS レスポンスの最初の IP アドレスへの接続を試みます。その IP アドレスに到達できない場合、ロードバランサは HTTP 502 (Bad Gateway) レスポンスを返します。これは、DNS レスポンスからの他の IP アドレスに到達できる場合も当てはまります。

Google の DNS リゾルバインフラストラクチャで使用される IP 範囲とロケーションの詳細については、Google Public DNS のドキュメントをご覧ください。パブリック DNS システムで解決できない名前は、外部バックエンドとして使用できません。

リージョン `INTERNET_FQDN_PORT` エンドポイントの IP アドレスの解決

リージョンインターネット NEG は、Cloud DNS と Google のパブリック DNS の両方を使用するドメイン名の解決をサポートしています。パブリック DNS サーバーの場合、Cloud DNS はトラフィックをパブリック DNS サーバーに転送します。

DNS サーバーが複数の IP アドレスを返す場合、Envoy は、構成されたロードバランシングアルゴリズム（ラウンドロビン、最小リクエストなど）に基づいて、返された IP アドレス間でトラフィックをロードバランスします。エンドポイントのリストは、DNS TTL に基づいて定期的に更新されます。再試行ポリシーを構成すると、Envoy で IP アドレスへの接続に失敗した場合に別の IP アドレスへの接続を試行させることができます。

バックエンドサービス

バックエンドサービスは、ロードバランサに構成情報を提供します。ロードバランサは、バックエンドサービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。

外部バックエンドを使用するロードバランサを設定するには、インターネット NEG バックエンドを使用してバックエンドサービスを構成します。インターネット NEG をバックエンドサービスに追加する場合は、NEG の範囲に応じて次の考慮事項が適用されます。

バックエンドサービスは、他のバックエンドタイプ（ゾーン NEG やインスタンスグループなど）をバックエンドとして使用できません。
バックエンドサービスあたりの NEG 数
- グローバル NEG。バックエンドサービスに追加できるインターネット NEG バックエンドは 1 つだけです。
- リージョン NEG。同じバックエンドサービスに最大 50 個のインターネット NEG を追加できます。
NEG あたりのエンドポイント数
- グローバル NEG。インターネット NEG に追加できるエンドポイントは 1 つのみです。
各グローバルインターネット NEG では 1 つのエンドポイントしか使用できないため、ロードバランシングは実際には実行されません。ロードバランサはフロントエンドとしてのみ機能し、トラフィックを指定された外部バックエンドにプロキシします。つまり、レート、接続、使用率などのロードバランシングモードは使用できません。
- リージョン NEG。1 つのバックエンドサービスには、NEG ごとに最大 256 個のエンドポイントを追加できます。
リージョン NEG は、レート、接続、使用率などのロードバランシングモードをサポートしていません。バックエンドサービスに接続されているすべての NEG のすべてのエンドポイントが 1 つのグループにプールされます。このエンドポイントのプール間のロードバランシングトラフィックは、Envoy ロードバランシングアルゴリズムを使用して処理されます。サポートされているロードバランシングポリシーアルゴリズムについては、リージョンバックエンドサービス API ドキュメントの localityLbPolicy をご覧ください。
ヘルスチェック
- グローバル NEG。バックエンドサービスではヘルスチェックを参照できません。
- リージョン NEG。ロードバランサは、分散 Envoy ヘルスチェックを使用します。
バックエンドサービスのロードバランシング方式は、デプロイするロードバランサが必要とする方式と一致する必要があります。完全なリストについては、バックエンドサービスをご覧ください。
バックエンドサービスプロトコルは、HTTP、HTTPS、HTTP2 のいずれかにする必要があります。

インターネット NEG を使用してバックエンドサービスを構成する場合は、プロトコルとして HTTPS または HTTP/2 のいずれかを使用することを強くおすすめします。これにより、ロードバランサとバックエンド間の通信が公共のインターネットで転送される際に、暗号化と認証が行われます。

また、バックエンドプロトコルとして HTTPS または HTTP/2 を使用する場合は、必ず INTERNET_FQDN_PORT エンドポイントを使用して外部バックエンドを作成してください。これには、次の 2 つの利点があります。
- ロードバランサは、外部バックエンドによって提示された SSL サーバー証明書を検証し、次の情報が正しいことを確認します。
  - 証明書が既知の認証局（CA）によって署名されていること。
  - 証明書の有効期限が切れていないこと。
  - 証明書の署名が有効であること。
  - 構成された FQDN が、証明書内のサブジェクト代替名（SAN）のいずれかと一致すること。
  INTERNET_IP_PORT エンドポイントを使用して外部バックエンドを作成した場合、SSL サーバー証明書の検証は行われません。
- SSL Server Name Indication（SNI）拡張機能は、INTERNET_FQDN_PORT エンドポイントでのみサポートされています。ロードバランサと外部エンドポイント間の SSL handshake 中の client hello 内で、構成された FQDN が SNI に送信されます。IP アドレスリテラルが SNI ペイロードの HostName フィールドで許可されないため、SNI は INTERNET_IP_PORT エンドポイントの使用時に送信されません。

ヘルスチェック

ヘルスチェックの構成は、ロードバランサの種類によって異なります。

グローバル外部アプリケーションロードバランサと従来のアプリケーションロードバランサグローバルインターネット NEG を使用するバックエンドサービスは、ヘルスチェックをサポートしていません。

外部バックエンドにアクセスできない場合、または構成されたホスト名（FQDN）を解決できない場合、ロードバランサは HTTP 502 (Bad Gateway) レスポンスをクライアントに返します。

リージョン外部アプリケーションロードバランサ、リージョン内部アプリケーションロードバランサ、リージョン外部プロキシネットワークロードバランサ、リージョン内部プロキシネットワークロードバランサヘルスチェックは省略可能です。これらのロードバランサのヘルスチェックプローブは、プロキシ専用サブネットから発信され、Cloud NAT を使用して事前予約した IP アドレスまたは自動で割り振られた NAT IP アドレスに NAT 変換されます。詳細については、リージョン NEG: Cloud NAT ゲートウェイを使用するをご覧ください。
分散 Envoy ヘルスチェックは、一元化されたヘルスチェックと同じ Google Cloud コンソール、gcloud CLI、API プロセスを使用して作成されます。その他の構成は不要です。

注意するポイント:
- gRPC ヘルスチェックはサポートされていません。
- PROXY プロトコル v1 が有効になっているヘルスチェックはサポートされていません。
- Envoy データプレーンはヘルスチェックを処理するため、Google Cloud コンソール、API、gcloud CLI を使用して、これらの外部エンドポイントのヘルスステータスを確認することはできません。Envoy ベースのロードバランサを使用するハイブリッド NEG の場合、Google Cloud コンソールでヘルスチェックステータスが N/A と表示されます。これは予期された状況です。
- VPC ネットワークのリージョン内のプロキシ専用サブネットに割り当てられた Envoy プロキシは、それぞれ独立してヘルスチェックを開始します。そのため、ヘルスチェックが原因でネットワークトラフィックが増加することがあります。その増加量は、リージョン内の VPC ネットワークに割り当てられた Envoy プロキシの数、これらのプロキシが受信するトラフィックの量、各 Envoy プロキシがヘルスチェックを実行するエンドポイントの数によって異なります。最悪の場合、ヘルスチェックによるネットワークトラフィックが二次関数的に (O(n^2)) の割合で増加します。
- 分散 Envoy ヘルスチェックのヘルスチェックログには、ヘルスチェックの詳細な状態が記録されません。記録される内容の詳細については、ヘルスチェックのロギングをご覧ください。Envoy プロキシから NEG エンドポイントへの接続をさらにトラブルシューティングするには、対応するロードバランサのログを確認する必要があります。

外部バックエンドでリクエストを受信する

リージョンインターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信され、Cloud NAT を使用して事前予約の NAT IP アドレスまたは自動で割り振られた NAT IP アドレスに変換されます。これには、ヘルスチェックプローブと、ロードバランサからバックエンドへのユーザーリクエストの両方が含まれます。

Google Cloud からのトラフィックを許可するように外部バックエンドを構成する方法は、NEG の範囲（グローバルまたはリージョン）によって異なります。

グローバル NEG: デフォルトの Google 下り（外向き）IP アドレスを許可リストに登録する

グローバルインターネット NEG を使用している場合は、外部バックエンドにリクエストを送信するために使用される IP アドレス範囲を許可リストに登録する必要があります。許可リストに登録する IP アドレスを検索するには、dig や nslookup などのツールを使用して _cloud-eoips.googleusercontent.com DNS TXT レコードをクエリします。

例については、外部バックエンドに Google Cloud からのトラフィックの受信を許可するをご覧ください。

リージョン NEG: Cloud NAT ゲートウェイを使用する

リージョンインターネット NEG を使用する場合は、まず Cloud NAT ゲートウェイを設定して、Google Cloud トラフィックの発信元となる IP アドレス範囲のセットを割り振ります。

ゲートウェイエンドポイントは ENDPOINT_TYPE_MANAGED_PROXY_LB タイプにする必要があります。

Cloud NAT ゲートウェイは、需要に基づいて外部 IP アドレスを動的に割り振るか、手動で事前予約した外部 IP アドレスのセットを使用するように構成できます。

自動的に割り振られた IP アドレス

外部バックエンド環境でトラフィックを外部バックエンドに送信できる特定の Google Cloud IP アドレスを許可リストに登録する必要がない場合は、自動的に割り振られる IP アドレスを使用します。
手動割り振りの IP アドレス

手動割り振りの IP アドレスは、外部バックエンド環境で特定の Google Cloud IP アドレスを許可リストに登録する必要がある場合にのみ使用します。プロキシサブネットに割り当てられた各 Envoy は IP アドレス全体を使用するため、予約済み IP アドレスのプールが、すべての Envoy に対応できる十分な大きさであることを確認してください。

警告: プロビジョニングする NAT IP アドレスが割り当て済みの Envoy プロキシの数より少ないと、インターネット NEG に送信されるリクエストで HTTP 5xx エラーが発生します。このようなイベントが発生したときに確実に通知されるように、nat_allocation_failed 指標にアラートを設定します。特定のリージョンのロードバランサに割り振る必要のある IP アドレスの数を計算する際にサポートが必要な場合は、サポートにお問い合わせください。
大規模な接続の問題が発生した場合は、Cloud NAT の上限に達したかどうかを確認します。デフォルトでは、手動割り振りの NAT IP アドレスはゲートウェイごとに 50 個までです。

この Cloud NAT 構成は、プロキシ専用サブネット全体に適用されます。リージョン内のすべてのリージョン Envoy ベースのロードバランサに関連付けられたインターネットトラフィックは、同じ NAT ゲートウェイを共有します。

Cloud NAT を使用すると、ユーザートラフィックとヘルスチェックトラフィックの両方で料金が発生します。リージョンインターネット NEG の料金の仕組みについては、リージョンインターネット NEG の料金をご覧ください。

プロキシ専用サブネットに構成された NAT ゲートウェイには、次のような制限があります。

1 対 1 の NAT 変換のみが実行されます。IP アドレスの共有はサポートされていません。
ロギングとモニタリングはサポートされていません。つまり、--enable-logging フラグと --log-filter フラグはサポートされていません。
静的ポートと動的ポートの割り当て、VM あたりの最大ポート数と最小ポートの設定、エンドポイントに依存しないマッピングなどのポート関連機能はサポートされていません。各プロキシは 65,536 個のポートをすべて取得します。

外部バックエンドへのリクエストを認証する

このセクションは、アプリケーションロードバランサにのみ適用されます。

外部バックエンドに送信されたリクエストを認証するには、次のいずれかを行います。

カスタムリクエストヘッダーを使用して、リクエストが Google Cloud ロードバランサから発行されたことを示すカスタムヘッダーを設定します。たとえば、16 バイト以上の暗号論的乱数を共有キーとして使用できます。

使用しているロードバランサの種類に応じて、カスタムヘッダー変換を実装します。
- グローバル外部アプリケーションロードバランサと従来のアプリケーションロードバランサカスタムヘッダー変換は、バックエンドサービスまたは URL マップで構成できます。
  
  たとえば、HTTP リクエストの Host ヘッダーに特定の値が想定されるように外部バックエンドを構成し、Host ヘッダーをその値に設定するようにロードバランサを構成できます。カスタムリクエストヘッダーを構成しない場合、ロードバランサは、クライアントがロードバランサへの接続に使用したヘッダーを保持し、レスポンスに同じヘッダーを含めます。ただし、Host ヘッダーの変更は URL マップでサポートされていません。
  
  Host ヘッダーの構成には、追加の制限があります。詳細については、バックエンドサービスでカスタムヘッダーを作成するをご覧ください。具体的な例については、外部バックエンドを使用するグローバル外部アプリケーションロードバランサを設定するをご覧ください。
- リージョン外部アプリケーションロードバランサとリージョン内部アプリケーションロードバランサカスタムヘッダー変換は、URL マップでのみ構成できます。
  
  これらの Envoy ベースのロードバランサの場合、Host と authority は Google Cloud が予約する特殊なキーワードです。これらのヘッダーは、これらのロードバランサでは変更できません。予約されたヘッダー名が干渉しないように、他のカスタムヘッダー（MyHost など）を作成することをおすすめします。
IAP を有効にして、リクエストヘッダーの署名済み JWT が Google によって署名されており、ロードバランサが定義されるプロジェクト番号が aud（オーディエンス）クレームに含まれていることを確認することもできます。

IAP には Cloud CDN との互換性がありません。IAP は、リージョン外部アプリケーションロードバランサとプロキシネットワークロードバランサ（内部と外部）ではサポートされていません。
非公開送信元の認証を有効にします。これにより、外部アプリケーションロードバランサは非公開の Amazon Simple Storage Service（Amazon S3）バケットまたは他の互換性のあるオブジェクトストアに長期間にわたってアクセスできます。Cloud CDN（非公開送信元の認証）は、リージョン外部アプリケーションロードバランサとリージョン内部アプリケーションロードバランサではサポートされていません。

ログ

外部バックエンドにプロキシされたリクエストは、他のバックエンドのリクエストと同様の方法で Cloud Logging に記録されます。

詳しくは以下をご覧ください。

外部バックエンドを使用する外部アプリケーションロードバランサで Cloud CDN を有効にすると、キャッシュヒットもログに記録されます。

外部バックエンドを使用したヘッダー処理

グローバル外部アプリケーションロードバランサと従来のアプリケーションロードバランサ

グローバルまたは従来のアプリケーションロードバランサが外部バックエンドにリクエストをプロキシする場合、HTTP ヘッダーは次の方法で調整されます。

一部のヘッダーは統合されます。同じヘッダーキー（例: Via）を持つ複数のインスタンスがある場合は、ロードバランサはそれらの値を 1 つのヘッダーキーを持つ、1 つのカンマ区切りのリストにまとめます。値をカンマ区切りのリストで表すことができるヘッダーのみが統合されます。その他のヘッダー（Set-Cookie など）は統合されません。
バックエンドサービスのプロトコルが HTTP または HTTPS の場合、ヘッダーはプロパーケースで表示されます。
- ヘッダーのキーの最初の文字とハイフン（-）の後に続くすべての文字は、HTTP/1.1 クライアントとの互換性を維持するために大文字になります。たとえば、user-agent が User-Agent に変更され、content-encoding が Content-Encoding に変更されます。
- Accept-CH（クライアントのヒント）などの特定のヘッダーは、標準の混合文字表現に一致するように変換されます。
いくつかのヘッダーが追加されるか、値が追加されます。外部アプリケーションロードバランサは常に、特定のヘッダー（Via や X-Forwarded-For など）を追加または変更します。

リージョン外部アプリケーションロードバランサとリージョン内部アプリケーションロードバランサ

インターネット NEG を使用した Envoy ベースのロードバランサには特別なヘッダー処理はありません。Envoy で通常ヘッダーが処理される方法については、HTTP ヘッダー操作をご覧ください。

制限事項

インターネット NEG をバックエンドとして構成する際の制限事項については、バックエンドサービスのセクションをご覧ください。
ロードバランサでバックエンドをインターネット NEG から他のバックエンドタイプに変更したり、バックエンドを他のバックエンドタイプからインターネット NEG に変更すると、アプリケーションに一時的にダウンタイムが発生します（約 30～90 秒）。たとえば、このダウンタイム中に、クライアントがグローバル外部アプリケーションロードバランサにリクエストを送信すると、エラーコード failed_to_connect_to_backend を含む 502 エラーが表示されます。これは想定された動作です。
次の高度なトラフィック管理機能は、グローバルインターネット NEG バックエンドではサポートされていません。
- リクエストのミラーリング
- 再試行ポリシー
- トラフィックポリシー（ロードバランシングの局所性ポリシー、セッションアフィニティ、外れ値検出など）
プロキシ専用サブネットに構成された NAT ゲートウェイに関する制限については、Cloud NAT ゲートウェイのセクションをご覧ください。

割り当てと上限

インターネット NEG には、次の割り当てと上限が適用されます。

既存のネットワークエンドポイントグループ割り当てで許可されている数の外部ネットワークエンドポイントを持つ NEG を構成できます。
バックエンドサービスあたりの NEG 数は、インターネット NEG の種類（グローバルまたはリージョン）によって異なります。
- グローバル NEG の場合、同じバックエンドサービスに追加できるインターネット NEG バックエンドは 1 つだけです。
- リージョン NEG の場合、同じバックエンドサービスに最大 50 個のインターネット NEG を追加できます。
NEG あたりのエンドポイントの数は、インターネット NEG のタイプ（グローバルまたはリージョン）によっても異なります。
- グローバル NEG の場合、インターネット NEG に追加できるエンドポイントは 1 つだけです。
- リージョン NEG の場合、インターネット NEG には最大 256 個のエンドポイントを追加できます。

詳細については、NEG バックエンドの割り当てと NEG ごとのエンドポイント数をご覧ください。

料金

外部インターネット NEG エンドポイントへの下り（外向き）トラフィックは、プレミアムティアネットワークのインターネット下り（外向き）レートで課金されます。送信元はクライアントのロケーションに基づき、宛先は公開エンドポイントのロケーションに基づきます。

リージョン Envoy ベースのロードバランサのプロキシ専用サブネットをマッピングするように Cloud NAT ゲートウェイを構成した場合、Cloud NAT の料金が発生します。ロードバランサに割り振られた Cloud NAT ゲートウェイには、32 個を超える VM インスタンスが存在するネットワークに相当する 1 時間単位の料金が発生します。詳細については、Cloud NAT の料金をご覧ください。

詳細については、Cloud Load Balancing の料金をご覧ください。