このドキュメントでは、 Trusted Cloud 外部プロキシ ネットワーク ロードバランサの構成に必要なコンセプトについて説明します。
外部プロキシ ネットワーク ロードバランサは、インターネットから送信された TCP トラフィックをTrusted Cloud Virtual Private Cloud（VPC）ネットワーク内の仮想マシン（VM）インスタンスに分散するリバース プロキシ ロードバランサです。外部プロキシ ネットワーク ロードバランサを使用する場合、受信 TCPトラフィックはロードバランサで終端します。新しい接続は、TCP または SSL（推奨）を使用して、最も近い使用可能なバックエンドをご覧ください。
外部プロキシ ネットワーク ロードバランサを使用すると、世界中のユーザーに対して単一の IP アドレスを使用できます。ロードバランサは、ユーザーに最も近いバックエンドにトラフィックを自動的にルーティングします。
このロードバランサはリージョン モードで使用できます。以降は、リージョン外部プロキシ ネットワーク ロードバランサと呼びます。このロードバランサは、オープンソースの Envoy プロキシをベースにマネージド サービスとして実装されています。リージョン モードでは、すべてのクライアントとバックエンドが指定されたリージョンに配置されます。このロードバランサは、1 つの位置情報のみからコンテンツを配信する場合に使用します（コンプライアンスで規制されている場合など）。
アーキテクチャ
次の図は、外部プロキシ ネットワーク ロードバランサのコンポーネントを示しています。
リージョン
次の図は、リージョン外部プロキシ ネットワーク ロードバランサのデプロイメントのコンポーネントを示しています。
外部プロキシ ネットワーク ロードバランサのコンポーネントは次のとおりです。
プロキシ専用サブネット
プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。このプロキシ専用サブネットの --purpose フラグは REGIONAL_MANAGED_PROXY に設定されています。同じリージョンと VPC ネットワーク内にあるすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットの Envoy プロキシのプールを共有します。
リージョンと VPC ネットワーク内のすべてのロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
重要ポイント:
- プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
- ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは外部マネージド転送ルールによって定義されます。
転送ルールと IP アドレス
転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシとバックエンド サービスからなるロード バランシング構成にトラフィックをルーティングします。
IP アドレスの指定。各転送ルールは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを参照します。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。静的 IP アドレスを予約することをおすすめします。それ以外の場合は、転送ルールを削除して新しく作り直すたびに、新しく割り当てられたエフェメラル IP アドレスで DNS レコードを更新する必要があります。
ポートの指定。このロードバランサの定義で使用される外部転送ルールは、1～65535 の 1 つのポートのみを参照できます。連続する複数のポートをサポートする場合は、複数の転送ルールを構成する必要があります。同じ仮想 IP アドレスと異なるポートを使用して複数の転送ルールを構成できます。したがって、別々のカスタムポートを持つ複数のアプリケーションを同じ TCP プロキシの仮想 IP アドレスにプロキシできます。詳細については、転送ルールのポート指定をご覧ください。
連続した複数のポートをサポートするには、複数の転送ルールを構成する必要があります。同じ仮想 IP アドレスと異なるポートを使用して複数の転送ルールを構成できます。したがって、別々のカスタムポートを持つ複数のアプリケーションを同じ TCP プロキシの仮想 IP アドレスにプロキシできます。
次の表に、外部プロキシ ネットワーク ロードバランサの転送ルールの要件を示します。
| ロードバランサ モード | ネットワーク サービス ティア | 転送ルール、IP アドレス、ロード バランシング スキーム | インターネットからロードバランサのフロントエンドへの転送 |
|---|---|---|---|
| リージョン外部プロキシ ネットワーク ロードバランサ | プレミアム ティア |
ロード バランシング スキーム: |
ロードバランサと同じリージョン内の Envoy プロキシにルーティングされるリクエスト。 |
転送ルールと VPC ネットワーク
このセクションでは、外部アプリケーション ロードバランサで使用される転送ルールを VPC ネットワークに関連付ける方法について説明します。
| ロードバランサのモード | VPC ネットワークの関連付け |
|---|---|
| リージョン外部プロキシ ネットワーク ロードバランサ | 転送ルールの VPC ネットワークは、プロキシ専用サブネットが作成されたネットワークです。ネットワークは、転送ルールを作成するときに指定します。 |
ターゲット プロキシ
外部プロキシ ネットワーク ロードバランサは、クライアントからの接続を終端し、バックエンドへの新しい接続を作成します。ターゲット プロキシは、これらの新しい接続をバックエンド サービスに転送します。
デフォルトでは、ターゲット プロキシは元のクライアントの IP アドレスとポート情報を保持しません。この情報を保持するには、ターゲット プロキシで PROXY プロトコルを有効にします。
次の表に、外部プロキシ ネットワーク ロードバランサのターゲット プロキシの要件を示します。
| ロードバランサ モード | ネットワーク サービス ティア | ターゲット プロキシ |
|---|---|---|
| リージョン外部プロキシ ネットワーク ロードバランサ | プレミアム ティアとスタンダード ティア | regionTargetTcpProxies |
バックエンド サービス
バックエンド サービスは、接続されている 1 つ以上のバックエンドに受信トラフィックを振り分けます。これらのバックエンドは、インスタンス グループまたはネットワーク エンドポイント グループと、バックエンドの処理能力に関する情報から構成されます。バックエンドの処理能力は、CPU または 1 秒あたりのリクエスト数（RPS）に基づいています。
各ロードバランサには、使用可能なバックエンドに対して実行されるヘルスチェックを指定する、単一のバックエンド サービス リソースがあります。
バックエンド サービスに対する変更は即時に行われるわけではありません。変更が GFE に反映されるまでに数分かかることがあります。ユーザーへの中断を最小限に抑えるために、バックエンド サービスのコネクション ドレインを有効にできます。このような中断は、バックエンドの停止、手動による削除、オートスケーラーによる削除によって発生することがあります。コネクション ドレインを使用してサービスの中断を最小限に抑える方法については、コネクション ドレインの有効化のドキュメントをご覧ください。
バックエンド サービス リソースの詳細については、バックエンド サービスの概要をご覧ください。
次の表に、外部プロキシ ネットワーク ロードバランサのバックエンド サービスでサポートされているさまざまなバックエンドを示します。
| ロードバランサ モード | バックエンド サービスでサポートされるバックエンド | ||||||
|---|---|---|---|---|---|---|---|
| インスタンス グループ | ゾーン NEG | インターネット NEG | サーバーレス NEG | ハイブリッド NEG | GKE | ||
| リージョン外部プロキシ ネットワーク ロードバランサ | GCE_VM_IP_PORT タイプのエンドポイント |
リージョン NEG のみ | |||||
バックエンドと VPC ネットワーク
リージョン外部プロキシ ネットワーク ロードバランサのバックエンドの場合は、次のようになります。
インスタンス グループ、ゾーン NEG、ハイブリッド接続 NEG の場合、すべてのバックエンドはバックエンド サービスと同じプロジェクトとリージョンに配置する必要があります。ただし、ロードバランサは、バックエンド サービスと同じプロジェクトで別の VPC ネットワークを使用するバックエンドを参照できます。 ロードバランサの VPC ネットワークとバックエンド VPC ネットワーク間の接続は、VPC ネットワーク ピアリング、Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメントのいずれかを使用して構成できます。
バックエンド ネットワークの定義
- ゾーン NEG とハイブリッド NEG の場合、NEG の作成時に VPC ネットワークを明示的に指定します。
- マネージド インスタンス グループの場合、VPC ネットワークはインスタンス テンプレートで定義されます。
- 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、インスタンス グループに追加された最初の VM の
nic0インターフェースの VPC ネットワークと一致するように設定されます。
バックエンド ネットワークの要件
バックエンド ネットワークは、次のいずれかのネットワーク要件を満たしている必要があります。
バックエンドの VPC ネットワークは、転送ルールの VPC ネットワークと完全に一致する必要があります。
バックエンドの VPC ネットワークは、VPC ネットワーク ピアリングを使用して転送ルールの VPC ネットワークに接続する必要があります。転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可するには、サブネット ルート交換を構成する必要があります。
他のすべてのバックエンド タイプの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。
バックエンドとネットワーク インターフェース
インスタンス グループのバックエンドを使用する場合、パケットは常に nic0 に配信されます。nic0 以外のインターフェース（vNIC または Dynamic Network Interface）にパケットを送信するには、NEG バックエンドを使用します。
ゾーン NEG バックエンドを使用する場合、パケットは NEG のエンドポイントで表されるネットワーク インターフェースに送信されます。NEG エンドポイントは、NEG に明示的に定義された VPC ネットワークと同じ VPC ネットワークに存在する必要があります。
バックエンドと通信するためのプロトコル
外部プロキシ ネットワーク ロードバランサのバックエンド サービスを構成するときに、バックエンド サービスがバックエンドとの通信に使用するプロトコルを設定します。ロードバランサは、指定したプロトコルのみを使用し、他のプロトコルとの接続をネゴシエートしません。外部プロキシ ネットワーク ロードバランサは、バックエンドとの通信に TCP のみをサポートします。
ファイアウォール ルール
次のファイアウォール ルールが必要です。
リージョン外部プロキシ ネットワーク ロードバランサの場合は、プロキシ専用サブネットからのトラフィックがバックエンドに到達することを許可する上り（内向き）ファイアウォール ルール。
ヘルスチェック プローブ範囲からのトラフィックがバックエンドに到達できることを許可する上り（内向き）
allowファイアウォール ルール。ヘルスチェック プローブの詳細と、プローブからのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。
ファイアウォール ルールは、GFE プロキシレベルではなく、VM インスタンス レベルで実装されます。ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。
これらのファイアウォール ルールのポートは、次のように構成する必要があります。
- 各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可します。
- インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。
GCE_VM_IP_PORT NEGゾーン NEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。
送信元 IP アドレス
バックエンドから見たパケットの送信元 IP アドレスは、ロードバランサのTrusted Cloud 外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。
リージョン外部プロキシ ネットワーク ロードバランサの場合:接続 1: 元のクライアントからロードバランサ（プロキシ専用サブネット）への接続。
- 送信元 IP アドレス: 元のクライアント（クライアントが NAT ゲートウェイまたは転送プロキシの背後にある場合は外部 IP アドレス）。
- 宛先 IP アドレス: ロードバランサの IP アドレス。
接続 2: ロードバランサ（プロキシ専用サブネット）からバックエンド VM またはエンドポイントへの接続。
送信元 IP アドレス: ロードバランサと同じリージョン、同じネットワークにデプロイされたすべての Envoy ベースのロードバランサ間で共有されるプロキシ専用サブネットの IP アドレス。
宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。
オープンポート
外部プロキシ ネットワーク ロードバランサは、リバース プロキシ ロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。これらのロードバランサは、世界中の Google Front End（GFE）プロキシを使用して実装されています。
GFE には、同じアーキテクチャで実行される他の Google サービスをサポートするための複数のオープンポートがあります。ポートスキャンを実行すると、GFE で実行されている他の Google サービスのオープンポートが表示される場合があります。
GFE ベースのロードバランサの IP アドレスにポートスキャンを実行することは、次の理由により、監査の観点からは役立ちません。
通常、ポートスキャン（たとえば
nmapを使用）では、TCP SYN プローブを実行するときにレスポンス パケットや TCP RST パケットは想定されません。GFE は転送ルールを構成したポートに対してのみ、SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。別の IP アドレスまたはポートに送信されたパケットはバックエンドに送信されません。GFE は、Google Cloud Armor などのセキュリティ機能を実装しています。Cloud Armor Standard を使用すると、GFE は、ボリューム型およびプロトコル ベースの DDoS 攻撃と SYN フラッドを常に阻止します。この保護は、Cloud Armor を明示的に構成していない場合でも使用できます。セキュリティ ポリシーを構成した場合、または Managed Protection Plus に登録した場合のみ、料金が発生します。
ロードバランサの IP アドレスに送信されたパケットには、Google のフリート内の任意の GFE が応答可能ですが、ロードバランサの IP アドレスと宛先ポートの組み合わせをスキャンすると、TCP 接続ごとに 1 つの GFE のみが検査されます。ロードバランサの IP アドレスは、単一のデバイスまたはシステムに割り当てられていません。したがって、GFE ベースのロードバランサの IP アドレスをスキャンしても、Google のフリート内のすべての GFE がスキャンされるわけではありません。
以下では、この点を考慮し、バックエンド インスタンスのセキュリティをより効果的に監査する方法を説明します。
セキュリティ監査担当者は、ロードバランサの構成で転送ルールの構成を検査する必要があります。転送ルールは、ロードバランサがパケットを受け入れてバックエンドに転送する宛先ポートを定義しています。GFE ベースのロードバランサの場合、1 つの外部転送ルールで参照できる宛先 TCP ポートは 1 つだけです。
セキュリティ監査担当者は、バックエンド VM に適用されるファイアウォール ルールの構成を検査する必要があります。ファイアウォール ルールの設定では、GFE からバックエンド VM へのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。
共有 VPC アーキテクチャ
リージョン外部プロキシ ネットワーク ロードバランサ は、共有 VPC ネットワークを使用するデプロイをサポートしています。共有 VPC を使用すると、ネットワーク管理者とサービス デベロッパーの責任を明確に分離できます。開発チームはサービス プロジェクトでのサービスの構築に集中し、ネットワーク インフラストラクチャ チームはロード バランシングのプロビジョニングと管理を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。
| IP アドレス | 転送ルール | ターゲット プロキシ | バックエンド コンポーネント |
|---|---|---|---|
| 外部 IP アドレスは、ロードバランサと同じプロジェクトで定義する必要があります。 | 外部転送ルールは、バックエンド インスタンスと同じプロジェクト（サービス プロジェクト）で定義する必要があります。 | ターゲット TCP プロキシは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。 |
通常、リージョン外部プロキシ ネットワーク ロードバランサの場合、バックエンド VM はサービス プロジェクトに配置されます。そのサービス プロジェクトでは、リージョン バックエンド サービスとヘルスチェックを定義する必要があります。 |
トラフィック分散
バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する場合は、バックエンドの負荷とターゲット容量を測定する方法を定義するロード バランシング モードを指定します。
外部プロキシ ネットワーク ロードバランサの場合、分散モードは CONNECTION または UTILIZATION に設定できます。
- ロード バランシング モードが
CONNECTIONの場合、バックエンドが処理できる接続の合計数に基づいてロードバランスされます。 - ロード バランシング モードが
UTILIZATIONに設定されている場合、インスタンス グループ内のインスタンスの使用率に基づいてロードバランスされます。このバランシング モードは、VM インスタンス グループのバックエンドにのみ適用されます。
バックエンド間のトラフィックの分散は、ロードバランサのバランシング モードによって決まります。
リージョン外部プロキシ ネットワーク ロードバランサ
リージョン外部プロキシ ネットワーク ロードバランサの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づきます。
分散モードでは、各バックエンド（インスタンス グループまたは NEG）に送信するトラフィックの重みと割合を決定します。ロード バランシングの局所性ポリシー（LocalityLbPolicy）により、グループ内のバックエンドのロード バランシング方法が決まります。
トラフィックを受信すると、バックエンド サービスは分散モードに従ってバックエンド（インスタンス グループまたは NEG）にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。
詳しくは以下をご覧ください。
セッション アフィニティ
セッション アフィニティでは、バックエンドが良好な状態で容量があれば、同じクライアントからのすべてのリクエストを同じバックエンドに送信するように、ロードバランサのバックエンド サービスを構成できます。
外部プロキシ ネットワーク ロードバランサには、次のタイプのセッション アフィニティがあります。なし
セッション アフィニティの設定の
NONEは、セッション アフィニティがないことを意味するわけではありません。これは、セッション アフィニティ オプションが明示的に構成されていないことを意味します。ハッシュは、バックエンドを選択するために常に実行されます。セッション アフィニティの設定が
NONEの場合、ロードバランサは 5 タプルハッシュを使用してバックエンドを選択します。5 タプルハッシュは、送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成されます。セッション アフィニティのデフォルト値は
NONEです。クライアント IP アフィニティ
「クライアント IP セッション アフィニティ（
CLIENT_IP）」は、パケットの送信元 IP アドレスと宛先 IP アドレスから作成された 2 タプルハッシュです。クライアント IP アフィニティは、バックエンドに容量があり、正常な状態を維持している限り、同じクライアント IP アドレスからのすべてのリクエストを同じバックエンドに転送します。クライアント IP アフィニティを使用する場合は、次の点に留意してください。
- パケットがロードバランサに直接送信される場合、パケットの宛先 IP アドレスはロードバランサの転送ルールの IP アドレスと同じになります。
- パケットが Trusted Cloud ロードバランサに配信される前に中間 NAT またはプロキシ システムによって処理されると、パケットの送信元 IP アドレスが元のクライアントに関連付けられた IP アドレスと一致しないことがあります。多くのクライアントが同じ有効な送信元 IP アドレスを共有する場合、一部のバックエンド VM は他の VM よりも多くの接続またはリクエストを受信する可能性があります。
セッション アフィニティを構成する際は、次の点に留意してください。
認証やセキュリティを目的としてセッション アフィニティに依存しないでください。セッション アフィニティは、サービスの数と正常なバックエンドの数が変わるたびに失われる可能性があります。詳細については、セッション アフィニティの喪失をご覧ください。
--session-affinityフラグと--subsetting-policyフラグのデフォルト値はどちらもNONEです。異なる値を設定できるのは一度に 1 つだけです。
セッション アフィニティの喪失
すべてのセッション アフィニティのオプションには、次の要件があります。
- 選択したバックエンド インスタンスまたはエンドポイントは、バックエンドとして構成されたままにする必要があります。セッション アフィニティは、次のいずれかのイベントが発生すると失われる可能性があります。
- 選択したインスタンスをインスタンス グループから削除します。
- マネージド インスタンス グループの自動スケーリングまたは自動修復により、選択したインスタンスがマネージド インスタンス グループから削除されます。
- 選択したエンドポイントを NEG から削除します。
- 選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG をバックエンド サービスから削除します。
- 選択したバックエンド インスタンスまたはエンドポイントは正常な状態を維持する必要があります。選択したインスタンスまたはエンドポイントでヘルスチェックが失敗すると、セッション アフィニティが失われる可能性があります。
- グローバル外部プロキシ ネットワーク ロードバランサと従来のプロキシ ネットワーク ロードバランサの場合、ルーティング パスの変更後に後続のリクエストまたは接続に別の第 1 レイヤの Google Front End（GFE）が使用されると、セッション アフィニティが失われる可能性があります。インターネット上のクライアントから Google へのルーティング パスがリクエストまたは接続によって異なる場合は、別の第 1 レイヤの GFE が選択される可能性があります。
選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG は、ターゲット容量で定義されている容量を満たしてはなりません。（リージョン マネージド インスタンス グループの場合、選択したインスタンスを含むインスタンス グループのゾーン コンポーネントがいっぱいになっていないこと）。インスタンス グループまたは NEG がいっぱいで、他のインスタンス グループまたは NEG がいっぱいでない場合は、セッション アフィニティが破棄される可能性があります。
UTILIZATIONバランシング モードを使用すると、満杯状態が予測できない方法で変化する可能性があるため、RATEバランシング モードまたはCONNECTIONバランシング モードを使用して、セッション アフィニティが破損する可能性のある状況を最小限に抑える必要があります。構成されたバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、構成されたバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。
新しいインスタンスまたはエンドポイントを追加する:
- バックエンド サービスで、既存のインスタンス グループにインスタンスを追加します。
- マネージド インスタンス グループの自動スケーリングでは、バックエンド サービスのマネージド インスタンス グループにインスタンスが追加されます。
- バックエンド サービスで、既存の NEG にエンドポイントを追加します。
- 空ではないインスタンス グループまたは NEG をバックエンド サービスに追加します。
選択したインスタンスまたはエンドポイントだけでなく、インスタンスまたはエンドポイントを削除する:
- インスタンス グループのバックエンドからインスタンスを削除した場合。
- マネージド インスタンス グループの自動スケーリングまたは自動修復により、マネージド インスタンス グループのバックエンドからインスタンスが削除されます。
- NEG バックエンドからエンドポイントを削除します。
- 空ではない既存のバックエンド インスタンス グループまたは NEG をバックエンド サービスから削除します。
正常なバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、正常なバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。
- インスタンスまたはエンドポイントがヘルスチェックに合格し、異常な状態から正常な状態に変わります。
- インスタンスまたはエンドポイントがヘルスチェックに失敗し、正常な状態から異常な状態に移行するか、タイムアウトします。
フェイルオーバー
外部プロキシ ネットワーク ロードバランサのフェイルオーバーは次のとおりです。
- バックエンドが異常な状態になった場合、トラフィックは同じリージョン内の正常なバックエンドに自動的にリダイレクトされます。
- すべてのバックエンドが異常な状態の場合、ロードバランサはトラフィックを破棄します。
GKE アプリケーションのロード バランシング
Google Kubernetes Engine でアプリケーションを構築する場合は、スタンドアロン NEG を使用してトラフィックを直接コンテナにロード バランシングできます。スタンドアロン NEG では、NEG を作成する Service オブジェクトを作成し、NEG をバックエンド サービスに関連付けます。これにより、ロードバランサが Pod に接続できるようになります。
関連ドキュメントについては、スタンドアロン ゾーン NEG によるコンテナ ネイティブのロード バランシングをご覧ください。
制限事項
Trusted Cloud コンソールを使用してプレミアム ティアでリージョン外部プロキシ ネットワーク ロードバランサを作成することはできません。 代わりに、gcloud CLI または API を使用してください。
Trusted Cloud は、外部プロキシ ネットワーク ロードバランサを使用する場合、TCP 接続の存続期間を保証しません。クライアントは、広範なインターネットの問題と、接続を管理するプロキシの定期的な再起動の両方による接続の切断に対して復元性がある必要があります。