通常、Google Cloud ロードバランサでは、クライアントからのトラフィックがバックエンドに到達するように、1 つ以上のファイアウォール ルールが必要です。
ほとんどのロードバランサは、バックエンド インスタンスのヘルスチェックを指定する必要があります。ヘルスチェック プローブがバックエンドに到達するには、上り（内向き）許可ファイアウォール ルールを作成して、ヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。
Google Front End（GFE）に基づくロードバランサには、GFE プロキシからのトラフィックがバックエンド インスタンスに到達することを許可する上り（内向き）許可ファイアウォール ルールが必要です。ほとんどの場合、GFE プロキシはヘルスチェック プローブと同じ送信元 IP 範囲を使用するため、個別のファイアウォール ルールは必要ありません。次の表に例外を示します。
オープンソースの Envoy プロキシに基づくロードバランサには、プロキシ専用サブネットからのトラフィックがバックエンド インスタンスに到達できるように上り（内向き）ファイアウォール ルールを作成する必要があります。これらのロードバランサによって受信接続が終端され、ロードバランサからバックエンドへのトラフィックはプロキシ専用サブネットの IP アドレスから送信されます。
次の表は、各タイプのロードバランサに最低限必要なファイアウォール ルールをまとめたものです。
| ロードバランサの種類 | 最小限必要な上り（内向き）許可のファイアウォール ルール | 概要 | 例 |
|---|---|---|---|
| グローバル外部アプリケーション ロードバランサ |
|
概要 | 例 |
| 従来のアプリケーション ロードバランサ |
|
概要 | 例 |
| リージョン外部アプリケーション ロードバランサ |
|
概要 | 例 |
| クロスリージョン内部アプリケーション ロードバランサ |
|
概要 | 例 |
| リージョン内部アプリケーション ロードバランサ |
|
概要 | 例 |
| グローバル外部プロキシ ネットワーク ロードバランサ |
|
概要 | 例 |
| 従来のプロキシ ネットワーク ロードバランサ |
|
概要 | 例 |
| リージョン外部プロキシ ネットワーク ロードバランサ |
|
概要 | 例 |
| リージョン内部プロキシ ネットワーク ロードバランサ |
|
概要 | 例 |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ |
|
概要 | 例 |
| 外部パススルー ネットワーク ロードバランサ |
|
概要 |
例 |
| 内部パススルー ネットワーク ロードバランサ |
|
概要 | シングルスタック デュアルスタック |
1 ハイブリッド NEG では、Google のヘルスチェック プローブ範囲を許可リストに登録する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲を許可リストに登録する必要があります。
2 リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信されます。このトラフィックは、Cloud NAT により、手動または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: 下り（外向き）に Cloud NAT を使用するをご覧ください。