Multi-regionは『同じ構成を2regionに複製』ではありません。regional failure domain、traffic steering、cross-region dependency、data replication、hybrid entry、DNS、inspection、RTO/RPOを明示し、primary region喪失時の実routeまで設計します。
Multi-Region Networkingを理解するための前提
Hub-Spoke architectureではHubはregional resource。複数regionのworkloadにはregionごとのHubを置き、Spokeは通常local Hubへ接続する。 Azure networking design guideはmulti-region hub topologyとしてtraditional hub-per-regionとVirtual WAN multi-hubを比較し、traditionalではcustomerがGlobal VNet Peering/UDR等を管理、Virtual WANではinter-hub routingをmanagedに扱う。
traditional designはgranular routing control、custom NVA、既存Hub投資が重要な環境に適しやすい。多regionかつglobal transit/branch connectivityを簡素化したい場合はVirtual WANを再評価する。 Front DoorやTraffic Managerのようなglobal traffic steeringと、backend replication用Global VNet Peering等は目的が異なる。user ingressのfailoverとbackend network pathを分けて設計する。
multi-regionではnon-overlapping CIDRをregion hierarchyで予約し、on-prem/other cloud/partner networkを含むrouting domain全体で重複を防ぐ。 HA/DR reviewではnetworkだけでなくapplication state、data replication、identity、DNS、certificate、secret、external allowlistまで依存関係を確認し、routeだけ切り替わってもservice復旧しない状態を避ける。
Ownership / Control / Data plane boundary
Hub/Firewall/gateway/DNS endpointをregion単位で独立させ、1 region障害で別regionのcontrol/data pathまで共倒れしない依存関係を確認。
Front Door/Traffic Manager、Virtual WAN、global peering等のglobal componentが何を決めるかと、regional resource failureを混同しない。
user ingress、workload-to-workload、replication、on-prem accessで経路が違う。traffic classごとにprimary/secondary pathを定義。
RTO/RPOはnetwork failoverだけで達成しない。DNS TTL、BGP/route convergence、Firewall policy、application/data readinessを合成して評価。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Topology | hub-per-regionかVirtual WAN multi-hubか。 | region数、global transit、branch scale、custom route/NVA、operations。 |
| Ingress | HTTP/SはFront Door等でglobal steerするか、DNS-based Traffic Managerか、regional endpointをどうhealth-checkするか。 | health probe、failover priority、TLS/cert、WAF、origin readiness。 |
| Cross-region private | Global VNet Peering、Virtual WAN inter-hub、ER等のどのpathをtraffic classごとに使うか。 | prefix、next hop、inspection、latency/cost、route preference。 |
| Hybrid | on-premから各regionへdual pathを持つか、1 region経由を許すか。 | ER/VPN location、BGP advertisement、local preference、failure route。 |
| DNS | regional/private/global DNSのauthoritative/resolver/failoverをどう分けるか。 | zone ownership、resolver endpoints、TTL、failover record update。 |
| DR | region down時にnetworkが何分で、applicationが何分で復旧すべきか。 | RTO/RPO、dependency checklist、drill frequency。 |
実装・展開の順序
- single-region production topologyを安定化し、そのaddress/routing/security/DNS contractを基準化する。
- secondary region用CIDRをIPAMから予約し、Hub/shared servicesをprimaryと独立したfailure domainとして構築する。
- cross-region connectivityをtraffic classごとに追加し、replicationとinteractive trafficを同じroute policyにまとめない。
- global ingress/health steeringを接続し、secondary applicationがcold/warm/hotのどの状態かをhealth signalへ反映する。
- planned failover drillでprimary ingress停止、route withdrawal/service disableなど現実的なfailureを起こし、DNS/route/firewall/applicationを時間軸で測る。
- failbackまで含めてrunbook化し、new region追加時は同じaddress/governance/observability templateを適用する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Regional hub | 各regionのHub/firewall/gateway容量とlocal routeを管理。 | workloadをlocal regionへ配置しregional dependencyを管理。 |
| Global ingress | global endpoint、health probe、WAF/TLS、origin priorityを管理。 | application health endpointとfailover readinessを提供。 |
| Cross-region routing | peering/vWAN/ER routeとinspectionを管理。 | replication/latency requirementとpermitted cross-region flowを定義。 |
| DNS | global/public/private resolution strategyを管理。 | application recordとendpoint lifecycleを管理。 |
| DR test | network path/route convergenceのdrillを管理。 | data state/business transaction/RTO-RPOをend-to-endで判定。 |
Verification / review evidence
設計レビューで残す証拠
- regionごとのCIDR / Hub / Spoke / gateway / Firewall map。
- traffic class別primary-secondary path matrix。
- global ingress health/failover policyとDNS TTL。
- RTO/RPOに対するroute/DNS/application各段階のbudget。
- planned failover/failbackの実測timeline。
runtimeで確認すること
- primary region正常時にtrafficが期待local pathを使い、unnecessary cross-region hairpinがない。
- primary ingress停止時にglobal steeringがsecondaryへ切り替わり、secondary backendが実transactionを処理。
- private/hybrid trafficがsecondary routeへ収束し、return pathも対称またはNVA要件どおり。
- secondary regionのFirewall/DNS/Key dependencyがprimary regionへhidden dependencyを持たない。
- failback時にroute flap、DNS stale、duplicate active endpointが発生しない。
az network vnet list -o table
az network firewall list -o table
az network vwan list -o table
az network vhub list -o table
az network front-door list -o table 2>/dev/null || trueGet-AzVirtualNetwork
Get-AzFirewall
Get-AzVirtualWan
Get-AzVirtualHub
# Global ingressは利用serviceのread-only cmdlet/APIでも確認Common failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| DR時にnetworkだけ切り替わる | secondaryのdata/identity/DNS/certificateがreadyでない。 | end-to-end business transactionをDR acceptanceにする。 |
| cross-region trafficがFirewallを迂回 | BGP/global peeringのmore-specific routeがinspection routeより優先。 | effective routeを両regionで確認しroute intentをprefix単位で設計。 |
| region追加でCIDR重複 | regional address pool予約がなく個別teamが採番。 | IPAM hierarchyとallocation gateを導入。 |
| primary障害でsecondary DNSも停止 | central resolver/upstreamがprimaryに単一依存。 | regional resolver pathとauthoritative dependencyをfailure matrixへ追加。 |
| failbackで断続的障害 | DNS TTL、connection drain、route convergenceを無視して一括復帰。 | 段階的failbackとtraffic drain、observability gateを使う。 |