Building blocks
Design goal
Scale connectivity across multiple workloads without turning the network into an any-to-any mesh or placing application resources inside the shared-services hub.
Architecture
A central hub hosts shared connectivity and security services. Application workloads remain in spoke VNets and use peering plus controlled routing to consume shared services.
Architecture decisions
Keep workloads out of the hub
WhyUse the hub for shared platform services and keep application resources in spokes.
Trade-offA clean hub keeps shared services stable, but spoke teams must use explicit routes and shared-service interfaces instead of local shortcuts.
Centralize inspection
WhyUse Azure Firewall or another approved inspection layer when traffic policy requires centralized enforcement.
Trade-offCentral inspection improves policy consistency and observability, but can add latency, processing cost, routing complexity, and a shared failure domain.
Networking
Make the traffic path explicit. Use non-overlapping address spaces, explicit route intent, and centralized DNS resolution for hybrid and private endpoint scenarios.
Security
Protect the control and data paths deliberately. Apply least-privilege network rules, centralized logging, controlled egress, and private endpoints for PaaS where appropriate.
Availability
Design for the failure domain that must be survived. Design gateway, firewall, and shared services for zone resilience where supported and avoid single dependencies in DNS or identity.
Disaster recovery
Treat regional recovery as a separate operating state. Duplicate required hub services in the recovery region when multiregion recovery is required; workload DR remains workload-specific.
Cost drivers
- Azure Firewall
- VPN/ExpressRoute gateways
- Bastion
- Private DNS Resolver
- inter-region and peering traffic
Design assumptions
- Address spaces are non-overlapping
- Central networking ownership is defined
- Routing and DNS requirements are documented
Implementation plan
- Define non-overlapping address space and decide which connectivity, inspection, DNS, and management services belong in the hub.
- Build the hub with the required gateway, firewall/NVA, resolver, and shared-service subnets while keeping application resources in spokes.
- Peer spokes to the hub and configure gateway transit or remote-gateway use only where the connectivity model requires it.
- Create route tables that make inspection and egress paths explicit; avoid route propagation that creates unintended spoke-to-spoke reachability.
- Link the required Private DNS zones/resolvers and validate routing, name resolution, and failure behavior from representative spokes.
Validate the design
- Inspect effective routes from representative spokes and confirm ingress, egress, hybrid, and inspection paths match the design.
- Attempt a disallowed spoke-to-spoke flow and confirm routing/security policy blocks it.
- Resolve representative on-premises and private-endpoint names from a spoke and confirm the intended DNS path.
- Fail or bypass a planned hub dependency in a controlled test and confirm the documented failure behavior.