Virtual Network Design and Address Planning

Lesson: Virtual Network Design and Address Planning

Introduction

In cloud computing, a Virtual Network (VNet) is the fundamental building block for your private network in the cloud. It enables Azure resources—such as Virtual Machines (VMs), App Services, and Databases—to securely communicate with each other, the internet, and on-premises networks.

Why is network design critical? Poorly planned address spaces often lead to "IP exhaustion," routing conflicts, and the inability to scale. Once a VNet is created, changing its address space can be disruptive, requiring you to delete and recreate resources. Effective address planning is the foundation of a scalable, secure, and manageable cloud infrastructure.

The Fundamentals of Address Planning

When designing a VNet, you must define an Address Space using Classless Inter-Domain Routing (CIDR) notation.

1. Understanding CIDR

CIDR notation (e.g., 10.0.0.0/16) represents the network prefix and the number of bits used for the network portion.

• A /16 network provides 65,536 addresses.
• A /24 network provides 256 addresses.
• A /27 network provides 32 addresses.

2. Subnetting Strategy

Subnets allow you to segment your VNet into smaller network slices. This is essential for:

• Security: Applying Network Security Groups (NSGs) to isolate tiers (e.g., separating Web, App, and Database tiers).
• Traffic Control: Routing traffic through a centralized firewall or virtual appliance.

Example Scenario: You have a total address space of 10.0.0.0/16. You can divide this into functional subnets:

• Web Tier: 10.0.1.0/24 (256 addresses)
• App Tier: 10.0.2.0/24 (256 addresses)
• Database Tier: 10.0.3.0/24 (256 addresses)
• Gateway Subnet: 10.0.255.0/27 (Required for VPN/ExpressRoute)

Practical Implementation (Infrastructure as Code)

Using Terraform is the industry standard for deploying repeatable network infrastructure. Below is an example of defining a VNet and subnets.

# Define the Virtual Network
resource "azurerm_virtual_network" "main" {
  name                = "vnet-production-001"
  address_space       = ["10.0.0.0/16"]
  location            = "East US"
  resource_group_name = azurerm_resource_group.rg.name
}

# Define the Web Subnet
resource "azurerm_subnet" "web" {
  name                 = "snet-web"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.1.0/24"]
}

# Define the Database Subnet
resource "azurerm_subnet" "db" {
  name                 = "snet-db"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.3.0/24"]
}

Note: Azure reserves 5 IP addresses in every subnet: the network address, the default gateway, three addresses for Azure services, and the broadcast address. Always plan for this overhead.

Best Practices

1. Avoid Address Overlap

If you plan to connect your VNet to your on-premises network (via VPN or ExpressRoute), ensure your cloud address space does not overlap with your corporate network ranges. If they overlap, traffic will not be able to route correctly, leading to connectivity outages.

2. Plan for Growth (The "Room to Breathe" Rule)

Never use the entire address space for your initial subnets. Leave gaps in your address allocation to accommodate future subnets or expanded requirements for existing tiers.

3. Use Hub-and-Spoke Topology

For enterprise environments, implement a Hub-and-Spoke model:

• Hub: Contains shared services (Firewalls, VPN Gateways, DNS).
• Spokes: Contain individual application workloads.
• Benefit: Centralizes management and reduces the complexity of managing peer-to-peer connectivity.

4. Zero Trust Segmentation

Don't put all your resources in one giant subnet. Use smaller subnets to enforce "Micro-segmentation." If a web server is compromised, a properly configured subnet boundary prevents lateral movement to the database tier.

Common Pitfalls

• Underestimating Subnet Size: Creating a /29 subnet for a large web cluster will lead to IP exhaustion within days. Always calculate the maximum possible number of instances and add a 20-30% buffer.
• Hardcoding IPs: Never assign static private IPs to individual VMs unless absolutely necessary. Use Azure internal DNS (Service Discovery) and Load Balancers to manage traffic.
• Ignoring Service Endpoints: If you need to connect to Azure PaaS services (like Azure SQL or Storage), use Service Endpoints or Private Links instead of routing traffic over the public internet.

⚠️ Critical Warning: The Gateway Subnet

Azure requires a specific subnet named GatewaySubnet if you intend to use Virtual Network Gateways. This subnet cannot contain other resources and should generally be sized as a /27 or /28.

Key Takeaways

1. Plan Early: Address space planning is difficult to change after deployment. Map out your IP requirements before writing a single line of code.
2. Use CIDR Wisely: Understand how network bits affect address counts. Always reserve room for future scaling.
3. Prioritize Security: Use subnets to group resources logically and apply Network Security Groups (NSGs) to enforce traffic flow policies.
4. Adopt Hub-and-Spoke: For multi-application environments, this architecture provides the best balance of security, scalability, and centralized management.
5. Leverage IaC: Use tools like Terraform or Bicep to ensure your network topology is version-controlled, repeatable, and documented.