Subnet Design and Configuration

Azure Virtual Networks: Mastering Subnet Design and Configuration

Introduction: Why Subnetting Matters in the Cloud

When you move infrastructure to the cloud, it is easy to treat a Virtual Network (VNet) as a single, flat bucket where all your resources live. However, as your environment grows from a single virtual machine to a complex architecture involving databases, load balancers, and application tiers, this "flat" approach becomes a significant liability. Subnetting is the foundational practice of partitioning your VNet into smaller, manageable segments. By breaking your network into subnets, you gain granular control over traffic flow, security boundaries, and resource organization.

Effective subnet design is not just about IP address management; it is a critical security and performance strategy. Without proper subnetting, you cannot implement effective Network Security Groups (NSGs) to isolate a database from the public internet or ensure that your internal services remain unreachable from unauthorized segments. Furthermore, subnetting helps in managing broadcast domains and routing tables, which are essential for maintaining a high-performance, predictable network environment. In this lesson, we will explore the mechanics of Azure subnets, how to design them for scale, and the best practices that keep your cloud infrastructure secure and performant.

Understanding Azure Virtual Network Fundamentals

Before diving into subnet configuration, we must establish a clear understanding of the relationship between VNets and subnets. An Azure Virtual Network is the fundamental building block for your private network in the cloud. It allows Azure resources, such as Virtual Machines (VMs), to securely communicate with each other, the internet, and your on-premises networks.

A subnet is a range of IP addresses in the virtual network. You can divide a VNet into multiple subnets for organization and security. When you assign an IP address to a resource within a subnet, it must fall within the range defined by that subnet's Classless Inter-Domain Routing (CIDR) block. Unlike on-premises networking, where you might have to deal with physical hardware limitations, Azure software-defined networking handles the underlying routing automatically. However, you are still responsible for the logical design and the enforcement of traffic rules.

Callout: The "Subnet" Distinction It is important to remember that in Azure, a subnet is not just a logical grouping; it is a boundary for security and routing. While subnets within the same VNet can communicate by default, you can override this behavior using Network Security Groups (NSGs) and User-Defined Routes (UDRs). This makes the subnet the primary unit of control for your network traffic architecture.

IP Addressing and CIDR Blocks

Azure VNets use private IP address spaces defined by RFC 1918. When designing your subnets, you must select a CIDR block that does not overlap with your on-premises networks or other peered VNets. A common mistake is choosing a range that is too small, leading to IP exhaustion as the environment scales. Always plan for future growth by selecting a larger base address space for the VNet and then carving out subnets that leave room for additional resources.

Designing Your Subnet Architecture

Designing a subnet architecture requires a balance between security and manageability. If you create too few subnets, you lose the ability to apply fine-grained security policies. If you create too many, you increase the complexity of managing routing tables and network monitoring.

The Tiered Architecture Model

A common and recommended approach is the "Tiered Architecture." In this model, you group resources based on their function and their exposure to the outside world. A typical three-tier application might look like this:

• Web Tier Subnet: Contains load balancers or web servers that face the public internet. This subnet is the most exposed and requires strict ingress rules.
• Application Tier Subnet: Contains the logic layer of your application. This subnet should only accept traffic from the Web Tier and should not have a direct route to the internet.
• Data Tier Subnet: Contains databases or storage clusters. This is the most protected area, often restricted to accepting traffic only from the Application Tier.

By isolating these tiers into separate subnets, you can apply distinct NSGs to each. For example, the Data Tier subnet can have an NSG that explicitly denies all traffic except for queries originating from the Application Tier's IP range.

Reserved IP Addresses

When you create a subnet in Azure, it is important to know that Azure reserves five IP addresses in every subnet for internal use. These are:

1. The network address (x.x.x.0)
2. The gateway address (x.x.x.1)
3. The first three reserved addresses (x.x.x.2, x.x.x.3, x.x.x.4)

If you create a subnet with a /29 CIDR block, which provides 8 addresses, you only have 3 usable addresses for your resources after the Azure overhead is accounted for. Always calculate your requirements with these reserved addresses in mind.

Implementing Subnets: Step-by-Step

Creating and configuring subnets can be done via the Azure Portal, Azure CLI, or Terraform. We will focus on the Azure CLI approach, as it provides a clear view of the configuration parameters.

Step 1: Create the Virtual Network

Before creating a subnet, you need a VNet. Use the following command to create a VNet with a base address space:

az network vnet create \
  --name MyVNet \
  --resource-group MyResourceGroup \
  --location eastus \
  --address-prefixes 10.0.0.0/16

Step 2: Create Subnets

Once the VNet exists, you can add subnets to it. Let's create a Web Tier and a Data Tier subnet:

# Create Web Tier Subnet
az network vnet subnet create \
  --name WebSubnet \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --address-prefixes 10.0.1.0/24

# Create Data Tier Subnet
az network vnet subnet create \
  --name DataSubnet \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --address-prefixes 10.0.2.0/24

Step 3: Configuring Network Security Groups

After creating the subnets, you should associate an NSG with each one to enforce the security boundary.

# Create an NSG for the Data Tier
az network nsg create \
  --name DataNSG \
  --resource-group MyResourceGroup

# Create a rule to allow traffic only from the App Tier
az network nsg rule create \
  --resource-group MyResourceGroup \
  --nsg-name DataNSG \
  --name AllowAppTier \
  --priority 100 \
  --destination-address-prefixes 10.0.2.0/24 \
  --destination-port-ranges 1433 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 10.0.1.0/24

Note: When you associate an NSG with a subnet, it applies to every resource within that subnet. This is a powerful way to ensure consistent security posture across all VMs in that tier without having to manage individual VM-level firewalls.

Best Practices for Subnet Design

Designing subnets is not a one-time task; it is an ongoing process of refinement. Follow these industry-standard practices to maintain a healthy network environment.

1. Avoid Over-Provisioning

It is tempting to create large subnets to "avoid running out of IPs," but this often leads to wasted address space. Use smaller, right-sized subnets and rely on Azure's ability to add address space to the VNet later if needed.

2. Plan for Service Endpoints and Private Links

Modern Azure architectures rely heavily on PaaS (Platform-as-a-Service) offerings like Azure SQL or Azure Storage. To keep traffic to these services within the Microsoft backbone network, use Service Endpoints or Private Links. Private Link requires a dedicated subnet to host the private endpoints, so plan your address space to accommodate these extra subnets.

3. Keep Routing Simple

Avoid complex User-Defined Routes (UDRs) whenever possible. While they are necessary for routing traffic through a Network Virtual Appliance (NVA) or a firewall, too many custom routes make troubleshooting difficult. Use the default system routes unless you have a specific requirement for traffic inspection.

4. Implement Monitoring

Use Azure Network Watcher to monitor your subnets. Specifically, use NSG Flow Logs to see which traffic is being allowed or denied. This data is invaluable for debugging connectivity issues and verifying that your security policies are working as intended.

Common Pitfalls and How to Avoid Them

Even experienced architects can fall into traps when dealing with cloud networking. Here are the most common mistakes and how to avoid them.

Pitfall 1: Overlapping CIDR Blocks

This is the single most common networking error. If you create a VNet with 10.0.0.0/16 and later try to connect it to an on-premises network that uses the same range, the connection will fail.

• The Fix: Maintain a central IP address management (IPAM) spreadsheet or use a tool to track address usage across your entire organization, including on-premises and multi-cloud environments.

Pitfall 2: The "Everything in One Subnet" Syndrome

Putting all your resources in a single subnet makes it impossible to apply effective network-level security. If a web server is compromised, the attacker has a direct, unrestricted path to your database server within the same subnet.

• The Fix: Always separate your resources into functional tiers. Even if your application is small today, designing for tiers ensures that you can add security layers later without re-architecting your entire network.

Pitfall 3: Ignoring Service Endpoints

Many developers assume that connecting to an Azure database is "secure enough" because it is a cloud service. However, by default, these services are accessible over the public internet.

• The Fix: Always use Service Endpoints or Private Link to restrict access to your PaaS resources. This ensures that your data traffic never traverses the public internet, which is a major security improvement.

Warning: Subnet Resize Limitations While you can add address space to an existing VNet, you cannot easily resize a subnet that already contains resources. If you have a subnet that is too small, you often have to create a new, larger subnet and migrate your resources to it. This is a time-consuming process that can cause downtime. Always start with a slightly larger subnet than you think you need.

Advanced Configuration: Delegated Subnets

In some cases, you need to use Azure services that require full control over a subnet. This is known as "Delegation." When you delegate a subnet to a service (like Azure NetApp Files or Azure Container Instances), that service gains the permissions to create its own resources, such as network interfaces, within that subnet.

To delegate a subnet, you must specify the service when creating the subnet configuration. For example, if you are setting up Azure Database for PostgreSQL (Flexible Server), you must delegate the subnet to Microsoft.DBforPostgreSQL/flexibleServers.

az network vnet subnet create \
  --name DatabaseSubnet \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --address-prefixes 10.0.3.0/24 \
  --delegations Microsoft.DBforPostgreSQL/flexibleServers

Once a subnet is delegated, you cannot deploy other resources into it, and you must follow the specific documentation for that service. This is a critical distinction that prevents configuration conflicts.

The Role of Network Security Groups (NSG) and Application Security Groups (ASG)

While this lesson focuses on subnet configuration, you cannot talk about subnets without discussing how they interact with NSGs and ASGs. An NSG contains security rules that allow or deny traffic to network interfaces or subnets. An ASG, on the other hand, allows you to group VMs by their function (e.g., "WebServers" or "DatabaseServers") regardless of their subnet.

By using ASGs in your NSG rules, you can create more readable and maintainable policies. Instead of writing a rule based on the IP address of a specific VM, you write a rule based on the ASG tag.

• Example: Create a rule that allows traffic from the WebServers ASG to the DatabaseServers ASG on port 1433.
• Benefit: If you add more web servers to the pool, you simply tag them with WebServers, and the security rule automatically applies to them without any manual updates to the NSG.

Designing for High Availability and Disaster Recovery

Subnet design plays a vital role in how your application handles failure. If you deploy all your VMs in a single availability zone, a data center outage could take down your entire application.

Multi-Zone Subnet Strategy

When designing your subnets, consider how they will interact with Azure Availability Zones. While subnets themselves are regional and span all zones within a region, you can deploy your resources into specific zones. Your architecture should ensure that you have redundant instances of your application spread across multiple zones. Your subnet design should be "zone-aware," meaning you have sufficient IP capacity in your subnets to handle the scaling needs of a multi-zone deployment.

Cross-Region Considerations

If you have a global application, you might use VNet Peering to connect VNets in different regions. Remember that subnets are VNet-specific. If you want to maintain a consistent security model across regions, you should standardize your subnet naming and CIDR allocation patterns. This makes it easier to write automated scripts that deploy resources across multiple regions without worrying about IP conflicts.

Security Best Practices: The "Zero Trust" Approach

In a modern cloud environment, the network perimeter is no longer just the edge of your office. With "Zero Trust," you assume that the network is already compromised. Your subnet design should reflect this by:

1. Micro-segmentation: Breaking your network into the smallest logical units possible.
2. Least Privilege: Ensuring that each resource only has the network access it needs to perform its job.
3. Traffic Inspection: Routing traffic through a centralized firewall (like Azure Firewall) for deep packet inspection, especially for traffic moving between subnets.

By placing an Azure Firewall in a dedicated "Hub" VNet and using "Spoke" VNets for your applications, you can force all cross-subnet and cross-VNet traffic to go through a central point of control. This is the "Hub-and-Spoke" topology, which is the industry standard for large-scale enterprise Azure deployments.

Troubleshooting Connectivity

Inevitably, you will run into a situation where a resource in one subnet cannot talk to a resource in another. When this happens, follow this systematic troubleshooting flow:

1. Check the NSG: Look at the effective security rules for the network interface of the source and destination VMs. Is there an explicit "Deny" rule?
2. Check the Routing Table: Use az network nic show-effective-route-table to see if the traffic is being routed as expected. Is a UDR sending the traffic into a black hole?
3. Check the Application: Is the application actually listening on the port you are trying to reach? Use a tool like telnet or nc to test the connection.
4. Check Service Endpoints/Private Links: If you are trying to reach a PaaS service, ensure that the subnet has the correct Service Endpoint enabled or that the Private Endpoint is correctly configured.

Callout: The Power of Effective Routes The "Effective Routes" feature in the Azure Portal is your best friend when troubleshooting. It shows you the final, computed routing table for a VM, combining system routes, BGP routes, and your own UDRs. If your traffic isn't going where you think it should, the Effective Routes view will show you exactly which rule is causing the diversion.

Summary of Key Takeaways

Throughout this lesson, we have explored the critical aspects of Azure subnet design and configuration. To summarize, keep these points in mind as you architect your cloud networks:

• Subnets are Security Boundaries: They are the primary mechanism for isolating different tiers of your application (Web, App, Data) and applying security policies via NSGs.
• Plan for Growth: Always select a VNet address space that is large enough to handle future expansion and avoid overlapping IP ranges with other networks.
• Use Tiered Architectures: Organize your resources into functional subnets to simplify security management and improve organizational clarity.
• Understand Reserved IPs: Remember that Azure reserves five IPs per subnet, and design your CIDR blocks accordingly to avoid running out of usable addresses.
• Leverage Infrastructure as Code (IaC): Use tools like Terraform or Bicep to define your network architecture. This ensures consistency, repeatability, and version control for your network environment.
• Implement Zero Trust: Treat your internal network as untrusted by using NSGs and ASGs to enforce the principle of least privilege between all resources.
• Monitor and Troubleshoot: Use Azure Network Watcher and Effective Routes to maintain visibility into your network traffic and resolve connectivity issues quickly.

By following these principles, you will move beyond treating the cloud as a simple collection of resources and start building a resilient, secure, and professional-grade network infrastructure that can support the most demanding workloads. The effort you put into the planning phase of your subnet design will pay dividends in the form of reduced downtime, easier security audits, and a more predictable environment for your developers and operations teams.