AZ VNet SpaceAzure Networking Wiki
Home / Load Balancing & Delivery
Load Balancing & Delivery参照資料確認: 2026-09-11

Application Gateway v2

Application Gateway v2を、regional Layer 7 proxy、listener/rule/backend setting、TLS termination、autoscale、source IP headerまで整理する。

この記事の目次
要点境界通信経路仕組み設計確認障害切り分け変更/rollbackCurrentSources

Application Gateway v2を理解するための前提

Application Gateway v2はregional Layer 7 reverse proxy/load balancerで、HTTP(S)、WebSocket、TLS termination、path/host routing等を提供する。 v2 productionの中心はStandard_v2/WAF_v2。v1は2026-04-28にretire済みで新規設計の対象にしない。

frontend listener→request routing rule→backend pool + backend setting→health probeという参照関係でdata pathを構成する。 backend network sourceはApplication Gateway instance private IPで、original clientはx-forwarded-for等のHTTP headerとして渡される。

HTTPS backendではbackend settingのHost/SNIとserver certificate subject/trusted rootの整合がhealth/live trafficに影響する。 v2はautoscaling、zone redundancy、static VIP等を備え、private-only frontendもcurrent supported configuration。

通信や判断の流れを追う
ClientEdge / Load balancerRouting / HealthBackend

Control plane / Data plane / Observability

Frontend L7

listenerがIP/port/protocol/hostを受ける。

Routing

ruleがhost/path等でbackend pool/settingsを選ぶ。

Backend connection

Gateway instanceが新しいconnectionをbackendへ張り、X-Forwarded-*でclient contextを渡す。

判定原則L4 flow、L7 proxy、DNS steering、NVA chainingを同じ「load balancing」として扱わず、clientが最終的にどのIPへ接続し、どこでconnectionが終端/再生成されるかを最初に固定します。

Client-to-backend path

  1. clientがApplication Gateway frontend listenerへHTTP(S) requestを送る。
  2. HTTPS listenerならGatewayでclient-side TLSを終端する。
  3. listener/routing ruleがhost/path等からbackend poolとbackend settingを選ぶ。
  4. health stateがHealthyなbackendへGateway instanceから新しいbackend connectionを張る。
  5. backendはsourceとしてGateway instance private IPを見て、original clientはX-Forwarded-For等で受け取る。
  6. backend responseをGatewayがclient connectionへ返し、rewrite/WAF等のconfigured processingを適用する。

仕組みを分解する

Application GatewayはLoad Balancerと違いproxyです。client側connectionとbackend側connectionは別です。そのためNSG/route調査ではclient→frontendとGateway instance→backendを分離し、client IP要件はpacket sourceではなくX-Forwarded-For trust chainを含めて設計します。TLSもfrontend terminationとbackend TLSの2区間でcertificate/SNIを別々に確認します。

運用時はresource configurationだけで完了判定せず、実clientからの名前解決、TCP/TLS handshake、HTTP status、backend側のsource IP/Host/header、health telemetryを同じtimestampで揃えます。load balancer/proxyがhealthyでもapplication dependencyが壊れている場合があり、逆にbackend applicationが正常でもhealth probe条件やrouting ruleが不整合ならtrafficは到達しません。

設計判断

判断軸設計方針
Standard_v2 vs WAF_v2L7 routingだけならStandard_v2、managed WAFが必要ならWAF_v2。Basic previewをproduction要件へ安易に採用しない。
Frontendpublic/private/bothを要件で選ぶ。private-onlyはnetwork isolation/current feature条件を確認する。
Host preservationorigin/appのredirect/cookie/authがhost依存ならoriginal Hostを保持する設計を優先する。
TLSclient cert/mTLS、frontend cert、backend trust/SNIを区間ごとにdocumentする。

確認手順

Read-only verification

  • listener、rule、backend pool、backend setting、probeのresource ID参照を辿る。
  • Backend healthでHealthy/Unhealthy/Unknownと詳細reasonを取得する。
  • backend access logでsource IPとX-Forwarded-For/Hostを確認する。
  • HTTPS backendではopenssl/curl等で証明書CN/SANと設定Host/SNIを比較する。

Evidence to keep

  • resource ID / subscription / region / frontend / backend targetを保存し、同名resource取り違えを防ぐ。
  • DNS answer、source IP、destination IP/port、Host/SNI、health status、timestampを同じincident recordへ残す。
  • 変更前後で同じclient journeyをnew connectionとして再実行する。
  • Portal表示だけでなくCLI/PowerShell/APIまたはlogsを併用し、観測面の一時差を識別する。
Azure CLI — read-only first
az network application-gateway show -g <rg> -n <appgw> -o jsonc
az network application-gateway rule list -g <rg> --gateway-name <appgw> -o table
az network application-gateway show-backend-health -g <rg> -n <appgw> -o jsonc
PowerShell — read-only first
Get-AzApplicationGateway -ResourceGroupName <rg> -Name <appgw>
Get-AzApplicationGatewayBackendHealth -Name <appgw> -ResourceGroupName <rg>

障害切り分け

症状第一候補証拠次の確認
Frontend 502all backend unhealthy/TLSBackend health + access logprobe/TLS/DNSを確認
redirect hostがおかしいHost overridebackend log/Location headerhost preservation
client IPがGateway IPpacket sourceを見ているX-Forwarded-Fortrusted proxy chain設定
HTTPS backend probe failureSNI/CN/root mismatchprobe detail/certbackend Host/SNI修正
一部pathだけ404routing rule/path maprule configpath order/rewrites確認

変更時の確認と rollback

  • listener/rule/backend setting/probeをexportしてから変更する。
  • certificate replacementはfrontend/backend TLSを分け、旧certをrollback可能に保持する。
  • routing changeはhost/pathごとのsynthetic testを用意する。
  • rollback後はclient→frontend→backendの同一request IDでend-to-end確認する。
Change safety: health probe、DNS、TLS certificate、WAF/routing rule、backend poolを同時に変えるとfailure domainを判別できません。1 hypothesisずつ変更し、各段階で同じobservable journeyを再実行します。

Current notes — 2026-09-11

Current behavior / guidance

Application Gateway v1は2026-04-28に廃止済みで、Microsoftによるpatch・support・SLA保証はありません。残存v1のtrafficも保証されないため、現行設計と継続運用はv2へ移行します。v2ではprivate-only frontend、autoscaling、zone redundancy、static VIP等を利用できます。

Application Gateway Listeners & Routing
関連するpacket path・health・TLS・delivery設計を続けて確認。Application Gateway Backend Health
関連するpacket path・health・TLS・delivery設計を続けて確認。Private Application Gateway
関連するpacket path・health・TLS・delivery設計を続けて確認。WAF for Application Gateway
関連するpacket path・health・TLS・delivery設計を続けて確認。

Official sources

動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。