「L4 プロキシがあればグローバル IP は要らない」とは何か：公開するのは入口だけ、を AWS の構成で整理する

Posted at 2026-09-20

はじめに

インフラの会話で「L4 プロキシを入れるから、サーバーにグローバル IP は要らないよ」と聞いた。
分かったような、分からないような一文である。

何が「要らない」のか。サーバーが外から見えなくなる、ということか
「グローバル IP を開けない」とは、どこの何を閉じるのか

この記事では、この一文が指すものを AWS の NLB を例に整理する。

この記事で分かること：

「入口だけ公開」とは、どんな構成のことか
「公開」を Public IP・DNS・Security Group・ルートに分けると、何が要らなくなり、何が残るか
「グローバル IP を開けない」という言い方が曖昧になる理由

前提

例は AWS の NLB（Network Load Balancer）と VPC を使う
本文の IP アドレスは例である。203.0.113.10 はドキュメント用アドレス（RFC 5737）、10.0.1.20 はプライベートアドレス（RFC 1918）で、実在の環境の値ではない
事実は主に AWS の公式ドキュメントに依拠する（nginx のドキュメントと、リバースプロキシの定義についてはベンダーの用語集も使う）。リンクは本文に載せる。動作検証はしていない整理記事である

1. この一文が指すもの

結論を先に書く。

公開が要るのは入口だけ。バックエンドは Private IP のまま、入口を経由した通信だけを受ける。ただし入口側の Public IP と公開 DNS は残る。

❌ 各サーバーに Public IP を付けて、それぞれ公開する
⭕ 入口（ロードバランサ）だけを公開し、サーバーは Private IP のまま入口経由で受ける

「サーバーにグローバル IP は要らない」は、後者の意味である。
「何も公開しない」という意味ではない。

図 1：直接公開と入口だけ公開

左は、クライアントがサーバーへ直接届く。サーバーの数だけ、外に見える口ができる
右は、クライアントが届くのは入口だけ。サーバーは Private IP のまま、入口から転送された通信を受ける
図の IP は例である

👉 AWS の言い方では、NLB は OSI 参照モデルの第 4 層で動くロードバランサである。会話で言う「L4 プロキシ」は、この入口の役を指している。ドキュメント上は NLB を「プロキシ」とは呼んでいないので、この記事では「第 4 層で動く LB」と書く。

出典: What is a Network Load Balancer?（英語版ドキュメント）

2. 「公開」を分解する

「公開する」は 1 つの操作ではない。見る場所が複数ある。

会話で言う「グローバル IP」は、ここでは Public IP（インターネットから見える IPv4 アドレス）のことである。

見る場所	何を決めるか	入口だけ公開のとき
Public IP	インターネットから見える IPv4 アドレスを持つか	入口だけが持つ。サーバーは不要
DNS	名前を引いたとき、どのアドレスが返るか	入口の DNS 名が公開で引ける
Security Group	どの通信を許可するか	サーバー側は入口からの通信だけ許可する
ルート	サブネットがインターネットゲートウェイへ出られるか	サーバーは Private Subnet に置ける

Public IP：サーバーには不要

ロードバランサは、ターゲットへ Private IP でリクエストを送る。ターゲットに Public IP は要らない
インターネット向け LB のノードは Public IP を持つ。これが「入口だけ Public IP」の入口である

出典: How Elastic Load Balancing works（英語版ドキュメント）

DNS：入口側は公開で引ける

インターネット向け LB のノードは Public IP を持ち、その DNS 名は公開で解決される
内部 LB でも、DNS 名は公開で引ける。ただし解決先が Private IP になる
そのため内部 LB には、VPC にアクセスできるクライアントからしか届かない

👉 「DNS が公開で引ける」ことと「そこへ届く」ことは別である。内部 LB は名前は引けても、Private IP が返るので外からは届かない。

Security Group：入口経由だけを許可する

ターゲット側の SG に「NLB の SG を参照元とするルール」を書くと、NLB 経由の通信は許可され、クライアントからターゲットへの直接通信は防げる
詳しい構成は 4 章で扱う

👉 NLB の SG は、作成時に 1 つも付けなかった場合、後から付けられない。

出典: Update the security groups for your Network Load Balancer（英語版ドキュメント）

ルート：Public IP だけでは届かない

Public Subnet は、インターネットゲートウェイへのルートを持つサブネットである。Private Subnet は持たない
Private Subnet のインスタンスは、Public IP を持っていても、インターネットと通信できない

"Because there is no route to the internet gateway, instances in the private subnet can't communicate with the internet, even if they have public IP addresses."

公式の説明では、IPv4 でインターネットと通信するには、インスタンスに Public IPv4 が要る
👉 「Public IP を持つ = 届く」ではない。届くには Public IP と、インターネットゲートウェイへのルートの両方が要る

出典: Enable internet access for a VPC using an internet gateway、Subnets for your VPC（英語版ドキュメント）

「グローバル IP を開けない」が曖昧な理由

この言い方は、上の 4 つのどれを指すのかが決まっていない。

サーバーに Public IP を付けない、という意味かもしれない
入口の Public IP まで閉じる、という意味ではない。入口の Public IP と公開 DNS は残る
SG でポートを閉じる、という意味かもしれない

👉 会話で聞いたら、「サーバーの Public IP のことか、入口のことか」を聞き返すと話が早い。

3. L4 と L7

「L4 プロキシ」の L4 は、入口が 何を見て転送するか の話である。

L4：TCP / UDP の情報（IP アドレスとポート）を見て転送する
L7：HTTP の中身（ホスト名・パス・ヘッダなど）を見て振り分ける

	見るもの	例	HTTP を理解するか
L4	IP アドレス・ポート・プロトコル（TCP / UDP）	NLB、nginx の `stream`	しない。HTTP の中身は転送先の判断に使わない
L7	HTTP のリクエストの中身（ホスト・パス・ヘッダなど）	ALB、nginx の `http`	する。中身に基づいて振り分ける

L4：NLB

NLB は第 4 層で動く。クライアントからの接続を受けて、ターゲットグループからターゲットを 1 つ選び、指定したプロトコルとポートで送る
TCP では、プロトコル・送信元 IP・送信元ポート・宛先 IP・宛先ポート・TCP シーケンス番号を使ったフローハッシュでターゲットを選ぶ
1 本の TCP 接続は、接続の間ずっと同じターゲットに送られる

👉 選ぶ材料は IP・ポート・シーケンス番号で、HTTP のパスやヘッダは出てこない。NLB を「プロキシ」と呼ぶかどうかは 1 章のとおり、ドキュメント上は「第 4 層で動く LB」と書く。

出典: What is a Network Load Balancer?（英語版ドキュメント）

L7：ALB

ALB は第 7 層（アプリケーション層）で動く。リクエストを受けると、リスナールールを優先度順に評価し、適用するルールを決めてターゲットを選ぶ
ルールの条件は 6 種類ある：host-header（ホスト名）、http-header（HTTP ヘッダ）、http-request-method（HTTP メソッド）、path-pattern（URL のパス）、query-string（クエリ文字列）、source-ip（送信元 IP）
ホスト名で振り分けるのは host-based routing、パスで振り分けるのは path-based routing と、公式は呼んでいる

出典: What is an Application Load Balancer?、Condition types for listener rules（英語版ドキュメント）

nginx なら `stream` と `http`

nginx では、TCP / UDP のプロキシと負荷分散は stream ブロックに、HTTP は http ブロックに書く。
L4 側の最小の例は次のとおりである（ホスト名とポートは例）。

stream {
    upstream stream_backend {
        server backend1.example.com:12345;
        server backend2.example.com:12345;
    }

    server {
        listen     12345;
        proxy_pass stream_backend;
    }
}

listen で受けたポートへの接続を、proxy_pass で upstream のサーバーへ渡す
stream は TCP / UDP の接続を扱う。HTTP のリクエストの設定は http ブロックに書く

出典: TCP and UDP Load Balancing（英語版ドキュメント。例は同ページの例を短くしたもの）

入口が L4 でも L7 でも

👉 入口が L4 でも L7 でも、この記事の要点は変わらない。ELB のドキュメントでは、インターネット向けでも内部でも、ロードバランサはターゲットへ Private IP でリクエストを送る。ALB も NLB も ELB のロードバランサなので、どちらを入口にしても、バックエンドは Private IP のまま入口経由で受けられる。違うのは、入口が何を見て転送先を決めるかである。

出典: How Elastic Load Balancing works（英語版ドキュメント）

4. AWS の構成例

2 章で分けた「公開」の見る場所を、1 つの構成にまとめる。

入口：Public Subnet に NLB を置く。Elastic IP は任意
バックエンド：Private Subnet に EC2 を置く。Public IPv4 は付けない
SG：EC2 の SG は、NLB の SG からの通信だけを許可する

AWS の言い方では、NLB は第 4 層で動く LB である（「プロキシ」とは呼ばれていない）。
この記事の例では、その NLB を Public Subnet に置く。

インターネット向けの NLB では、サブネット（AZ）ごとに Elastic IP を 1 つ関連付けて、入口の IP を固定できる。関連付けは任意である。

図 2：サブネットと SG の関係

クライアントが届くのは NLB だけ。EC2 に Public IPv4 は無い
NLB は、ターゲットへ Private IP でリクエストを送る
EC2 の SG は、参照元を NLB の SG にしたルールで通信を受ける
図の IP は例である

サーバーを Private Subnet に置ける根拠

2 章の表で「サーバーは Private Subnet に置ける」と書いた根拠は、次の 2 点である。

ロードバランサは、インターネット向けでも内部でも、ターゲットへ Private IP でリクエストを送る。ターゲットに Public IP は要らない
Private Subnet は、インターネットゲートウェイへの直接のルートを持たないサブネットである。公式は、AWS のリソースを守るために Private Subnet を使うことを推奨している

この 2 点から、入口経由で受けるだけのサーバーは、Private Subnet に置ける。
サーバーが外へ出る通信は 5 章で扱う。

出典: How Elastic Load Balancing works、Subnets for your VPC（英語版ドキュメント）

EC2 の SG の例

NLB の SG を sg-nlb、EC2 の SG を sg-ec2 とする（どちらも例の名前で、実在の ID ではない）。
sg-ec2 の inbound は、次の 2 行にする。

参照元	ポート	意味
`sg-nlb`	ターゲットポート	NLB から、ターゲットポートへの通信を許可する
`sg-nlb`	ヘルスチェックポート	NLB から、ヘルスチェックの通信を許可する

参照元を CIDR ではなく NLB の SG にすると、NLB 経由の通信は許可され、クライアントから EC2 への直接通信は防げる
ヘルスチェックのポートも、NLB の SG を参照元にして許可する必要がある
クライアント IP の保持が有効でも、NLB の SG を参照元にすれば、NLB からの通信を受けられる

出典: Update the security groups for your Network Load Balancer（英語版ドキュメント）

落とし穴

❌ NLB の SG は、あとから付ければよい

NLB の SG は、作成時に 1 つも付けなかった場合、後から付けられない
SG を付けずに作った NLB は、参照元にする NLB の SG が無いので、この構成は取れない
SG を付けずに作った NLB には、すべてのクライアントの通信がリスナーに届く
作成時に SG を付けておけば、その後は SG を変更できる。公式も、作成時に付けることを勧めている

出典: Update the security groups for your Network Load Balancer、Create a Network Load Balancer（英語版ドキュメント）

❌ L4 なら、EC2 にはクライアントの IP がそのまま見える

見えるかどうかは、ターゲットグループの種類とプロトコル、そして設定で決まる
instance 型は、クライアント IP の保持が既定で有効。IPv4 のクライアントなら、送信元 IP がそのまま見える
IP 型で TCP / TLS のターゲットは、既定で無効。無効のとき、ターゲットから見える送信元は NLB の Private IP になる
保持を有効にできるのは、ターゲットが NLB と同じ VPC か、ピア接続した VPC にある場合である
保持できない場合は、Proxy Protocol v2 を有効にすると、ヘッダからクライアント IP を取得できる

👉 アクセス元の IP で制限やログ集計をするなら、ターゲットの種類と、保持の設定を確認する。

出典: Edit target group attributes for your Network Load Balancer（英語版ドキュメント）

5. サーバーが外へ出る通信：NAT Gateway

ここまでは「外から入ってくる通信」の話だった。
Public IP を持たない EC2 にも、外へ出たい通信はある。

OS やパッケージの更新を取りに行く
外部の API を呼ぶ

入口の NLB は、外から入ってくる通信を受ける部品である。
Private Subnet のリソースがインターネットへ出るには、NAT デバイスが要る。
この記事の構成では、その NAT デバイスとして NAT Gateway を使う。

NAT Gateway がすること

Private Subnet のインスタンスが、VPC の外のサービスへ接続できるようにする
外部のサービスから、そのインスタンスへ接続を開始することはできない
Public NAT Gateway は Public Subnet に作り、Elastic IP の関連付けが必須。VPC のインターネットゲートウェイへルーティングする
接続は常に、NAT Gateway のある VPC の内側から始める必要がある

「出られる」と「入って来られる」は別である。
NAT Gateway 越しに、インスタンスはインターネットへ接続できる。
ただし、外からの一方的な着信接続は受けられない。

図 3：入ってくる通信と出ていく通信

実線は入ってくる通信。インターネットから NLB を通って EC2 へ届く
点線は出ていく通信。EC2 から NAT Gateway、インターネットゲートウェイを通ってインターネットへ出る
図では、NLB と NAT Gateway をどちらも Public Subnet に置いている
図の IP は例である

👉 「入ってくる通信の入口」と「出ていく通信の出口」は別の部品である。入口は NLB、出口は NAT Gateway が担う。

❌ 入口の NLB を置けば、サーバーが外へ出る通信も面倒を見てくれる

公式の定義では、Private Subnet のリソースがインターネットへ出るには NAT デバイスが要る
この記事の構成で、その役を担うのは NAT Gateway である。NLB とは別に用意する
NAT Gateway は、外からの一方的な着信を受けられない。外から EC2 へ入る通信は、入口の NLB 経由である

出典: NAT gateways、Subnets for your VPC（英語版ドキュメント）

6. リバースプロキシ・NAT・L4 LB の違い

会話には「プロキシ」「NAT」「LB」が混ざって出てくる。ここまでに出た部品を 1 つの表に並べる。

リバースプロキシとは

リバースプロキシは、Web サーバーの前に立ち、クライアントのリクエストをそれらの Web サーバーへ転送する。返ってきたリソースは、プロキシ自身から来たように見える
nginx のドキュメントでは、プロキシは複数のサーバーへの負荷分散や、HTTP 以外のプロトコルでアプリケーションサーバーへリクエストを渡す用途に使われる、と書かれている
nginx がリクエストをプロキシすると、指定したプロキシ先へリクエストを送り、応答を取得して、クライアントへ返す

👉 1 つ目の定義は F5 の用語集による。ベンダーの用語集であり、AWS や nginx の技術ドキュメントほどの一次資料ではない。

出典: What Is a Reverse Proxy?（F5 の用語集）、NGINX Reverse Proxy（英語版ドキュメント）

比較表

	どの層で	何をするか	向き	バックエンドの Public IP
リバースプロキシ	—	Web サーバーの前に立ち、クライアントのリクエストを転送する	—	—
NAT Gateway	—	Private Subnet のインスタンスが VPC の外へ接続できるようにする。外から接続を開始することはできない	outbound	—
L4 LB（NLB）	第 4 層	IP・ポート・プロトコルを見て、ターゲットグループからターゲットを 1 つ選んで転送する	inbound（入ってくる通信の入口）	要らない（ターゲットへ Private IP で送る）
L7 LB（ALB）	第 7 層	HTTP の中身（ホスト・パス・ヘッダなど）を見て、リスナールールで振り分ける	inbound（入ってくる通信の入口）	要らない（ターゲットへ Private IP で送る）

「—」は、この記事では言い切らない、という意味である。公式の記述で確認できた範囲だけを書いている
NAT Gateway の Public NAT は、Public Subnet に置き、Elastic IP の関連付けが必須である

👉 「NAT」という言葉は別々のものを指す。NAT Gateway は、インスタンスの送信元 Private IPv4 アドレスを変換する（outbound）。一方、AWS のドキュメントには、ロードバランサがターゲットへ転送する前に宛先 IP アドレスを書き換える、という記述がある（inbound）。この 2 つは別々に書かれている。NLB を NAT と呼んだり、NAT Gateway と同じ種類の部品として扱ったりはしない。

出典: NAT gateways、Target groups for your Network Load Balancers（Request routing and IP addresses の項）、What is a Network Load Balancer?、What is an Application Load Balancer?、How Elastic Load Balancing works（英語版ドキュメント）

7. まとめ

冒頭の結論をもう一度書く。