Introduction to Azure Virtual Networks (VNet)

Understanding the Foundation of Cloud Connectivity

When you move workloads to the cloud, the first thing you need is a way for those resources to communicate with each other, with your on-premises infrastructure, and with the internet. In the Azure ecosystem, that capability is provided by the Azure Virtual Network (VNet). Think of a VNet as your own private network in the cloud. It is a logical isolation of the Azure cloud dedicated to your subscription, allowing you to define your own IP address spaces, subnets, route tables, and network gateways.

Without a VNet, your virtual machines and cloud services would exist in a vacuum, unable to talk to one another securely. By configuring a VNet, you take control of your network traffic, security boundaries, and connectivity patterns. This is the fundamental building block for any architecture you deploy in Azure, whether you are running a simple web application or a complex, multi-tier enterprise environment that spans multiple regions. Mastering VNets is not just a technical task; it is a prerequisite for building secure, scalable, and manageable cloud solutions.

In this lesson, we will explore the core concepts of Azure Virtual Networks, how to design your IP addressing schemes, how to segment your network using subnets, and how to manage traffic flow effectively. We will also dive into the practical side of deploying these resources using both the Azure Portal and CLI/PowerShell, ensuring you have the tools needed to manage your network infrastructure with confidence.

Core Components of an Azure Virtual Network

Before jumping into the configuration, it is essential to understand the individual parts that make up a VNet. A VNet is not just a single entity; it is a container for several interconnected networking objects.

1. IP Address Spaces

When you create a VNet, you must specify a private IPv4 address space using CIDR (Classless Inter-Domain Routing) notation. For example, you might choose 10.0.0.0/16. This provides you with 65,536 addresses to use within that VNet. It is critical to choose an address space that does not overlap with your on-premises networks or other connected VNets, as overlapping IP ranges cause routing conflicts that are notoriously difficult to troubleshoot.

2. Subnets

A VNet is divided into one or more subnets. Subnets allow you to segment the virtual network into smaller, manageable pieces. You can place different types of resources in different subnets—for example, putting your web servers in one subnet and your database servers in another. This segmentation is the first step toward implementing network security, as you can apply different policies and rules to each subnet.

3. Network Interfaces (NICs)

A Network Interface is the interconnection between a virtual machine and the VNet. Every virtual machine you deploy must have at least one NIC attached to it. The NIC is where you configure the private IP address, the public IP address (if needed), and the security groups that control traffic to and from that specific virtual machine.

4. Route Tables

By default, Azure automatically routes traffic between subnets, connected virtual networks, and the internet. However, you often need more control. Route tables allow you to define custom routes to control where network traffic is directed. This is particularly useful when you need to route traffic through a virtual appliance, such as a firewall or a WAN optimizer, before it reaches its destination.

Callout: Virtual Networks vs. Physical Networks In a traditional on-premises data center, you would manage switches, routers, and physical cabling. In Azure, the VNet provides this functionality as a software-defined network (SDN). You do not need to worry about the physical hardware; the SDN layer handles the switching and routing logic, while you simply define the policies and IP schemas through the Azure management plane.

Designing Your Network Topology

Planning your network architecture is the most important step before you click "Create." A poorly planned network is hard to change once resources are deployed.

Choosing your IP Range

When selecting an IP range, aim for the largest block you think you might need without causing conflicts. RFC 1918 defines private address spaces (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). Most enterprises stick to the 10.x.x.x range because it offers the most flexibility for large-scale deployments. Always leave "headroom" in your address space for future expansion.

Planning Subnets

Subnets should be organized by the function of the resources they contain. A common pattern is the "Three-Tier Architecture":

• Web Subnet: Contains load balancers and web servers.
• App Subnet: Contains application logic servers.
• Data Subnet: Contains databases and storage caches.

Tip: Do not make your subnets too small. While it is tempting to create a small subnet for a specific group of servers, you might find yourself needing to add more capacity later. Azure reserves five IP addresses in every subnet for infrastructure (the network address, the gateway address, and three addresses for Azure services). Plan accordingly.

Practical Deployment: Creating a VNet

Let’s walk through the process of creating a VNet using the Azure CLI. This is a common task for automation scripts and infrastructure-as-code deployments.

Step-by-Step CLI Deployment

1. Create a Resource Group: Everything in Azure lives in a resource group. az group create --name MyNetworkRG --location eastus

2. Create the VNet: Define the address space. az network vnet create --name MyVNet --resource-group MyNetworkRG --address-prefix 10.0.0.0/16

3. Create a Subnet: Add a subnet to the VNet. az network vnet subnet create --name WebSubnet --resource-group MyNetworkRG --vnet-name MyVNet --address-prefix 10.0.1.0/24

4. Verify the Configuration: List the VNet details. az network vnet show --name MyVNet --resource-group MyNetworkRG

This sequence creates a basic foundation. From here, you would attach virtual machines to the WebSubnet by specifying the VNet and Subnet IDs during the virtual machine creation process.

Managing Network Security

Once your network is up and running, your primary concern becomes security. You should never leave a network wide open.

Network Security Groups (NSGs)

An NSG is a virtual firewall that contains security rules that allow or deny inbound and outbound network traffic. You can associate an NSG with a subnet or with a specific network interface.

Rules are processed in priority order, starting from the lowest number. Once a rule matches the traffic, processing stops. This means you must be very careful with your rule ordering.

Common NSG Rules:

• Allow RDP/SSH: Only allow access from specific, known public IP addresses (your office or home VPN).
• Deny All Inbound: A standard practice is to have a "deny all" rule at the end of your inbound rule set.
• Allow Internal Traffic: Permit traffic between your web and database tiers, but restrict it to only the necessary ports (e.g., port 1433 for SQL Server).

Warning: Be extremely cautious when creating an "Allow All" rule for port 22 (SSH) or 3389 (RDP) from the source "Any" or "Internet." This is the most common way Azure resources are compromised by brute-force attacks.

Advanced Connectivity: Peering and Gateways

A single VNet is rarely enough for a large organization. You will eventually need to connect multiple VNets together or connect your VNet to your physical office.

VNet Peering

VNet Peering allows you to connect two VNets in the same Azure region (or different regions) so that they appear as one network. Traffic between peered virtual networks stays on the Microsoft private backbone network, which is fast and secure.

• Local Peering: Connects VNets in the same region.
• Global Peering: Connects VNets across different Azure regions.

Peering is non-transitive. If VNet A is peered to VNet B, and VNet B is peered to VNet C, VNet A cannot automatically talk to VNet C. You would need to peer A and C directly if they need to communicate.

VPN Gateways

When you need to connect your VNet to an on-premises network, you use a VPN Gateway. This creates an encrypted tunnel over the public internet. Alternatively, for higher performance and reliability, you can use Azure ExpressRoute, which provides a dedicated, private connection between your on-premises network and Azure.

Troubleshooting Common Networking Pitfalls

Networking is often the most complex part of cloud infrastructure. Here are some common mistakes and how to avoid them.

1. Overlapping IP Addresses

If you connect two networks that share the same IP space, routing will fail. You will not be able to determine which network a specific IP belongs to.

• Fix: Use a centralized IP address management (IPAM) plan. Maintain a spreadsheet or database of all your allocated IP ranges across all subscriptions and locations.

2. Misconfigured NSGs

Sometimes you create a rule that seems correct, but it doesn't work. Often, this is because a higher-priority rule is overriding your new rule.

• Fix: Use the "IP Flow Verify" tool in Azure Network Watcher. It allows you to input the source and destination IP and port to see if a specific packet is allowed or denied, and which rule is responsible.

3. Routing Loops or Dead Ends

If you use User-Defined Routes (UDRs), you might accidentally create a loop where traffic bounces between two appliances, or a dead end where traffic is dropped because there is no route to the destination.

• Fix: Keep your routing tables simple. Only use UDRs when absolutely necessary. Use the "Next Hop" tool in Network Watcher to see exactly where a packet is going to be sent.

4. DNS Resolution Issues

Virtual machines in a VNet need to resolve hostnames. By default, Azure provides internal DNS, but if you have a complex setup with on-premises servers, you might need an Azure Private DNS zone or a custom DNS server.

• Fix: If your VMs can ping each other by IP but not by name, check your DNS settings on the VNet.

Callout: The Importance of Network Watcher Azure Network Watcher is a suite of tools that provides monitoring, diagnostic, and visualization capabilities for your network. Instead of guessing why traffic is blocked, use the Topology view to see your network layout and the Connection Troubleshoot tool to test connectivity between two endpoints in real-time.

Best Practices for Enterprise Networking

When managing Azure networking at scale, follow these industry-standard practices to maintain a clean, secure environment.

Use Hub-and-Spoke Topology

The Hub-and-Spoke model is the gold standard for Azure networking.

• The Hub: A central VNet that contains shared services like firewalls, VPN gateways, and DNS servers.
• The Spokes: Individual VNets for specific workloads (e.g., Development, Staging, Production) that peer to the Hub. This design centralizes management and security while keeping workloads isolated.

Implement Infrastructure as Code (IaC)

Never configure your production network manually through the portal. Use ARM templates, Bicep, or Terraform. This ensures that your network configuration is version-controlled, repeatable, and documented. If a network configuration is deleted or modified accidentally, you can redeploy the entire stack in minutes.

Centralized Logging and Monitoring

Enable Azure Monitor and NSG Flow Logs. NSG Flow Logs provide information about ingress and egress IP traffic through network security groups. This data is invaluable for security auditing and troubleshooting traffic patterns. You can send these logs to a Log Analytics workspace and use Kusto Query Language (KQL) to search for specific traffic events.

Principle of Least Privilege

Apply the principle of least privilege to your network resources. Only allow the traffic that is strictly necessary for the application to function. If a web server only needs to talk to the database on port 1433, do not open any other ports between those subnets.

Regularly Audit Configurations

Use Azure Policy to enforce networking standards. For example, you can create a policy that prevents the creation of any VNet that does not have a specific set of tags, or a policy that denies the creation of public IP addresses in specific subnets.

Deep Dive: Managing User-Defined Routes (UDRs)

While Azure handles routing automatically, there are scenarios where you must intercept traffic. For example, if you want all traffic going from your internal subnet to the internet to pass through a virtual firewall appliance (like an NVA - Network Virtual Appliance), you must define a custom route.

How to create a Route Table

1. Create the Route Table: az network route-table create --name MyRouteTable --resource-group MyNetworkRG
2. Add a Route: az network route-table route create --resource-group MyNetworkRG --route-table-name MyRouteTable --name ToFirewall --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.5.4
3. Associate with Subnet: az network vnet subnet update --vnet-name MyVNet --name WebSubnet --resource-group MyNetworkRG --route-table MyRouteTable

In this example, we are telling the WebSubnet that any traffic destined for the internet (0.0.0.0/0) should be sent to the IP address 10.0.5.4, where your virtual appliance resides. This is a common pattern for "forced tunneling," ensuring that all traffic is inspected by a security appliance.

Security Considerations: Beyond the NSG

While NSGs are great for subnet and interface-level security, they are not the only security layer in Azure. You should also consider:

• Azure Firewall: A managed, cloud-native firewall service that provides high availability and scalability. It can filter traffic based on FQDNs (Fully Qualified Domain Names), which NSGs cannot do.
• Application Security Groups (ASGs): ASGs allow you to group virtual machines based on their role (e.g., "WebServers", "DatabaseServers") rather than by IP address. This makes your NSG rules much easier to read and maintain. Instead of writing a rule for 10.0.1.0/24, you write a rule for the "WebServers" ASG.
• Azure Bastion: Instead of opening RDP or SSH to the internet, use Azure Bastion. It provides secure, seamless RDP/SSH access to your virtual machines directly in the Azure portal over SSL. This eliminates the need for public IP addresses on your virtual machines.

Note: Always favor Application Security Groups (ASGs) over hardcoded IP addresses in your NSG rules. ASGs allow your security policy to move with the virtual machines, regardless of what IP address they are assigned.

Managing DNS in Virtual Networks

By default, Azure provides an internal DNS service that allows resources in the same VNet to resolve each other's hostnames. However, as your network grows, you will likely need more control.

Azure Private DNS Zones

Private DNS zones allow you to manage and resolve domain names in a virtual network without adding a custom DNS solution. You can create a private zone like internal.contoso.com and link it to your VNets. This is an excellent way to maintain a clean naming convention for your internal resources.

Custom DNS Servers

If you have a complex on-premises setup, you might need to point your VNet to your internal DNS servers (like Windows Server Active Directory DNS). You can configure this at the VNet level:

1. Go to your VNet configuration.
2. Select "DNS Servers."
3. Choose "Custom" and enter the IP addresses of your internal DNS servers.

Once set, all virtual machines in that VNet will automatically use those servers for name resolution, ensuring they can reach your on-premises resources by name.

Frequently Asked Questions (FAQ)

Q: Can I change the address space of a VNet after it is created? A: Yes, you can add additional address ranges to a VNet. However, you cannot remove or modify an address range that is currently in use by a subnet.

Q: What is the difference between a public IP and a private IP? A: A private IP is used for communication within the VNet and is not reachable from the internet. A public IP allows communication between the resource and the internet.

Q: How many VNets can I have in a subscription? A: The default limit is 1000 VNets per region, per subscription. This limit can be increased by opening a support ticket, but it is rarely necessary.

Q: Does traffic between subnets cost money? A: Traffic within the same VNet (even between subnets) is generally free. Traffic between peered VNets incurs standard data transfer rates.

Q: Can I move a VNet to a different subscription or resource group? A: Yes, you can move a VNet using the "Move" operation in the Azure portal, provided that all resources inside the VNet are also moved.

Summary and Key Takeaways

Configuring and managing Azure Virtual Networks is a foundational skill that dictates the performance, security, and scalability of your cloud environment. Here are the core takeaways from this lesson:

• Plan Ahead: Always design your IP address space to avoid overlaps and provide room for growth. Use a consistent naming convention for all networking resources.
• Segment with Subnets: Use subnets to logically group resources by tier or function. This is your first line of defense and management.
• Use NSGs and ASGs: Implement granular security rules using Network Security Groups, and simplify those rules by using Application Security Groups. Never expose management ports like RDP or SSH to the internet.
• Automate Everything: Use Infrastructure as Code (IaC) to deploy and update your network. Manual configuration is prone to error and difficult to audit.
• Leverage Network Watcher: Use the built-in diagnostic tools like IP Flow Verify, Next Hop, and Topology to troubleshoot connectivity issues quickly.
• Adopt Hub-and-Spoke: For enterprise environments, the Hub-and-Spoke topology is the recommended pattern for centralizing shared services and security management.
• Monitor and Log: Enable flow logs and monitor your network traffic to detect anomalies and ensure compliance with your security policies.

By mastering these concepts, you transition from simply "putting servers in the cloud" to architecting a professional-grade network infrastructure that is resilient, secure, and ready for whatever business requirements come your way. Networking is the "plumbing" of the cloud; when done correctly, it is invisible and reliable, allowing your applications to run without interruption.