AWS NLB と Nginx LB の比較｜L4とL7の違い・クライアントIP・運用負荷で選ぶ

AWS の Network Load Balancer（NLB）と、EC2 などに自前で立てる Nginx のロードバランサーは、そもそも得意な層が違います。NLB は TCP/UDP レベル（L4）で大量の接続を低遅延にさばくマネージドサービス、Nginx は HTTP の中身（L7）を見て振り分けやキャッシュ、ヘッダー操作までできるソフトウェアです。この記事では、両者の違いを WordPress 運用の観点から整理し、どちらを選ぶか、あるいは組み合わせるかを判断できるようにします。

AWS の機能追加は頻繁で、NLB でも以前はできなかったことが後から可能になった例があります。以下は（2026年10月現在）の一般的な理解に基づくため、採用前に AWS 公式ドキュメントで最新の仕様を確認してください。料金は構成と通信量で大きく変わるので、本記事では扱いません。

両者の立ち位置の違い

AWS NLB

NLB は TCP、UDP、TLS のリスナーを持つ L4 のロードバランサーです。HTTP のパスやホスト名を見て振り分ける機能はなく、その役割は同じ ELB ファミリーの Application Load Balancer（ALB）が担います。NLB の主な特徴は次のとおりです。

• アベイラビリティーゾーンごとに固定の IP アドレスを持てる（Elastic IP の割り当ても可能）
• 接続をそのまま転送するため遅延が小さく、急な接続数の増加にも追従しやすい
• TLS リスナーで ACM の証明書を使い、TLS を終端できる
• ターゲットの種類によってはクライアントの送信元 IP がそのまま届き、届かない構成では PROXY プロトコル v2 で渡せる
• 冗長化やスケールは AWS が管理し、ロードバランサー自体のサーバー運用は不要

固定 IP が求められる取引先のファイアウォール許可、メールや独自プロトコルなど HTTP 以外の通信、ALB の前段に固定 IP を置きたい場合に選ばれることが多いサービスです。

Nginx LB

Nginx は upstream ブロックで複数のバックエンドに振り分けられ、HTTP として扱う場合は URL ごとのルーティング、ヘッダーの付け替え、プロキシキャッシュ、レート制限、Basic 認証などを一か所で設定できます。stream モジュールを使えば TCP/UDP の L4 転送も可能です。

その代わり、ロードバランサー自体を自分で運用することになります。1台構成ではそのサーバーが単一障害点になるため、本番では2台以上と keepalived などによる切り替えや、前段にさらに別の仕組みが必要です。また、オープンソース版のヘルスチェックはリクエストの失敗を見て一時的に外す受動的な方式で、定期的に死活を問い合わせる能動的なヘルスチェックは商用の NGINX Plus の機能です。

比較の観点

違いを観点ごとに並べると次のようになります。

表だけで決めず、「HTTP の中身を見る処理が必要か」「ロードバランサーの運用を誰が担うか」の2点から考えると判断しやすくなります。

WordPress ではどう選ぶか

WordPress を複数台の Web サーバーで動かすだけなら、AWS 上では ALB が最も素直な選択です。HTTPS の終端、パスでの振り分け、HTTP のヘルスチェックがそろっており、NLB と比べて WordPress 側で必要な調整が少なく済みます。NLB を選ぶ理由が明確でない場合は、ALB も比較対象に入れてください。

NLB が向くのは、固定 IP が要件にある場合や、HTTP 以外の通信も同じ入口で受けたい場合です。このとき、後ろに Nginx を置いて L7 の処理を任せる「NLB + Nginx」の組み合わせがよく使われます。NLB は入口の固定 IP と冗長化、Nginx は振り分け・キャッシュ・セキュリティヘッダーと役割を分けられます。

Nginx 単体でのロードバランサーは、AWS 以外の VPS やオンプレミス環境、あるいは費用や構成の自由度を優先する小規模構成で現実的な選択になります。

組み合わせたときのつまずきどころ

クライアント IP が取れない

NLB の後ろに Nginx を置き、TLS を NLB で終端したり IP ターゲットを使ったりすると、Nginx から見た送信元が NLB の IP になる場合があります。WordPress のコメント記録やログイン試行の制限が全部同じ IP 扱いになり、セキュリティ対策が誤作動する原因になります。

PROXY プロトコル v2 をターゲットグループで有効にした場合は、Nginx 側でも PROXY プロトコルを受け付ける設定が必要です。片方だけ有効にすると接続自体が失敗するので、両方を同時に切り替えます。

server {
    listen 80 proxy_protocol;
    server_name example.com;

    # VPC の CIDR に置き換える（NLB からの接続だけを信頼する）
    set_real_ip_from 10.0.0.0/16;
    real_ip_header proxy_protocol;

    location / {
        proxy_pass http://wp_backend;
        proxy_set_header X-Real-IP $proxy_protocol_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
    }
}

HTTPS 判定がずれる

NLB で TLS を終端して Nginx に平文で渡すと、WordPress は HTTPS でのアクセスだと認識できず、リダイレクトのループや混在コンテンツの原因になります。Nginx から X-Forwarded-Proto を渡し、wp-config.php で信頼できる前段からのヘッダーに限って $_SERVER['HTTPS'] を設定する、という対応が一般的です。

ヘルスチェックの対象

NLB のヘルスチェックを TCP にすると、PHP-FPM が止まっていても Nginx がポートを開いていれば「正常」と判定されます。HTTP のヘルスチェックで、WordPress まで到達する軽いパスを確認するほうが実態に近くなります。ただし、データベースに重い処理を走らせるパスは避けてください。

自前 Nginx のバックエンド設定例

Nginx 側で複数の Web サーバーに振り分ける場合の最小例です。オープンソース版では max_fails と fail_timeout で失敗が続いたサーバーを一時的に外します。

upstream wp_backend {
    least_conn;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

keepalive を使う場合は、location 側で proxy_http_version 1.1; と proxy_set_header Connection ""; も設定します。設定変更は nginx -t で確認してから反映し、本番の前にステージング環境で切り替えを試してください。

まとめ

• NLB は L4 のマネージドサービスで、固定 IP・低遅延・運用不要が強み。HTTP の中身での振り分けはできない
• Nginx は L7 の処理が豊富だが、冗長化とヘルスチェックの強化は自分で用意する必要がある
• WordPress を複数台で動かすだけなら ALB も比較に入れ、固定 IP が要るときに NLB + Nginx を検討する
• 組み合わせる場合は、クライアント IP（PROXY プロトコル）、HTTPS 判定、ヘルスチェックの対象を最初に設計する

• AWS EC2 と ALB の構築手順
• PROXY プロトコルの仕組みと設定