outputAzure Load Balancer vs Application Gateway｜オンプレ経験者のためのAzure負荷分散サービスの違いと使い分けガイド

オンプレでHAProxyやNginx、あるいはF5によるロードバランサーを運用してきたエンジニアがAzureに移行すると、まず戸惑うのが「ロードバランサーが複数ある」という点です。Azure Load BalancerとAzure Application Gatewayは名前は似ていますが、動作するレイヤーも適したユースケースも全く異なります。

この記事では、Azure Load Balancer（ALB）とAzure Application Gateway（AGW）の違いを、オンプレのネットワーク構成と比較しながら実践的に解説します。どちらを選ぶかの判断基準も具体的に示しますので、Azureで負荷分散設計をはじめて行う方はぜひ参考にしてください。

なぜAzureに複数の負荷分散サービスがあるのか

オンプレでは「ロードバランサー＝L4/L7を1台でこなす装置」として扱うケースが多かったはずです。F5のBIG-IPならL4のSNATからL7のHTTPヘッダー操作まで一つの筐体で対応できました。

Azureは役割ごとにサービスが分かれています。これはクラウドの「マネージドサービスはスコープを絞って深く作る」という設計思想に基づいています。

この記事では最も使用頻度の高いAzure Load BalancerとAzure Application Gatewayの2つに絞って解説します。

Azure Load Balancerの特徴と使い方

Azure Load Balancer（以下ALB）はL4（トランスポート層）で動作するロードバランサーです。TCPセッションを透過的に転送するため、HTTPのヘッダーは見えません。その分、レイテンシが低くスループットが高いという特徴があります。

1. SKUの違いを理解する

ALBにはBasicとStandardの2つのSKUがあります（2026年3月時点）。

・Basic SKU: 無料。可用性ゾーンに非対応。開発・検証用途向け。
・Standard SKU: 有料（約$0.005/時間〜）。可用性ゾーン対応、SLA 99.99%。本番環境はこちらを選ぶ。

本番ワークロードではBasic SKUは使わないことをお勧めします。Basic SKUは可用性ゾーンをサポートしておらず、将来的にMicrosoftが廃止を予告しているためです。

2. 内部LBとパブリックLBの違い

ALBには「パブリックロードバランサー」と「内部（プライベート）ロードバランサー」の2種類があります。

・パブリックロードバランサー: インターネットからの通信をVNet内のVMに分散する。フロントエンド向け。
・内部ロードバランサー: VNet内のプライベートIPアドレスを使って内部サービス間通信を分散する。DB層・マイクロサービス間通信に使う。

オンプレの構成に例えると、DMZ上のLBがパブリックLB、内部ネットワーク（サーバーセグメント）上のLBが内部LBに相当します。

3. Azureポータルでの基本設定手順

Standard SKUのパブリックロードバランサーを作成する手順を示します。

①Azureポータルで「ロードバランサー」を検索し、「作成」をクリックします。
②SKU「Standard」、タイプ「パブリック」を選択します。
③「フロントエンドIP構成」でパブリックIPアドレスを追加します（新規作成またはExisting）。
④「バックエンドプール」に対象のVMまたはVM可用性セットを追加します。
⑤「負荷分散規則」でフロントエンドIPとバックエンドプール、プロトコル・ポートを紐付けます。
⑥「正常性プローブ」でバックエンドVMの死活確認方法（HTTP/TCP・確認先ポート・間隔）を設定します。

Zabbixでいう「監視対象登録」に近い感覚ですが、ポータル上でGUIが完結する点がオンプレとの大きな違いです。

Azure CLIで確認する場合：

# Azure CLIでロードバランサーの設定を確認する
az network lb show \
  --resource-group your-rg \
  --name your-lb-name \
  --output table

Azure Application Gatewayの特徴と使い方

Azure Application Gateway（以下AGW）はL7（アプリケーション層）で動作するWebアプリケーション向けのロードバランサーです。HTTPSターミネーション、URLベースルーティング、Cookieスティッキーセッション、WAF機能を持ちます。オンプレでNginxのリバースプロキシとF5 ASMを組み合わせて使っていた方には、それを一本化したサービスと考えると理解しやすいです。

1. SKUと主要機能

AGWにはStandard_v2とWAF_v2の2つのSKUがあります。

・Standard_v2: URLルーティング・HTTPSターミネーション・自動スケーリングが使える基本SKU。
・WAF_v2: Standard_v2の全機能に加え、OWASP Core Rule Setに基づくWAFが有効になる。Webアプリを公開する場合はこちらを選ぶ。

料金の目安（2026年3月時点）：
・Standard_v2: 約$0.246/時間〜 + データ処理料
・WAF_v2: 約$0.443/時間〜 + データ処理料

ALBと比べて料金は高めですが、SSLオフロードやWAFを個別に構築する手間が省けることを考えると、Webアプリには合理的な選択です。

2. URLベースルーティングの設定

AGWの強みの一つがURLパスに基づくバックエンドへの振り分けです。

例：
・`/api/*` → APIサーバーのバックエンドプール
・`/images/*` → 静的ファイルサーバーのバックエンドプール
・それ以外 → Webアプリサーバーのバックエンドプール

これはNginxのlocation設定でupstream先を変える動作と同じです。AGWではこれをGUIまたはARM/Bicepテンプレートで定義します。

3. HTTPS終端と証明書管理

AGWでHTTPS終端を設定すると、クライアント〜AGW間はHTTPS、AGW〜バックエンドVM間はHTTPまたはHTTPSで通信できます。証明書はAzure Key VaultのシークレットとしてAGWに紐付ける方法が推奨されています（証明書の自動更新が容易になります）。

# Azure CLIでApplication GatewayのHTTPSリスナーを確認する
az network application-gateway http-listener list \
  --resource-group your-rg \
  --gateway-name your-agw-name \
  --output table

どちらを選ぶか——判断基準の整理

「ALBかAGWか」を判断するシンプルな基準を以下にまとめます。

よくある構成パターンは「AGWをフロントに置き、AGWのバックエンドにVMを並べる」です。AGW〜VM間のさらに細かいL4分散が必要な場合に内部ALBを組み合わせることもあります。

料金の仕組みとコスト感覚

両サービスのコスト比較を現場で使う感覚でまとめます（2026年3月時点・東日本リージョン）。

【重要】AGWは自動スケーリング設定で最小インスタンス数を0にできますが、トラフィックがゼロでも最低課金（0ユニット$0/h）が発生し、リクエスト到着時に起動ラグが生じます。本番運用では最小インスタンス数を1以上に設定することをお勧めします。

開発・ステージング環境でコストを抑えたい場合は、夜間・週末にAGWを停止するスクリプトをAzure Automationで自動実行する方法もあります。

実務Tips——よく聞くハマりポイント

1. ALBの「フローティングIP（Direct Server Return）」に注意

ALBでフローティングIPを有効にすると、バックエンドVMにロードバランサーのフロントエンドIPがそのまま届きます。オンプレのDirect Server Return（DSR）と同じ概念ですが、バックエンドVMのNIC設定で対応するIPアドレスをloopbackに追加しないと通信が成立しません。特殊なユースケース以外では無効のまま使いましょう。

2. AGWとNSGの組み合わせ

AGWを含むサブネットにNSGを適用する場合、ポート65200〜65535（AGWの管理用通信）をインバウンドで開放する必要があります。これを忘れるとAGWが正常に動作しなくなります。

# AGWサブネットのNSGに必要なインバウンドルール（Azure CLI）
az network nsg rule create \
  --resource-group your-rg \
  --nsg-name your-nsg \
  --name AllowAGWManagement \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes GatewayManager \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 65200-65535

3. ALBのアウトバウンド規則（SNAT枯渇対策）

パブリックALBを使うVMからインターネットへの外向き通信には、ALBのSNATポートが使われます。VM数が多い環境ではSNATポートが枯渇し「Connection Refused」が発生します。ALBの「アウトバウンド規則」でSNATポート数を手動で増やすか、Azure NAT Gatewayを別途設けることで解決します。

よくあるトラブルと対処法

バックエンドVMに疎通できない（正常性プローブが失敗する）

最も多い原因はVMのNSGでプローブのポートをブロックしていることです。ALBの正常性プローブはAzureのインフラ側IPから来るため、ソースIPはVNet内には現れません。NSGには「AzureLoadBalancer」タグからのインバウンドを許可するルールを追加してください。

# NSGに正常性プローブ許可ルールを追加（Azure CLI）
az network nsg rule create \
  --resource-group your-rg \
  --nsg-name your-vm-nsg \
  --name AllowAzureLBProbe \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol '*' \
  --source-address-prefixes AzureLoadBalancer \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'

AGWでSSLハンドシェイクエラーが発生する

AGWのバックエンド設定で「バックエンドHTTPSを使用する場合の証明書検証」が有効になっているとき、バックエンドVMの証明書がAGWに信頼されていないと通信が失敗します。開発環境では「バックエンド設定 → カスタムプローブをオフにする / 証明書検証をオフにする」で暫定対処できますが、本番環境では適切な証明書を設定してください。

本記事のまとめ

Azure Load BalancerとAzure Application Gatewayは役割が明確に分かれています。

「HTTPSで公開するWebアプリにはAGW（WAF_v2）、それ以外のTCP通信にはALB（Standard）」がAzureにおける標準的な選択パターンです。

オンプレで磨いたL4/L7の使い分け感覚はそのまま活かせます。変わるのは設定の方法だけです。AzureのマネージドLBをうまく活用して、運用負荷を大幅に減らしていきましょう。

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。Azure VM上でNginxやHAProxyを動かす際のLinux知識が必要な方はあわせてご参照ください。