Private Application Gatewayを理解するための前提
Application Gateway v2はprivate IP only、public IP only、public + private frontendの組み合わせをサポートする。 private frontendはApplication Gateway subnet内のstatic private IPを使用する。
private-only deploymentはInternet-facing frontendを不要にし、internal LOB/hybrid applicationのregional L7 entry pointとして利用できる。 network isolation/private-onlyのsubscription featureやdeployment propertyはregion/API version/rollout差があり、current subscription stateを確認してからIaCへ固定する。
private frontendの名前解決は利用者側DNSでcustom FQDN→private IPを管理する。public IPがないこととprivate DNSの自動作成は同義ではない。 backendがpublic FQDN/CRL/OCSP等へ到達する必要がある場合、Gateway subnetのoutbound pathは別途設計する。
Control plane / Data plane / Observability
VNet/peering/VPN/ExpressRoute等でprivate frontend IPへ到達。
internal FQDNをprivate frontendへ解決。
Gateway instance→backend/DNS/PKI dependencyのoutboundを別設計。
Client-to-backend path
- internal clientがprivate DNSでAppGW private frontend IPを取得する。
- route/NSGを通ってprivate listenerへ接続する。
- listener/rule/WAFがrequestを処理する。
- Gateway instance private IPからbackendへ新しいconnectionを張る。
- backend responseをprivate frontend経由でclientへ返す。
- certificate validation等でexternal dependencyが必要ならGateway subnetのegress pathを使う。
仕組みを分解する
private-onlyにすると「public management trafficが完全に不要」「Gateway subnetの0.0.0.0/0を何でもNVAへ向けてよい」とは限りません。current network isolation guidance、service tag、control-plane/data-plane dependencyを確認し、Gateway subnet routingを通常workload subnetと同じテンプレートで扱わないことが重要です。
運用時は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は到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Use case | internal-only L7 publishingならprivate-only、同一GatewayでInternetも受けるならpublic+privateを比較する。 |
| Addressing | static private frontend IPをIPAM予約し、subnet resize/移動制約を確認する。 |
| DNS | internal FQDN、split-horizon、certificate SANを一体で設計する。 |
| Egress/UDR | backend/PKI/DNS依存を壊さないrouteをcurrent AppGW network isolation docsで確認する。 |
確認手順
Read-only verification
- frontend IP configurationにpublic IP referenceがなくprivate static IPだけか確認する。
- client VNet/on-premからFQDN→private IP resolutionとTCP 443を確認する。
- AppGW subnet effective route/NSGとBackend healthを同時に確認する。
- public Internetからcustom FQDNが意図せず到達しないことを外部networkから確認する。
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を併用し、観測面の一時差を識別する。
az network application-gateway show -g <rg> -n <appgw> --query "{frontends:frontendIPConfigurations,sku:sku,subnet:gatewayIPConfigurations[0].subnet.id}" -o jsonc
az feature show --namespace Microsoft.Network --name EnableApplicationGatewayNetworkIsolation -o tableGet-AzApplicationGateway -ResourceGroupName <rg> -Name <appgw> | Select-Object -ExpandProperty FrontendIPConfigurations障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| private-only deploy拒否 | feature/rollout条件 | deployment error + feature state | subscription feature確認 |
| VNet内から名前解決不可 | private DNS record | nslookup/Resolve-DnsName | zone/forwarder確認 |
| frontendへrouteなし | peering/VPN/UDR | effective route | private IP path確認 |
| Backend health Unknown | Gateway subnet egress/DNS | health detail | DNS/CRL/route |
| 外部からも到達 | public frontend/DNS残存 | frontend config/public DNS | public exposure除去 |
変更時の確認と rollback
- public→private-only切替はDNS cutover/rollback recordを用意する。
- frontend private IPを変更する場合はcertificate/allowlist/IPAM依存を確認する。
- feature registration自体をrollback手段とみなさず、resource configを戻す。
- rollback後はinternal/external両方から到達性を再確認する。
Current notes — 2026-09-11
Application Gateway v2はprivate-only frontendをcurrent supported combinationとして持つ。v1はretire済みのためprivate deploymentもv2前提で設計する。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。