Designing Azure Virtual Networks and Subnets

Overview and What You Will Learn

In this lab, you will create a VNet with a properly sized address space, divide it into subnets for different application tiers, and understand why the initial CIDR planning decision is hard to undo once resources are already deployed inside it.

Why This Matters in Production

A team at a startup creates a VNet with a small address range because "we only have a few VMs right now," and eighteen months later, once the application has grown and needs more subnets than the original range can accommodate, the only real fix is building an entirely new, larger VNet and migrating everything into it. Planning the address space generously from day one avoids this exact rebuild.

Core Principles

A VNet is your own isolated, private network inside Azure, defined by a CIDR address range and then divided into Subnets - smaller ranges within that overall space, typically one per application tier.

Each subnet acts as its own boundary for applying Network Security Group rules and routing decisions - separating tiers into different subnets is what makes it possible to apply different security rules to your web tier versus your database tier.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group:

2. Create a VNet with a generously sized address space and a first subnet:

3. Add two more subnets for the application and data tiers:

4. List all subnets to confirm the address space was divided as expected:

5. Confirm the total available address space remaining, to see how much room is left for future subnets:

Note

A /16 VNet with three /24 subnets carved out of it still has room for well over a hundred more /24 subnets - this headroom is exactly why starting with a /16 rather than a smaller range matters, even if only a few subnets are needed today.

6. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Sizing a VNet's address space based only on current, immediately known requirements. A VNet's CIDR block cannot be expanded after creation - if the workload later grows beyond the original range, the only fix is building an entirely new, larger VNet and migrating every resource into it.

Tip

Always start VNets at /16 and divide into small subnets like /24, rather than starting small and hoping growth stays within a tight range. The unused address space in an oversized VNet costs nothing - it's simply reserved for whenever it's actually needed.

• Separate subnets by tier, not by convenience. Web, application, and data tiers in separate subnets makes it possible to apply different, appropriately scoped Network Security Group rules to each - collapsing everything into one subnet removes that isolation.
• Azure reserves 5 IP addresses per subnet for its own internal use (network address, VPC router, DNS, a reserved address, and broadcast) - plan subnet sizes accounting for this, not just the raw address count.

Quick Reference & Troubleshooting Commands