Network Foundation

Networking is where landing zones most often go wrong quietly. The topology usually gets attention; DNS usually does not — and a private endpoint without a DNS plan is a workload that fails intermittently for reasons nobody can explain. This page defines a network foundation where traffic paths are understandable and public exposure is the exception.

Purpose

This page defines the network foundation for the platform: topology, address space, routing, egress, DNS, private endpoints, and hybrid connectivity — all anchored in a dedicated connectivity subscription.

Design Reasoning

Hub-spoke is the topology the Cloud Adoption Framework recommends, and the right default when you need shared services, centralized ingress and egress control, network security, and hybrid connectivity. A central hub VNet hosts shared services; workload spokes peer to it.

Azure Virtual WAN is the better fit when the environment has multiple regions, many branch sites, ExpressRoute or VPN connectivity at scale, and a need for Microsoft-managed transitive routing. It trades some control of the hub for managed scale.

For a very small environment with no hybrid connectivity and no multiple isolated workload networks, a single simpler VNet can be a temporary step. Treat that as a pragmatic, documented simplification — not the standard landing zone target.

Architecture Decision Record

Tradeoff: Hub-spoke centralizes egress and inspection, which adds a hop and a shared component to operate. The benefit is one place to control, inspect, and log outbound traffic instead of per-workload exceptions.

Recommended Configuration

Example Implementation

A hub-spoke foundation, with shared network services in the connectivity subscription and workload spokes peered to the hub:

flowchart LR
subgraph conn[Connectivity subscription]
  H[Hub VNet]
  F[Azure Firewall]
  R[DNS Private Resolver]
  P[Private DNS zones]
  G[VPN or ExpressRoute]
  N[NAT Gateway]
end
subgraph work[Workload subscriptions]
  S1[Production spoke]
  S2[Non-production spoke]
  S3[Sandbox spoke]
end
H --> F
H --> R
H --> P
H --> G
H --> N
S1 --> H
S2 --> H
S3 --> H

Validation Steps

1
# Inventory the network foundation
2
az network vnet list --output table
3
az network private-dns zone list --output table
4
az network dns-resolver list --output table
5
az network nat gateway list --output table

Then validate private endpoint DNS behavior — this is the check most often skipped:

1
nslookup <sql-server-name>.privatelink.database.windows.net
2
nslookup <storage-account-name>.privatelink.blob.core.windows.net

Confirm that private endpoint FQDNs resolve to private IP addresses, and that on-premises DNS queries are forwarded correctly when hybrid name resolution is required.

Common Mistakes

• Deploying private endpoints without a DNS strategy — the single most common networking failure.
• Building a hub with no clear egress or ingress role.
• Direct spoke-to-spoke peerings created without a clear reason.
• Expecting customer-managed shared services to run inside a Virtual WAN managed hub.
• Using Azure Firewall for everything without weighing cost or inspection requirements.
• Forgetting outbound connectivity planning for private workloads, or mixing workload and private-endpoint subnets without design intent.

References

• Hub-spoke network topology in Azure
• Virtual WAN network topology in an Azure landing zone
• Private Link and DNS integration at scale
• Private endpoint DNS configuration
• Azure DNS Private Resolver
• Azure NAT Gateway