Network Architecture & Connectivity
Network Architecture & Connectivity defines how resources reach each other and the outside world — virtual networks, topology, and the boundaries between them.
At a glance
Section titled “At a glance”- What it is: virtual networks (VNets/VPCs), subnets, hub-and-spoke or mesh topology, hybrid connectivity (VPN/ExpressRoute/Direct Connect), and segmentation controls like NSGs and firewalls.
- Why it matters: a flat, unsegmented network means a single compromised resource can reach everything else; good network design contains that blast radius.
- For developers: if your service can currently reach every other service and database in the environment with no restriction, that’s a network design gap, not a feature.
- When to use it: whenever more than one workload or environment shares a cloud footprint.
- When not to use it: a single isolated proof-of-concept with no sensitive data may not need full hub-spoke segmentation yet.
- Prerequisites: Landing Zone Design.
Mental model
Section titled “Mental model”graph TD
Hub["Hub VNet: firewall, VPN gateway"] --- SpokeA["Spoke: Checkout VNet"]
Hub --- SpokeB["Spoke: Warehouse VNet"]
Hub --- SpokeC["Spoke: Payments VNet"]
OnPrem["On-premises network"] -- VPN / ExpressRoute --> Hub
SpokeA -.blocked direct peer.- SpokeB
Step-by-step walkthrough
Section titled “Step-by-step walkthrough”- Decide topology: hub-and-spoke (shared services centralized) versus mesh (direct peer-to-peer), based on the number of workloads and need for central inspection.
- Define address spaces up front to avoid overlapping ranges that block future peering.
- Place shared services — firewall, VPN/ExpressRoute gateway, DNS — in the hub.
- Segment each workload into its own spoke/subnet, with explicit rules for what can talk to what.
- Connect on-premises or other clouds via VPN or a private circuit through the hub, not directly into each spoke.
Worked example
Section titled “Worked example”Northwind’s warehouse and storefront workloads currently sit in one flat VNet with no segmentation, and a security review flags that a compromised storefront VM could reach warehouse databases directly.
- Input: one flat VNet, no segmentation, unrestricted east-west traffic.
- Process: the team introduces a hub VNet containing the firewall and VPN gateway; moves warehouse and storefront into separate spoke VNets peered only to the hub; adds NSGs on each spoke that block spoke-to-spoke traffic by default; and configures firewall rules in the hub to allow only the specific ports each workload actually needs to reach the other.
- Output: a compromised storefront VM can no longer reach warehouse databases directly — any cross-workload traffic is inspected and explicitly allowed at the hub. Concretely, this is a hub Azure Virtual Network running Azure Firewall, peered to a Checkout spoke VNet and a Warehouse spoke VNet, each with Network Security Groups denying spoke-to-spoke traffic by default.
Common use cases
Section titled “Common use cases”| Use case | When to use | Notes |
|---|---|---|
| Multiple workloads sharing one cloud environment | Hub-and-spoke topology | Centralizes shared services, contains blast radius |
| Connecting an existing on-premises datacenter to the cloud | Site-to-site VPN or private circuit | Choose a private circuit for latency/bandwidth-sensitive workloads |
| Isolating a regulated workload’s traffic | Dedicated spoke with stricter NSGs/firewall rules | Keeps compliance scope contained at the network layer too |
Advanced details
Section titled “Advanced details”- Overlapping IP address ranges between VNets is one of the most common blockers to peering after the fact — plan address spaces before, not after, provisioning.
- Private endpoints/private link let PaaS services (databases, storage) be reached only from within the VNet, removing public internet exposure entirely.
- Zero-trust network design assumes no implicit trust between segments — every cross-segment connection must be explicitly allowed, not just perimeter-firewalled.
- Cross-region network design should follow Azure’s paired regions (see Business Continuity & Disaster Recovery) — peering or ExpressRoute/VPN routes between a workload’s primary and secondary VNets are far more predictable when the secondary sits in the documented pair rather than an arbitrary nearby region.
Quick reference
Section titled “Quick reference”| Term | Meaning |
|---|---|
| VNet / VPC | Isolated virtual network within a cloud account |
| Hub-and-spoke | Topology centralizing shared services in a hub, workloads in spokes |
| Peering | A direct network connection between two virtual networks |
| NSG | Network security group — layer 3/4 allow/deny rules on a subnet or NIC |
| Private endpoint | A private IP for a PaaS service, removing public exposure |
Troubleshooting
Section titled “Troubleshooting”| Symptom | Likely cause | Fix |
|---|---|---|
| Two VNets can’t be peered | Overlapping address spaces | Re-address one of the VNets, or plan non-overlapping ranges upfront |
| A compromised VM can reach unrelated workloads | Flat network with no segmentation | Introduce spokes/NSGs to isolate workloads |
| On-premises app has inconsistent latency to cloud resources | Traffic routed over public VPN instead of a private circuit | Evaluate a dedicated private connection for latency-sensitive traffic |
Check your understanding
Section titled “Check your understanding”- Why does a flat, unsegmented network increase the blast radius of a single compromised VM?
- What has to be planned before two VNets can be peered together?
Related pages
Section titled “Related pages”Part of Introduction to Cloud & Infrastructure Architecture. See also Landing Zone Design, Compute & Container Platforms, Business Continuity & Disaster Recovery for multi-region networking, and the Glossary.