What Does Azure Virtual Network Design Mean?
Also known as: Azure Virtual Network Design, AZ-305 networking, VNet design best practices, Azure subnet design, Azure network security
On This Page
Quick Definition
Azure Virtual Network Design means deciding how to set up your own private network inside Azure. Think of it as drawing a map for a city: you decide where the streets go, where buildings are placed, and how traffic flows. A good design ensures that your cloud resources can talk to each other safely and that only the right people and systems can access them.
Must Know for Exams
Virtual Network Design is a heavy topic in the Microsoft Azure Architect Design exam (AZ-305). This exam tests your ability to recommend and design network solutions that meet specific business and technical requirements. You can expect multiple questions that present a scenario and ask you to choose the appropriate VNet design, connectivity method, or security measure.
The exam objectives related to VNet design fall under the section Design network solutions. This includes designing for connectivity between resources (VNet peering, VPN, ExpressRoute), designing for name resolution (Azure DNS, private DNS zones), and designing for network security (NSGs, Azure Firewall, DDoS protection). To pass, you need to understand not just how these services work, but when to use each one based on requirements like latency, cost, security, and hybrid connectivity needs.
Questions often appear as multiple-choice or case studies. A typical scenario might describe a company with multiple offices and a cloud workload that must be highly available and secure. You will need to decide whether to use a hub-and-spoke topology with VNet peering, whether to implement a VPN or ExpressRoute for on-premises connectivity, and where to place Azure Firewall or a network virtual appliance.
The exam also tests your ability to design for disaster recovery and business continuity. For example, you might need to design VNets in multiple regions and connect them using global VNet peering, ensuring that traffic stays within the Microsoft backbone network. Understanding IP address planning to avoid overlapping CIDR blocks is critical because overlapping addresses will break peering and VPN connections.
Another common exam area is hybrid networking. You must know the differences between Site-to-Site VPN, Point-to-Site VPN, and ExpressRoute. For example, a company needing a consistent, low-latency connection with a service level agreement should use ExpressRoute, not VPN. If a company has a small home office needing occasional access, Point-to-Site VPN is sufficient. The exam expects you to match these solutions to the correct requirements.
Finally, security in VNet design is tested heavily. You need to know when to use NSGs versus Azure Firewall, how to design a DMZ with subnets and NSGs, and how to block inbound and outbound traffic. The exam will ask you about forced tunneling to route internet traffic through a firewall, and when to use service endpoints or private endpoints for PaaS services. Mastering these concepts is essential for scoring well on AZ-305.
Simple Meaning
Imagine you are moving into a new office building that many different teams will share. You need to decide how to organize the space so that everyone can work efficiently and securely. You will decide which team sits in which area, which doors they can use, and who gets a key to what. Azure Virtual Network Design is exactly like that, but for your online resources in Microsoft's cloud.
When you create resources in Azure, such as virtual machines (which are like computers running in the cloud) or databases, they need to talk to one another. They also may need to connect to the internet or to your company's existing network in your own building. An Azure Virtual Network (VNet) is the dedicated space you create for your cloud resources. Designing this VNet means you plan its layout: you decide what IP addresses your resources will use, how they will be grouped into smaller sub-networks (called subnets), and what rules will control traffic coming in and going out.
A good design is like a well-organized city. You plan the streets (the network routes), you put traffic lights and stop signs (firewalls and security rules), and you create pedestrian zones or restricted areas (private subnets) where only certain people can enter. If you design poorly, you might create traffic jams (slow performance), leave doors unlocked (security vulnerabilities), or find that some buildings have no road to reach them (resources unable to connect). By thinking carefully about your design from the start, you save time, money, and prevent headaches later.
The process involves understanding how many resources you will have, what data they need to share, who needs access, and whether you need to connect to your own company's network. Then you choose IP address ranges, divide them into subnets, set up security rules, and optionally connect your VNet to other networks using VPNs or dedicated connections. The goal is to make everything work smoothly, securely, and cost-effectively.
Full Technical Definition
Azure Virtual Network Design refers to the architectural planning and implementation of Virtual Networks (VNets) within Microsoft Azure. A VNet is a logically isolated section of the Azure cloud dedicated to your subscription. It acts as a network boundary within which you can launch and manage Azure resources like virtual machines, App Service Environments, Azure Kubernetes Service clusters, and more. VNets are the fundamental building block for private connectivity in Azure.
IP address planning is the first and most critical step. When you create a VNet, you assign it a private IP address space using CIDR notation, such as 10.0.0.0/16. This address space must not overlap with any other networks you intend to connect, such as your on-premises network or other VNets. Within that address space, you create subnets (e.g., 10.0.1.0/24) to segment resources based on function or security requirements. Each subnet is a range of IP addresses within the VNet. Azure reserves the first three IP addresses in each subnet for networking purposes (specifically the network address, a default gateway, and a broadcast address), so you should account for that when sizing subnets.
Network Security Groups (NSGs) are stateful firewalls that filter traffic to and from Azure resources in a VNet. You can apply NSGs at the subnet level or at the network interface level of individual VMs. NSGs use rules that specify source and destination IP addresses, ports, and protocols, along with an action (Allow or Deny). Azure also provides Azure Firewall, a managed, cloud-native firewall service for more advanced filtering and threat protection.
Route tables control traffic flow within and between subnets. By default, Azure creates system routes that allow resources in the same VNet to communicate, as well as routes to the internet and to VPN gateways. You can create custom routes to override these defaults, for example, to force all internet-bound traffic through a firewall appliance for inspection. This is called forced tunneling.
Peering connects two VNets within the same region or across regions (global peering) so that resources in different VNets can communicate as if they were on the same network. Transit routing is not supported by default through peering — if you peer VNet A to VNet B and VNet B to VNet C, VNet A cannot directly communicate with VNet C unless you explicitly peer A to C. Hub-and-spoke architectures solve this by routing traffic through a central hub VNet.
Finally, connecting an Azure VNet to an on-premises network can be done using Site-to-Site VPN (over the internet), Point-to-Site VPN (individual client machines), or Azure ExpressRoute (a dedicated private connection). Each method has different latency, security, and cost characteristics. A well-designed VNet plan considers all these components: IP allocation, subnet segmentation, security controls, routing, peering, and hybrid connectivity. Proper design scales with your organization and minimizes attack surface.
Real-Life Example
Think of an office building with many different departments. The building itself is like your Azure subscription. Each floor of the building is a separate Virtual Network (VNet). On each floor, there are different rooms — some are open-plan offices, some are meeting rooms, and some are secure storage rooms. These rooms are like subnets within your VNet.
Now, imagine you are the facilities manager. You must decide how many floors you need, how many rooms on each floor, and who gets keys to which rooms. You also need to plan the hallways and elevators that connect everything. This is exactly like designing an Azure VNet. The IP address range you choose for your VNet is like deciding the size and shape of the floor. Choosing 10.0.0.0/16 is like saying my floor is 65,536 square feet. Dividing that into subnets of 10.0.1.0/24 is like building rooms of 256 square feet each.
Security is like installing locks on doors. NSGs are like locks on individual rooms or on entire wings. For example, the finance department's room (a subnet) might have a lock that only allows people with finance badges to enter. Azure Firewall is like a security guard at the building entrance who checks every visitor and package coming in or out.
Route tables are like the signs in the hallways that tell people which way to go. By default, the signs point to the exits and to other floors. But you can change the signs so that all visitors first have to go past the security guard (firewall) before they can reach any other room. This is forced tunneling.
Finally, connecting this building to another building across the street is like VNet peering or VPN. You might build a skybridge (peering) so people from the two buildings can walk directly to each other's offices. Or you might use a secure tunnel under the street (VPN) to connect them. The design ensures everyone can get where they need to go without bumping into walls or getting lost.
Why This Term Matters
Azure Virtual Network Design matters because it forms the backbone of everything you deploy in the cloud. Without a proper design, you risk creating networks that are insecure, slow, or impossible to manage. For IT professionals working in cloud infrastructure, a poorly designed VNet can lead to data breaches, unexpected downtime, and runaway costs.
Security is a primary concern. The VNet is your first line of defense. By segmenting resources into subnets and applying NSGs, you control exactly who can access what. For example, you can place your web servers in a public subnet with internet access, your application servers in a private subnet that only the web servers can reach, and your databases in an isolated subnet that no external traffic can touch. This layered defense is known as defense in depth and is a core principle of cybersecurity.
Performance also relies heavily on VNet design. If you place resources that need to talk frequently into different VNets without peering, traffic will have to traverse the internet and will be slower and less secure. Proper placement and routing reduce latency and improve application response times. Additionally, choosing the right IP address space prevents overlapping address issues when you need to connect to on-premises networks later. Overlapping IPs can break connectivity and require costly rework.
Cost is another factor. Data transfer between Azure services in the same VNet is free, but transferring data across VNets or regions incurs charges. A well-planned design keeps related resources together and minimizes unnecessary cross-boundary traffic, saving your organization money.
Finally, scalability depends on VNet design. As your organization grows, you will add more resources. A VNet with a well-thought-out address space has room to expand without needing to recreate the entire network. Without planning, you might hit a wall where you cannot add more subnets or connect to new networks, forcing a painful migration. In short, Azure Virtual Network Design is not just a technical task — it is a strategic decision that affects security, performance, cost, and long-term success.
How It Appears in Exam Questions
Exam questions on Azure Virtual Network Design appear in several distinct formats. The most common is the scenario-based multiple choice question. A typical question describes a company with certain requirements and asks you to select the best design or connectivity option. For instance, the scenario might say: A company has an Azure VNet in the East US region with 100 virtual machines. They need to connect to a new VNet in West US with 50 VMs. The connection must be low latency and stay within the Microsoft network. Which solution should you recommend? The correct answer would be Global VNet peering, while incorrect options might include Site-to-Site VPN or ExpressRoute (which is overkill or unnecessary).
Another common format is the ordering or drag-and-drop type question. Here, you may be asked to put steps in the correct order for designing a VNet. For example: After creating a VNet, what is the next step? The correct sequence typically starts with planning the IP address range, then creating subnets, then applying NSGs, then deploying resources, then configuring peering or VPN. Questions like this test your understanding of the workflow.
Configuration-based questions also appear. You might be shown a partial configuration for a VNet, subnet, and NSG, and asked to identify what is missing or wrong. For example, the subnet address range 10.0.1.0/24 overlaps with the on-premises network 10.0.1.0/24, and you must recognize that this will break VPN connectivity. Or you might see an NSG rule that allows all inbound traffic from the internet to a database subnet, and you need to flag it as a security risk.
Troubleshooting questions are less common but appear. For example, a company reports that virtual machines in two different subnets cannot communicate. You are given the NSG rules and route tables, and you must identify that a custom route is misconfigured or an NSG is blocking traffic. These questions require you to understand the flow of traffic and how NSGs and route tables interact.
Architecture design questions are the most challenging. These are often part of a case study that spans multiple questions. For example, a global company with offices in New York, London, and Tokyo wants to migrate all its workloads to Azure. They have strict security, latency, and cost constraints. You will need to design a VNet topology, decide on regional VNets, set up peering, choose connectivity methods for each office, and plan DNS resolution. These questions test your ability to synthesize many concepts into a cohesive solution.
In all these question types, the key is to read carefully for requirements like latency, cost, security, and scalability. The wrong answer often looks tempting because it is technically possible, but it fails to meet one specific requirement. For example, using a VPN might be cheaper and work, but if the requirement says low latency with SLA, ExpressRoute is the only correct choice.
Practise Azure Virtual Network Design Questions
Test your understanding with exam-style practice questions.
Example Scenario
A medium-sized company named GreenLeaf Logistics runs a warehouse management application. They have 50 virtual machines in Azure that handle inventory tracking, order processing, and reporting. Their current setup puts all VMs in a single VNet with one subnet, and all VMs have public IP addresses for remote management. Recently, they experienced a security incident where an attacker accessed the application server through an open port and stole customer data.
To fix this, GreenLeaf decides to redesign their Azure Virtual Network. First, they create a new VNet with the IP address range 10.0.0.0/16. They then divide this range into three subnets: a frontend subnet (10.0.1.0/24) for web servers that need to be accessible from the internet, an application subnet (10.0.2.0/24) for the business logic servers, and a data subnet (10.0.3.0/24) for the database servers.
Next, they apply NSGs. The frontend subnet NSG allows inbound HTTP and HTTPS traffic from the internet only. The application subnet NSG only allows traffic from the frontend subnet on specific ports. The data subnet NSG only allows traffic from the application subnet on the database port (1433 for SQL Server). All other inbound traffic is denied. They also remove all public IP addresses from the application and database VMs, so those servers are not directly reachable from the internet.
Finally, they set up a Site-to-Site VPN connection from their on-premises office to the VNet so that the IT team can securely manage the VMs without exposing them to the internet. This redesigned VNet provides clear segmentation, minimal attack surface, and secure remote access. GreenLeaf now has a network that is much more secure and follows best practices for cloud architecture.
Common Mistakes
Choosing an IP address range that overlaps with the on-premises network.
If the address ranges overlap, Site-to-Site VPN and ExpressRoute connections will fail because Azure cannot route traffic to overlapping IPs — it does not know whether the destination is on-premises or in Azure. This breaks hybrid connectivity completely.
Always verify the IP address ranges used in your on-premises network and choose a VNet address space that does not overlap. For example, if your on-premises network uses 10.0.0.0/16, pick 10.1.0.0/16 for your Azure VNet.
Creating subnets that are too small, leaving no room for growth or for Azure reserved addresses.
Azure reserves the first three IP addresses in each subnet for networking infrastructure (network, gateway, broadcast). If you create a /30 subnet (4 IP addresses total), you only have 1 usable IP after reservations. Your virtual machines will fail to deploy or scale.
Always account for Azure's reserved addresses and plan for future growth. Use at least a /24 subnet (256 addresses, 251 usable) unless you are absolutely sure you need only a few IPs. Leave room for future resources.
Applying NSGs only at the network interface level and not at the subnet level.
While NSGs at the NIC level provide fine-grained control, they can be inconsistently applied and harder to audit. If you rely only on NIC-level rules, you might miss applying a rule to a new VM, leaving it exposed. Subnet-level NSGs ensure all resources in that subnet inherit the same baseline security rules.
Always apply an NSG at the subnet level as a first layer of defense. Use NIC-level NSGs only for additional, specific exceptions when needed. This is called defense in depth.
Assuming that VNet peering provides transitive routing between peered VNets.
VNet peering is non-transitive. If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot directly communicate with VNet C unless they are explicitly peered. Many learners think traffic flows through B automatically, but it does not.
Remember the rule: peering is not transitive. If you need VNet A to talk to VNet C, create a direct peering between them, or use a hub VNet with a network virtual appliance or Azure Firewall that routes traffic between spoke VNets.
Exam Trap — Don't Get Fooled
An exam question states: You have two Azure VNets in the same region. VNet A contains web servers, VNet B contains databases. You peer VNet A and VNet B. You then create a new VNet C in the same region and peer it with VNet B.
You now need the web servers in VNet A to communicate with resources in VNet C. What should you do? A learner might answer: No additional configuration is needed because traffic can route through VNet B.
Memorize this rule: Azure VNet peering is always non-transitive. Unless you specifically peer VNet A with VNet C, or configure a hub VNet with a network virtual appliance that performs routing, traffic cannot flow from A to C through B. On the exam, if you see a scenario with multiple peered VNets and need communication between non-adjacent ones, look for an option that says peer the two directly or use a hub with Azure Firewall.
Commonly Confused With
VNet Peering is a specific connectivity feature that connects two VNets so they can communicate. In contrast, Virtual Network Design is the entire planning process that includes deciding whether and how to use peering. Peering is one tool in the design toolkit; design is the broader strategy.
Designing a VNet is like designing a city's layout including roads, zones, and traffic rules. Peering is like building a bridge between two parts of the city. The city design decides whether a bridge is needed, and where to put it.
An NSG is a rule set that filters traffic to and from resources in a VNet. It is a component you use within a VNet design. VNet Design is the overall plan that includes where to apply NSGs, but also includes IP allocation, subnets, routing, and connectivity. NSGs are just one piece of the puzzle.
Designing a VNet is like planning the security for a building. An NSG is like a specific lock on a specific door. The overall design decides which doors need locks and what kind. The lock itself is only a small part of the security plan.
A Virtual Network Gateway is a specific Azure resource that provides encrypted connectivity between a VNet and an external network (like on-premises) over VPN or ExpressRoute. VNet Design might include using a gateway, but the gateway is just one component. Design covers the entire network architecture, not just the connection point.
Designing a VNet is like designing a house. A Virtual Network Gateway is like the front door that connects the house to the outside world. The house design includes the door's location and size, but the door itself is just one element of the whole structure.
Step-by-Step Breakdown
Plan Your IP Address Space
You start by deciding the private IP address range for your VNet using CIDR notation, such as 10.0.0.0/16. This range must not overlap with any other network you plan to connect (on-premises, other VNets). Think of this as deciding the size of your property. A /16 gives you 65,536 addresses, while a /24 gives only 256. Choose a range that allows for future growth.
Create Subnets for Segmentation
Divide your VNet into subnets to organize resources by function or security level. For example, create a frontend subnet, an application subnet, and a data subnet. Each subnet gets a smaller IP range, like 10.0.1.0/24. Subnets act like rooms in your building. Remember that Azure reserves the first three IP addresses in each subnet, so always leave extra space.
Apply Network Security Groups (NSGs)
Create NSG rules that control traffic entering and leaving each subnet (or individual resources). For example, allow HTTP and HTTPS traffic from the internet into the frontend subnet only. Deny all inbound traffic to the data subnet except from the application subnet. NSGs are your locks and security guards.
Configure Route Tables if Needed
Azure automatically creates routes that allow communication within the VNet and to the internet. If you need to change this behavior, create custom route tables. For example, you may want all outbound internet traffic from your VNet to go through a firewall first (forced tunneling). Route tables are like signs that tell traffic which path to take.
Set Up Connectivity (Peering or VPN)
If you have multiple VNets that need to communicate, set up VNet peering. To connect your VNet to an on-premises network, set up a Site-to-Site VPN or ExpressRoute. This step creates the bridges or tunnels between your cloud network and other networks. Test the connection to ensure everything works.
Deploy Resources and Validate
Finally, deploy your virtual machines, databases, and other resources into the appropriate subnets. Verify that they can communicate as intended and that security rules are working. Use Azure Network Watcher tools to troubleshoot any connectivity issues. This step confirms that your design is functional and secure.
Practical Mini-Lesson
Designing an Azure Virtual Network is a foundational skill for any cloud architect. In practice, the process begins long before you open the Azure portal. You must gather requirements from the business: how many applications will run? What are the security and compliance needs? Will you eventually connect to on-premises networks? Do you need to comply with data residency regulations? All these answers shape your VNet design.
Once you have requirements, you map out the IP address ranges. A common mistake is to use the same range your on-premises network uses, which will break hybrid connectivity. Always use a range that is defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) but is not already in use elsewhere. Many organizations use 10.x.x.x and carve out a /16 per region or per application. For example, 10.10.0.0/16 for one region, 10.20.0.0/16 for another. This makes peering and future expansion easier.
Next, you design subnets. A typical three-tier application uses three subnets: web, app, and data. This segmentation is critical for security. If an attacker compromises the web server, they cannot directly reach the database because the NSG on the data subnet blocks traffic from the web subnet. Professionals also create a separate AzureBastionSubnet (with the name AzureBastionSubnet exactly) if they want to use Azure Bastion for secure RDP/SSH access without public IPs on VMs.
Security groups must be designed with the principle of least privilege. Only allow what is absolutely necessary. For example, the data subnet should only allow traffic from the application subnet on the specific port your database uses. Avoid using ranges like 0.0.0.0/0 for inbound traffic on any subnet except perhaps a load balancer that fronts your web servers. Logically, plan your NSG rules so that the most specific rules come before broader ones, but remember that Azure processes all rules in order.
Routing is often overlooked. By default, all traffic within a VNet can flow freely. If you need a different topology, you must create custom routes. For example, in a hub-and-spoke design, you might need to add routes in the spoke VNets that force traffic to the hub for inspection. This requires a network virtual appliance or Azure Firewall in the hub, and route tables on the spokes with a next hop pointing to the hub's internal IP address.
What can go wrong? Overlapping IPs are the most common issue when connecting VNets or on-premises. Another issue is accidentally creating a subnet with no capacity (e.g., a /29 with only 3 usable addresses) and running out of IPs. Also, forgetting that VNet peering is non-transitive leads to broken connectivity. Finally, leaving RDP or SSH ports (3389 and 22) open to the internet is a critical security mistake.
In real-world environments, professionals use infrastructure as code (like Azure Resource Manager templates, Terraform, or Bicep) to deploy VNets consistently. They also leverage Azure Policy to enforce naming conventions and security rules. The work does not stop at deployment — you must monitor network traffic using Network Watcher, enable diagnostic logging for NSGs, and regularly audit security rules. This lesson covers how VNet design is not just a one-time event, but an ongoing process that evolves with your cloud environment.
Memory Tip
Remember the acronym I P S C R — IP planning, Subnets, Security (NSGs), Connectivity (peering/VPN), Routing. This gives you the five pillars of VNet design. Practice saying them in order when you approach any design scenario question.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
AZ-305AZ-305 →Related Glossary Terms
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
Frequently Asked Questions
Do I need to create a VNet before I create a virtual machine in Azure?
Yes, every Azure virtual machine must be placed inside a VNet. If you do not create one beforehand, Azure can create a default VNet for you, but it may not meet your design needs. It is better to plan and create your own VNet first.
Can I change the IP address range of a VNet after it is created?
No, you cannot modify the IP address space of an existing VNet. If you need a different range, you must delete the VNet and recreate it. This is why careful IP planning upfront is very important.
What is the difference between a VNet and a Subnet?
A VNet is the entire private network, like a city. A subnet is a smaller segment within that VNet, like a neighborhood. Subnets help you organize and secure related resources together, such as putting all web servers in one subnet and all databases in another.
How many VNets can I create in a single Azure subscription?
There is a default limit of 50 VNets per subscription per region, though you can request an increase. For large organizations, you will likely need many VNets, so planning your design with a hub-and-spoke topology can help organize them efficiently.
Can two VNets in different regions communicate with each other?
Yes, you can use Global VNet Peering to connect VNets in different Azure regions. Traffic stays on the Microsoft backbone network and is not sent over the public internet. It is low latency and secure.
Is it possible to block all internet access for resources inside a VNet?
Yes. You can apply a custom route table with a default route (0.0.0.0/0) pointing to a next hop of None, or force traffic through a firewall and then block it. Combine this with NSGs that deny outbound traffic to the internet for complete isolation.
What is the difference between a Site-to-Site VPN and ExpressRoute?
A Site-to-Site VPN uses the public internet with encryption to connect your on-premises network to Azure. ExpressRoute uses a dedicated private connection that does not traverse the internet, offering higher reliability, lower latency, and a guaranteed SLA. ExpressRoute is more expensive.
Summary
Azure Virtual Network Design is the essential process of planning and building the private network that hosts your cloud resources. A good design starts with careful IP address planning to avoid overlaps and allow room for growth. It then divides the VNet into subnets to logically separate resources based on function and security needs.
Network Security Groups and route tables provide fine-grained traffic control and custom routing. Connectivity features like VNet peering, VPN, and ExpressRoute extend the network to other regions and to on-premises data centers. For certification exams like AZ-305, you must understand not only the components but also the decision-making process behind each choice — when to use peering versus VPN, how to design for security and scalability, and how to avoid common pitfalls like overlapping IPs and non-transitive peering.
Mastering Azure Virtual Network Design is critical for any IT professional working with Azure because the network is the foundation upon which everything else relies. Get the design right, and your cloud environment will be secure, performant, and ready to scale.