Connectivity subscriptionは『全部のnetwork resourceを入れる場所』ではなく、複数landing zoneが共有するplatform connectivityを中央管理する境界です。Application teamへはnetwork実装の詳細ではなく、vended VNet・接続class・DNS・egress・security baselineという利用contractを提供します。
Azure Landing Zone Connectivityを理解するための前提
Azure Landing Zone conceptual architectureでは、platform landing zoneとapplication landing zoneを分離し、connectivity subscriptionにshared network resourcesを配置する構成が示されている。 traditional Hub-Spokeを採用する場合、regional hub VNet、Azure Firewallまたはpartner NVA、VPN/ExpressRoute gateway、DNS等をconnectivity subscriptionへ集約できる。
Virtual WANを採用する場合も、Virtual WAN resources、Azure Firewall、DDoS plan等をconnectivity subscriptionに置くcurrent guidanceがある。 Application landing zoneはworkload lifecycleとownershipの単位。Platform teamがcentral hubへpeerするVNetをsubscription vending時に提供し、application teamへsubnet等の適切なautonomyを渡すpatternが推奨される。
network governanceはmanagement groupに割り当てるAzure PolicyやAzure Virtual Network Manager / Security Admin Rulesでplatform baselineを適用し、個別teamの手作業だけに依存しない。 CIDR allocation、routing domain、DNS suffix/zone、egress class、hybrid requirementをsubscription発行時に確定すると、onboarding後の後付けnetwork変更を減らせる。
Ownership / Control / Data plane boundary
Policy/RBAC/initiativeを継承するgovernance boundary。Network standardをsubscription個別設定より上位で表現する。
regional hub/VWAN、hybrid gateways、central firewall/NVA、shared DNS、DDoS planなどplatform connectivityを所有。
workload VNet/subnet、private endpoints、application ingress、workload NSGなどapplication lifecycleに追従するresourceを所有。
subscription作成時にCIDR、region、connectivity class、DNS/egress/security baselineを自動で適用し、hand-off条件を明示する。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Topology | traditional Hub-SpokeかVirtual WANか。region数、branch、NVA、route controlで決める。 | platform topology standardとexception条件。 |
| Subscription vending | Platform teamがどこまでnetwork resourceを事前作成するか。 | VNet/CIDR/peering、route table、DNS link、baseline NSG/Policyの責任。 |
| Connectivity class | corp-connected、online/privateなどworkloadが選べる接続profileをどう定義するか。 | egress path、on-prem reachability、private DNS、inspection、public exposure。 |
| IPAM | CIDR allocationを誰が承認し、重複をどう防ぐか。 | pool hierarchy、allocation workflow、reserved blocks、ownership metadata。 |
| Governance | management group PolicyとAVNM/Security Admin Rulesの役割をどう分けるか。 | deny/audit/modify policy、network group membership、global security baseline。 |
| Exception | 標準から外れるroute/NVA/public IPを誰が承認するか。 | expiry、risk owner、review date、rollback。 |
実装・展開の順序
- Management group hierarchyとplatform/application subscription boundaryを先に確定する。
- regional/global network topologyを選定し、connectivity subscriptionへ配置するshared service catalogを作る。
- IPAMでaddress poolを設計し、vending inputとしてregion、environment、workload、required size、connectivity classを定義する。
- non-production subscription vendingでVNet/peering/DNS/route/security baselineを自動適用し、Platform→Application hand-off evidenceを生成する。
- application teamの最小権限でsubnet/private endpoint等の日常作業が完結するかを確認し、central permissionへの不要な依存を削る。
- Policy compliance、AVNM deployment status、route/DNS reachabilityを定期監査し、landing zone update時も標準をversion管理する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Subscription / MG | platform hierarchy、Policy、RBAC baselineを管理。 | vended subscription内のworkload resource lifecycleを管理。 |
| VNet / IPAM | central hub接続VNetとaddress allocation standardを提供。 | 割り当て範囲内でsubnet設計し、追加CIDRが必要なら申請。 |
| Hybrid / Egress | ER/VPN、central firewall/NVA、shared public egressを管理。 | 必要destination/FQDN/portとbusiness justificationを管理。 |
| DNS | central Resolver、forwarding、shared Private DNS patternを管理。 | workload private endpoint/record lifecycleを管理。 |
| Security | Policy/Security Admin Rulesで最低baselineを強制。 | NSG/application controlsでさらにleast privilege化。 |
Verification / review evidence
設計レビューで残す証拠
- Management group / subscription hierarchyとowner。
- Connectivity subscription resource inventoryとregion mapping。
- Subscription vending input/output contract。
- IPAM allocation ledgerとoverlap check。
- Policy/AVNM baselineとexception register。
runtimeで確認すること
- 新規landing zoneをvendingしてHub/VWANへのconnectionが自動かつ期待scopeで作成されること。
- on-prem/private/shared service/Internetの各connectivity classが契約どおりに到達または拒否されること。
- Private Endpoint作成後にDNS pathがcentral designと整合すること。
- workload team権限でcentral gateway/firewallを変更できず、日常subnet作業は実行できること。
- landing zone削除時にIPAM allocation/peering/policy artifactが孤児化しないこと。
az account management-group list -o table
az account list -o table
az network vnet list -o table
az network firewall list -o table
az network vwan list -o tableGet-AzManagementGroup
Get-AzSubscription
Get-AzVirtualNetwork
Get-AzFirewall
Get-AzVirtualWanCommon failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| Application teamがHubを直接変更 | RBAC boundaryがsubscription/VNet ownershipと一致していない。 | central resourceはconnectivity subscriptionへ隔離し、必要actionだけdelegation。 |
| 新規subscriptionで毎回CIDR/DNSが手作業 | vending contractにnetwork input/outputがない。 | IPAM、region、connectivity class、DNS、Policyをsubscription vendingへ統合。 |
| PolicyとAVNMが二重管理で競合 | どのcontrolが何をenforceするか未定義。 | resource complianceはPolicy、topology/security/routingはAVNM等、責任を設計書で分離。 |
| platform serviceがworkload固有要件で肥大 | central hubへapplication-specific resourceを集めすぎる。 | shared service判定基準を定義し、workload固有はapplication subscriptionへ戻す。 |
| landing zone移管後に疎通問題 | hand-off前のruntime acceptanceがない。 | source/destinationごとのpositive/negative testをvending完了条件にする。 |