Azure Networking - Six steps to secure network design

Based on my experience, these are the 6 core steps that ensure your Azure network environment is not only secure today but scalable for the long term.

Read more about my essential blueprint for building enterprise-grade Azure architectures.

1. Design the VNet and plan for CIDR

Theory: Virtual Network (VNet) address space planning is the crucial first step. Proper planning ensures you have sufficient non-overlapping IP space for current and future resources, regions, and VPN connections. Using large, well-defined CIDR blocks (e.g., /16 for an entire region or /24 for a standard Subnet) simplifies routing and avoids complex renumbering later.

Actions:

• Use RFC 1918 space and allocate large blocks (e.g., /16 or /17) per region for scalability.
• Ensure VNet CIDR blocks do not overlap with any on-premises networks or other peered Azure VNets.
• Immediately split the VNet’s CIDR block into smaller, dedicated subnets (e.g., /24, /26) for distinct resource types (Firewall, App Gateway, Web, App, DB).
• Always reserve a large unused block for future expansion, new regions, or unforeseen peering requirements.
• Use standardized, recommended subnet sizes for Azure services (e.g., Azure Firewall requires a /26, Azure Gateway Subnets need at least a /27).

2. Use the Hub‑and‑spoke topology

Theory: The Hub-and-Spoke network topology centralizes shared security and management services in a Hub Virtual Network (VNet). This Hub VNet connects via VNet Peering to multiple Spoke VNets, which host isolated application workloads. This structure is essential for enforcing central controls and providing a single, inspected egress point for all traffic.

Actions:

• Use a hub VNet for shared services (Azure Firewall, NAT Gateway, Private DNS, etc.) and spokes for application workloads.
• Place Azure Firewall and NAT Gateway in dedicated subnets within the hub VNet and peer spokes to the hub.
• Deploy regional hubs for multi‑region workloads (hub and spokes in the same region) to avoid costly cross‑region hairpins.
• Keep shared logging and monitoring (Network Watcher, Sentinel) attached to the hub for centralized visibility.

3. Specify explicit routing with Route Tables and UDRs

Theory: While Azure provides automatic system routes, enterprise security often requires overriding this default behavior. User Defined Routes (UDRs) allow you to create custom Route Tables associated with subnets. This mechanism is used to force traffic to “hop” through a virtual appliance (like a firewall) for mandatory inspection, ensuring spokes cannot accidentally bypass security perimeters. UDRs do not apply to traffic within the same subnet; they only affect inter-subnet or inter-VNet flows.

Actions:

• Associate Route Tables with subnets and use UDRs to override system routes and force traffic to virtual appliances (next hop = Virtual Appliance).
• Add a UDR on each spoke subnet with the firewall’s private IP as the virtual appliance next hop.
• Automate Route Table deployment with infrastructure as code.
• Use an Azure Policy to audit that required UDRs are present and point to approved appliances.

4. Egress control and NAT Gateway design

Theory: Resources accessing the internet require Source Network Address Translation (SNAT). Although Firewalls provide SNAT, they have limited port capacity (2496 SNAT ports) per public IP, risking connection failures (SNAT exhaustion) under high load. Azure NAT Gateway is a managed service designed to mitigate this risk by providing massive, highly scalable outbound port capacity. NAT Gateway provides 64512 SNAT ports per public IP and supports up to 16 public IPs.

Actions:

• Centralize outbound traffic through Azure Firewall and/or NAT Gateway so egress is predictable and logged.
• Attach a NAT Gateway to the firewall subnet (or to spokes) so outbound flows use the NAT’s static public IPs.
• Use multiple Public IPs (PIPs) to increase SNAT capacity and avoid exhaustion.
• Combine Azure Firewall + NAT Gateway by configuring the Azure Firewall subnet to use the NAT Gateway for its outbound public IP address.

5. Apply subnet boundary controls with NSGs

Theory: The Network Security Group (NSG) is a lightweight, stateful, network-level access control within Azure. Applied at the subnet level, it uses security rules to control inbound and outbound network traffic (east‑west flow). NSGs are critical for achieving micro‑segmentation and enforcing simple access intent within the application VNet itself.

Actions:

• Apply NSGs at the subnet boundary for intent‑based filtering.
• Use NSGs to express minimal allow/deny rules (e.g., allow web → app; deny all else).
• Delegate complex deep-packet inspection to the hub firewall.
• Remember, NSGs are evaluated in priority order; lower numbers have higher precedence.
• Enforce NSG standards with an Azure Policy to audit presence, naming, and rule baselines.

6. Private connectivity and Private DNS

Theory: Accessing PaaS services (like Storage or SQL) via public endpoints introduces security risks. Azure Private Link provides the solution by projecting these services into your VNet via a Private Endpoint. To ensure seamless service resolution, Private DNS Zones are necessary to map the service’s public hostname to its new internal private IP address.

Actions:

• Prefer Private Endpoints / Private Link for sensitive services and use Private DNS zones for internal resolution.
• Make Private Endpoints the default for critical services (Key Vault, Storage, SQL)
• Explicitly disable public network access where supported (manual disabling required for some services).
• Link Private DNS zones to VNets so clients resolve service names to private IPs automatically.
• Create Azure Policies that require Private Endpoints, block ad‑hoc public IPs, and audit public network access settings.
• Version the Private Endpoints with infrastructure as code to reduce configuration drift.