Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 14

Virtual Network Design and Segmentation

Recommended resources

Welcome to our third module, where we shift from the principles of identity and access to the foundational layer of Azure's infrastructure: networking. In the previous module, we established how to control who can access resources and how they prove their identity. Now, we will build the private, secure spaces where those resources will live and communicate.

This lesson begins our journey into Azure Networking by tackling its most fundamental component. Our objective is to learn how to design Azure Virtual Networks (VNets) with appropriate address spaces and subnet segmentation for a given architecture. For a principal engineer, this is an essential skill, analogous to the urban planning of a city before any buildings are constructed. A well-designed network is scalable, secure, and manageable; a poorly designed one creates problems that are difficult and costly to fix later. We will approach this from an architectural perspective, focusing on the critical design decisions you need to make upfront.

Azure Virtual Network: Your Private Space in the Cloud

An Azure Virtual Network, or VNet, is the primary building block for creating an isolated network environment in Azure. If you are familiar with Amazon Web Services, the concept is directly analogous to an AWS Virtual Private Cloud (VPC). A VNet allows you to provision a logically isolated section of the Azure cloud where you can launch Azure resources in a virtual network that you define.

To start, let's establish the foundational characteristics of a VNet and how it compares to its AWS counterpart. The following video provides a concise overview.

Azure Virtual Network Overview

This video from John Savill's Technical Training channel covers the essential properties of a VNet, including its scope and relationship with subnets.

Please watch the following segments: VNet Basics: This part covers the core definition, the use of private IP ranges (RFC 1918), and the critical rule that a VNet is scoped to a single subscription and region. Subnets and Availability Zones: Pay close attention to the explanation of subnets and the fact that they can span Azure Availability Zones.

From the video, and reinforced in the Microsoft Learn documentation, two key architectural points stand out:

  1. Scope: A VNet is bound to a single Azure region and a single subscription. Resources can only be placed in a VNet that exists in the same region and subscription.
  2. Subnet Placement: This is a key differentiator from AWS. In AWS, a subnet is tied to a specific Availability Zone (AZ). In Azure, a subnet is a regional construct and resources within the same subnet can be deployed across different AZs within that region. This provides greater flexibility for designing high-availability architectures without needing to manage networking across multiple subnets for AZ-level redundancy.

The article below provides a direct comparison that will be useful given your AWS background.

Compare AWS and Azure Networking Options

This official Microsoft documentation directly compares AWS and Azure networking services.

Please read the introductory section, Azure virtual networks and AWS VPCs, and review the first row of the comparison table under Cloud virtual networking. Focus on the "Subnet placement" point, which confirms this important architectural difference.

Step 1: Planning the Address Space

The first and most critical design decision is planning your IP address space. Getting this wrong can lead to significant challenges later, especially when you need to connect your VNet to other networks (e.g., other VNets or your on-premises datacenters). The cardinal rule is to ensure your VNet's address space does not overlap with any other network it might ever need to connect to.

This is a strategic, architectural decision, not a trivial configuration detail. The following blog post provides an excellent guide to the design thinking involved.

Building a Hub and Spoke Network Topology in Azure - Glen Thomas

While this article focuses on a hub-spoke topology (which we'll cover in the next lesson), its section on IP address planning is universally applicable and provides the architectural mindset needed.

Read the section titled "IP Address Planning." Pay attention to the recommendations for being generous with address allocation and using standard private ranges (RFC 1918).

As the article emphasizes, there is no cost associated with reserving a large private IP address range, so it's wise to be generous. A common practice for a significant deployment is to allocate a large CIDR block like 10.x.0.0/16, which provides 65,536 addresses. This gives you ample room to carve out subnets for your current needs and future growth without risking address exhaustion.

Step 2: Subnet Segmentation for Security and Function

Once you've defined the overall address space for your VNet, the next step is to divide it into one or more subnets. A subnet is a range of IP addresses within your VNet. You deploy your Azure resources, like Virtual Machines and PaaS services with private endpoints, into these subnets.

Why do we segment a VNet?

  • Security Boundaries: Subnets are the primary mechanism for implementing network security policies. You can associate Network Security Groups (NSGs)—which are essentially firewall rules—to subnets to control traffic flow. For example, you can allow traffic from the internet to your web server subnet but block it from reaching your database subnet directly.
  • Organizational Structure: Subnets can represent different tiers of an application (e.g., web, application, data), different environments (e.g., development, testing), or different functional units.
  • Service Requirements: Some Azure services, like Azure Bastion or Azure Firewall, require their own dedicated subnet.

A classic example of subnet segmentation is for an N-tier application architecture, a pattern you are likely very familiar with from your software engineering background.

This diagram shows a typical N-tier architecture deployed in Azure. Each tier (Web, Business, Data) is isolated in its own subnet, with load balancers managing traffic between them and NSGs (Network Security Groups) enforcing security rules at the subnet level.

In this design:

  • The Web tier subnet contains the web servers and is the only subnet that might receive traffic from the internet (via an Application Gateway).
  • The Business tier subnet contains the application logic. It is configured to only accept traffic from the Web tier subnet.
  • The Data tier subnet contains the database servers. It is the most restricted, configured to only accept traffic from the Business tier subnet.

This segmentation creates a defense-in-depth strategy. If a web server is compromised, the attacker does not have direct network access to the database servers.

The following video walks through this exact scenario, explaining the rationale for segmenting the network and introducing the role of NSGs.

Designing Microsoft Azure Virtual Networks

This video provides a practical explanation of VNet and subnet design using a common application scenario.

Watch the following segments: First, get the formal definitions from VNet and Subnet Definitions. Next, watch the scenario walkthrough from Subnet Design for an N-Tier App. This demonstrates how to segment an application into web and database subnets and why you would use NSGs to control traffic between them.

A Practical Design Framework

Let's synthesize these concepts into a simple design process for a new application.

  1. Define the VNet Address Space: Choose a large, non-overlapping CIDR block from the RFC 1918 ranges.

    • Example: 10.20.0.0/16 for our new application environment.

  2. Identify Functional/Tier-Based Segments: Analyze your architecture and identify the distinct components that should be isolated.

    • Example: We have a web front end, a set of backend APIs, and a SQL database. We also need a secure way to manage our VMs. This gives us four segments: Web, App, Data, and Management.

  3. Allocate Subnets for Each Segment: Carve out CIDR blocks from your VNet address space for each identified segment. A /24 block (251 usable IPs, as Azure reserves 5 per subnet) is a common and flexible starting point for a single tier.

    • Example:
      • snet-web: 10.20.1.0/24
      • snet-app: 10.20.2.0/24
      • snet-data: 10.20.3.0/24
      • AzureBastionSubnet: 10.20.254.0/26 (Note: Bastion requires this specific name and a minimum size of /26).

This structured approach ensures that your network design is intentional, secure, and ready for future growth.

Conclusion

In this lesson, we established the core principles of Azure Virtual Network design. You are now equipped to make foundational architectural decisions about your cloud network environment.

The key takeaways are:

  • An Azure VNet is the fundamental building block for private networking, analogous to an AWS VPC, but with a key difference: Azure subnets are regional and span Availability Zones.
  • IP address planning is a critical first step. Always choose a large, non-overlapping RFC 1918 address space to avoid future connectivity issues.
  • Subnetting is the primary tool for segmenting your network to create security boundaries and organize resources.
  • Designing subnets around application tiers (e.g., web, application, data) is a fundamental and highly effective pattern for securing applications.
  • Certain managed services in Azure require their own dedicated, specifically named subnets, which must be factored into your design.

So far, we have focused on designing a single VNet in isolation. However, most enterprise environments consist of many VNets for different applications, environments, and business units. In our next lesson, we will explore how to connect these isolated networks together securely and scalably using VNet Peering and hub-spoke network topologies.