Azure Networking from Zero to Enterprise — Part 1: Networking Basics

This is Part 1 of a multi-part series where we'll go from the absolute basics of Azure networking all the way to deploying a production-grade hub/spoke architecture with a firewall NVA, on-premises connectivity via ExpressRoute, and full DNS integration — all deployed with Bicep.

What you'll learn in this part:

• What a Virtual Network (VNet) is and how it differs from on-prem networking
• Subnets, address spaces, and CIDR planning
• Network Security Groups (NSGs) — the first line of defense
• Route Tables and User-Defined Routes (UDRs)
• Azure DNS basics — what resolves where and why it matters
• Service Endpoints vs Private Endpoints — when to use which

Why Azure Networking Matters

If you're a cloud engineer, solutions architect, or DevOps professional working with Azure, networking is the foundation everything else sits on. Get it wrong, and you'll spend months untangling routing issues, firewall misconfigurations, and DNS headaches. Get it right from the start, and everything else — compute, databases, security — just clicks into place.

The problem? Azure networking has a lot of moving pieces, and Microsoft's documentation, while comprehensive, is scattered across hundreds of pages. This series aims to give you the complete picture in one place, with real-world opinions and working code.

Virtual Networks (VNets)

A Virtual Network is Azure's fundamental networking construct. Think of it as your private, isolated network in the cloud — similar to a VLAN or a dedicated IP segment in your on-premises data center, but software-defined.

Key properties of a VNet:

• Region-scoped: A VNet lives in a single Azure region. You can't stretch a VNet across regions (you'd peer two VNets for that).
• Address space: You assign one or more CIDR blocks (e.g., 10.0.0.0/16). This is the total IP range available to the VNet.
• Isolation: VNets are completely isolated from each other by default. Two VNets with the same address space won't conflict — they simply can't talk to each other unless you explicitly connect them.
• Free: VNets themselves are free. You pay for what goes through them (gateways, peering traffic, etc.).

Creating a VNet — what you need to decide:

1. Address space size. Use RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. For enterprise, I recommend using a /16 per VNet (65,536 addresses) which gives you room to grow. Don't be stingy with IP space in the cloud — running out of addresses in a VNet is a pain to fix later.

2. Avoid overlaps. If you plan to connect to on-premises networks (via VPN or ExpressRoute), your Azure address space must NOT overlap with your on-prem ranges. This is the number one mistake I see in enterprise deployments. Map out all your address spaces across on-prem and cloud before you create a single VNet.

3. Region placement. Deploy the VNet in the same region as your workloads. Cross-region traffic costs money and adds latency.
   

Example:
On-prem range:    10.1.0.0/16
Azure Hub VNet:   10.10.0.0/16
Azure Spoke 1:    10.20.0.0/16
Azure Spoke 2:    10.30.0.0/16

Subnets

A subnet is a subdivision of your VNet's address space. Every resource you deploy (VMs, load balancers, private endpoints) goes into a subnet.

Subnet design principles:

• Plan ahead. You can resize subnets later, but only if they're empty. Moving resources between subnets is disruptive.
• Separate by function, not by team. Create subnets like snet-workload, snet-data, snet-privateendpoints, snet-appgw — not snet-teamalpha.
• Azure reserves 5 IPs per subnet. The first 4 and the last IP address in every subnet are reserved. A /28 gives you 16 addresses minus 5 = 11 usable. Keep this in mind for small subnets.
• Some services need dedicated subnets. Azure Application Gateway, Azure Firewall, VPN Gateway, Azure Bastion, and several others require their own dedicated subnet, often with specific naming (like AzureBastionSubnet or GatewaySubnet).

Common subnet layout for a hub VNet:

10.10.0.0/16 (Hub VNet)
├── GatewaySubnet:          10.10.0.0/26    (VPN/ExpressRoute Gateway)
├── AzureFirewallSubnet:    10.10.1.0/26    (Azure Firewall or NVA)
├── AzureBastionSubnet:     10.10.2.0/26    (Azure Bastion)
├── snet-management:        10.10.3.0/24    (Jump boxes, monitoring)
├── snet-shared-services:   10.10.4.0/24    (DNS forwarders, AD DCs)
└── snet-privateendpoints:  10.10.5.0/24    (Private Endpoints for shared services)

Common subnet layout for a spoke VNet:

10.20.0.0/16 (Spoke VNet - Workload A)
├── snet-app:               10.20.1.0/24    (Application tier)
├── snet-data:              10.20.2.0/24    (Database tier)
├── snet-privateendpoints:  10.20.3.0/24    (Private Endpoints)
└── snet-integration:       10.20.4.0/24    (App Service VNet integration)

Network Security Groups (NSGs)

NSGs are Azure's stateful firewall at the subnet (or NIC) level. They're your first line of defense and should be applied to every subnet (except for those that don't support them, like GatewaySubnet).

How NSGs work:

• An NSG contains inbound and outbound rules.
• Each rule has a priority (100–4096, lower = processed first), source, destination, port, protocol, and action (Allow or Deny).
• Azure has default rules you can't delete (allow VNet-to-VNet, allow outbound internet, deny all inbound from internet, etc.). You can override them with higher-priority rules.
• NSGs are stateful — if you allow inbound traffic on port 443, the response traffic is automatically allowed.

NSG best practices:

1. Apply NSGs at the subnet level, not individual NICs (unless you have a very specific reason). Subnet-level NSGs are easier to manage and audit.
2. Use Application Security Groups (ASGs) to group VMs by role instead of using IP addresses in rules. E.g., create an ASG called asg-webservers and reference it in rules — when you add a new web server, it inherits the rules automatically.
3. Don't rely solely on NSGs for east-west traffic control in enterprise. They're great for basic segmentation, but for advanced inspection (IDS/IPS, URL filtering, threat intelligence), you need a firewall NVA — which we'll cover in Part 4.
4. Enable NSG flow logs for troubleshooting and compliance. Send them to a Log Analytics workspace.

Example NSG rule:

Priority: 100
Name: Allow-HTTPS-Inbound
Source: Internet
Destination: asg-webservers
Port: 443
Protocol: TCP
Action: Allow

Route Tables and User-Defined Routes (UDRs)

By default, Azure routes traffic between subnets within a VNet automatically (system routes). It also routes to the internet via a default 0.0.0.0/0 route. But in enterprise architectures, you almost always need to override these defaults.

Why UDRs matter:

In a hub/spoke model (which we'll build in Part 3), you want all traffic to flow through a central firewall. Without UDRs, traffic between spoke VNets would go directly via peering — bypassing your firewall entirely. UDRs let you force traffic through a specific next hop.

Key concepts:

• Route Table: A collection of routes that you associate with one or more subnets.
• User-Defined Route (UDR): A custom route you create to override Azure's default routing.
• Next Hop Types:
  • VirtualAppliance — send traffic to a specific IP (your firewall NVA)
  • VirtualNetworkGateway — send to VPN/ExpressRoute gateway
  • VnetLocal — keep within the VNet
  • Internet — route to internet
  • None — drop the traffic (black hole)

Example: Force all internet-bound traffic through a firewall

Route Table: rt-spoke-workload
├── Route: to-internet
│   Prefix: 0.0.0.0/0
│   Next Hop: VirtualAppliance → 10.10.1.4 (firewall NVA IP)
├── Route: to-onprem
│   Prefix: 10.1.0.0/16
│   Next Hop: VirtualAppliance → 10.10.1.4
└── Route: to-hub-shared
    Prefix: 10.10.0.0/16
    Next Hop: VirtualAppliance → 10.10.1.4

Important: When you associate a route table with a subnet, it only affects traffic leaving that subnet. The firewall's own subnet should NOT have a UDR pointing to itself (routing loop). This is a common mistake.

Azure DNS Basics

DNS in Azure is one of those things that seems simple until you start dealing with hybrid environments. Let me break down the layers:

1. Azure-provided DNS (default)

Every VNet gets Azure's built-in DNS (168.63.129.16) for free. It resolves:

• Public DNS names (google.com, etc.)
• Azure internal names (vmname.internal.cloudapp.net)
• Private Endpoint DNS (if integrated correctly)

For simple deployments, this is fine. For enterprise with on-prem connectivity, you'll need more.

2. Azure DNS Public Zones

This is Azure's managed DNS for public domains you own. Instead of using GoDaddy/Cloudflare for DNS hosting, you can point your domain's nameservers to Azure DNS. Not directly relevant to networking architecture, but useful to know.

3. Azure DNS Private Zones

This is where it gets important for enterprise:

• A Private DNS Zone (e.g., privatelink.database.windows.net) allows you to create DNS records that are only resolvable within your VNets.
• When you create a Private Endpoint for an Azure service (like SQL Database), Azure can auto-create a DNS record in the linked Private Zone so mydb.database.windows.net resolves to the private IP.
• You link Private DNS Zones to VNets. Linked VNets can resolve records in the zone.

4. The Hybrid DNS Problem

When you connect on-premises to Azure:

• On-prem servers need to resolve Azure private DNS names (e.g., mydb.privatelink.database.windows.net)
• Azure VMs might need to resolve on-prem DNS names (e.g., dc01.corp.local)

Solution: Conditional Forwarders

On-prem DNS Server:
  "For *.privatelink.database.windows.net → forward to 10.10.5.10" (DNS forwarder VM in Azure)

Azure DNS Forwarder (10.10.5.10):
  "For *.corp.local → forward to 10.1.0.5" (on-prem DC)
  "Everything else → forward to 168.63.129.16" (Azure DNS)

We'll set this up properly in Part 5 with actual configuration.

Note: Azure now offers DNS Private Resolver as a managed service that replaces the need for DNS forwarder VMs. We'll cover both approaches.

Service Endpoints vs Private Endpoints

Both are designed to let your VNet resources access Azure PaaS services (Storage, SQL, Key Vault, etc.) privately. But they work very differently.

Service Endpoints

• Enables a direct route from your subnet to the Azure service over Microsoft's backbone network.
• The PaaS service still has a public IP, but traffic from your subnet takes an optimized private path.
• Free to use.
• Limitations: Only works from the VNet with the service endpoint enabled. Doesn't work from on-premises or peered VNets (without extra config). The PaaS service's public endpoint still exists.

Private Endpoints

• Creates a private IP address in your subnet that maps to a specific PaaS resource.
• Traffic goes entirely over your private network. The PaaS service effectively gets a NIC in your VNet.
• Works from anywhere that can reach the private IP — other VNets, on-prem via VPN/ExpressRoute.
• Costs money: ~$7.30/month per endpoint + $0.01/GB processed.
• Requires DNS configuration (Private DNS Zones) to resolve the service name to the private IP.

When to use which:

In this series, we'll primarily use Private Endpoints because we're building an enterprise architecture.

Summary

Here's what we covered:

What's Next

In Part 2, we'll cover Bicep and Azure Verified Modules (AVM) — the infrastructure-as-code language we'll use to deploy everything in this series. You'll learn why Bicep over Terraform (for Azure-native work), how AVM modules save you from reinventing the wheel, and we'll deploy our first VNet with subnets and NSGs in code.

If you want to follow along with the code, the companion repo will be linked here once Part 2 drops.

Resources

If you're studying for the AZ-700 (Azure Network Engineer Associate) certification, this series covers most of the exam objectives. Here's the official study path:

• 📘 Microsoft Learn: AZ-700 Study Guide
• 🛠️ diagrams.net — Free tool for drawing Azure network diagrams (I use it for all my architecture work)

About the Author

I'm a cloud network engineer specializing in Azure enterprise architectures — hub/spoke, ExpressRoute, NVAs, and infrastructure-as-code with Bicep. If you're building something similar in your org and want a second pair of eyes, feel free to reach out.

Found this useful? Follow this blog to get notified when Part 2 drops — we're building all of this in Bicep. Drop your questions in the comments, I read every one.