Azure Load Balancer と AWS CLB の比較｜L4とL7の違い、移行時の対応関係とWordPressへの影響

Azure Load Balancer と AWS の Classic Load Balancer（CLB）は、名前は似ていても守備範囲が違います。Azure Load Balancer は TCP/UDP を扱う L4 専用のロードバランサーで、証明書を持ってHTTPSを終端することはできません。CLB は L4（TCP/SSL）と L7（HTTP/HTTPS）の両方のリスナーを持ち、SSL終端や Cookie によるセッション固定もできます。この記事では両者の違いを機能ごとに比べ、クラウド間の移行や併用でどのサービスが対応するのか、WordPress の設定がどう変わるのかを整理します。

先に結論：対応関係の目安

1対1で比べるより、次の対応関係で考えると判断を誤りにくくなります（2026年10月現在）。

• CLB の HTTPS/HTTP リスナー（L7 として使っている場合） → Azure では Application Gateway（または Front Door）が近い役割。Azure Load Balancer ではない
• CLB の TCP/SSL リスナー（L4 として使っている場合） → Azure Load Balancer（Standard SKU）が近い
• Azure Load Balancer を AWS へ移す場合 → CLB ではなく Network Load Balancer（NLB）が近い。CLB は AWS で前世代扱いのため、新規の移行先には選ばないのが一般的です

以下では、この対応関係の根拠となる違いを見ていきます。

動作する層とプロトコル

Azure Load Balancer は、パケットの送信元と宛先のIP、ポート、プロトコルの組み合わせ（ハッシュ）をもとに、背後の仮想マシンへ振り分けます。HTTP の中身は見ないため、URL のパスで振り分ける、ヘッダーを付け足す、リダイレクトする、といった処理はできません。その代わり、TCP 以外に UDP も扱え、HTTP 以外のサービス（データベースの読み取りレプリカ、独自プロトコルなど）にも使えます。

CLB は、リスナーごとに HTTP/HTTPS（L7）か TCP/SSL（L4）かを選べます。HTTP/HTTPS リスナーでは X-Forwarded-For などのヘッダーを付けて転送し、SSL 終端もできます。ただし L7 機能は最小限で、パスによる振り分けやリダイレクトはありません。UDP には対応していません。

SSL/TLS の扱い

ここが WordPress の運用に最も影響する違いです。

• CLB：HTTPS リスナーに ACM などの証明書を設定し、LB で TLS を終端できます。1つのリスナーに設定できる証明書は1枚で、SNI による出し分けはできません
• Azure Load Balancer：TLS 終端の機能を持たないため、HTTPS の通信は暗号化されたまま仮想マシンへ届きます。証明書は各仮想マシン（Nginx や Apache）に置くか、前段に Application Gateway や Front Door を置いてそこで終端します

仮想マシンに証明書を置く場合、複数台で同じ証明書を使う必要があります。Let's Encrypt の HTTP-01 検証は、LB 経由だと検証リクエストが別の台に届いて失敗することがあるため、DNS-01 検証で1か所から取得して配布するか、Key Vault などの仕組みで配る方法を検討してください。

訪問者IPの見え方

Azure Load Balancer は受信方向で送信元IPを書き換えずに届けるため、仮想マシンからはクライアントの本当のIPがそのまま見えます。WordPress のログイン試行制限やアクセスログは追加設定なしで正しく動きやすい構成です。

CLB の HTTP/HTTPS リスナーでは、接続元は CLB のIPになり、本当のIPは X-Forwarded-For に入ります。Webサーバーの realip 設定などで復元が必要です。TCP リスナーではヘッダーを付けられないため、Proxy Protocol を有効にして、Webサーバー側でも受け取る設定をします。Proxy Protocol を片側だけ有効にすると通信が壊れるので、両側を同時に切り替えてください。

ヘルスチェック

どちらも TCP と HTTP のヘルスチェックを持ちます。Azure Load Balancer の正常性プローブは HTTPS にも対応しています。共通の注意点は、HTTP のヘルスチェックが 200 以外を異常とみなすことです。WordPress のトップページをチェック先にすると、HTTPS へのリダイレクト（301）や、プラグインによるメンテナンス表示（503）で全台が切り離されることがあります。チェック先には静的ファイル（例: /healthcheck.html）を用意し、リダイレクトの対象外にしておくのが安全です。

Azure の Standard SKU は既定で受信を許可しない設計のため、ネットワークセキュリティグループ（NSG）で利用者からの通信とプローブの通信を許可する必要があります。プローブの送信元は Azure の特別なIPで、NSG ではサービスタグ「AzureLoadBalancer」で許可するのが一般的です。

セッション固定とタイムアウト

WordPress はログイン状態を Cookie とデータベースで管理するため、全台で同じ wp-config.php の認証用キーとDBを使っていれば、セッション固定は基本的に不要です。一方、タイムアウトは影響が出やすい項目です。大きなファイルのアップロードやインポート、時間のかかる管理画面の処理が途中で切れる場合は、LB のアイドルタイムアウトと、Webサーバー・PHP のタイムアウトを合わせて見直します。Azure では既定のアイドルタイムアウトが CLB より短いため、移行後に初めて問題が表面化することがあります。具体的な既定値と設定範囲は、各社の最新ドキュメントで確認してください。

WordPress の設定がどう変わるか

AWS の CLB（HTTPS で SSL 終端）から Azure Load Balancer（L4 で素通し）へ移す場合を例にすると、次の変更が必要です。

1. 各仮想マシンの Nginx/Apache に証明書を設定し、443番で待ち受ける
2. wp-config.php の X-Forwarded-Proto による HTTPS 判定は不要になる（残しても動作はしますが、ヘッダーを偽装されない構成か確認します）
3. HTTP から HTTPS へのリダイレクトは、Webサーバーで通常どおり $scheme（Nginx）や %{HTTPS}（Apache）を見て行う
4. X-Forwarded-For による訪問者IPの復元設定は外し、直接の送信元IPを使う

逆方向の移行では、この逆の設定を足します。どちらの場合も、切り替え前に DNS の TTL を短くしておき、データベースと設定ファイルのバックアップを取ってから作業してください。

どう選ぶか

• Azure で WordPress を HTTPS 公開し、証明書を LB 層で一元管理したい → Application Gateway（または Front Door）を前段に置く
• Azure で L4 のまま各仮想マシンで TLS を扱う、または HTTP 以外も分散したい → Azure Load Balancer
• AWS で既存の CLB を使い続けている → 当面は運用できますが、移行するなら L7 用途は ALB、L4 用途は NLB を候補にする

まとめ

• Azure Load Balancer は L4 専用、CLB は L4 と L7 の両方を持つ前世代の LB。単純な横並びの比較は成り立たない
• CLB の HTTPS 用途に対応するのは Azure の Application Gateway、Azure Load Balancer に近いのは AWS の NLB
• TLS 終端の場所、訪問者IPの見え方、ヘルスチェック先、アイドルタイムアウトが WordPress の設定に影響する
• 移行時は証明書の配置、HTTPS 判定、IP 復元の設定を入れ替え、バックアップと検証環境での確認を先に行う

• Azure Load Balancer でヘルスチェック（正常性プローブ）を設定する方法
• AWS CLB でセッションアフィニティを設定する方法