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

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

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

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

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

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

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

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

用語

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

  • 外部バックエンド: 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 サービスを参照している場合、サービスは HTTPHTTPS、または HTTP/2 プロトコルを使用して、TCP ポート 80443 経由で接続可能である必要があります。

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

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

ロードバランサ エンドポイントのタイプ エンドポイントの定義 スコープ ヘルスチェック
  • グローバル外部アプリケーション ロードバランサ
  • 従来のアプリケーション ロードバランサ

INTERNET_FQDN_PORT

公開で解決可能な完全修飾ドメイン名とオプションのポート。例: backend.example.com:4431

ドメイン名は、Google のパブリック DNS インフラストラクチャで解決可能である必要があります。

NEG ごとに使用できるエンドポイントは 1 つだけです。

グローバル 非対応

INTERNET_IP_PORT

パブリック ルーティングが可能な IP アドレスとオプションのポート。例: 8.8.8.8:4431

IP アドレスを RFC 1918 アドレスにすることはできません。

NEG ごとに使用できるエンドポイントは 1 つだけです。

  • リージョン外部アプリケーション ロードバランサ
  • リージョン内部アプリケーション ロードバランサ
  • リージョン外部プロキシ ネットワーク ロードバランサ
  • リージョン内部プロキシ ネットワーク ロードバランサ

INTERNET_FQDN_PORT

公開で解決可能な完全修飾ドメイン名とオプションのポート。例: backend.example.com:4432

ドメイン名は、Cloud DNS または Google のパブリック DNS インフラストラクチャによって解決可能である必要があります。

NEG あたりの最大エンドポイント数は 256 です。

リージョン Envoy の分散ヘルスチェック

INTERNET_IP_PORT

パブリック ルーティングが可能な IP アドレスとオプションのポート。例: 8.8.8.8:4432

IP アドレスを RFC 1918 アドレスにすることはできません。

NEG あたりの最大エンドポイント数は 256 です。

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

2 リージョン インターネット 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 は、レート、接続、使用率などのロード バランシング モードをサポートしていません。バックエンド サービスに接続されているすべての NEG のすべてのエンドポイントが 1 つのグループにプールされます。このエンドポイントのプール間のロード バランシング トラフィックは、Envoy ロード バランシング アルゴリズムを使用して処理されます。サポートされているロード バランシング ポリシー アルゴリズムについては、リージョン バックエンド サービス API ドキュメントlocalityLbPolicy をご覧ください。

  • ヘルスチェック

  • バックエンド サービスのロード バランシング方式は、デプロイするロードバランサが必要とする方式と一致する必要があります。完全なリストについては、バックエンド サービスをご覧ください。

  • バックエンド サービス プロトコルは、HTTPHTTPSHTTP2 のいずれかにする必要があります。

    インターネット 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 を使用している場合は、外部バックエンドにリクエストを送信するために Google が使用する IP アドレス範囲を許可リストに追加する必要があります。許可リストに追加する IP アドレスを検索するには、dignslookup などのツールを使用して _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 に対応できる十分な大きさであることを確認してください。

    大規模な接続の問題が発生した場合は、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 ベースのロードバランサの場合、Hostauthority は Google Cloud が予約する特殊なキーワードです。これらのヘッダーは、これらのロードバランサでは変更できません。予約されたヘッダー名が干渉しないように、他のカスタム ヘッダー(MyHost など)を作成することをおすすめします。

  • IAP を有効にして、リクエスト ヘッダーの署名済み JWT が Google によって署名されており、ロードバランサが定義されるプロジェクト番号が aud(オーディエンス)クレームに含まれていることを確認することもできます。

    IAP には Cloud CDN との互換性がありません。IAP は、リージョン外部アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサ(内部と外部)ではサポートされていません。

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

ログ

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

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

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

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

ロードバランサによって、外部バックエンドへのリクエストをプロキシする際のヘッダー処理が異なる場合があります。ロードバランサのタイプによって HTTP ヘッダーがどのように処理されるかについては、以下の情報を確認してください。

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

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

  • 一部のヘッダーは統合されます。同じヘッダーキー(例: Via)を持つ複数のインスタンスがある場合は、ロードバランサはそれらの値を 1 つのヘッダーキーを持つ、1 つのカンマ区切りのリストにまとめます。値をカンマ区切りのリストで表すことができるヘッダーのみが統合されます。その他のヘッダー(Set-Cookie など)は統合されません。

  • バックエンド サービスのプロトコルが HTTP または HTTPS の場合、ヘッダーはプロパーケースで表示されます。

    • ヘッダーのキーの最初の文字とハイフン(-)の後に続くすべての文字は、HTTP/1.1 クライアントとの互換性を維持するために大文字になります。たとえば、user-agentUser-Agent に変更され、content-encodingContent-Encoding に変更されます。

    • Accept-CHクライアントのヒント)などの特定のヘッダーは、標準の混合文字表現に一致するように変換されます。

  • いくつかのヘッダーが追加されるか、値が追加されます。外部アプリケーション ロードバランサは常に、特定のヘッダーViaX-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 の料金をご覧ください。

次のステップ