Azure Load BalancerとApplication Gatewayの使い分け｜L4・L7ロードバランサー選定の判断軸

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ Azure ＞ Azure Load BalancerとApplication Gatewayの使い分け｜L4・L7ロードバランサー選定の判断軸
「Azure Load BalancerとApplication Gateway、どちらを選べばいいのか」
Azureでシステムを構築するとき、まず直面するのがこの選択です。

名前が似ていることもあり混同されがちですが、2つのサービスはOSI参照モデルの異なる層で動作するため、解決できる問題の種類が根本的に異なります。「とりあえずApplication Gatewayにしておこう」という判断が後になってコストを圧迫したり、逆に「Load Balancerで足りると思ったらURLパスルーティングができなかった」という失敗は現場でよく起きるパターンです。

この記事では、L4・L7という層の違いを基礎から整理した上で、実際のアーキテクチャシナリオに応じた選定の判断軸を解説します。VMSS + Load Balancerの構築手順は別記事で取り上げているため、本記事は「どちらを選ぶか」の判断力を鍛えることに特化します。

この記事のポイント

・Load Balancer（L4）はTCP/UDP分散、Application Gateway（L7）はHTTPルーティング
・SSLオフロード・URLパスルーティングが必要ならApplication Gatewayを選ぶ
・VM/VMSSへの汎用TCP分散はLoad Balancerが低コストで適切
・WAF統合が要件に入るならApplication Gateway WAF_v2 SKUで一本化できる


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

L4とL7の違い——選定の前提知識

ロードバランサーを選ぶとき、最初に確認すべきはOSI参照モデルの「どの層で動作するか」です。

L4（トランスポート層）で動作するLoad Balancerは、送信元・宛先のIPアドレスとポート番号だけを見て振り分け先を決めます。HTTPリクエストの中身やURLのパスは一切参照しません。プロトコルの中身を解析しないため、オーバーヘッドが小さく高スループットと低レイテンシを維持できます。

L7（アプリケーション層）で動作するApplication Gatewayは、HTTPリクエストの中身（URLパス、Hostヘッダー、Cookieなど）を読み取ってルーティングを決定します。クライアントとのTCPセッションを終端し、バックエンドに向けて別のTCPセッションを確立する「リバースプロキシ」動作が特徴です。

この違いが2つのサービスの機能差を生み出します。Application GatewayはHTTP通信を理解できるからこそSSLオフロードやURLパスルーティングが可能であり、Load BalancerはHTTPの中身を見ないからこそTCP/UDPの汎用プロトコルを低コストで分散できます。

Azure Load Balancerの特徴と得意な用途

1. L4ロードバランサーとして動作する仕組み

Azure Load Balancerは、フロントエンドIPアドレスとポートの組み合わせで受け取ったパケットを、バックエンドプールのVMまたはVMSSインスタンスに転送します。

ルーティングの判断基準はIPアドレスとポート番号のみです。HTTPヘッダーやURLパスは参照しません。このシンプルさが高スループットと低レイテンシの両立を可能にしています。プロトコルはTCPとUDPに対応しており、Webアプリケーションに限らず、MySQLのTCPポート（3306）やPostgreSQLのTCPポート（5432）の分散にも使えます。

内部Load Balancer（Internal LB）と外部Load Balancer（Public LB）の2種類があります。

・外部Load Balancer：パブリックIPアドレスでインターネットからのトラフィックを受け付け、VNet内のバックエンドに転送する
・内部Load Balancer：VNet内部のプライベートIPアドレスを使い、サービス間の内部トラフィックを分散する

2. Standard SKUで使える主な機能

Azure Load BalancerにはBasicとStandardの2つのSKUがありましたが、Basic SKUは2025年9月30日にリタイア済みです。2026年時点での新規構築はStandard一択です。

Standard SKUの主な機能は以下の通りです。

・フロントエンドIP：パブリックまたはプライベートIPを選択できる
・ヘルスプローブ：TCP・HTTP・HTTPSによるバックエンドの死活監視（応答がないVMは自動で外れる）
・可用性ゾーン対応：ゾーン冗長フロントエンドIPをサポートし、単一ゾーン障害でも継続稼働できる
・アウトバウンドルール：バックエンドVMからインターネットへの送信NATを明示的に設定できる
・SLA：99.99%（複数VMのバックエンドプールが条件）

az CLIでLoad Balancerのロードバランシングルールを確認する例です。

# load balancer のロードバランシングルール一覧を確認する
$ az network lb rule list \
    --resource-group rg-webapp \
    --lb-name lb-webapp \
    --output table

Name          Protocol    FrontendPort    BackendPort    LoadDistribution
------------  ----------  --------------  -------------  -----------------
http-rule     Tcp         80              80             Default
https-rule    Tcp         443             443            Default

# ヘルスプローブの確認
$ az network lb probe list \
    --resource-group rg-webapp \
    --lb-name lb-webapp \
    --output table

Name          Protocol    Port    IntervalInSeconds    NumberOfProbes
------------  ----------  ------  -------------------  ----------------
http-probe    Http        80      15                   2

3. Azure Load Balancerが向いているシナリオ

以下のいずれかに該当する場合は、Azure Load Balancerを選ぶのが適切です。

・HTTP/HTTPS以外のTCP/UDPプロトコルを扱う（DBサーバー、SMTPサーバーなど）
・同じポートのTCPトラフィックを複数のVMに単純分散させたい
・VNet内部のサービス間通信に内部ロードバランサーが必要
・URLパスやホスト名によるルーティングは不要
・コストを最小限に抑えたい
・Application Gatewayのバックエンドにいるアプリサーバー間の内部通信を分散したい

Azure Application Gatewayの特徴と得意な用途

1. L7リバースプロキシとして動作する仕組み

Application GatewayはHTTPリクエストを受け取り、その内容を解析してからバックエンドにプロキシします。

クライアントはApplication GatewayとTCPセッションを確立します。Application GatewayはバックエンドのVMやApp Serviceと別のTCPセッションを確立し、リクエストを転送します。この二重のセッション構造（リバースプロキシ動作）があるため、クライアントの元IPアドレスはX-Forwarded-ForヘッダーでバックエンドVMに渡されます（Load Balancerは送信元IPをそのままパスする）。

このリバースプロキシ構造により、HTTPヘッダーの書き換え・URLパスのルーティング・SSLの終端など、HTTP通信を理解した上での制御が可能になっています。

2. URLルーティングとSSL終端

Application Gatewayの最大の強みは、URLパスとホスト名によるルーティングです。

パスベースルーティングの例：
・/api/* のリクエスト → APIサーバー（バックエンドプールA）
・/static/* のリクエスト → 静的コンテンツサーバー（バックエンドプールB）
・それ以外 → 汎用Webサーバー（バックエンドプールC）

同一ドメイン上の複数のパスを、それぞれ異なるバックエンドに振り分けられます。マイクロサービス構成で、パスごとに独立したサービスをデプロイしているケースに特に有効です。

マルチサイト（ホストベース）ルーティングの例：
・app1.example.com → バックエンドプールA
・app2.example.com → バックエンドプールB

1つのApplication GatewayのIPアドレスで複数のドメイン（マルチサイト）を捌けます。複数サービスごとにApplication Gatewayを立てる必要がなく、コストを集約できます。

SSLオフロードはApplication Gatewayの定番機能です。クライアントとApplication Gateway間はHTTPSで保護し、Application GatewayからバックエンドVMへはHTTPで転送することでバックエンドのSSL処理負荷を軽減します。証明書はApplication Gateway側に配置するため、更新管理が1箇所に集約されます。

az CLIでApplication Gatewayのルーティングルールを確認する例です。

# Application Gatewayのルーティングルールを確認
$ az network application-gateway rule list \
    --resource-group rg-webapp \
    --gateway-name agw-webapp \
    --output table

Name          RuleType          Priority    BackendAddressPool    BackendHttpSettings
------------  ----------------  ----------  --------------------  --------------------
api-rule      PathBasedRouting  100         pool-api              settings-api
default-rule  Basic             200         pool-web              settings-web

# HTTPSリスナーの確認（SSL証明書が適用されているか）
$ az network application-gateway http-listener list \
    --resource-group rg-webapp \
    --gateway-name agw-webapp \
    --output table

Name              Protocol    FrontendPort    SslCertificate
----------------  ----------  --------------  ----------------
https-listener    Https       443             cert-example-com
http-listener     Http        80              -

3. WAFとの統合

Application GatewayはWAF（Web Application Firewall）機能を内蔵できます。WAF_v2 SKUを選ぶと、OWASPのルールセットを使ったWebアプリへの攻撃防御が有効になります。

WAFが検知・防御できる主な攻撃：

・SQLインジェクション（DBへの不正クエリ注入）
・クロスサイトスクリプティング（XSS）
・コマンドインジェクション
・HTTPプロトコル違反・スキャンツールによる探索

検知モード（Detection）と防御モード（Prevention）を切り替えられます。最初は検知モードで誤検知の有無を確認してから防御モードに移行するアプローチが一般的です。

PCI DSSやISO 27001などのセキュリティ認証要件でWAFが必須とされる場合、Application Gateway WAF_v2を選ぶことで外部のWAF製品を別途導入するコストを省けます。

4. Application Gatewayが向いているシナリオ

以下のいずれかに該当する場合は、Application Gatewayを選ぶことを検討してください。

・URLパスやホスト名でバックエンドを切り替えたい（パスベース・ホストベースルーティング）
・SSLオフロードで証明書をGateway側に集中管理したい
・Cookie-basedセッションアフィニティが必要（ステートフルなアプリ）
・PCI DSSなどのセキュリティ要件でWAFが必須
・同一IPアドレスで複数ドメインのWebアプリを捌きたい（マルチサイト構成）
・HTTP/2に対応させたい

Azure Application Gatewayの実践的な設定については https://azure.linuxmaster.jp/ でもハンズオン演習を提供しています。

用途別の選定基準——判断フロー

1. シナリオ別の選択マトリクス

代表的なアーキテクチャシナリオと推奨サービスを整理します。

シナリオ 推奨サービス 理由
WebアプリへのHTTPS受付・SSL終端 Application Gateway SSL終端とURLルーティングが必須
VM/VMSSへのシンプルなTCP分散 Load Balancer ポートベースで十分・低コスト
/api/* と / を別バックエンドに振り分け Application Gateway パスベースルーティングはL7のみ可能
MySQL（3306）・PostgreSQL（5432）の分散 Load Balancer Application GatewayはHTTP/HTTPSのみ対応
WAFでWebアプリを保護したい Application Gateway WAF_v2 WAFはApplication Gatewayに内蔵されている
app1.example.comとapp2.example.comを同一IPで Application Gateway マルチサイト（ホストベース）ルーティング対応
VNet内部のサービス間TCP通信の分散 内部Load Balancer 非HTTP・内部通信向け・低コスト
Application GatewayとVM間の内部通信 Application Gateway + 内部Load Balancer 外部L7 + 内部L4の組み合わせパターン

2. コストと複雑さのトレードオフ

Application Gatewayは機能が豊富な分、Load Balancerよりコストが大幅に高くなります。

Azure Load Balancer（Standard SKU、東日本リージョン）の概算：
・ロードバランシングルール：約220円/ルール/月
・データ処理料金：約0.9円/GB

Azure Application Gateway（Standard_v2、東日本リージョン）の概算：
・キャパシティユニット（CU）課金：最小構成でも月数千円以上
・固定コスト＋トラフィック量に応じた従量課金でLoad Balancerより高コスト

URLパスルーティングやSSL終端などのL7機能を実際に使わないのであれば、Load Balancerで十分です。「コストが10倍以上違う」というケースは珍しくないため、要件を確認してから選定してください。

また、Application Gatewayのインスタンスの起動・停止には数分かかります。Load Balancerは即時反映に近い応答性があるため、デプロイ速度が重要な開発環境ではLoad Balancerが向いています。

az CLIで設定を確認する（実測例）

1. Application Gatewayのバックエンドヘルスを確認する

実際の環境でバックエンドVMの状態を確認する際に使うコマンドです。

# Application Gatewayのバックエンドヘルスを確認する
$ az network application-gateway show-backend-health \
    --resource-group rg-production \
    --name agw-webapp \
    --output json | \
    python3 -c "
import json, sys
data = json.load(sys.stdin)
for pool in data['backendAddressPools']:
    pool_name = pool['backendAddressPool']['id'].split('/')[-1]
    print(f'プール: {pool_name}')
    for setting in pool['backendHttpSettingsCollection']:
        for server in setting['servers']:
            print(f'  アドレス: {server["address"]}  状態: {server["health"]}')
"

プール: pool-api
  アドレス: 10.0.1.4  状態: Healthy
  アドレス: 10.0.1.5  状態: Healthy
プール: pool-web
  アドレス: 10.0.2.4  状態: Healthy
  アドレス: 10.0.2.5  状態: Unknown
バックエンドの状態が Unknown になる場合は、Application GatewayとバックエンドVM間のNSG（ネットワークセキュリティグループ）でヘルスプローブのポートが許可されているか確認してください。

2. Application Gatewayのヘルスプローブ許可確認

Application Gatewayはバックエンドへのヘルスプローブをポート65200～65535から送信します。このポート範囲がNSGで遮断されると、バックエンド全台がUnhealthyと判定されます。

# バックエンドVMのNSGルール一覧を確認する
$ az network nsg rule list \
    --resource-group rg-production \
    --nsg-name nsg-backend \
    --output table

Name             Priority    Access    Direction    Protocol    SourceAddressPrefix    SourcePortRange    DestinationPortRange
---------------  ----------  --------  -----------  ----------  ---------------------  -----------------  --------------------
AllowAppGwProbe  100         Allow     Inbound      *           GatewayManager         *                  65200-65535
AllowVnetIn      200         Allow     Inbound      *           VirtualNetwork         *                  *
DenyAllIn        4096        Deny      Inbound      *           *                      *                  *
GatewayManager からの65200～65535ポートへのInboundが許可されていることを確認してください。このルールがないと、バックエンド全台が Unhealthy 判定になります。設計時の注意ポイントです。

よくある選定ミスとエラー対処

1. HTTPアプリにLoad Balancerを使ってSSL集約できない

症状：各バックエンドVMにSSL証明書を配置しなければならず、証明書の更新管理が煩雑になる
対処：Application GatewayのSSLオフロードを採用し、証明書管理をGateway側に集約する。バックエンドVMはHTTPで受け取るだけでよく、証明書の配備・更新はGateway1箇所で済む

2. 非HTTPプロトコルにApplication Gatewayを選択して接続できない

症状：MySQLのTCPポート（3306）をApplication Gatewayで受けようとして接続できない
対処：Application GatewayはHTTP/HTTPSのみ対応。TCPやUDPの汎用分散にはLoad Balancerを使う

3. Application GatewayのバックエンドがUnhealthyになる

よくある原因：
・NSGでGatewayManagerからの65200～65535ポートへのInboundが遮断されている
・バックエンドVMのWebサーバー（Apache/Nginx）が起動していない
・ヘルスプローブに設定したパス（例：/health）がバックエンドで実装されていない
・ヘルスプローブのタイムアウト設定が短すぎてバックエンドの応答が間に合わない

4. コストが想定より大幅に高くなった

症状：L7機能をほとんど使っていないのにLoad Balancerの数十倍のコストが発生している
対処：URLルーティング・SSLオフロード・WAFを実際に使用しているか見直す。これらが不要であれば、Standard SKUのLoad Balancerに切り替えることでコストを大幅に削減できる

本記事のまとめ

比較項目 Azure Load Balancer Application Gateway
動作層 L4（TCP/UDP） L7（HTTP/HTTPS）
ルーティング基準 IPアドレス＋ポート番号 URLパス・ホスト名・HTTPヘッダー
対応プロトコル TCP・UDP（汎用） HTTP・HTTPSのみ
SSLオフロード 不可 可能（証明書集約）
WAF なし WAF_v2 SKUで利用可
セッションアフィニティ 送信元IPハッシュ Cookieベース
マルチサイト対応 不可 可能（ホストベースルーティング）
コスト目安 低（ルール単位＋データ転送） 高（キャパシティユニット課金）
主な用途 VM/VMSS・DBサーバー・内部通信 WebアプリのHTTPS受付・WAF

選定の判断は「HTTP/HTTPSのWebアプリでL7制御（URLルーティング・SSL・WAF）が必要か」で8割が決まります。必要なら Application Gateway、不要なら Load Balancerが適切な選択です。

両者を組み合わせるアーキテクチャも一般的です。Application Gateway（外部向けHTTPS＋WAF）＋内部Load Balancer（アプリサーバー間のTCP通信）という構成で、役割に応じた使い分けができます。

Azure Load Balancer・Application Gatewayの実構成も、ハンズオンで体系的に習得できます

Load BalancerとApplication Gateway、選定判断の次は実際の構成演習です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Azureハンズオン学習コースでは実機を使った演習で即戦力スキルを習得できます。

今すぐ詳細を確認する ＞＞ Azureハンズオン学習コースを見る

※ 「Linuxの基礎から体系的に学びたい」という方には、『Linuxサーバー構築入門マニュアル（図解60P）』を無料でプレゼントしています。こちらから無料ダウンロード。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。