Centralized egressの目的は『0.0.0.0/0をFirewallへ向ける』ことではありません。送信元workloadからinternet/SaaSまで、route selection、inspection policy、SNAT capacity/public identity、DNS、return traffic、loggingを一つのegress contractとして設計します。
Centralized Egress Architectureを理解するための前提
Cloud Adoption Frameworkのcurrent guidanceは、default outbound accessへ依存せず、workload要件に合う明示的なoutbound methodを設計するよう推奨している。 Hub-SpokeではAzure Firewallまたはpartner NVAをcentral hubへ置き、Spoke subnetのUDRでinternet/private prefixをinspection pointへ向けるpatternが一般的。
Azure NAT Gatewayはsubnet outboundの明示的SNAT機能であり、Layer 7 policy/IDPS/FQDN inspectionを行うFirewallの代替ではない。要件が『安定したSNAT/public IPと大きいSNAT port pool』だけならdistributed NAT Gatewayが適する場合がある。 Azure FirewallのSNAT scalabilityが要件になる場合、traditional Hub-SpokeではNAT GatewayをAzureFirewallSubnetへ関連付けてFirewall outboundを拡張するofficial patternがある。
FQDN application ruleを使うcentral Firewallでは、clientとFirewallの名前解決結果が不一致だと正当trafficをblockする可能性がある。DNS pathはegress architectureの一部。 centralized egressは共有failure domainでもある。Firewall/NVAのavailability、zone、route convergence、policy deployment、SNAT pressure、logging pipelineをcapacity/failure reviewへ含める。
Ownership / Control / Data plane boundary
Spokeからどのprefixをcentral egressへ送るかをUDR/effective routeで定義。Internetだけか、east-west/on-premも同じinspectionへ送るかを分ける。
Firewall Policy/NVA ruleは許可条件を決める。routeがFirewallを指していてもpolicyが許可するとは限らず、逆も同じ。
partner allowlistやauditに見えるsource public IPをownership対象にする。Firewall public IP / NAT Gateway prefix等を明示。
FQDN policy利用時はclient resolver、Firewall DNS proxy/upstream、Private/Public resolutionを整合させ、IP driftを考慮する。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Inspection | L3/L4、FQDN、TLS inspection、IDPS、third-party security serviceのどこまで必要か。 | service/SKU、rule model、certificate/DNS dependency、log requirement。 |
| Route scope | 0.0.0.0/0だけか、RFC1918/on-prem/spoke routeもinspectionするか。 | prefix list、longest-prefix conflict、BGP propagation方針。 |
| SNAT | 同時connection、destination fan-out、partner allowlist、public IP stabilityを満たすか。 | public IP/prefix、capacity model、monitoring threshold。 |
| DNS | Firewall FQDN ruleとworkload resolutionを同一provider/resultへ寄せるか。 | DNS proxy、resolver、upstream、TTL、split-horizon。 |
| Bypass | Microsoft PaaS/Private Endpoint/backup/updateなどdirect pathを許すか。 | bypass criteria、service tag/prefix、security owner、exception expiry。 |
| HA | egress serviceまたはregion障害時にfail closed / fail overのどちらか。 | RTO、secondary path、route switch mechanism、test cadence。 |
実装・展開の順序
- workloadごとのegress destinationをIP/FQDN/service tag/port/protocolでinventoryし、direct/inspect/denyへ分類する。
- central Firewall/NVAのpolicyとDNSを先に作り、routeを変える前にrule coverageとloggingを検証する。
- canary subnetだけUDRを関連付け、Effective Routesでdefault/private routeのselected next hopを確認する。
- 実requestを発生させ、Firewall/NVA logにsource/destination/rule/SNATが記録され、partner側から期待public IPに見えることを確認する。
- SNAT capacity、latency、failure behaviorを負荷/障害testで確認し、必要ならAzureFirewallSubnetへのNAT Gatewayなどscaling designを適用する。
- deployment ringごとにSpokeを移行し、legacy egress pathの使用量が0になったことを観測してから撤去する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Egress policy | central allow/deny、TLS/IDPS、public IP inventoryを管理。 | required SaaS/FQDN/portとbusiness ownerを申請。 |
| UDR | 標準route intentとNVA/Firewall next hopを管理。 | subnet固有route exceptionを申請し、勝手な0/0上書きを避ける。 |
| DNS | Firewall DNS proxy/central resolverを管理。 | applicationが独自DNSを使う場合はFQDN policy影響を申告。 |
| SNAT / capacity | public IP/prefix、SNAT monitoring、scale actionを管理。 | expected concurrency/destination patternをcapacity planningへ提供。 |
| Validation | platform path/log/negative testを提供。 | actual SaaS/API transactionでend-to-end successを確認。 |
Verification / review evidence
設計レビューで残す証拠
- Egress traffic inventoryとrule owner。
- Spoke subnetごとのroute table / effective route snapshot。
- Firewall/NVA policy versionとdeployment timestamp。
- public IP/prefix allowlistとSNAT capacity assumption。
- DNS query path、FQDN rule dependency、rollback route。
runtimeで確認すること
- source NICで0.0.0.0/0および対象prefixが期待Firewall/NVAへ向く。
- Firewall/NVA logでactual flowが期待ruleにmatchし、bypassしていない。
- 外部destinationから見えるsource public IPがallowlistと一致。
- DNS名前解決結果とFirewall側resolutionが整合し、FQDN ruleが安定してmatch。
- Firewall/NVA failover、policy rollback、route rollback後に新規connectionが回復。
az network route-table list -o table
az network firewall list -o table
az network public-ip list -o table
az network nat gateway list -o tableGet-AzRouteTable
Get-AzFirewall
Get-AzPublicIpAddress
Get-AzNatGatewayCommon failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| 一部SaaSだけ失敗 | FQDN解決がclientとFirewallで不一致、またはTLS/IDPS/application rule dependency。 | DNS query pathとFirewall logを同じ時刻で比較。 |
| 大量接続時だけtimeout | SNAT port/capacity不足やdestination fan-outの偏り。 | SNAT utilization/connection metricを確認しpublic IP/NAT Gateway integrationを検討。 |
| Firewallを迂回 | more-specific routeや別NIC/subnet route、PaaS direct pathが存在。 | effective routeとactual flow logで選択pathを証明。 |
| Partner allowlistに不一致 | egress public IP setを資産管理していない。 | public IP/prefixをcontract化し、変更をpre-change notification対象にする。 |
| egress変更で全Spoke同時停止 | central route/policyを一括deploy。 | canary subnet/network group、staged rollout、automatic rollback thresholdを設ける。 |