5.1.2.1. Design for Azure Virtual Network (VNet)
5.1.2.1. Design for Azure Virtual Network (VNet)
💡 First Principle: A logically isolated virtual network is the fundamental building block for private networking in the cloud, providing a secure and customizable environment with granular control over IP addressing, subnets, routing, and security.
Scenario: You are designing the network for a multi-tier web application in Azure. You need separate subnets for the web, application, and database tiers. The database subnet should be completely isolated from the internet. All inter-subnet communication needs to be controlled by specific firewall rules.
An Azure VNet is a logical representation of your network in the cloud. It is isolated from other Azure VNets.
Key Design Considerations:
- IP Addressing: Plan your VNet address space carefully using CIDR notation to avoid overlaps with on-premises networks.
- Subnetting: Divide your VNet into subnets to logically segment resources based on function or security requirements.
- Network Isolation: Use Network Security Groups (NSGs) to filter network traffic to and from resources within subnets.
- Connectivity: Establish VNet peering for seamless connectivity between VNets. Use VPN Gateway or ExpressRoute for hybrid connectivity.
- DNS: Configure DNS resolution for resources within the VNet.
- Routing: Understand default routes and consider User Defined Routes (UDRs) for custom routing scenarios, such as forcing traffic through a network virtual appliance (NVA).
- Security: Integrate with Azure Firewall for centralized security, and consider Azure Private Link for secure access to Azure PaaS services.
Design decisions in practice — address planning is the part you cannot redo cheaply:
| Rule | Detail |
|---|---|
| Never overlap | Peered VNets and on-premises ranges must not overlap. Overlapping space cannot be peered, and renumbering a live VNet means redeploying into it |
| Azure reserves 5 addresses per subnet | The first four and the last. A /29 yields 3 usable addresses, not 8 — size subnets with that in mind |
| Named subnets have fixed minimums | GatewaySubnet /27 recommended, AzureFirewallSubnet /26 required, AzureBastionSubnet /26. These names are exact and cannot be changed |
| Plan for growth | A subnet cannot be resized while resources sit in it. Allocate larger than today's need |
| Peering is non-transitive | A peered to B and B peered to C does not give A to C. Spoke-to-spoke traffic routes through the hub by user-defined route |
Delegated subnets are a further constraint worth designing for early: App Service regional VNet integration, Container Apps and several managed services each require their own delegated or dedicated subnet, and a delegated subnet cannot host anything else.
⚠️ Exam Trap: a scenario that says two networks "cannot be connected" is usually describing overlapping address space, not a missing peering. Adding a peering does not fix an overlap.
⚠️ Common Pitfall: Allocating a VNet address space that overlaps with an on-premises network. This will cause major routing issues when you later try to establish hybrid connectivity.
Key Trade-Offs:
- Security vs. Simplicity: A multi-subnet, tiered architecture is more secure but also more complex to configure and manage than a simple, flat network.
Reflection Question: How does designing for Azure Virtual Network (VNet) (including IP addressing, subnetting, and integration with NSGs) fundamentally provide the connectivity, isolation, and security necessary for Azure resources to communicate securely and efficiently?
