Blog / How to Design Azure Network Topologies
26 August 2026 Azure

How to Design Azure Network Topologies

Designing a well-structured Azure network topology is the cornerstone of any successful cloud deployment. Your virtual network is the fabric that ties together compute, storage, databases, and external services — and getting it right from the start saves significant pain as your architecture scales.

This guide covers the key Azure networking concepts and patterns, from Virtual Networks and subnets through to hub-and-spoke topologies, Azure Virtual WAN, ExpressRoute, and Azure Landing Zones.

1. Overview: Azure Networking Building Blocks

Azure networking is composed of several interconnected services. Before designing a topology, you should understand the core building blocks:

  • Virtual Network (VNet) — your isolated private network in Azure
  • Subnets — subdivisions of a VNet, used to segment workloads
  • Network Security Groups (NSG) — stateful traffic filtering rules
  • User-Defined Routes (UDR) — override Azure default routing
  • VNet Peering — connect two VNets with low-latency, high-bandwidth links
  • Azure Load Balancer / Application Gateway — L4 and L7 load balancing
  • Azure Firewall — managed, stateful firewall for centralised traffic inspection
  • Virtual Network Gateway — VPN and ExpressRoute termination
  • Azure Virtual WAN — managed hub-and-spoke networking at scale
  • Private Endpoints — bring PaaS services onto your VNet

Most Azure network topologies are built by combining these primitives into patterns that balance security, performance, and operational simplicity.

2. VNet Fundamentals

An Azure Virtual Network (VNet) is a logically isolated network within a single Azure region. VNets are scoped to a subscription and defined by one or more address spaces (CIDR blocks).

Key design decisions:

  • Address space: Choose a range large enough for growth, typically 10.0.0.0/8 subdivided into /16 blocks per VNet (e.g. 10.1.0.0/16 for production, 10.2.0.0/16 for staging).
  • Non-overlapping CIDRs: Peered VNets and on-premises networks must not share overlapping address ranges. Plan a centrally managed IP address management (IPAM) strategy early.
  • One VNet or many: A common approach is one VNet per environment or per application team, connected via a central hub VNet using the hub-and-spoke pattern.
  • Region: VNets are regional. For multi-region deployments, create a VNet per region and use Global VNet Peering or Virtual WAN to connect them.

3. Subnet Design

Subnets are subdivisions of a VNet. Unlike AWS, Azure subnets are not tied to specific availability zones — zone redundancy is achieved at the resource level using Availability Zones.

A standard subnet layout for a workload VNet:

  • Gateway subnet — reserved for the Virtual Network Gateway (VPN/ExpressRoute). Must be named exactly GatewaySubnet. No NSGs or UDRs here.
  • AzureFirewallSubnet — if using Azure Firewall in the hub, must be named exactly AzureFirewallSubnet with a minimum /26 block.
  • Public / DMZ subnet — hosts Application Gateway, Azure Front Door origins, or jump servers.
  • Application subnet(s) — hosts compute: VMs, AKS nodes, App Service Environments, or other PaaS delegated subnets.
  • Data subnet — isolated subnet for databases, Azure SQL Managed Instance, or other data tier resources.

Reserve larger subnets than you think you need — Azure reserves the first four and last IP in each subnet, and some services (like AKS) consume IPs rapidly.

4. Network Security Groups and User-Defined Routes

Network Security Groups (NSGs) are stateful packet filters that control inbound and outbound traffic at the subnet or NIC level. They work on allow/deny rules with priority numbers — lower numbers are evaluated first.

NSG best practices:

  • Apply NSGs at the subnet level for broad policies and NIC level for exceptions
  • Use Service Tags (e.g. Internet, AzureLoadBalancer, VirtualNetwork) instead of hardcoded CIDRs where possible
  • Use Application Security Groups (ASGs) to group resources logically and write rules between ASGs rather than IPs
  • Always deny all inbound traffic by default and allow only what is needed
  • Enable NSG Flow Logs for diagnostics

User-Defined Routes (UDRs) override Azure's default system routes. Common uses:

  • Force all internet-bound traffic through Azure Firewall or an NVA: next hop = firewall private IP
  • Force spoke VNet traffic through the hub before going to other spokes
  • Control traffic between subnets within the same VNet

5. Internet Access

Azure provides several ways to control outbound and inbound internet connectivity:

  • Public IP addresses — attach to VMs, Load Balancers, or Application Gateway for inbound access. Direct public IP on a VM is generally discouraged in production.
  • NAT Gateway — provides managed, scalable outbound connectivity for subnets. Use instead of per-VM public IPs for private workloads needing internet egress. Supports up to 64,512 SNAT ports per public IP.
  • Azure Firewall (with SNAT) — centralise all outbound internet traffic through a managed firewall, enabling logging and FQDN-based filtering. Route tables force traffic from all subnets to the firewall.
  • Azure Front Door / CDN — for inbound traffic to global web applications, use Front Door as the global entry point, with Application Gateway behind it for WAF and L7 routing.

6. Hub-and-Spoke Topology

The hub-and-spoke (or star) topology is the most widely recommended pattern for enterprise Azure networking. It provides centralised shared services and controlled connectivity between workloads.

Hub VNet contains shared infrastructure:

  • Azure Firewall or Network Virtual Appliance (NVA)
  • Virtual Network Gateway (VPN or ExpressRoute)
  • Bastion Host (for secure VM access)
  • DNS resolvers
  • Shared monitoring and management tools

Spoke VNets contain workloads:

  • One spoke per application, team, or environment
  • Peered to the hub with Allow Gateway Transit enabled
  • UDRs force spoke traffic through the hub firewall
  • Spokes do not peer directly to each other — all traffic goes through the hub

This topology provides clear security boundaries, centralised inspection, and simple management. The trade-off is that the hub is a critical dependency — make it highly available using zone-redundant resources.

7. Azure Virtual WAN

Azure Virtual WAN (vWAN) is a managed networking service that provides a fully automated hub-and-spoke topology at scale. Microsoft manages the underlying routing infrastructure.

Virtual WAN advantages over manual hub-and-spoke:

  • Automatic routing between all spokes and branches — no manual UDRs needed
  • Built-in any-to-any connectivity (spoke to spoke, branch to spoke)
  • Integrated Site-to-Site VPN, Point-to-Site VPN, and ExpressRoute
  • Supports Azure Firewall in the hub (Secured Virtual Hub)
  • Better suited for large-scale, multi-region deployments

Choose Virtual WAN if you have many branch offices, many VNets, or need Microsoft to manage hub routing complexity. For simpler architectures, a manually managed hub-and-spoke is lighter and more flexible.

8. Hybrid Connectivity

Azure supports two primary hybrid connectivity options:

  • Azure VPN Gateway — encrypted IPSec/IKE tunnels over the public internet. Supports route-based and policy-based VPNs. Zone-redundant SKUs provide 99.99% SLA. Use for branch offices, lower-bandwidth workloads, or as a failover for ExpressRoute.
  • Azure ExpressRoute — a dedicated private connection from your on-premises network to Azure via a connectivity provider. Offers consistent latency, up to 100 Gbps, and does not traverse the public internet. ExpressRoute Global Reach connects on-premises sites through the Azure backbone.

Best practice for production:

  • Use ExpressRoute as primary and VPN Gateway as failover
  • Terminate both in the hub VNet or vWAN hub
  • Use ExpressRoute circuits with redundant connections from two different provider edge devices
  • Enable BFD (Bidirectional Forwarding Detection) for fast failover

9. Azure Firewall

Azure Firewall is a managed, cloud-native stateful firewall service. Deploy it in the hub to inspect all traffic between spokes, and between spokes and the internet or on-premises.

Key capabilities:

  • FQDN-based application rules (e.g. allow traffic to *.microsoft.com)
  • Network rules for IP/port/protocol filtering
  • NAT rules for inbound traffic (DNAT)
  • Threat intelligence-based filtering (blocks known malicious IPs)
  • Integration with Azure Monitor, Sentinel, and Log Analytics
  • Premium SKU adds TLS inspection, IDPS, and URL filtering

Use Firewall Policy to manage rules centrally across multiple Azure Firewall instances in different regions, enabling consistent security posture globally.

10. Private Endpoints and Private Link

By default, Azure PaaS services (Storage, SQL Database, Key Vault, etc.) are accessed over public endpoints. Private Endpoints bring these services into your VNet with a private IP address.

Benefits:

  • Traffic between your VNet and the PaaS service never leaves the Microsoft network
  • Eliminates exposure to the public internet
  • Works with NSGs and UDRs for additional control
  • Enables access from on-premises networks connected via ExpressRoute or VPN

After creating a Private Endpoint, configure Private DNS Zones (e.g. privatelink.blob.core.windows.net) to ensure name resolution returns the private IP rather than the public endpoint. Link these DNS zones to your hub VNet and configure conditional DNS forwarding from on-premises if needed.

11. Azure Landing Zones

For enterprise deployments, Microsoft recommends the Azure Landing Zone framework — a set of opinionated architectural patterns and accelerators that establish a well-governed, scalable foundation for workloads.

The network topology in an Azure Landing Zone typically includes:

  • A Platform Management Group containing Connectivity, Identity, and Management subscriptions
  • A dedicated Connectivity subscription hosting the hub VNet (or vWAN hub), Azure Firewall, ExpressRoute/VPN gateways, and DNS infrastructure
  • Landing Zone subscriptions (spokes) for individual application teams, peered to the connectivity hub
  • Azure Policy enforcing network guardrails — disabling public IPs, requiring NSGs, enforcing Private Endpoints

The Azure Landing Zone architecture can be deployed using the Azure Landing Zone Accelerator (Bicep or Terraform) to automate the full setup. This is the recommended starting point for any organisation building on Azure at scale.

12. Diagramming Your Azure Network

A well-drawn network diagram communicates your Azure topology at a glance and is essential for team alignment and operational documentation.

What to include in an Azure network diagram:

  • Azure region and subscription boundaries
  • VNet address spaces and subnet CIDR blocks
  • Hub VNet with shared services (Firewall, Gateway, Bastion, DNS)
  • Spoke VNets with workload groupings
  • VNet peering connections and their direction
  • NSG assignments per subnet
  • UDRs and next-hop destinations
  • ExpressRoute / VPN Gateway connections to on-premises
  • Private Endpoints and associated Private DNS Zones
  • Internet egress path (NAT Gateway or Azure Firewall)

Use official Azure icons (available in Diagram App's icon library under the Azure category) to produce diagrams that match Microsoft's documentation style and are immediately familiar to Azure engineers.

Conclusion

A solid Azure network topology is the foundation of a secure, scalable, and well-governed cloud deployment. Starting with a sound VNet and subnet design, adopting hub-and-spoke or Virtual WAN for connectivity, and using Azure Firewall and Private Endpoints to control traffic flow gives you an architecture that can grow with your organisation.

The Azure Landing Zone framework provides a battle-tested blueprint for enterprise deployments, bringing together network design, governance, and automation into a consistent structure. For greenfield deployments, starting from the Landing Zone is almost always the right move.

Ready to diagram your Azure network? Open Diagram App — free, in your browser, with Azure icons built in.