CH03-02: Virtual Networks, Subnets, and IP Planning

Goal

The previous section introduced Azure networking as the design of intentional communication paths. This section explains the basic private placement model those paths depend on: virtual networks, subnets, and IP address planning.

The goal is to help you understand where Azure workloads live from a networking point of view and why address planning matters before an environment grows.

You do not need to become a subnetting expert to understand this section. You need the architecture instinct: network placement choices become harder to change once applications, routes, private endpoints, and hybrid connections depend on them.

The Short Version

A virtual network is a private network space in Azure.

A subnet is a smaller area inside a virtual network where resources can be placed and controlled.

The simplest mental model is:

Virtual Network
  |
  +-- Subnet
  +-- Subnet
  +-- Subnet

A more practical example looks like this:

Virtual Network: prod-customer-api-vnet 10.20.0.0/16
  |
  +-- Subnet: web        10.20.1.0/24
  +-- Subnet: app        10.20.2.0/24
  +-- Subnet: endpoints  10.20.10.0/24

The names and numbers are examples. The important idea is that a virtual network gives the workload a private network boundary, while subnets create smaller placement areas inside that boundary.

What a Virtual Network Does

An Azure virtual network, often shortened to VNet, gives resources a private network space inside Azure.

A virtual network helps answer questions such as:

• Which private IP address range does this workload use?

• Which resources can be placed together?

• Which other networks can this workload connect to?

• Which subnets should exist for application tiers or platform requirements?

• How will this workload reach shared services, other Azure networks, or on-premises systems?

A VNet is not the same as a subscription or resource group. A subscription is a major boundary for billing, access, policy, quotas, and ownership. A resource group is a management container for resources that often share lifecycle or ownership. A VNet is a network boundary. These boundaries often align, but they do different jobs.

For example, a production workload may live in its own production subscription, have resource groups for application and data resources, and use a VNet for private network placement. The subscription helps govern and pay for the workload. The resource groups help deploy and operate related resources. The VNet defines the private network space used by the workload.

What Subnets Do

A subnet divides a VNet into smaller address ranges.

Subnets are useful because not every resource inside a VNet should be treated the same way. Different parts of a workload may need different routing, traffic filtering, delegation, or operational ownership.

Common subnet purposes include:

Do not worry if gateway, firewall, private endpoint, or delegation details still feel new. They appear later in the chapter. For now, notice the pattern: subnets are places where network responsibilities can be separated.

Address Spaces and CIDR Ranges

Every VNet uses one or more private IP address ranges. You may see ranges written in CIDR notation, such as 10.20.0.0/16 or 10.20.1.0/24.

At this stage, you do not need to calculate every address by hand. You need to understand what the range represents:

• A VNet address space is the larger private range available to the VNet.

• A subnet range is a smaller slice of that VNet address space.

• Resources placed into a subnet receive private IP addresses from that subnet.

• Networks that may connect later should avoid overlapping address spaces.

For example:

VNet address space: 10.20.0.0/16
  |
  +-- Web subnet:       10.20.1.0/24
  +-- App subnet:       10.20.2.0/24
  +-- Endpoints subnet: 10.20.10.0/24

This gives the workload room to place resources into different areas while keeping them inside one private network boundary.

Why Overlap Matters

Address overlap is one of the most common early network planning problems.

Imagine a company has an on-premises data center that already uses this range:

On-premises data center: 10.30.0.0/16

Now an Azure team creates a VNet with the same range:

Azure workload VNet:     10.30.0.0/16

Both networks now claim the same address space. If the company later wants the Azure workload to connect to the data center, routing becomes ambiguous. When a system tries to reach 10.30.5.20, does that address live in Azure or on-premises?

This is why enterprise Azure networking usually needs an IP address plan before many teams create VNets. The plan does not need to be perfect forever, but it should avoid obvious overlaps with existing data centers, branch networks, other cloud environments, and planned Azure VNets.

The painful part is timing. Address planning feels like a detail at the start. Later, after applications, private endpoints, peerings, gateways, and firewall rules depend on those ranges, changing them can become disruptive.

Regional Scope

Azure VNets are regional. A VNet exists in one Azure region.

That matters for multi-region design. If a workload runs in two regions, it usually needs network design in both regions. For example, a production workload may have one VNet in East US and another VNet in West Europe. Those VNets may need peering, routing, private endpoints, DNS, and security rules that match the resilience model.

Do not turn this into a memorization point. The architecture question is:

If the workload spans regions, how will the network span regions too?

Regional networking affects latency, failover, data access, inspection, cost, and operational troubleshooting.

How to Think About VNet Boundaries

A common question is whether to put many workloads into one VNet or give workloads separate VNets.

There is no universal answer. Use the boundary that matches ownership, risk, connectivity, and operations.

A shared VNet may be reasonable when:

• Workloads are tightly related.

• One team owns the whole environment.

• The traffic model is simple.

• Segmentation can be handled cleanly with subnets, NSGs, and routing.

• The environment is small enough to operate safely.

Separate VNets may be better when:

• Workloads have different owners.

• Production and non-production need stronger separation.

• Applications have different risk or compliance profiles.

• Different teams need different network policies.

• A hub-spoke model is being used.

• The organization wants clearer blast-radius and routing boundaries.

Avoid both extremes. One giant VNet can become hard to govern. Too many VNets can become hard to route, secure, monitor, and troubleshoot. The design should match the operating model.

Example: A Migration Addressing Mistake

Imagine a payments team is moving an internal application to Azure. To move quickly, the team creates this VNet:

payments-prod-vnet: 10.50.0.0/16

The application deploys successfully. The web and app tiers can communicate. Testing looks good.

Then the team discovers that a data center network already uses 10.50.0.0/16. The payment application still needs to call an on-premises fraud system during migration. Now the network team cannot create clean routing between Azure and the data center without dealing with overlapping address spaces.

The application itself may be fine, but the network plan blocks the migration path.

A better approach would have been:

1. Check existing enterprise address ranges.

2. Reserve Azure ranges that do not overlap with on-premises or other clouds.

3. Allocate ranges by region, environment, business unit, or landing zone pattern.

4. Create VNets and subnets from that plan.

5. Leave room for future subnets, private endpoints, gateways, or additional workloads.

This does not remove every future network challenge, but it avoids one of the most avoidable ones.

Common Early Mistakes

• Choosing address ranges casually. Overlap may not hurt on day one, but it can block peering, hybrid routing, and migration later.

• Treating subnets as folders. Subnets are network placement areas where routing, NSGs, delegation, and service requirements may apply.

• Putting unrelated workloads in one VNet because it is convenient. Convenience can turn into unclear ownership, broad access, and difficult troubleshooting.

• Creating too many small VNets without an operating reason. Every network boundary may need routing, monitoring, security review, DNS, and ownership.

• Forgetting service-specific subnet requirements. Some Azure services require dedicated, delegated, or specially named subnets.

• Ignoring future hybrid connectivity. A VNet that never connects anywhere has simpler requirements. Most enterprise VNets eventually connect to something.

If Someone Asks You

If someone asks, "What is an Azure virtual network, and why do subnets matter?" a clear answer is:

An Azure virtual network is a private network space where Azure resources can communicate using private IP addresses. Subnets divide that network into smaller areas for workload placement, routing, security rules, private endpoints, gateways, or service-specific needs. Good VNet and subnet design helps separate responsibilities, avoid address overlap, support hybrid connectivity, and make the network easier to operate.

This answer connects the terms to architecture instead of only defining them.

What You Should Remember

Virtual networks and subnets are the placement foundation for Azure networking.

The most important idea is this:

Network placement decisions become harder to change after workloads depend on them.

Plan address spaces before connecting environments. Use subnets to express real placement and control needs. Choose VNet boundaries that match ownership, risk, routing, and operations.

Questions to Check Your Understanding

1. What does a virtual network provide in Azure?

2. Why are subnets more than folders inside a VNet?

3. Why does IP address overlap matter during hybrid migration?

4. How can subnet design support segmentation?

5. Why should VNet design happen before private connectivity is built?